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

Krishna,

Good to see your comments. Let me state first some commonly
held ideas before I respond to your question on what is infrastructure.

I believe what the Web Services "movement" (if one may call it so)
has made the notion of "service integration" a mainstream, or at least
fashionable with analysts. If one were to speculate on the genesis of
web services, one can see how the deficiencies of application
integration done through CORBA/DCOM from B2B perspective
led to the service integration. I will not try to peel onions
on which community came up with the idea, etc.

My assertion (again, not very original) is that both business integration
community and semantic integration community would find service integration
useful.
Since W3C is the pre-eminent body on everything web, and we are the WS-A
team,
it would possibly behoove us to define infrastructure as the most common
denominator within service integration that serves both communities.

It is my understanding that WS-A is a steering committee and not a "real
work"
committee - so I am unsure of the benefit of my following statements, except
to do
some "broad-brushing." I also hesitate to be dogmatic, but in the interest
of clarity, I would say
the following would be in the WS-A scope and what would fall outside.
Outside doesn't mean "out" - only that the build-out is not WS-A
responsibility,
we may suggest ideas to whomsoever bodies.

Fundamentally, a web service is an entity that us uniquely identifiable on
the web, independently describable,
and that can be interacted with from web services or entities (note, I avoid
s/w in consideration for the emergence of humanoid agents that have URIs
instead of ears/eyes)

Intermediaries - yes - a definition would help "indirect" service
interactions.
Specification of routing across intermediaries would be helpful. Limited
specification
of reliability would be helpful. Some generic specifications of security may
be (end-to-end
security is business specific). Besides security specification should not
disable
the semantic integration efforts.
Eventually, the consumers of the products of the W3C activity should make
the
ultimate call on whether the spec from W3C hurts them or helps them.
Over-specification
will hurt the other bodies from leveraging W3C specs. In other words,
creating
another ebXML MS should not be the goal, but what can help ebXML MS and
semantic
integration needs should be the goal.

Orchestration - no - there is a notion of business process execution and
another of
business process collaboration that interface with each other but are
mutually exclusive.
(e.g., ebXML BPSS - collaboration, BPML - process execution). Orchestration
IMHO
mixes up both ideas and gives the impression that process execution is the
same
as collaboration. Besides, it is unclear what orchestration means to
semantic integration.

Service collaboration - possibly later - From business integration point of
view, there is
merit in recognizing this idea, though I doubt WS-A would be the right forum
for furthering it - ebTWG is working on it now.
I have not thought through what this means to the semantic
integration community. Does it mean, an preferred order of inferencing
sequence (a-priori)?
Or, could it be a dynamic collaboration of ontologies for conducting a
service?
We may simply say that, yes, there is value in having services collaborate,
and let it
take shape later.

Ontologies/vocabularies - yes, a little later - I do think that when we have
a service "independently described," then surprisingly, it can be described
in some vocabularies, and ontology, crudely, is really a set of relationship
on base vocabularies. Thus, I do think within the "independent description"
axis, the next stage is the vocabularies. However, I would rather defer the
actual creation of these to the respective communities.

Now in brief, I suggest that we view web services idea hanging from 
and grow through three axes: 
	unique identification,  - URI/...
	independent specification, - WSDL/vocabulary/ontology
	and interaction - XMLP/intermediary/collaboration

In any case, we should start from the minimum possible
specification/definition.

With best regards,
-Suresh
--------------------www.sterlingcommerce.com--------------------------------
Suresh Damodaran Ph.D.                         
Senior Software Architect
469-524-2676(O)
----------------------------------------------------------------------------
----------------                           



-----Original Message-----
From: Krishna Sankar [mailto:ksankar@cisco.com]
Sent: Thursday, March 07, 2002 12:41 AM
To: Damodaran, Suresh; www-ws-arch@w3.org
Subject: 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 11:17:50 UTC