Re[2]: [platform-core-dev] Reuse registry implementation in 'org.eclipse

[Peter Kriens <Peter.Kriens@xxxxxxxxx>]

Maybe you should take a step back and look at the requirements. It
looks like you think very much in the existing architecture.
OSGi/Equinox will give a powerful component model which might be
suitable for the task at hand but is a possible mismatch to your
current architecture.

I assume (with the little knowledge I have of ERP systems) that you
want run a large number of applications that:

 1. Collaborate
 2. Share and extend a data model (Masks?)
 3. Share and extend common functions (Formulars?)
 4. Share client sessions

It appears that an application would be a bundle in the OSGi model. In
this model, a bundle must be able to use a central data model or in
your case a registry of Masks. The bundle must be able to also provide
functionality which sounds like your Formulars.

The natural model for these interactions is the OSGi service registry.
A service is any java object that you register with the framework with
a set of properties. Other bundles can get notifications or query the
registry for services. This is a very dynamic model that works very
well. It handles dynamics well and one of the great software
advantages is that it uses Java interfaces which are easy to use and
provide type safety. The declarative services remove most of the
overhead. Sharing is also very easy because all objects are available to
all applications (security permitting).

The Equinox registry is different. It is described in XML schema that
belongs to a single bundle. Other bundles can contribute to this
extension point, but they can not directly use the contributors. The
intention of the registry is not so much sharing as well as allowing a
single bundle to define how its plugins should look like.

BJ and Jeff McAffer have explained this better in their presentation:
http://www.eclipsecon.org/2006/Sub.do?id=185

To conclude. It sounds like you have to do some core architecture
design that takes the requirements of your current ERP system into
account as well as the facilities that OSGi/Equinox provide. This type
of architectural work is crucial for a good result, but it is also
very hard because decisions tend to be amplified strongly (bad becomes
really bad, and good becomes, well, good).

So my advice depends. If your company has high expectations of the
OSGi route it should try to get help from an architect that has
designed OSGi based systems; this will be well worth the money.

If your project is just an evaluation project to see if it
might be useful in the future, I suggest to use the time to
get some OSGi/Equinox expertise by building some simple examples
and learning the difference between extension points and
OSGi services.

Overall I think that an ERP system designed OSGi technology is
extremely attractive; ERP systems seem to require a high degree of
extendibility.

Kind regards,

     Peter Kriens



JR> Hello Peter, 

JR> now let me explain why I would like to reuse btw. extend the registry
JR> API for my purposes. IŽm trying to develop a proof of concept:
JR> Mirgrating an erp plattform based on c and odbc to java and some kind of
JR> or-mapping.

JR> The old platform uses 2 basic concepts: Masks and Formulars. Mask
JR> encapsulate one the on hand the data model on the other define the
JR> relation database scheme. Formulars contain the commands triggerd by
JR> some well defined mask actions. Both concepts can be extended and
JR> modified through a module compiler, which makes it possiple for a higher
JR> level application to modify a field or an action of an preceeding
JR> module. (for example: the crm mask extends the address mask). This is
JR> done by a compiler. So if you change a mask, the application has to be
JR> recompiled, application stopped, database scheme adapted and application
JR> restarted. Very tedious and no more bareable in an enterprise
JR> application!

JR> So I came to the OSGi architekture in genereal and the exquionx/eclipse
JR> plugin specially. I would like to use a registry in two places. 

JR> First a registry should keep track of all value objects bound to a
JR> session. These registry will be needed to syncronize the client
JR> application (should be a eclipse (e)RCP gui), to validate, etc.

JR> Second I need to provide some mechanism to make masks, fields and
JR> actions/commands extendible for other plugins. But I dont want the
JR> plugin-developer to define an extension-point for every fragment of the
JR> mask...

JR> So IŽm totaly disconcerted about to manage all things (and probably not
JR> experienced enough). But IŽm sure that equinox would be the absolut
JR> right platform for such an application. Do you some advice?

JR> Regards
JR> ---
JR> Joachim Rosskopf 

JR> Am Mittwoch, den 12.04.2006, 10:13 +0200 schrieb Peter Kriens:
>> Classes that are not exported are implementation classes and should not be used.
>> However, the extension registry is intended to be used. So something
>> looks fishy.
>> 
>> JR> P.S.: Where is the right place to get advice for a design issue with a
>> JR> sever side equinox/OSGi application which should contain of eclipse non
>> JR> gui plugins. Can anybody help me.
>> I'd gladly help out, just send us the design issues you are struggling
>> with.
>> 
>> Kind regards,
>> 
>>      Peter Kriens


-- 
Peter Kriens                              Tel +33870447986
9C, Avenue St. Drézéry                    AOL,Yahoo: pkriens
34160 Beaulieu, France                    ICQ 255570717
Skype pkriens                             Fax +1 8153772599