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.
So versioning isn't a problem for Service API, like it is for protocols.
Versioning does need to apply to the proxy implementation, so objects
are unmarshalled with the correct classes. This should be invisible to
the client. Dennis Reedy has suggested we add the version to the jar
archive name, I think it's a good suggestion.
So now implementations are free to change, if Service API is completely
interface and jvm platform based, then we are also not tied to the
Serialized form of our implementation classes, different version
implementations only need to be compatible via the service API, every
thing else is free to change.
When we break up the components this way the versioning problem goes away.
That is why someone said Jini meant the end of protocols, I suspect.
What is more interesting in the API approach is that
inherently we imply the 'RPC' like invocation semantics. Instead of asking a
service to do something, we command it to execute the required
functionality. It is sometimes non-trivial to come up with service
interfaces that can be acceptable for a large user population. If we move
towards a messaging flavour with Jini, service discovery becomes (almost)
obsolete, at least in the Jini sense of services.
Yes we do need to determine some more Service API's, although I don't
think we should distribute them with the River release.
For User interfaces, ServiceUI is the interface, all you need is a
JFrame window,
So what I'm trying to say is that in the new world of SOA where everything
is a web service (or REST service???) we need to define and position Jini.
We have to know whether this is a competing or complementary technology. I
got many negative remarks on our previous Jini-based grid work that although
it was great it was Java-based and interoperability with other languages and
web services was so crucial that without giving support you're dead. I don’t
see how you could have these working together.
I don't think we're competing with SOA web services, the two can
co-exist, but it would be fun to do things they can't, so I'd call it
complementary, like flash. But we can also exist in our own universe.
A SOA web UI could be a Service UI implementation I suppose, in this
case the Web server would be the Jini client. A Java Applet could also
be a client.
Non JVM languages can't play the full field, they can be part of the
game, by providing services, but they cannot be clients.
Cheers,
Peter.
On the technical front, remote invocation semantics is an issue (do you give
guaranties for execution), or how to prevent error propagation during a
service call sequence - and execution breakdown. Transaction may not be the
right model for Internet scale distribution execution either, and
unmarshalling and object movements may help DoS attacks to happen, etc, etc.
I'll think about it a bit more and come back with issues. Let's discuss
where Jini should be heading on the Internet.
Cheers,
Zoltan
=================================
Dr Zoltan Juhasz
Dept of Electrical Engineering and Information Systems
University of Pannonia (formerly University of Veszprem)
Veszprem, Hungary
-----Original Message-----
From: Peter Firmstone [mailto:[email protected]]
Sent: 25 September 2010 10:42
To: [email protected]
Subject: Towards Internet Jini Services
Who's interested in Internet based Jini Services?
River is a Jini platform implementation, Jini's the Standard.
Currently Jini is most suited to private networks, it has
advanced tools for dealing with security issues like
integrity, privacy, identity and authorisation, however there
are some gaps before the realisation of internet based
services is possible.
Interesting areas of research:
1. JERI Endpoint's for Traversing Firewalls (Like Sim's Mekong)
2. Dealing with Dynamic IP.
3. Discovery of Registrar's from the Internet. (DNS-SD)
4. Standards for River's Jini Service Jar Archive Names
<https://issues.apache.org/jira/browse/RIVER-341> (River-341).
5. Clients ability to deal with massive lookup result sets, without
having to download all their jar files. (Similar to
Gregg's use of
delayed unmarshalling)
6. Automating ClassLoader tree's so that Java, Jini Platform and
ServiceAPI are loaded into Parent ClassLoader's, while
applications (containing clients and service
implementations) are
in child ClassLoaders separate from smart proxy's loaded into
individual child ClassLoader's, to remove the problems
developers
experience with ClassLoading. All cooperation communication
between objects occurs using Service API and Jini and Java
platform classes.
7. Distributed Object Registry, for long lived object that move.
8. Security Improvements for trust, monitoring behaviour, stopping
and reporting incidents of breaching trust.
There are of course other areas in River requiring attention,
like concurrency and design improvements, bugs, tests and
build improvements.
What are your thoughts?
Peter.
_____________ NOD32 5482 (20100927) Információ _____________
Az üzenetet a NOD32 antivirus system megvizsgálta.
http://www.nod32.hu
