Read at your peril.
On Dec 23, 2008, at 1:17 PM, Gregg Wonderly wrote:
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.
WINI, XINI, YINI and ZINI are competitors, not users, of JINI.
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.
The problem is that that maximum specificity in matters of standards
is not a virtue but a vice. Minimum specificity is the goal.
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.
Actually in SOA the interfaces are not that important. One of the
great things about SOA is the integration of disparate interfaces with
using triangulate numerals as adapters.
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,
Do you not want to talk about SOA?
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.
Yes. How do you think that happens? There are no connections from
the business logic. When you get what happens, I think you will see
what I am saying.
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.
Then, Gregg, you don't understand SOA. SOA is stateless at the
service level, so there cannot be knowledge of one service, consumer,
producer, etc. of another.
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.
Still SOA is stateless and what you need to see is how different that
is from JINI. I do not mean JINI has no use in a SOA but it has
nothing to do with a JINI service.
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.
Event-based communications also completely decouple integration
logic. There are four kinds of IT communications. They are based on
what values they have with respect to two attributes, viz., whether
the consumer or the producer initiates the communication and whether
the initiator of the conversation (producer or consumer) knows the
address of the other one (consumer or producer). An event-based
communication is initiated by the producer and is unaware of the
address of the consumer. This is why SOAs are event-based.
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.
The genius of SOA is exactly the opposite of what you are saying.
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.
There is no value if you do.
Only then can one see and understand the ramifications that each has
on the system.
The whole point is that whatever they are they do not have
ramifications.
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.
The details in SOA are delayed forever in IT. That is required.
SOA, for me is a waterfall, top-down view unless you include
technologies in your view of how the system will function overall.
SOA is wholly unrelated to the technology.
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.
In my opinion, Gregg, you do not understand system architectures. You
think solely in terms of engineering and pretty much nothing I say
will appeal to you.
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.
SOA architectures are defined at the business level by businessmen
and women.
You talked earlier about SLAs, so I'll guess that you'd like to
include an SLA in the description of the service.
The service really is the SLA. Nothing else matters or is settled,
ever, anytime.
What else do you think needs to be included to understand how this
service would be used?
Nothing.
Would we consider whether a database was a useful storage spot?
Definitely not.
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?
No. None of these.
Would we ask whether caching was important for speed?
No, just read the SLA. That's it.
Would we talk about whether the liveness of the cache would be a
push or query based refresh?
No.
How much detail would you include?
None.
The more detail you go into the more technology choices you expose
right?
No. You don't do that.
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.
You mean a service has to include these. SOA is an architecture and
not an 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.
You really don't understand what SOA is, Gregg. You are talking like
someone who says they don't give a damn about gravity because it is
just a theoretical construct. The questions are way, way, way deeper
and more subtle tthan you are allowing for here.
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?
Users subscribed to or register with services in a SOA. You think
that communication in IT means a connection between the parties to the
communication. That is only true half the time. The other half you
don't understand. I suggest you take on some reading on event-based
communications and anonymous request/reply communications.
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.
Any distributed state. The trouble here, I think, Gregg, is you don't
have a lot and maybe hardly any exposure to architectural principles
in software development. This is not unusual.
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).
We are talking applies and oranges here. Yes, a lookup service should
be decoupled from the applications it is used with, one of the reasons
why I think JavaSpaces is primary to JINI. Normally, however, a
lookup service provides a reference. We definitely don't want that to
happen with a SOA service.
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 problem is not the size, it is the nature of the understanding.
SOA is completely orthogonal to your concerns. I think I understand
the basic architecture of JINI and I like it.
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.
No the spec is not at the SOA level. Businessmen do not design JINI
services based on the spec.
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.
All this is beside the points being discussed, Gregg.
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.
No. That is not true. Did you know that OSGi is used with CLDC?
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.
Like I said, you don't see how systems provide emergent properties.
The code that is written on top of Java matters. Java itself is not
written in Java, you know. This is like saying Java cannot do more
than C. Or, this is like saying that people cannot do more than
molecules or an engine cannot do more than what its parts can do. The
design of the engine makes it possible for emergent properties to come
out of what were just leather, steel, plastic, oil.
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.
Notice the talk about components? Components here are not classes,
they are components.
If you look at the APIs there is a world of stuff there.
Our company is an OSGi member and I am the company rep for OSGi. So,
I have looked at it a bit.
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.
I don't understand this.
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.
I think the problem is that the code is a jumble and needs to be
seriously rearranged and admit that I am not sure how that should be
done just yet. A lot of JINI I definitely want not to have as a
person involved with certain kinds of products. JINI is, frankly, too
good at discovery for many projects.
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.
Packaging Java is not like packaging Christmas presents or naming
kids. It is serious business with serious consequences.
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.
Enjoying talking to yuu, Gregg.
