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

I acknowledge the benefits of discussion and discourse and disagreement.
I prefer those things to be driving toward understandin--then when
understanding is reached, argreement or disagreement is founded.


> Dave, you do not seem to acknowledge the position I (and a few other
people) 
> took yesterday on this subject, i.e. that our definition of Web services 
> coincide with what is included in our architecture.

How is that not "the first thing" and choices 1 and 2?



My posting was discussing your statement:
> 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.
> 
Clearly, at least to me, option 3 would allow definition that does
not conflict nor does it require explict inclusion into the defined
architecture. Said differently, I *could* define web services in an
inclusive way and create an architecture in a more exclusive way.

DaveH


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


Dave, you do not seem to acknowledge the position I (and a few other people)
took yesterday on this subject, i.e. that our definition of Web services
coincide with what is included in our architecture. 

I know it's not the same position you took, but that's why we have many
people in the same group, i.e. to make the discussion more interesting and
less uniform ;-)

Ugo

> -----Original Message-----
> From: Dave Hollander [mailto:dmh@contivo.com]
> Sent: Friday, April 18, 2003 12: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 Friday, 18 April 2003 16:54:16 UTC