river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Towards Internet Jini Services
Date Thu, 30 Sep 2010 11:26:21 GMT
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: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
>>
>>
>>     
>
>
>   


Mime
View raw message