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

You say, "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 used to
have that mindset, but I became convinced that somehow you need to put
in the concept that the primary purpose of the exercise is app<->app
communication.  I personally think that this is the big differentiator.
Web sites intended for human consumption are not, IMO, Web services,
even if they are produced by applications somehow and even if there are
applications that scrape information off of them.  I'm not sure how to
get that concept over succinctly and effectively, but I really think
that it is pretty central.

-----Original Message-----
From: Marco Adragna [mailto:marco.adragna@kellogg.oxford.ac.uk] 
Sent: Tuesday, June 10, 2003 6:35 AM
To: www-ws-arch@w3.org
Cc: anne@manes.net
Subject: Re: Counting noses on (The GCF is -5, Interoperability is the
key, don't leave legacy systems out of the web service party)




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=WST20030424S000
8
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 10:17:30 UTC