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 06:17:00 GMT
Peter Firmstone wrote:
> 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:
>
>                       Java
>                         |
>                   Jini Platform
>                         |
>                   Service API (not a requirement to depend on Jini 
> Platform)
>           ______________|_______________
>          |          |         |         |
>   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.
>
> Notes:
> 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 ClassLoader.
>
> 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
>                    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 ClassLoaders.
>
> 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.
>
> Cheers,
>
> Peter.

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
                 ClassLoader



Mime
View raw message