river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zoltan Juhasz" <juh...@irt.vein.hu>
Subject RE: Towards Internet Jini Services
Date Wed, 29 Sep 2010 08:26:24 GMT

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

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. 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. 

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.

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.


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:jini@zeus.net.au] 
> Sent: 25 September 2010 10:42
> To: river-dev@incubator.apache.org
> 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

View raw message