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
