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.

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.  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.

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 14:28:04 UTC