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

Ok. I agree that we could choose to only have one thing we 
call a web service.And I can see that my naming choices 
were based on that premise. 

My point was if we have an architecture with specific 
constraints such as "must have soap or wsdl", *there* are 
two things--regardless if we choose to discuss or name 
two things.

I can see two ways to discuss one thing: rhetorical or technical.
Rhetorically, we could just choose not to discuss things that do not 
meet our technical definition that therefore need not name it. Or we 
could technically define one web service that is inclusive--where I 
thought we started from and were moving away from. Are you advocating
restoring a definition like the general one we had or is there another 
way? Am I missing something from your position?

Would you describe the nature of this thing?
	a) is ws the thing that all the various industry papers and 
		press talks about?
	b) is ws the thing that conforms to our architecture?
	c) is it both of these?

   If both, 
	1) then is what we publish in the architecture document nearly all 
		optional features? 

	2) Is it precise enough to define how ebXML works and other 
		instances of a) above? or does it include those only though
		general statements? or something else?

DaveH

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


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

All the choices you list are based on the premise "our definition of Web
Services is different and presumeably broader than the set of
constraints/principles/defnitions defined by our architecture". From that
premise you start mentioning two "things" in all your choices. 

I am not at all convinced that we need to talk about two things. In fact, my
point yesterday was that we only need to talk about one thing.

Ugo

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