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

My mistake. I was referring to X4ML (not S4ML). But note that the primary
focus of X4ML is SOAP, not simple XML messaging. X4ML is a SOAP processor
and CICS dispatcher. From the first article:

> Also, he says, X4ML allows old COBOL (COmmon Business Oriented Language)
> programs to "participate" in SOAP (Simple Object Access Protocol), "so a
SOAP
> message can be sent from the Web and X4ML will convert that into the
format that
> the mainframe expects."
> The real financial benefit of X4ML, says Crew, is that the firm doesn't
> have to modify the legacy code to publish the program as a Web service.

Personally, I think the SOAP processing model makes it much easier to
integrate with legacy systems than it would be using simple XML messaging.
SOAP provides a structured mechanism to help you convert the XML into a
format that the legacy application can work with. And as ML can attest, they
wrote one piece of glue code (X4ML -- total cost $30,000), which permits
them to expose all 40,000 legacy CICS transactions without writing custom
code for each transaction. (The article says that they have exposed 20
transactions, but I was speaking with Anthony Skipper recently, and he told
me they now provide access to about 40,000 transactions.) When using XML
messaging, you would need to write a specific conversion routine for each
message-to-transaction mapping.  That is -- unless you define your own
proprietary XML protocol that permits you to do the mapping in a more
automated fashion. But I can't imagine why someone would want to define a
proprietary protocol for this purpose when a standard one (SOAP) exists --
the most powerful feature of SOAP is that it enables simple interoperability
with any other type of application -- VB, Java, C++, Perl, PHP, Ada, COBOL,
you-name-it. If you use a propreitary protocol, or if you use a simple XML
message, then you also need to write custom code on the client to create the
XML message.

Again from the article:
> Major project-development tools -- such as .NET, BEA Workshop,
> all those tools -- do a fantastic job of consuming Web services and
> generating code so that things are a cakewalk for front-end developers.
> Now, with X4ML, we can take the back-end legacy applications and
> reuse and publish those as Web services," explains Crew. "Those two
> combined together are bringing about huge savings."

Best regards,
Anne

----- Original Message -----
From: "Marco Adragna" <marco.adragna@kellogg.oxford.ac.uk>
To: <www-ws-arch@w3.org>
Cc: <anne@manes.net>
Sent: Tuesday, June 10, 2003 7:34 AM
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=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 08:23:44 UTC