Warning - what follows is mostly a bit of fun concerning Gregg's idea
that good changes are welcomed generally. It is not worth reading
unless you have time to burn or are Gregg.
Mike
On Dec 22, 2008, at 1:59 PM, Gregg Wonderly wrote:
Michael McGrady wrote:
JINI, in your world, wants Entry, Transaction, etc interfaces in
JINI that multiple services employ so these services are JINI
services.
Well, Entry, Transaction and Lease, are core concepts to the
distributed computing model that the name Jini is tied into.
Agreed. They are also core concepts in JavaSpaces.
These are "facilities" that allow clients/services to have advanced
notice of how they will interact with others.
For JINI, which certainly is interesting and powerful. My interest is
elsewhere at the moment and more JavaSpaces oriented.
This includes a number of concepts from a number of different
perspectives. There are the API signatures, which spell out what
values and types are understood by both ends. There is the Jini
spec, which details what each "operation" needs to make happen for
the things that the API represents from the Jini spec. There are
failure mechanisms that you have to support in your client so that
you can take advantage of knowing that something is not working.
It's important to understand that with Jini, you have a platform for
remote, distributed computing that doesn't leave you wondering about
how you will interact with other clients and services that use Jini.
I understand the value of JINI and also appreciate your small
tutorial. More learning is usually good. My concern, however, is
whether or not the architecture vis-a-vis JavaSpaces and other
services makes sense.
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?
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?
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.
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.
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.
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 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.
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 think most people like to work on known problems. Few have the
stomach or interest to really get down into the engine room and make
changes. People generally seem to hate change. Those that enjoy
trying to solve problems in a big way have to dedicate themselves to
the task because others always push back. This is not a bad thing, I
think. This is probably the way it should be. But, I really don't
think it is not this way as you do.
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.
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.
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. One last thing, "heaven" ("sky" in the original Koine Greek -
euranus) was known as firmament because, not knowing about gases and
such, the ancients figured there was something solid up there.
Understandable back then. No trouble changing that was there? To be
more mundane, a good read on the acceptance of the railroad in Britain
is very interesting.
Who was it that said that there would be use for at most about 10
computers?
Mike
