RE: [Embedlets-dev] New version 1.3 of the Architecture Discussion Document posted in CVS...
Status: Alpha
Brought to you by:
tkosan
|
From: James C. <ca...@vi...> - 2003-02-10 03:22:37
|
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 > > |