Harm Smit wrote:
> > The pieces I think we ultimately will find lacking though,
> > *are* found in Jini, no WS-* at least for the foreseeable future.
> > (Patrick Logan)
>
> > This is the most predominant reason why I absolutely refuse
> > to jump on the webservices bandwagon. With Jini/Java, I am in
> > control of my architecture.
> > (Gregg Wonderly)
>
> It's flabbergasting to see that some people obstinately refuse to
> understand the value of platform-neutrality. The essential motivation
> for WS has always been universal interoperability, irrespective of
> implementation technologies and platforms. It simply makes no sense to
> compare Jini and WS-*, they are not in the same ballpark.
There are some interesting issues about what is what when talking about Jini vs
WS. Jini is a platform that includes many technologies for building
distributed
systems. One aspect of these technologies is the use (no, exploitation) of the
RMI programming model to capitalize on mobile code. In Jini 1.X, there was no
choice but to use JRMP or JRMP-IIOP for transport. Plain and simple, there was
essentially no choice.
With Jini 2.0, the Jini Extensible Remote Invocation part of the platform
provides a pluggable transport and invocation layer. This means that non-java
environments can be integrated with Jini by simply providing an appropriate
implementation of the part of the stack that you need for integration.
You can provide a WS transport, if you want.
My argument is not about whether or not to use WS. My argument is about
whether
or not to use WS as the BUS/ESB for your SOA. By choosing it as your BUS/ESB,
you get to live with its limitations, plain and simple.
Whether you choose WS, Jini, Modbus, MPEG-4 or Semaphores, you still have to
integrate legacy systems. The question is not about whether you can do that
with web services. The question is when you do that with web services, are you
getting everything you need in your SOA.
For some systems, mobile code is not needed. For others, that are growing and
changing, mobile code can provide a dramatic capability for managing that
change
in terms of local vs remote computing and redistribution and/or conglomeration
of services. Without mobile code features, you'll have to orchestrate and make
changes with synchronized complexity to all affected systems in many cases. In
some situations, you can just tack another element onto your XML document.
This
is the "virus" of XML programming.
> One of Jini's
> basic assumptions is that everybody adhere to the Java religion, and
> those who don't (some would say "the infidels") are out of luck.
No, the assumption of Jini is that mobile code is powerful. The JERI stack
does
not make it necessary though. I have prototyped, on paper a Modbus endpoint
which allow me to make method calls which would then perform modbus operations
to a remote site.
The client has no idea that they are talking directly to a modbus enabled
device. But, I could later replace the client endpoint with a standard
endpoint
that talked to a delegate service which might optimize and cache access to the
modbus device as part of scaling the service.
> One of
> the basic assumptions underlying WS-* is that nobody is in control of
> other peoples' architectures and religions, yet all parties want to be
> able to interoperate. Quite obviously, this platform-independence
> constraint inhibits the use of features that are bound to technologies,
> such as mobile Java code. But having such a neutral middleground is the
> conditio-sine-qua-non for any sort of wide-scale adoption.
Not in my view. It gives you a chance to do something like what we experience
with the web. However, the creation of the web has diminished the visibility
of
"the internet" and now, most people think that there's only one port in the
world, port 80.
I don't want to get into a portability independence of vendor argument. I will
only state that you are never, ever independent of a vendor, a technology, or a
protocol. Instead, you can only balance the benefits that you get from a
technology against the investment you have to make to use it.
> A simple example. I'm involved in the WS-enablement of devices of all
> kinds, using the Devices Profile for Web Services. Such devices can be
> integrated in all sorts of WS environments, MS Longhorn/Vista, IBM
> WebSphere, SAP NetWeaver, ... you name it. There is no chance we could
> ever have achieved something similar using Jini - not because Jini is a
> bad technology, but because its technology bias gets in the way of
> widespread acceptance.
It is an outright lack of understanding of what Jini is and what Jini can do
that persists such outlandish assertions. Jini is dependent on Java, much like
websphere is dependent on Java. Beyond the basic issue that you have to run a
JVM to run the "tool set", there is no other dependency on Java. Jini enabled
services are Java based applications. But, their exported interfaces don't
have
to be dependent on Java.
I will assert that there are distinct advantages to creating a Java based SOA
that directly uses the native protocols in the JERI stack as well as using the
built in distributed Leasing and Transaction services.
But, the JERI stack and proxy/delegating services all provide mechanisms for
neutralizing any particular vendor's protocol.
Your statements, similar to others who are ignorant of the JERI stack and the
pardigms of programming associated with its use, will, when examined in
isolation, provide plenty of negativity toward using Jini.
> Sorry for explaining the obvious. Communication protocols have always
> been platform-agnostic, making them depend on a programming language is
> simply a heresy...
I need to ask what programming language you programmed your WS-enabled device
profile solutions in. Are you not dependent on that programming environment,
its vendor, and the lifecycle of that product? How is that dependency any less
of a problem than your dependency on a particular protocol that is used between
your devices and the other end? Where did you invest your time, expertise and
money? I'd suggest that the protocol is the cheapest investment that you can
make.
If you have to reimplement the same thing over and over, its expensive. The WS
standards provide for interworking. But so do all the other documented
protocols on the planet. The question is, what are the benefits and
limitations
of chosing to use one protocol vs the other. You can buy an implementation of
a
MODBUS library today, and it's a standard. You can get an implementation in
any
language that exists for a modbus server and modbus client APIs.
The fact that it's not widely used for enterprise applications is because it
has
limitations. There are 100's of proprietary extensions to it that plaque the
embedded devices/SCADA marketplace. If someone says that have a modbus device
that you can talk to, you have to ask questions to find out what that means.
The WS protocols are such a shell, that I see the same sort of thing happening.
There will continue to be refinements. That means that different vendors
will
have different versions of the stack at different times. The features that are
being added are things like compression and security.
Jini already supports security using the Java security model with plugable
authorization so that you can use PAM, Kerberos, X.5xx, or anything else you
need.
The whole compression (or binary XML) thing is just a reflection of a weakness
associated with the on size fits all mentality of XML over some-such-transport.
JERI and the RMI programming model through the use of mobile code allows you
to solve your data transport problems in whatever way you need, and to change
it
dynamically.
So, my question is, where do you want to spend your time and your money? Do
you
think that the benefits of a standard messaging protocol is such an
overwhelming
gain that you should throw away all of the tools that are in Jini?
Is communications the hardest, most difficult problem that you solve day after
day? What about security, leasing, transactions, distribution of updates etc.
Is it not more likely that you'll deal with the communications protocol once,
and then have to work on managing these other issues day in and day out?
I guess my experience is that I set up COMMs once, and then have to worry about
these other things when adding features to my software. Jini provides me tools
to manage these complex issues, including communications more effectively. My
software talks to people and to embedded devices, neither of which speak XML
natively.
Gregg Wonderly
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
