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
