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.
