W3C home > Mailing lists > Public > www-ws-arch@w3.org > April 2003

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

From: Dave Hollander <dmh@contivo.com>
Date: Fri, 18 Apr 2003 12:44:10 -0700
Message-ID: <BD52C6379806D51188DD00508BEEC96C012A0F09@mail.contivo.com>
To: www-ws-arch@w3.org

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

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

-----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
> WSA v 2.0 and ebXML v. whatever could be architecturally compatible down
> road.  I'm leery of taking ebXML compatibility on as a requirement,

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.

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:06 UTC