river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Jini and OSGI revisited
Date Sun, 10 Oct 2010 03:29:12 GMT
Michal Kleczek wrote:
> I've sent my message to early...
> On Saturday 09 of October 2010 17:52:59 Michal Kleczek wrote:
>> On Saturday 09 of October 2010 15:54:49 Sim IJskes - QCG wrote:
>>> And downloading a jar? A jar has everything already. Dependencies,
>>> codesigning. Extendable manifest, etc.
>> 2. Dependencies - that is something I am not really sure is needed in OSGI
>> - the service can provide everything that it needs in its bundle and
>> express its public packages (a service interface) as exports.
>> But it seems useful if we don't want to depend on OSGI container - service
>> interface would be provided by a dependency. If the client depends on the
>> same dependency Module (the problem of Module identity is something to be
>> solved anyway - I would go for Java object identity here) there would be
>> no ClassCastExceptions.
>> In OSGI they don't do any harm - it is just that a service can provide some
>> of its code in it's own bundle and some - as dependencies.
> But a Jini service actually consists of two (or more) Modules - a server 
> module and a proxy module. So deploying a service is actually installing two 
> modules (server and its proxy module as a dependency). Objects sent over the 
> wire would be annotaded only by a proxy module.
> Michal

There's an earlier discussion about dependency's on the mail list, what 
we basically came up with:

   1. *-api.jar  - the Service API jar file, it resides in both the
      client and the service implementation node.
   2. *-proxy.jar  - the smart proxy jar file, dynamically downloaded,
      depends on *-api.jar
   3. *-imp.jar - the service implementation.
   4. *-ui.jar - for the Service UI implementation.
   5. *-api-ext.jar - for extending a Service API, can also be
      downloaded dynamically by clients using the original Service API
      only, allowing clients to unmarshall proxy's that support extended
      Service API functionality not used by the client.

See the draft spec on https://issues.apache.org/jira/browse/RIVER-341 
for details, feel free to make comments or suggestions for improvement.

Dependency Tree:

                   Jini Platform
                   Service API (not a requirement to depend on Jini 
          |          |         |         |
   Service Imp     Proxy     Client    Service UI 

I've had some further thoughts about Extending Service API (we may not 
need to have a specially named *-api-ext.jar, see below):

   1. The initial service implementation might be called transport-api.jar
   2. Someone extends the transport service api and comes up with
      bus-api.jar which depends on transport-api.jar (Bus might provide
      some additional features)
   3. Earlier clients only lookup services that implement the transport api.
   4. Bus services will also need to make the bus-api.jar available for
      dynamic download, since earlier clients that lookup transport
      services only might not have bus-api.jar and will need it to
      unmarshall the bus proxy classes, even thought the client doesn't
      utilise them directly via the bus API.

bus-api.jar, when dynamically downloaded, should not be loaded into the 
Parent ClassLoader containing Service API in the client, unless the 
client provisions it itself, under normal circumstances, when the client 
doesn't have the bus-api.jar, it should be loaded into the Proxy's 

If we have a ClassLoader inheritance hierarchy, similar to the 
dependency tree, we'll end up with a ClassLoader tree like this:

        Java System Loader and Extension Loader
         Jini Platform & Service API ClassLoader
          |              |               |        
   Service Imp         Proxy           Client App  
   ClassLoader      & Service UI      ClassLoader

The above ClassLoaders don't represent different class types for 
ClassLoader's but instead just Isolated Name spaces for implementations 
that should remain separate from each other, there may be multiple proxy 
and service implementation name spaces.

So in the above case a Client might embed an OSGi framework, into the 
Client application, being a dynamic evolving environment, the client in 
this case will want to add new Service API, it will need to provision 
the Service API jar files and load them into the Jini Platfom & Service 
API ClassLoader.  If the environment is set up this way, the Client can 
utilise Jini Services from other nodes that know nothing of OSGi.

A Service implementation and it's proxy can also utilise and embed OSGi 
and clients that know nothing of OSGi can discover and utilise them.

The runtime type of classes is the canonical class name + the 
ClassLoader namespace.

The Jini Platform & Service API ClassLoader (and the parent 
ClassLoader's above) represent class types that all implementations can 
use to call methods on each other and be grouped by type.  If we have 
different versions of Service API, we potentially end up with multiple 
types that become incompatible, since they're loaded into different 

In OSGi the service definitions are String's, (service names), so the 
Service type is discovered by name, in Jini the Service definition is 
the serialized from as represented by MarshalledObject.

Service API represent the components that don't change often, rather 
than change Service API, it is simpler to extend or replace Service API.

OSGi is about making software upgradeable remotely, by segregating it 
into replaceable components.

It would be interesting to see how Jini and the Java platform might be 
upgraded dynamically, the above discussion represents my current 
thinking, although it would be interesting to explore the possibility of 
making River and possibly even Java upgradeable also.



View raw message