embedlets-developer

[Embedlets-dev] New version 1.3 of the Architecture Discussion Document posted in CVS...

[Andrzej J. T. <an...@ch...>]

This new version of the Outpost/Embedlets Architecture Discussion 
Document, v1.3, was just posted to the CVS documents dir and includes the 
following new stuff:

- Added optional Security Service
- Added Appendix A: Build vs. Deployment vs. Management Processes
- Added Appendix B: Outpost Management Service and JMX

I'll probably add some of our thoughts/decisions on Serialization for the next go 
round.

Gonna try and do up some preliminary interfaces/base classes this week (if 
time allows) so we can start discussing the actual Embedlet Standard and the 
directions of the first implementation of a compatible Container.

Enjoy!

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

RE: [Embedlets-dev] New version 1.3 of the Architecture Discussion Document posted in CVS...

[James C. <ca...@vi...>]

Andrzej,

Can you clear up a few points for me. I have been reading your changes to
your doc, good work BTW, about the Build Process.

So, in summary we take the XML Embedlet Configuration (Or wiring model) and
autogenerate the code to build the embedlet application this is 'included'
in the build and called by the container to construct the application, ie
Instantiate the Embedlet tree from the XML into a initialisation code.
Ie Create a verbose code version of serialisation? - pseudo Serialisation.

So now I see your advatages
- platforms that don't support serialisation can still deploy the Embedlet
applications.
- Versioning is not a problem

However, Now that I work through it I DEFINETELY! think these should be
interchangeable with platforms that do support serialisation because the
hardcoded serialisation could be a very substantial chunk of code actually.
If this can be done 'off device' where the Serialisation API transforms the
XML Embedlet application into a binary on behalf of the target device then
this is definetely more lightweight for the device as it doesn't need all
this config code. The config code will most certainly take up more FLASH
than to store the serialisation stream for example.

What I would like here is to 'unify' these two concepts because they are the
same thing,

- Pseudo Serialisation ie Build Process Bytecode that implementation
serialisation ie Traverses and builds the Embedlet object heirachy directly
in code
- Serialisation API which 'understands' the target and generates the object
heirachy directly

The end result of both these processes is the internal binary representation
of the Embedlet application generated from the XML schematic representation
which may have been generated from the Wiring Application.

Lets see if we can use them interchangeably pending device capabilities, in
fact lets see if we can't use one to make it easy to create the other.

What might it look like... during the build process

1) We start with the XML Embedlet description of the application
2) The build process generates a configuration ByteCode script, our pseudo
serialisation script
3) Create a Virtual Container ie Our PC Container, and execute the pseudo
serialisation script to instantiate the object heirachy in our PC Container
4) The correctness of the Embdlet configuration is verified by the virtual
container

Now this is where the process diverges.

EITHER the Target has no serialisation API

5) The pseudo serialisation code is inserted into the Container startup
constructor

OR the Platform has a serialisation API

** The developer (Vendor) of the Serialisation API then uses introspection
or system serialisation (on the full blown VM) to generate a serialised
version of the PC Virtual Container contents compatible with their target
platform.
5) The serialised version of the bytecode startup constructor is inserted
into the Container startup constructor

6) The static image is built and targeted for the appropriate platform.


In this way we get the best of both worlds and the also if we provide a
standard reference implementation for the way the Serialisation API
interacts with Container to serialise the application then it will help
other VM vendors with their efforts.

Note: This does not have to be FULL! serialisation - it can be a subset ie
The container only needs to be able to deserialise.

In this way
1) We keep the XML Embedlet Description
2) We keep the build process to autogenerate the configuration code
3) We keep the ability to support non serialise support VM's
4) We add the ability to support serialise enabled VM's
5) We add the ability to strip the configuration code out of the VM making
it more lightweight
6) We add the ability to upload new configurations dynamically into the
container (if they only use the same classes)

Combine this with the XML persistance PropertyBag from my last post, and it
starts looking quite nice :-)

James Caska
http://www.muvium.com
'Java Bred for Embedded'







> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of
> Andrzej Jan Taramina
> Sent: Monday, February 10, 2003 11:42 AM
> To: emb...@li...
> Subject: [Embedlets-dev] New version 1.3 of the Architecture Discussion
> Document posted in CVS...
>
>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> This new version of the Outpost/Embedlets Architecture Discussion
> Document, v1.3, was just posted to the CVS documents dir and includes the
> following new stuff:
>
> - Added optional Security Service
> - Added Appendix A: Build vs. Deployment vs. Management Processes
> - Added Appendix B: Outpost Management Service and JMX
>
> I'll probably add some of our thoughts/decisions on Serialization
> for the next go
> round.
>
> Gonna try and do up some preliminary interfaces/base classes this
> week (if
> time allows) so we can start discussing the actual Embedlet
> Standard and the
> directions of the first implementation of a compatible Container.
>
> Enjoy!
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
>

