W3C home > Mailing lists > Public > www-ws-arch@w3.org > June 2003

Re: Counting noses on (The GCF is -5, Interoperability is the key, don't leave legacy systems out of the web service party)

From: Marco Adragna <marco.adragna@kellogg.oxford.ac.uk>
Date: Tue, 10 Jun 2003 12:34:37 +0100 (BST)
Cc: anne@manes.net
To: www-ws-arch@w3.org
Message-Id: <E19PhOg-0007V9-00@wing4.herald.ox.ac.uk>
('binary' encoding is not supported, stored as-is) I’m happy to receive feedback from a recognised web service expert as Anne is. This might help me to clarify my own ideas on the topic. I would also like to clarify that my (-5) vote express a completely personal opinion. Of course I do know that SOAP support for legacy systems exist in the industry, with a very good third party product being softwareAG EntireX. What I was pointing out, is the lack of Native SOAP support by legacy application. Legacy apps already struggling to provide TCP/IP and simple XML messages. I would prefer them not to strictly need SOAP. I would like businesses to be able to play with their legacy systems and easily do something that can be called a Web Service. Let them start, spending nearly nothing. Then they'll come, looking for third parties ! Talking about the Merrill Lynch experience, I think it actually focused on exposing CICS transaction with X4ML (XML 4 Merrill Lynch) They support SOAP too, but XML is their focus (I haven't heard of S4ML) In general, I personally stand for the idea of calling XML Web Service any software system identified by a URI and capable of responding to clients messages with XML documents conveyed by TCP/IP protocols. I have to admit that this position is also determined by a sort of artistic attraction to the idea of a web service not requiring a web service (protocol) to work ! I also think that more might be achieved with xml web services, without requiring the implementation of yet another protocol (e.g. BPEL4WS) For example, I am working at infrastructure-based support for stateful web service interactions. Again, I particularly like the idea of doing it with no SOAP and no WSDL. Thank you again for the feedback Regards Marco Some links about X4ML: http://www.wallstreetandtech.com/printableArticle?doc_id=WST20030424S0008 http://www.infoworld.com/article/03/04/01/HNmerrill_1.html?s=cto PS: (The use of native TCP/IP directly into CICS has been added only in the last version of CICS transaction server, 2.2) (CICS folks are also working on supporting SOAP but still at early stages.) -------------- I'm not sure that I follow your reasoning regarding legacy's inability to support the SOAP processing model. I see no reason why a legacy system *is* capable of writing and interpreting an XML message but *is not* capable of processing a SOAP message. There are SOAP processors available for nearly every language you can think of, supporting nearly every platform in existence. The only fundamental requirement is the ability to communicate using HTTP and XML. When these fundamental capabilities aren't available, then you must use a gateway model -- but the gateway model would also be necessary for simple XML processing. Points of fact: - Merrill Lynch developed S4ML (SOAP for Merrill Lynch), which is a CICS-based SOAP dispatcher, providing SOAP access to more than 40,000 CICS transactions. - Software AG EntireX provides SOAP access to the 20 or 30 different legacy systems that it supports. Best regards, Anne -------------- Ciao all, Interoperability is one of the key benefits of web services over competing technologies and a fundamental factor for wide business adoption. Many businessman see web services as the first “new” technology that can bring value, without requiring a big-bag highly-expensive approach. If web services are to succeed, we should encourage this belief. Legacy IT infrastructure shouldn’t be left out from the party. Legacy systems are typically unable to support SOAP/WSDL, but capable of writing an xml text message. Look for the answer in the greatest common factor, definitely -5 Have a nice week Marco Adragna (Oxford Uni) Received on Tuesday, 10 June 2003 07:35:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:07 UTC