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
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/
