Anne Thomas Manes wrote:
> A SOA infrastructure [sorry JP, but I think this term is useful] ought to
> support any type of communication style: synchronous vs asynchronous,
> request/response vs one-way, direct connection vs brokered, queued, pub/sub,
> Linda, etc. It's even better if the infrastructure is natively supported by
> most development platforms.
Jini does not lack the ability to support these facilities natively. That's
exactly what JERI provides, a programatic mechanism for creating communications
stacks that follow a spec'd API that can then be plugged into any instance of
Jini.
How is a webservices endpoint for JERI any different from a webservices
endpoint
for "java" from a "natively supported" interface perspective?
> I think this last point is the most serious downfall for J/JS. You had the
> luxury of developing your own communication infrastructure, and you chose to
> base it on J/JS. (I think this was a great decision for you.) Most
> organizations don't have that luxury, though. For them, software
> infrastructure development is not a core competency. So they buy it. And
> because a communication infrastructure is such a critcal component in their
> IT systems, they tend to buy it from solid, stable vendors -- IBM,
> Microsoft, BEA, Oracle, SAP, etc. None of these vendors provide native
> support for J/JS (or any Linda system for that matter).
J/JS is not JUST a communications infrastructure, its a distributed computing
platform which includes a plugable communications stack (JERI).
It seems to me like you're saying that only communications matters. Everywhere
I look, the value added in applications is what they do. The ability to talk
between applications is a big enabler. The ability to optimize that
communications is often a big ordeal. Jini provides better tools for
optimizing
the communications, and the Java mobile code architecture allows communications
to be an invisible part of your system that you can change at will.
When you need to talk an open protocol, you can do that. But when you need to
optimize, that's not a global impact to all attached applications.
I don't see that there is missing functionality to deal with "natively
supported" communications to other entities. It might not exist yet, but
because JERI provides a plugable stack, you can create it, pay someone to
create
it, find it on the internet, or buy it from a vendor.
> I've always been a big fan of Linda, but you must agree that it's a fringe
> technology. It's been around for ever, but never been a part of the
> mainstream. The key advantage I see for using SOAP as the foundation for SOA
> is that *everyone* provides native support for the technology.
The Linda programming model is a broadcast queue mechanism. There are many
different pubsub architectures which provide similar capabilities and which are
in wide use. All the semantics are not as simple, in all variations, but the
basic broadcast bus mechanism is a well known entity.
Many of the implementations have no plugable APIs. There's broadcast ethernet
at the lowest level along with Multicast-UDP. Neither of those have
persistencem, so if you miss the message, ohh well. Above that, we have
software queuing systems built around single APIs such as JMS and Juxta. There
is standardization here, but the complexity of the implementation is visible in
those APIs.
The J/JS mechanism has such few API methods and such simple semantics, that it
is quite easy to create a JERI endpoint/ILFactory to coerce a web services API
into a JERI based invocation.
The software industry has solved most of the trivial software problems that
have
surfaced over the past couple of decades of opensource and community computing
(notes, netnews etc.) Software developers are going to have to learn about
some
new issues and perhaps be in charge of some more demanding views of there
systems than before as distributed computing becomes more wide spread.
This will certainly drive people in the direction of simplifying at all cost.
What the industry has to control is simplifying ourselves into a state of
technology failure. I.e. basing our systems on technologies which fail to
provide the features that we need.
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/
