Peter Firmstone wrote:
Zoltan Juhasz wrote:
Peter,
I am (has been) interested in the Internet use of Jini. There are many
issues as you have noted below. More fundamental is the model of
interaction
between services. Way back I was trying to talk about these issues in a
London Jini Meeting perhaps without much success. There are two main
schools
of thought in service interaction; API vs messaging (aka document) based
models.
Messaging relies on a relatively simple send/receive interface, the real
thing is the content. Services are meant to be intelligent enough to
interpret these messages and deal with them accordingly. In the
networking
world (and also in the Jini community) this is referred to as the
world of
protocols. My personal belief is that these only work for simple and
well-defined services like ftp and the like. If you ask agent people they
will say the opposite I suppose.
The API approach that Jini takes requires up-front design work and
same say
these systems will inherently be brittle. I think versioning is a
problem in
both approaches.
Versioning - Service API is like an Interface, once it is widely in use,
it cannot change, the implementation can, but the API cannot, since it
is installed in the client.
However we can extend service API, just like we can extend an Interface.
Then, new clients utilise the extended Service API, while old clients
continue to use the original, I've suggested the extended service API
jar archive previously, but it's also possible to add any new API
classes to the proxy download codebase. In the old client it will be
loaded with the proxy's ClassLoader, but not utilised (unless the
Service UI uses it), but the new interface won't be loaded by the proxy
ClassLoader at the new client, because the new client has already loaded
the extended Service API, in a parent ClassLoader, since new clients are
compiled against the extended API.
The mailing list [email protected] contains discussion of
"defender methods", which are intended to make it possible to specify a
default implementation for an interface method. A class that implements
the interface without supplying an implementation for the interface
method would use its default implementation instead of being treated as
an error.
With that in place, it would be possible to add a method to an interface
as long as it can be given a default implementation, without resorting
to a new extension.
Does that have any effect on River direction? Do we want to aim for
similar flexibility?
Patricia
