Playing catchup on some older messages regarding Avalon 5 and the embedded container space. So pardon the long post....
Berin said: > It is clear that cell phones and PDAs really should not be our > focus--even though we *technically* could support them at the > interface level. The constraints of such devices would prove too > limiting for our purposes. I agree with this sentiment. Though a good embedded container spec should provide support for such devices without much trouble. > PersonalJava and CDC + PersonalProfile. > Would this plan satisfy the requirements of the J2ME users out there? I think it's a mistake to try and target any specific profile (PJ, CDC/PP, or even J2ME), since many embedded devices may not comply with any of these, and there is too wide a variation of contstraints/capabilities across the whole range of embedded/personal/mobile devices. I would humbly suggest that a better approach would be to use the profiles as a "validation test" that Avalon 5 can support the widest possible range of such devices, but to architect Avalon 5 so that it is highly modular in nature. What I mean by this is that a container developer should be able to pick and choose from various parts of Avalon 5 independently of each other. For example, you should be able to choose whether you want to use the Avalon Logging framework pieces...or not, without impacting other Avalon framework elements that might be attractive for that specific container implementation. This level of modularity should especially extend into the configuration area. For embedded devices the config will most likely have to happen statically rather than dynamically. So the Avalon 5 framework should be flexible enough to allow for the creation of a config/assembly process that would read XML descriptors, and then code-generate the underlying hardcoded config data structures/objects that the container would need, thus eliminating all need for XML parsers/generators at run time (at least as far as configuration is concerned). ----------------------------------------------------- Sylvain asked: > >Per a prior email of mine, Avalon would be VERY useful for embedded > >controller devices (such as manufacturing process control)...in fact, there is a > >sourceforge project that is spinning up to do just that. It's aims are to make > >embedded programming and integration with enterprise systems (eg. J2EE) > >easier. Think of small footprint servers.... > > > > > > Is this project http://ichilli.sourceforge.net/ ? Nope..that is a different project. The one I am thinking of is the Outpost/Embedlet project that can be found at: http://sourceforge.net/projects/embedlets/ ---------------------------------------------- Berin then comments on config generation: > The major difference between the Avalon ME (for lack of a better > name) and the regular container is that ME will be static--the > classes needed for running the container will be pregenerated. > > No. We interpret it at build time, and provide generated helper > classes that the ME runtime uses. I.e. we trade run-time discovery > of components and component metadata for compile-time discovery > of components and component metadata. I think that how the config of a container is done should be independent of the framework. The config can be specified by XML as it is usually done. For an embedded environment, there would be an extra code-gen/compile/assembly step that would generate any required classes/objects/data structures. But regular containers could implement dynamic config the way they always have done. This approach would provide maximal compatibility between the embedded and enterprise containers based on the Avalon 5 Framework, yet still address the unique needs of both. For an embedded container, this would come at the expense of some extra work/development of a "config tool", but I feel that is a very reasonable approach. --------------------------------------- Stephano raises a concern: > But say that the JCP comes up with the concept of metadata built into > Java 1.5 (Avalon will need that in the future) but they decide, for > simplicity and cost of implementation, to leave this feature out of J2ME. > > What do we do? ignore a nice feature that 90% of our users would love to > have because it's not available on J2ME? Using the above approach, it should be possible to use a post-compile step to generate equivalent functionality (if required) for embedded containers (note I am not saying J2ME containers very deliberately, since I think that is too restrictive per my earlier comments). Or if the Avalon 5 spec is modular enough, enterprise containers would be able to adopt the new feature, and the embedded containers would just choose to not implement that particular part of the framework. The key here, in my opinion, is to walk a fine line ensuring that the framework itself is dependent on as few constructs as possible (the ultimate in decoupling?) That is don't assume RMI is available, nor XML parsers, reflection...etc., and instead wrap these building blocks in modular constructs that can be selected independently by the container builder. ------------------------------------ Finally, Peter comes up with a good observation: > It would be genuinely useful and I don't think it would freeze progress for > the simple reason that a AvalonME version would be completely separate from > main tree. Mainly because of completely different architecture required to > accomodate the limited resources. It might be a bit tricky, but I think it should be possible to avoid such a split of the code base to a great degree per my comments above. And I believe it would be very beneficial to both enterprise and embedded arenas to ensure that there isn't a "split" into two distinct specs, but to craft a flexible enough spec that can suit both extremes. > That said I can't see any of the current committers stepping up to do it > properly as none of them know it well enough and no-one does it in their day > job. However - hopefully Andrzej will be able to provide an embedded > container which we can point at. That is the plan! Assuming that Avalon 5 makes sense as a foundation for such work. ;-) Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