[Embedlets-dev] RE:[Arch]New version 1.3 of the Architecture Discussion Document posted in CVS...

[Ted K. <tk...@ya...>]

James stated:

>So, in summary we take the XML Embedlet Configuration (
>Or wiring model) and autogenerate the code to build the 
>embedlet application this is 'included' in the build and 
>called by the container to construct the application, ie
>Instantiate the Embedlet tree from the XML into a 
>initialisation code. Ie Create a verbose code version of 
>serialisation? - pseudo Serialisation.

One thing that I have been wrestling with since I started experimenting with
the Elevator challenge was which of the following scenarios made more sense:

A) The Embedlet Container for any given device would be pre-installed on that
device and then the Embedlet application would be deployed into it as a
separate operation.

B) The workstation that was being used to build the application would start
with a default minimal functionality Embedlet Container, have JAPL peripherals
and Container Services plugged into it as needed, have the Embedlet application
assembled and installed into the container, have the system as a whole Unit
tested and then have the complete system (Embedlet container and all) packaged
into the target system's proprietary deployment format and then sent to the
target device.

For a TINI, the deployment file is called a .tini file and it contains an
application's compressed .class files.  The way that a .tini file is deployed
to a TINI is through FTP and one way to execute the application is through
telnet.


So, is the Embedlet Container pre-installed on the target device or does it get
installed with the application?  Are there compelling reasons to allow for both
scenarios?


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

RE: [Embedlets-dev] RE:[Arch]New version 1.3 of the Architecture Discussion Document posted in CVS...

[James C. <ca...@vi...>]

Ted,

These are just different views of the same thing (which is why there is no
silver bullet)

In Scenario A, where the container and all the classes are loaded at the
same time and it makes sense for the application to have a new 'program'
uploaded dynamically then it makes sense to have the container and classes
pre-installed. An examples of this would be a PLC, whereby the classes of
all the 'components' of the PLC are preinstalled and the new ladder logic
diagram is uploaded by serialisation. However, we may be loading more
classes than are needed for all applications but in this instance it is
significantly faster to upload a new 'embedlet configuration' - for one
thing the serialised version may not need to hit the FLASH which means is a
RAM transfer so new programs can be configured almost instantaneously. I can
think of reasons to swap out whole programs' - almost like a thread
transfer - to reconfigure the resource limited device.

Scenario B, where we statically configure requires the more resource
intensive full build process, has to hit the slow flash, but has the
advantage of only storing exactly what is needed and only binding exactly
the classes required.

I think it is perfectly reasonable to support both

Scenario A
* Possibly Non-Optimal class storage requirements
* Fast Serialised RAM Only Reprogramming ~Second(s)
* Minimal programming interface (Serialisation API Only)

Scenario B
* Optimal Class Storage
* Slow Reprogramming FLASH program reprogramming ~minute(s)
* Resource intensive Build process for optimal configuration

Each with advantages and applications.

James Caska
http://www.muvium.com
'Java Bred for Embedded'





> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of Ted
> Kosan
> Sent: Monday, February 10, 2003 9:14 PM
> To: emb...@li...
> Subject: [Embedlets-dev] RE:[Arch]New version 1.3 of the Architecture
> Discussion Document posted in CVS...
>
>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> James stated:
>
> >So, in summary we take the XML Embedlet Configuration (
> >Or wiring model) and autogenerate the code to build the
> >embedlet application this is 'included' in the build and
> >called by the container to construct the application, ie
> >Instantiate the Embedlet tree from the XML into a
> >initialisation code. Ie Create a verbose code version of
> >serialisation? - pseudo Serialisation.
>
> One thing that I have been wrestling with since I started
> experimenting with
> the Elevator challenge was which of the following scenarios made
> more sense:
>
> A) The Embedlet Container for any given device would be
> pre-installed on that
> device and then the Embedlet application would be deployed into it as a
> separate operation.
>
> B) The workstation that was being used to build the application
> would start
> with a default minimal functionality Embedlet Container, have
> JAPL peripherals
> and Container Services plugged into it as needed, have the
> Embedlet application
> assembled and installed into the container, have the system as a
> whole Unit
> tested and then have the complete system (Embedlet container and
> all) packaged
> into the target system's proprietary deployment format and then
> sent to the
> target device.
>
> For a TINI, the deployment file is called a .tini file and it contains an
> application's compressed .class files.  The way that a .tini file
> is deployed
> to a TINI is through FTP and one way to execute the application is through
> telnet.
>
>
> So, is the Embedlet Container pre-installed on the target device
> or does it get
> installed with the application?  Are there compelling reasons to
> allow for both
> scenarios?
>
>
> Ted
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
>