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
>
>