river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: Split JavaSpaces and JINI
Date Tue, 23 Dec 2008 17:24:44 GMT
Michael McGrady wrote:
>> There is the expansion point provided by JERI which allows the 
>> invocation layer and transport layer to be non-java centric.  This is 
>> where WINI, XINI, YINI and ZINI need to be interfaced.
> 
> What if they are Java?  Would you still say this?

Yes, all Java applications can and should interface to other Java applications 
using JERI if they want to participate in a distributed systems environment, 
based on the principals of the Jini specification.  It's because this layer 
provides the standardization for invocation and transport that I say this.  It 
allows for a SOAP stack or any other invocation layer to be plugged in so that 
Java objects go in and out of the users (clients and servers) environment.

For Java software, the JERI stack codified in River, provides the ability to 
plug in the needed invocation details (starting at the BasicILFactory point). 
The Exporter allows this invocation layer and an endpoint technology and 
security constraints to all be unified into a single point that allows them to 
be plugged together and arranged to work as needed.

>> Why?  Because the spec has semantics in it too, and those semantics 
>> (like RMI call-by-value) need to be supported at the Java interface 
>> level for a Java written Jini bit of software to be compatible with 
>> other Jini bits of software.
> 
> But, is this good or not good?

The specification of anything that is a standard narrows the path for 
non-conformance or other forms of confusing that create the need for "work 
arounds" or "better solutions".

>> In the world of SOA, there are all these concepts, but they are 
>> described independent of a technology, and they are honestly more akin 
>> to "best practices" than they are as "architecture."
> 
> I definitely do not agree with this.  First, comparing SOA and JINI is 
> comparing applies and oranges.  A SOA service is nothing like a JINI 
> service.  SOA definitely, to my way of thinking, is an architecture. 

A Jini service is a service, plain and simple.  A Jini client is a client of a 
service, but may be a service itself.  Service Oriented Architecture includes no 
specification of technology.  What this means is that you can talk about SOA all 
you want, and in the end, that conversation is valueless in terms of solutions, 
because it doesn't let anyone know how they might actually get work done in such 
your SOA.  They might discern that you have particular types of services, they 
might learn that you've embraced various details of an SOA.

When the rubber hits the road, you have to decide on a technology that provides 
the features of your SOA.  Some of those technologies might be things like pens, 
postit notes, white boards, projectors, chairs, tables etc.  Which are services 
to their users in that they allow certain tasks to be carried out using the 
specific mechanical interfaces that they provide.

But when you get into the realm of software, then you have to decide what will 
be the pen (invocation layer), ink color (marshalling technology) and paper 
(transport layer) of exchanges between software bits.  These decisions dictate a 
lot of other things about what the software can do with the other entities in 
the system.  So, many people end up with a custom, combined invocation layer and 
marshalling layer that hide SOAP/XML or whatever technology they've decided on.

As soon as you do that, you've effectively wrote off all features of the IL and 
marshalling that you don't expose in that layer.

This is where Jini differs.  With Jini, that IL and marshalling is completely at 
your control.  It has exact details specified in simple terms.

At the method layer:
o	all methods throw RemoteException to indicate a problem in the
	IL or endpoint mechanics.
At the invocation layer:
o	method values are passed by value always.

There are other things about security constraints which can change some of
the types of RemoteException which will occur, but still, you get a RemoteException.

All of these we know will always be present in a Jini system.  So, we can be 
very deliberate and very specific about how to deal with the problems that can 
occur.

 > It
> means "Service-Oriented Architecture" which is not dispositive but is a 
> strong hint or something has gone very wrong.  JINI is really not SOA 
> oriented at all.  It has uses which really interest me but SOA is not 
> one of them.

Okay so with my explanation above of my view of Jini, how would you clarify your 
view that Jini is not SOA "oriented".  What features of Jini keep it from 
working as a client and service creating technology?

>>   With the Jini spec, came the codification of so many important and 
>> related concepts which are all about making distributed systems be 
>> resilient and robust.
> 
> I believe the JINI spec came out of the concepts rather than vice 
> versa.  I remember well when JINI rolled out in the traveling Sun 
> shows.  I have been a JINI fan for a while, even if not a user.

The Jini spec was created as reverse engineering exercise I believe.  It just 
means that it was codified as a text document after the concepts where codified 
in software.  Jini still existed as a concept, no matter what its representation 
was.

>>> JavaSpaces, in my world, wants its Entry, Transaction, etc interfaces 
>>> in JavaSpaces so that JINI must compete with WINI, XINI, YINI and 
>>> ZINI in using the JavaSpaces.
>>
>> Make sure you are staring at what is presented as the JavaSpace spec, 
>> and not what outrigger is doing in exporting a JERI endpoint which 
>> uses BasicILFactory...  Any external entity can use JavaSpace if it 
>> has access to an invocation environment that allows it to.  JERI 
>> allows plugability so that others can get in, without being Java even.
> 
> I have said this before but I will repeat it again, I only look at the 
> interfaces when thinking about a system.  The implementation is not of 
> particular interest to me.

The spec is what you should consider first.  That is the behavioral description 
of what has to happen.  The interfaces, which exist today, are one way to do the 
things that the spec details.  No other implementation has appeared with a 
different API, so the net.jini stuff has sort of become what some thing of as 
Jini.  I consider the net.jini interfaces to represent a Java codification of 
the spec, but not necessarily the only one.  It wouldn't be great to have lots 
of different version of the same interface running around which supported the 
same spec behavior, but used entirely different types etc.  So, certainly the 
existing net.jini definitions of classes and interfaces are what meet the spec 
and provide a portable platform.

