Warning to readers: this post is pretty much a dialogue between Gregg
and I on SOA and JINI. Not of much interest to others.
On Dec 23, 2008, at 9:24 AM, Gregg Wonderly wrote:
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.
My question was what if WINI, XINI, YINI and ZINI were Java? If so,
JERI would not be involved, for example.
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".
Specifications sometimes are enhanced by creating as much non-
conformance as possible. You have to have MPEGs read one way but they
can be written any way. Standards should be as lean as possible to
let innovation work. Don't you agree?
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.
There is not such thing as a "service, plain and simple". SOA is not
a sudden discovery that there is such a thing as services. Services
are as old as the hills and SOA is not. The type of service in SOA
does not predate SOA. SOA services are defined by business people and
those people do not have to know a single thing about technology to do
that.
A Jini client is a client of a service, but may be a service itself.
A SOA service is a producer, a producer that encapsulates its state.
The SOA producer knows nothing about the consumers: SOA transactions
are stateless. Nothing means nothing. The consumers also know
nothing about the producer: they too are stateless. Nothing also
means nothing here. There is an SLA that the system provides. The
system, consequently, requires that integration logic be decoupled
from the business logic.
Service Oriented Architecture includes no specification of technology.
This depends on what you mean by "specification". SOA requires that
the communications be event-based. That certainly has a huge impact
on 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.
SOA is not a problem. SOA is a solution. So, talk about SOA
certainly should have something to do with solutions.
They might discern that you have particular types of services, they
might learn that you've embraced various details of an SOA.
I don't understand this. Not sure how you can talk about a SOA like
this.
When the rubber hits the road, you have to decide on a technology
that provides the features of your SOA.
This too does not make sense to me. Technologies have nothing to do
with SOA features. Those features are architectural and paper bound.
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.
This is totally unconnected to a SOA.
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.
This all has nothing to do with SOA that I can see.
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.
How are we marshalling with SOA? That does not make sense.
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
Yes, which means that it is totally antithetical to SOA, which does
not mean it is worthless. Just that it is different.
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?
Pretty much everything you said about JINI was confirmation that it is
antithetical to a SOA service and the implied sorts of communications
that must exist between consumers and producers that know nothing
about one another.
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.
How so?
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 JINI spec is an end product. I am interested JINI but am also
interested in a little wider or higher view than the JINI spec.
Interfaces are the leverage points in an architecture. I am more
interested in interfaces.
The services in River are implementations of the spec.
I am not quite sure what an "implementation of the spec" would be. I
do know what an implementation of an interface is. I also know what
compliance with a spec would be.
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.
Dan said he would resign? Sorry to hear that. I don't have time to
read all these posts.
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.
If you think that OSGi is merely a clever way to use class loaders,
you are missing the boat, I think. OSGi provides a lifecycle service
and is a system with emergent properties far beyond a mere class
loader mechanism, which is probably a tautology but a good one.
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).
SOAP today is not the SOAP Microsoft intended. Indeed, the use of
SOAP today is almost 180 degree different than the original Simple
Object Access Protocol intentions.
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.
I understood you and still understand you to say that people go with
or against change depending upon how they assess the suggested
change. I am disagreeing with that. I think most people, the vast
majority of people, will fight against change simply because it is
change with no assessment at all. I am not saying this is bad. It
may be good, right, mete, etc. I don't know. I do know that with the
status quo most people have their part and they don't want the status
quo changed because then they will have to reinvent themselves. I
would be amazed if the conversation in River went different than it
has. Here is a technology with great promise that is on the edge of
distinction and will have to be reinvented from a different direction
if it does not succeed and it is not responding to this pressure on
the whole. This is normal.
I always have liked the explanations given by Thomas Kuhn in Sources
of Scientific Revolution.
