Let us clothe the Emperor in Blue Jeans (was: Emperor has no clothes (Observations on the Web Services Definition)

Suresh,

	You have some interesting points. I think the main thrust is the
point that the WS-Arch team should focus on "infrastructure" and nothing
above that layer. I assume that means the Transport, Routing and
Packaging, security, interoperability, reliability et al. I assume
ontologies is outside the scope, what about orchestration,
intermediaries et al. What else is in your mind (i.e. in the
infrastructure domain) ?

 | 
 | 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"
 | 
<KS>
	We are defining a technology here. The applications above us
will define the business semantics and apply the technology (we develop)
to solve interesting business problems. But we are not defining business
solutions.
</KS>

 | 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
 | 
<KS>
	This is a weak argument. Web Service = Infrastructure, XML =
Infrastructure, hence Web Service = XML looks like the third Law of
Thermodynamics.

	I agree with the positive assertion that web services *can* be
defined by XML. But going as far as saying that "there is no web service
without XML" cannot be supported by the current argument set.

	Remember, 5 years from now XML might not be there but web
services could be. Hopefully nobody quotes this e-mail back to me in 5
years :o)
</KS>

cheers
 | -----Original Message-----
 | From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]
On
 | Behalf Of Damodaran, Suresh
 | Sent: Wednesday, March 06, 2002 9:56 AM
 | To: www-ws-arch@w3.org
 | Subject: 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 Thursday, 7 March 2002 01:41:52 UTC