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

I agree with this.

-----Original Message-----
From: Dave Hollander [mailto:dmh@contivo.com] 
Sent: Friday, April 18, 2003 2:44 PM
To: www-ws-arch@w3.org
Subject: 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 Monday, 21 April 2003 10:44:44 UTC