RE: Emperor has no clothes (Observations on the Web Services Defi nition)

Doug,

Thanks for your comments. My responses are inline.
-Suresh

-----Original Message-----
From: Doug Bunting [mailto:db134722@iPlanet.com]
Sent: Wednesday, March 06, 2002 1:27 PM
To: Damodaran, Suresh
Cc: www-ws-arch@w3.org
Subject: Re: Emperor has no clothes (Observations on the Web Services
Definiti on)


Suresh,

Thanks very much for distilling a number of longer threads into 3
assumptions.
If we choose tomorrow to decide one of the existing definitions before the
group
aren't "good enough" (big if), I'd suggest we begin separate discussions of
each
of the assumptions you've outlined.

<sd>
My goal of writing that lengthy email was to point out that web services
can't be the silver bullet that did the end-to-end business integration as
well as semantic integration. At best, the technologies or components in web
services basket
can be great infrastructure pieces. In the interest of "truth in
advertisement"
WS-A team, i.e., us, should own up to it. If this is not the truth,
let us debate regardless on all assumptions. Let us find out whether the
emperor
has any clothes own!
</sd>

One small point in that vein on assumption 3: I haven't heard anyone suggest
XML
is irrelevant.  The discussion seems to centre around either which parts of
the
w/s definition require XML (payloads, envelope, description, routing, ...)
or
whether the definition (and not the architecture) must mention XML at all.
The
first part alone will take us down an incredibly deep rat hole.  If we look
at
web services as component to solve a particular business problem, as you
described in assumption 1, the definition might describe that component
without
mentioning XML but the overall architecture (how that component could or
should
be used to solve the problem) we define must use XML everywhere.

<sd> First of all thanks for pointing out my poor wording regarding
XML's relevancy. You are suggesting that we avoid mentioning XML in the
definition,
and have it mentioned (ok, how can we avoid it!) in the architecture.
I agree with that. It might even be superior to the alternate approach,
since the service description can be generic, and service integration can be
generic,
and will apply to both business integration and semantic integration camps.

The way the current definition stands, per Chris's agenda email:
"A web service is a software application or component identified by
a URI, whose interfaces and binding are capable of being described
by standard XML vocabularies and that supports direct interactions
with other software applications or components through the exchange of
information that is expressed in terms of an XML Infoset via 
internet-based protocols".

This is a fairly generic description, except that I change in the following
ways.
"A web service is a software application or component identified by
a URI, whose interfaces and binding are capable of being described
by [SNIP: standard XML ] vocabularies and that supports direct interactions
with other software applications or components [SNIP: through the exchange
of
information that is expressed in terms of an XML Infoset] via 
internet-based protocols".

To really cut it short with some minor info loss, I would suggest:

"A web service is a software application or component identifiable by a URI,
describable with a vocabulary, and interactable with one or more web
services
via internet-protocols"

(Ed. Note.: I avoided "direct" interaction because that disallows
interaction through
intermediaries - a.k.a. proxy interaction)

Thanks again for the comments.

</sd>


  Therefore, I
can understand leaving XML out of the definition though I'm unsure about
that
approach's value in the context of this activity.

<sd> ditto </sd>

thanx again,
    doug

"Damodaran, Suresh" wrote:

