Hi All,
Just catching up with my email after the Xmas break and saw this thread.
By way of a clarification on where we've got to with RMI/OSGi
integration in Newton, here's a short update.
My colleague Rob is in the process of putting together a paper to
describe how we can build a specification for RMI and OSGi integration.
This is based on our experience of integrating these technologies within
Newton. We'll be submitting this for discussion to the OSGi forum in the
near future as this is obviously of wider importance for
interoperability in the enterprise.
To date we've been working on OSGi/Jini integration within Newton and
therefore we've had a lot of time to think about how to make RMI and
OSGi work well together. However, our forthcoming paper will be relevant
to any RMI/OSGi solution, not just Jini.
Ok so, where are we in terms of code in the Newton project? Currently we
have implemented a Jini discovery and remoting layer based on the SCA
specification. This entails:
* Discovering services via Java interface from reggie
* Dynamically generating remote codebase annotations (based on OSGi
bundle imports and exports) for exported services/data objects
* Intercepting classloading for Bundled classes for imported
services/data objects to remap into the OSGi peer class loading model.
This allows us to seamlessly publish a remote service, import that
service, and marshal and unmarshal data objects across the service
interfaces, all based on the OSGi bundle specifications.
Areas where we have more work to do, but have partial solutions include:
* Handling multiple versions
* Dynamic installation of bundles based on unmarshal events
* Garbage collection of dynamically installed bundles
The above point on dynamic installation is required to handle the case
where an object is unmarshalled from a remote service but there is
currently no bundle installed in the OSGi container to provide the class
for that object.
Currently we fall back to the standard RMI model where we download the
class from the codebase. However, this can lead to class
incompatibilities if that object is stored in a collection of some sort
and later a bundle is installed that provides this class.
In the long term we need to be more intelligent about this and trigger
the bundle installation lifecycle based on an unmarshal event.
Hope that's of some interest.
Regards,
Dave
Niclas Hedhman wrote:
On Saturday 23 December 2006 09:13, Thor Heinrichs-Wolpert wrote:
It looks to be a very promising project http://newton.codecauldron.org/
Yes, I know that. In fact, even went over to visit Richard, David and the gang
in Londion a few weeks ago, for a first hand demo.
Apparently, they have overcome some of the difficulties, but I got the
impression that they still struggle to do complete transparency and
auto-resolution of classes in the MarshalledObject. If David Savage is on
this list, perhaps he could elaborate what works and what could be improved
on each side of the fence...
Cheers
Niclas
________________________________________________________________________
This email has been scanned by both Message Labs and Paremus internal
systems for viruses and inappropriate attachments. Email suspected of
carrying a virus payload or inappropriate attachment will not be
delivered to you, and the sender will receive an appropriate warning notice.
Paremus Limited.
107-111 Fleet Street, London EC4A 2AB. Phone number +44 20 7936 9098
________________________________________________________________________
________________________________________________________________________
The information transmitted is intended only for the person(s) or entity
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please contact the sender and delete the
material from any computer.
Paremus Limited.
107-111 Fleet Street, London EC4A 2AB. Phone number +44 20 7936 9098
________________________________________________________________________
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
