RE: Issue 5; GET vs GetLastTradePrice

Walden,

Yes, I was trying to draw a distinction between the case where applications share semantic information totally out of band, and the case in which applications rely totally on automatic discovery mechansisms to share semantics.  I think there's a middle ground that we sort of avoid when we polarize the discussion as "REST vs RPC/SOAP" or "specific interfaces vs generic" or whatever. 

What I was trying to say is that XML tools can help reduce the custom coding effort, not eliminate it altogether.  

Eric


-----Original Message-----
From: Walden Mathews [mailto:waldenm@optonline.net]
Sent: Thursday, January 02, 2003 9:25 AM
To: Newcomer, Eric
Cc: www-ws-arch@w3.org
Subject: Re: Issue 5; GET vs GetLastTradePrice


From: "Newcomer, Eric" <Eric.Newcomer@iona.com>

> As Mike said, you can accomplish the same goal many ways.  We could
certainly push the entire burden of understanding messages into the
applications, and just use primitive file transfer methods to transfer
documents.  Many systems work like that; many integration applications in
production still use magnetic tapes to move information, and entire programs
are written for the specific purpose of transferring file formats from one
application to another.

When you say "push the entire burden of understanding messages into the
application", are you referring
to applications which have managed to coordinate their understandings
offline somehow, as opposed to
sharing coordination information in a generally visibly manner?  If so, then
the next paragraph is talking
about the benefits of visible coordination mechanisms.  Please correct me if
I misunderstand.

>
> But XML provides us tools to improve upon this most basic of integration
scenarios by adding semantic information *of some kind* whether it's a
simple service name and associated data or a specific interface.  There is
no requirement in Web services for the semantic information to be a specific
interface.  But if you have a service name, you can use it as a key to
"discover" service description information that can help avoid a lot of
custom coding for application integration.  This loosely-coupled model
provides many benefits but you keep focusing on the tightly-coupled model.
>

I'm trying to understand this distinction.  There seems to be broad
agreement that "understanding"
is a matter of sharing both syntax and semantics.  When there is no simple
shared syntax, then getting
to the semantic level is harder.  I'm not arguing in favor of what you call
the "tightly-couped model",
but I am trying to understand how massaging the fundamentals of
"understanding" yields a different
problem.

If I dereference a "service name" and get a body of description on how to
access that service, isn't
that body still describing, at the end of the day, some syntax and some
semantics?  Isn't the need for
"custom coding" a function of custom interfaces, not the lack of descriptive
material about custom
interfaces?  In other words, I would have thought that once I download the
metadata that describes
how to access your service, i would then be embarking on the custom coding
task, not avoiding it.
How would it be otherwise?

Thanks,

Walden Mathews

Received on Thursday, 2 January 2003 09:39:43 UTC