> Hi All,
>
> It is interesting, overwhelming, and exciting to see the many
> comments on "how to define web services." I would like submit for your
> consideration
> a questioning of the assumptions under which we are trying to do the
> definition.
> The ideas below are not necessarily new or particularly revolutionary, and
> some
> of you are probably already thinking along the same lines.
>
> I apologize for the long email.
>
> Assumption 1. Web Services can be defined without a context.
>
> I respectfully disagree.
>
> "Ma, how big is the sky" - Web Services definition needs a (business)
> context
>
> Trying to define web services without a business context is somewhat
> like a 5 year old trying to define how big is sky. Is it as high as the
hand
> can reach? Is it as high as the planes can go? Or, is it as high as the
> stars at night? What does the fish in the sea think how big the sky is?
> Once you provide a context (such as "wherever you can breathe", it is
easier
> to define).
>
> Is the goal of defining web services to eventually create an architecture
> to carry out business across the web? Or, is it to create seamless
semantic
> integration of the web? Or, is it both? If so, is there a tighter
> context in which we can define web services, say as an "infrastructure
> to enable business integration and semantic integration" Note that
> many other standards bodies (e.g., OASIS) members view W3C as creating
> infrastructure standards. Also, observe that the core standard, SOAP, is a
> foundation
> of  ebXML messaging. Thus, there is already an expectation of
> infrastructure.
>
> Bottom line 1: We have to agree on the business context - IMHO, I would
> say it is to support "infrastructure to enable business and semantic
> integration"
>
> Assumption 2. Web Services can deliver complete integration solutions for
> problems
>
> I respectfully disagree.
>
> "Sir, just add water, you will be integrated!"
>
> There is much more to creating a solution that works for either business
> integration
> or semantic integration. The whole of ebXML community has spent many
> zillions
> of man-hours (just add the hours spent on RosettaNet, eCo, EDI...).
> It is quixotic to think that Web Services Architecture will be the
> superceding
> architecture for all business service integration. Same for semantic
> integration.
> Semantic Web community is a vibrant community that has its own view points
> on how
> to do integration. I would argue that the major common factor in these
> integrations
> is only interoperability. Business integration requires, in addition to
> interoperability, reliability, security, and accountability. This does not
> mean that semantic integration does not care for these attributes. Just
that
> these requirements are lower on their list of priorities - they have
bigger
> fish to fry - such as how to create and propagate ontologies.
>
> Bottom line: Trying to define a web services architecture that will be the
> complete
> solution to business integration and semantic integration is way beyond
the
> scope
> of WS-A. The best we can go for is to define the least common
denominators.
> Really,
> we can only try to define "Infrastructure components" for these
> integrations.
>
> Assumption 3. XML is irrelevant (or really not necessary) in the
definition
>
> I respectfully disagree.
>
> XML is not just another format. It is ubiquitous. Just look at the trend.
>
>         XML is has become infrastructure
>                 SOAP is used as the basis of enveloping in ebXML and
BizTalk
>                 (yes, wire protocol is infrastructure, IMHO)
>
>         XML has become content
>                 Whatever EDI has left undefined, XML attempts to capture
>                 UML to XML mapping exists (though, many argue it is not
> perfect)
>                 RDF to XML mapping exists
>         XML is used for storage
>                 (XQuery is the SQL of tomorrow?)
>
>         XML has many toolkits and other ecosystem supports.
>
> The implications of XML as infrastructure are that it could be used for
> packaging
> by enveloping other documents in binary formats, and as much
infrastructure
> requirements
> that can be generically met can be standardized (more on this below).
>
> Bottom line: Web Services cannot be defined sans XML
>
> Assumption 4. All infrastructure requirements (interoperability,
> reliability, security,
> accountability) can be addressed by web services completely.
>
> I respectfully disagree.
>
> Interoperability requirements can be addressed only among the components
> that are within
> the purview of the WS-activity. Interoperability from business
> integration/semantic integration has to be taken up by those communities,
> and solved for themselves.
>
> Reliability requirements are more standard - it should be possible to
define
> a message
> is guaranteed to be delivered /once and once only/at most once/etc.
However,
> there is a
> need to define contract for reliability. WSDL may grow to meet that need.
> For example,
> WSDL++ may say that that service would expect a message exactly once.
>
> Security requirements are hard to be standardized completely using the
> infrastructure -
> because the end-to-end security solution is much dependent on the specific
> business scenario. It is not that XML Signature cannot be used - but the
> exact sequence of
> processing is very much dependent on the business needs. Business
> integration
> community is addressing it through ebXML, so I do not wish WS-A to compete
> with ebXML
> on this issue.
>
> Accountability requirements - contract specification, and verification
> through audit.
> Some of these actually could be addressed within the infrastructure
> umbrella.
> For example WSDL++ may specify reliability and some time limits as well as
> specify
> ways to log the events as they happen. However, complete solution
> specification
> by WS-Architecture is, IMHO, not wise from the point of WS-A.
>
> Bottom line: Some infrastructure requirements can be addressed, but not
all.
> WS-A is not the silver bullet for all integration woes.
>
> The BIG bottom lines:
> WS-A could best focus on defining web services from an infrastructure
point
> of view,
> and not attempt overloading the definition with either business/semantic
> integration issues.
> The WS-A can work on preventing inconsistencies within the infrastructure
> specs
> such as XMLP and WSDL, and may pass on the infrastructure issues that come
> across it.
>
> Thanks for your patience.
>
> Respectfully,
>
> -Suresh
>
>
--------------------www.sterlingcommerce.com--------------------------------
> Suresh Damodaran Ph.D.
> Senior Software Architect
> 469-524-2676(O)
>
----------------------------------------------------------------------------
> ----------------
>
>

Received on Wednesday, 6 March 2002 19:47:15 UTC