>> The services in River are implementations of the spec.  They are not 
>> the only way to do that and they have a particular orientation toward 
>> working together and utilizing each other for a combined system that 
>> presents all the concepts of the Jini specs as a unified distributed 
>> systems toolkit.
> 
> So far as I can tell, as yet there is no River, i.e., that it is being 
> created.  Exciting stuff!  I realize it comes with a history.

 From a simple perspective, River is the JTSK, which has been started as a 
podling at Apache.  It works, does what a lot of people need, and presents 
challenges from all the perspectives that Dan and Niclas have been going back 
and forth about, as well as others (I have mentioned some that I perceive).

So we have to graduate...  That doesn't mean a particular set of changes must 
happen to the codebase.  It means that we have to graduate...

>>> What to do?
>>
>> Realize that your world has a non-zero intersection with other peoples 
>> worlds in terms of what "features" you want your distributed 
>> application to have.
> 
> This says that my world intersects with others' worlds.
> 
>> When there is distinct value in a change, people tend to agree or 
>> gravitate toward that change.
> 
> Not according to my experience.  Generally speaking they show their 
> calcification in my experience.  Socrates might argue the point.  So 
> might Kepler.  Ever hear people talking about modern art?  Notice how 
> readily each generation of adults so gladly accepts the new living 
> styles of the youth?  The new music that new generations bring is 
> especially hated.  We still talk about affairs of the heart using an 
> analogy that was broken so long ago and so bad that it bogles the mind 
> it could have any currency.  No, I cannot say I agree with this at all.  
> And that is okay by me.

I said gravitate, not move.  Society goes in a direction that the minority push 
the hardest towards which has the least resistance of the majority.  Resistance 
is changed by informing people, enacting rules to remove the right to resist, 
hiding the reasons to resist etc.

The value proposition is not the only reason things change, but in software, 
value has a number of perspectives.  For example, Dan said he would resign as a 
committer if it was decided to focus on a local only javaspaces and jini 
infrastructure.  That would create change, but not as a value.  Instead, it 
woudl be a "removal of resistence" more than an agreement to change.

> Let me mention that OSGi has taken 10 years to get where it is and the 
> big breakthrough was when it was adapted by Eclipse.  JINI is no 
> youngster either.  There are lots of technologies started in the late 
> 1990s that are just coming around.

OSGi had lots of problems and incomplete bits and pieces.  It was a concept 
which need lots of refinement.  By the time all is said and done, it will not be 
much more than a restatement of the rules and API of Java classloaders expressed 
as a textual description of what one would code.  Does that make it valuable? 
I'm sure many, who don't understand what happens in the trenches, how things 
relate and what things must be done, will feel fine to use OSGi, because it will 
create appropriate limits and controls to cause them to do things largely, 
correctly.  But, it will present limits on the total possibilities, or it will 
just be re-expression of the Java language constructs that one can program class 
loading and container systems with today.

> I watched business computing go from mainframes, batch processing, 
> databases, visicalc, R/2 SQL, R/3, data warehouses, www, EAI, BPM, 
> packaged applications (CRM, SCM, ERP), MDA and did not see this march of 
> reason you suggest.  It was always emotion and based on fear and 
> entrenched positions.  The same happened with distributed technology 
> going from VT100, VT3270, client/server, TCP/IP sockets, RPC, NFS, 
> CORBA, stored procedures, EAI, MQ, EJB, SOAP, WSDL and there was no more 
> ease of transition.  Not at all.  The same things happened going from 
> Assembler, COBOL, SIMULA, Pascal, Modela 2, Smalltalk, Ada, PROLOG, C++, 
> Java, and C#.
> 
> Now that we are entering the age where the Ilities are supreme and the 
> realization that they are best handled by a good architecture rather 
> than a post-architectural workaround, the howl of the Greek chorus 
> continues unabated.
> 
> Well, at least that is how I see it.  I definitely did not see any easy 
> transitions on anything at all.

What happened in the past was that companies like IBM (hardware) and EDS 
(software) ran huge businesses that needed to make very large amounts of income 
to survive.  The costs of their goods and services was perceived as unavoidable 
due to licensing, embedded capital expenditures etc.  They drove the 
technologies because they dictated what got used.  Open source software, 
simplifying library packages etc have lowered the bar for what you need to know 
to create your own solutions.

SOAP is microsoft trying to say "we are open" while still maintaining control. 
They drive hard to make their software systems a standard because governments 
around the world are demanding open standards (as you stated).

>> When there is a lot of discomfort in a change people tend to push 
>> back.  Discomfort comes from more than "that's the name it's had for 
>> years" in this case.
> 
> For what it is worth, this also is not my experience.  That is plenty 
> reason for most to push back.
> 
> Not all of course and no one in River for sure. Also not anyone that 
> lives within 100 miles of me.   ;-)
> 
> I hope you accept all this with a pinch of salt but I do definitely not 
> agree with your statements about how change is embraced in the world.  

Again, I didn't say change was embraced, I said value was embraced.  Sometimes 
that creates change as people gravitate in the direction of making use of a 
perceived value.

Gregg Wonderly

Mime
View raw message