Wednesday, February 4, 2009

New CXF SubProject : Distributed OSGI RI

Apache CXF has recently had a new subproject created which hosts a Distributed OSGI Reference Implementation.

David Bosschaert and Eric Newcomer have already posted about it.

I'd like to add few comments.

I think in the todays software world it's not easy to innovate and it's a great achievement indeed for Eric, David, Tim Diekman, Eoghan Glynn and all the folks from various companies who worked very hard and have contributed to the DOSGI-related efforts.

Don't get discouraged by the RPC-ishness of DOSGI - if you do then I recommend you to read this very convincing post.

I do hope to plugin the CXF JAXRS implementation into a DOSGI RI. It's a topic for a separate post, but one can write a perfectly restful yet capable of surviving the changes client code which relies on proxies.

While DOSGI will be perfect for OSGI developers, it will also attract those who are primarily after the promise of OSGI containers to replace modules on the fly in a predictable way - this is one of the reasons people might want to play with DOSGI even though today they may do fine without it.

When a given DOSGI server module will get replaced it would be ideal for the active incoming client requests not to be lost or for clients to get helpful error messages. OSGI can help here. Hopefully future versions of DOSGI will address this fundamental issue. Perhaps we can expect a dedicated (OSGI) service be introduced which will process the pending messages as needed, by either replying properly or saving them to some storage while a given service implementation or a DOSGI bundle itself get replaced.

You can expect a lot of features from DOSGI RI which sits on top of WS-Policy aware CXF runtime.

Please give it a try, contribute and provide some feedback and enjoy playing with this new and cool technology.

2 comments:

Eric Newcomer said...

Sergey,

Thanks very much for the kind words, and for your help with this project, and with the OSGi work in particular.

We have omitted asynch protocols from the initial DOSGi design primarily because of time constraints. But another, related, reason, is that it will take a lot of time and effort to design a workable asynchronous system behind an essentially synchronous model - i.e. OSGi services are based on a Java interface, which is a synchronous design artifact. At least it assumes synchronous semantics.

Sergey Beryozkin said...

Hi Eric - you're very welcome :-)

I agree it'd something which will be non-trivial to do - but hope OSGI will help somehow if such an effort is ever undertaken...

Unfortunately I haven't been involved in the project during the last few months but hope to contribute more again...

thanks Sergey