R: Counting noses on ( -5 get tempted from +5, but +5 withouth "...Prior semantic agreement..." could be making the wrong promise)

Thank You for the feedback.
I have been told that "To every difficult problem there is a simple
answer. And it's wrong." but I'm still attracted to simplicity.

You say "I became convinced that somehow you need to put
in the concept that the primary purpose of the exercise is app<->app"
This was almost drawing me from -5 to +5 (still can't see nothing in
between)
But, among other things, I am concerned that having the concepts of WSDL
and SOAP as the very essence of web services, 
without no mention to a prior semantic agreement, 
implicitly make a wrong promise to the superficial web service user.
Many developer might understand that: "If I develop a Web Service
application, support SOAP, and place a Web Service Description where
client applications can discover it, then I get app<-->app
communication"
But no full, automatic app<-->app interoperability exist without a clear

semantic agreement between the two parties.

Furthermore, a wide mechanic description-level interoperability, 
multiply the occasions for semantic misunderstandings, 
because client and server are more likely to belong to different
loosely-coupled organizations. (less likely with DCom/Corba/..)

I can see developer going "Let's try to use this exciting web service
technology" 
and then "Hooray! Our company software successfully communicate with
CompanyX Web Services" 
and then "What the ....! I should get a sum of gross prices here and it
hasn't got VAT instead! Maybe CompanyX doesn't even know what a Gross
price is? This web services are really unreliable stuff..." 

When I read for the first time: 
[Definition: A Web service is a software system identified by a URI,
whose public interfaces and bindings are defined and described using
XML. Its definition can be discovered by other software systems. These
systems may then interact with the Web service in a manner prescribed by
its definition, using XML based messages conveyed by internet
protocols.]
I actually believed that
" These systems may then interact ... " but they don't without prior
semantic agreement. 
Ok, this might be related to the fact that English is not my mother
tongue (!), but if discovering the service definition is at the essence
of being a web service, I would find more honest something like
" Upon semantic agreement, these systems may interact ... "

Re-reading this message, I can see my point is not that strong, 
and maybe I am destined to +5 ... ;)

Marco


-----Messaggio originale-----
Da: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] Per
conto di Cutler, Roger (RogerCutler)
Inviato: marted́ 10 giugno 2003 16.15
A: Marco Adragna; www-ws-arch@w3.org
Cc: anne@manes.net
Oggetto: 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 Thursday, 12 June 2003 06:40:18 UTC