RE: Some proposed definitions of "web service" based on the call toda y

Ugo, you do not seem to acknowledge a difference that we talked about
yesterday.

One thing is: 
	...included in our architecture

This is a very active act that would require the efforts you outline.


A potentially different thing is: 
	...included in our definition of Web Services

This simply means that our definition of Web Services
is different and presumeably broader than the set of 
constraints/principles/defnitions defined by our 
architecture. In essence, it implies that 
our architecture defines some "new thing". 

Yet another related and not orthogonal choice we face is
a naming choice:

	1) should we use the same name for both: Web Services

	2)  should we name the "new thing": Web Services
	2a) should we name things that are not "new things": ?YYY?

	3)  should we name the "new thing": ?XXX?
	3a) should we name things that are not new things: Web Services


My preference is stongly toward 3. With XXX being XWS.
A canidate for YYY (choice 2a) that made sense to me was: SOA
Dave

-----Original Message-----
From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
Sent: Friday, April 18, 2003 12:37 PM
To: Champion, Mike; www-ws-arch@w3.org
Subject: RE: Some proposed definitions of "web service" based on the
call toda y



> I don't know if this will cover ebXML as within the
> scope of the WSA.  I'll guess that is will ... or at least will allow the
> ebXML folks to rigorously define how they differ from WSA v1.0, and
perhaps
> WSA v 2.0 and ebXML v. whatever could be architecturally compatible down
the
> road.  I'm leery of taking ebXML compatibility on as a requirement,
however.

I have some serious doubts that, by giving a definition of Web services that
does not conflict directly with what ebXML has today (e.g. not requiring
WSDL), we will automatically comprehend ebXML in our architecture.

ebXML invokes a set of concept (e.g. CPP/CPAs, business semantics,
repository, etc.) that so far have only been minimally addressed by this
group, if not at all. Doing a serious work of comprehending ebXML in our
architectural scope would involve, in my mind, carefully analyzing all those
ebXML-specific concepts, compare them with our current scope, and (most
likely) modify our scope and architectural model to include them. I suspect
this goes well beyond what this group is chartered for at this time.

Missing this type of rigorous work, the attempt of making ebXML part of our
Web services architecture by way of relaxing the Web services definition
looks to me mostly like a marketing gimmick.

Ugo

Received on Friday, 18 April 2003 15:49:34 UTC