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:27:49 UTC