Michael McGrady wrote:
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.
You didn't indicate whether any of these where remote or local, has classloading
capabilities etc. Each layer of the Exporter->InvocationLayerFactory->Endpoint
chain provides a unique point to couple into the JERI "stack". Technically,
Exporter is not in the JERI stack, but I consider it as part of the stack
because for a service, it provides the first layer in how a service interfaces
with clients.
If you want to export a JavaSpace, without JERI (InvocationLayerFactory plus
Endpoint), then technically, you can provide outrigger an Exporter, in the
Configuration, which does whatever you want through the Exporter.export()
returned "proxy". It could use whatever it wanted. I've done this to use
MODBUS as the interface to a device.
But, if you want to take advantage of more of the infrastructure that JERI
provides, then you should code to the JERI interfaces and use existing classes,
such as BasicJeriExporter.
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?
I believe in maximum specificity of what matters, and "generate perfection", and
"tolerate imperfection" as a basic premise to software construction.
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.
I will concure that they can define that a particular type of service is needed.
But, until it has one or more interfaces to its users, it is just
conversational interest because it is providing no value.
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.
Until a technology is applied that lets consumers have access, it is just of
conversational interest, and has no value.
> There is an SLA that the system provides. The system,
consequently, requires that integration logic be decoupled from the
business logic.
Something or somebody has to make the connection or neither can participate in
the system. When that connection is made, a technology is employed. At that
moment, there is value to be had. I don't see how there is a "requirement" that
the integration logic be decoupled from the business logic. What I know is that
at deployment, the implementers of the service had to have enough information
about what choices might be made at deployment to provide a software system that
allows that to occur. That would require them to choose specific technologies
that allowed the choices.
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.
There are lots of ways to get event based communications and I am not sure that
it's a huge impact, but it can drive the design of the software system, as I
said above.
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.
The solutions are discussed, but the actual value is unrealized until they exist
as consumable services.
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.
SOA discussions, for me always go in this direction. I'm a detail person.
There is no value in SOA until you talk about the technologies that you will
involve. Only then can one see and understand the ramifications that each has
on the system. By deferring the discussions of technologies, too long, you
disallow yourself the opportunity to understand the ramifications until later.
I fear that this will typically cause a lot more grief. This is probably more
of my view of bottom up design, which I think is a service oriented view, vs the
old waterfall, top down design view, which I think causes services to be
mis-designed because the details of a service are delayed too long.
SOA, for me is a waterfall, top-down view unless you include technologies in
your view of how the system will function overall.
You can ignore technologies for a while. But after a while, technologies become
the controlling factor in the success of your implementation. This, causes me
to favor early consideration over delayed commitment.
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.
Let's say that you have a business that has a summary item that drives most of
what happens. As part of your SOA, you decide that you need to have a summary
service that will take all the inputs and create the summary item needed.
You talked earlier about SLAs, so I'll guess that you'd like to include an SLA
in the description of the service. What else do you think needs to be included
to understand how this service would be used? Would we consider whether a
database was a useful storage spot? Would we consider whether the database
interface for queries would be the primary point of access, or would we talk
about whether a web interface is needed for human consumption? Would we ask
whether caching was important for speed? Would we talk about whether the
liveness of the cache would be a push or query based refresh? How much detail
would you include? The more detail you go into the more technology choices you
expose right?
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.
No, an SOA has to include people tasks too. If you don't include human impact
and interface issues, you've missed on the largest factor of efficiency in your
system.
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.
This is where I think at. This is why SOA is valueless to me. Details are what
matter and what make things actually work. For me this is the system
architecture because communications is all that matters in an SOA vs a single
process system. If you can't communicate between services and users, there is
no value in the services existance.
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.
Sometimes I guess services and users should communicate... If your SOA has no
communication between services and users, that's fine, but where is the value then?
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.
Maybe you can explain to me what is not antithetical to SOA from your viewpoint?
When you throw out these types of comments with absolutely nothing behind it,
it's very difficult to communicate about the real issues.
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.
Jini service lookup is THE point of "knows nothing about one another". By using
the discovery services, I can find ALL services (not just ones implementing a
particular interface).
There could be a WSDLEntry on a service if I wanted to advertise a SOAP
interface. A proxy service could just look for all WSDLEntry services, and
provide the interface between my Jini service and your SOAP enabled client.
I also could just use Java introspection to find out about a service and then
utilize what is there. But, that doesn't seem like much of an architecture
thing. You said that you look at the interface level. If you have a Java
interface, then you have lots of choices, because the implementation of that
interface can be multifaceted to include proxied services etc.
Client Jini software can use things like ServiceDiscoveryManager to not have to
know how many of a particular kind of service exists, or which one to use for
the task at hand. But, an architectural decision has to be made about whether
something is a singleton or a multiple instance "service" so the client can
utilize the appropriate patterns. To make that plugable still requires advanced
knowledge to make that possible.
What I sense is that you really have a limited idea/concept of how Jini relates
to the solutions you need. I'm more than happy to keep plugging away at the
gap, but I really am having a hard time given the size of the gap that I perceive.
The spec is what you should consider first. That is the behavioral
description of what has to happen.
How so?
It says things about why there are transactions and leases. What those mean in
the system and how you deal with events related to the lifecycle of those items
for example. The API javadoc might say something more or less in line with the
spec documents. Over the years, more spec has moved into the javadocs so there
is more one stop shopping.
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 spec is the SOA level. The interfaces are the technology behind that.
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.
There are both classes and interfaces detailed in the spec. You need to
consider that interfaces have some behavior specified, while classes have
behavior implemented. Outrigger is an implementation of the JavaSpace
specification and associated API. It has behaviors that are not tied to the
spec. For example the spec does not detail storage of Entry objects, nor the
performance of the storage system. Outrigger stores a copy of Entry objects in
memory. This sets an upper limit on the total number of items that can be
stored. It still meets the spec as an implementation in this regard because the
spec doesn't say what it should do for this issue.
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.
If I dereference a classloader, it is unloaded, that's lifecycle management.
from 2.1 in the JSR 291 proposal:
This specification will define a dynamic component framework including component
lifecycle for existing Java SE platforms. The dynamic component model will
support assembly of applications from components and support implementation
detail hiding between components as well as lifecycle management of those
components.
The specification will be built upon capabilities in existing Java SE platforms
and provide a consistent and predictable dynamic component model across the
family of Java platforms in conjunction with JSR 232 for Java ME (CDC).
The specification will enable components to be declared through metadata and be
assembled at runtime using a class loader delegation network. The specification
will also allow components to be dynamically life cycle managed (install, start,
stop, update, uninstall).
This says "existing java SE platforms" so it can't do more that what Java
already provides in class loading.
This says "components to be declared through metadata" and "be assembled at
runtime using a class loader delegation network". It also notes dynamic life
cycle management.
If you look at the APIs there is a world of stuff there. So, yes, in the end it
is more than a classloading mechanism with lifecycle control, but why? There is
more to creating a plugable frame work than running code. You have to be able
to communicate within and out of the framework. It's interesting, but
communications is a solved problem, so I don't look at this as a "value" of OSGi.
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.
If you choose not to decide you still have made a choice...
> 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.
The pressure has been around for a long time. We've talked, blogged, educated,
enhanced and reinvented (Rio, Chiron/Seven, Bantam, Harvester and many other
work simplifying tools). What hasn't happened is everyone jumping on.
I, personally, believe that the problem is ignorance of the problem space and
how Jini facilitates solutions more than anything. Until people really
understand, it won't matter how it's packaged. There will always be people who
don't like a package name, don't like an API, don't understand why there's not a
signature without Transaction etc. All of that requires education.
Now the question, for me, is can we make changes to the "packaging" and the
"experience" when provides the education in a way that makes people hang on and
learn what they need to know?
This is what Niclas and others keep proding and pressing for directly and
indirectly.
I always have liked the explanations given by Thomas Kuhn in Sources of
Scientific Revolution.
Far out in the uncharted backwaters of the unfashionable end of the Western
Spiral arm of the Galaxy, there lies a small, unregarded yellow sun. Orbiting
this at a distance of roughly 98 million miles is an utterly insignificant
little blue-green planet whose ape-descended life forms are so amazingly
primitive, they still think digital watches are a pretty neat idea.
Gregg Wonderly
