Hi Gregg, To me this problem is a discontinuity between the specifications and the implementations. It is true enough to say that the WS-* specs are language, protocol, and data format independent because they have all been written that way.
However, most vendors implement them using a single language, single transport protocol, or single data format. IONA's ESB for example (disclosure: I work for IONA) treats WSDL as a completely independent artifact. Given a WSDL, our toolset can map it to CORBA, HTTP, Tuxedo, Tibco, CICS, IMS, JMS, FTP, database management system, etc. It can generate proxy and stub code (if you want) in Java, C++, COBOL, or PL/I. You can run SOAP over IIOP, SOAP over HTTP, SOAP over JMS, etc. And we are fully compliant with the set of WS-* specs we implement. There is no technical reason for tying SOAP to any specific transport or WSDL to any specific data format. Thus the confusion. Eric --- Gregg Wonderly <[EMAIL PROTECTED]> wrote: > 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 > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com 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/
