Emperor has no clothes (Observations on the Web Services Definiti on)

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 12:56:46 UTC