|
Gregg,
> The Jini Configuration mechanism in concert with the JERI
stack
> provide a great mechanism for deciding transport
at deployment.
>
I agree with this design approach (I am wondering, if my
earlier post left
an an impression, that I am recommending
transport binding at a stage
earlier than deployment?)
> You can just plug
your appropropriate transport into the configuration
> and go. This is
one level of abstracting that many SOA architectures
> completely miss out
on.
>
Some SOA Architectures (and certainly Fiorano's) supports
exactly this.
So, I must say that not all SOA architectures are "missing
this".
> I think it's very short sighted to say that ESBs will be
based solely
> on WS-* technologies.
>
Once again, I agree completely! (and I am again not sure how
you got
an impression that my definition of ESB, restricted ESB to
WS-*).
Just because a service INTERFACE can be represented by a
WSDL,
it does not imply that the ESB should limit the invocation
semantics
to those limited to WS-* or SOAP....
For e.g., even though Fiorano SOA Platform 2006, exposes each
configured "Service Component" as WSDL, it still allows
multiple
such Services to participate in a single ACID (distributed or
simple)
transaction - without necessarily having to go over the WS-*
semantics.
Thanks,
Amit Gupta
Fiorano Software Inc.
----- Original Message -----
Sent: Wednesday, January 11, 2006 11:16
PM
Subject: Re:
[service-orientated-architecture] RE: Basics
Amit Gupta (FSI) wrote:
> Service
implementation should not use "transport specific" API's, so that it
remains
> completely agnostic to transport used for delivery/invocation
of the service.
The Jini Configuration mechanism in concert with the
JERI stack provide a great
mechanism for deciding transport at
deployment. You can just plug your
appropropriate transport into the
configuration and go. This is one level of
abstracting that many SOA
architectures completely miss out on. The fact that
SOAP ties the
transport to the API and content is a big inhibitor to choosing
the
appropriate wire representation and transport of your enterprise
data.
> ESB vendors provide (or will provide) infrastructure for
following:-
>
> a) Configuring Services (representing a
configured service by a WSDL)
> b) Deploying Configured Services to a
machine (network endpoint)
> c) Instantiating 1 or more such services
over a set of machines
> d) Associating services with transport bindings
(WS, JMS, In-memory invocation,
> MQ series,
MSMQ, Tibco, HTTP, FTP etc.)
> e) Creating a business process by
connecting multiple such services (which are
>
bound to a transport) by linking output of a service to input of 1 or
> more services.
I think it's very short
sighted to say that ESBs will be based solely on WS-*
technologies.
I still continue to be amused by the fact that people
think that WS-* has made
them, somehow language/platform
independent. Its just the transport
implementation that is
open. All of your software solutions and vendor tools
that wrote
that software have positioned you to be completely dependent on the
technology, its risks and its costs.
Gregg
Wonderly
SPONSORED LINKS
YAHOO! GROUPS LINKS
| 