RE: Web Service Definition [Was "Some Thoughts ..."]

I thought that web services were supposed to include entire processes that
might involve a number of data transmissions and provision of services from
a number of sites???  If that is true, doesn't your definition of a web
service actually describe a component of a web service?
 
Another thing -- I don't think that the resolution of a web service
necessarily has to be done entirely via software.  That is, one could have a
process where some of the components occur via human actions (e.g.
expenditure approvals).
 
I'm not good at crafting these phrases, but in the spirit of not just being
critical let me take a wild stab ...
 
A web service is a process in which the communication between the service
providers and requesters takes place over the web via XML.
 
Yeah, well, I told you I wasn't good at this ...
 
-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com] 
Sent: Saturday, February 16, 2002 12:31 PM
To: www-ws-arch@w3.org
Subject: RE: Some Thoughts about Goals


I think I agree with most of these points.  I'd phrase my position as: 
 
a) we need at least a fuzzy definition of "web services"  up front so that
we can make sure that we're all on more or less the same page when defining
an architecture for them.
 
b) that definition should in principle be general enough to include multiple
message exchange patters including the "RPC over HTTP" model that is
currently dominant, the more traditional "EDI using XML and the Internet",
and the emerging "Next generation web services based on REST principles"
(see http://www.xml.com/pub/a/2002/02/06/rest.html
<http://www.xml.com/pub/a/2002/02/06/rest.html> ) 
 
c) Ideally, this group would take the time to make sure that the
architecture is "right" before releasing it.  I believe that the history of
the internet and software industry shows clearly that "the best is the enemy
of the good."  That is, those who take time to do it "right" are left in the
dust because a barely adequate solution beats no solution every time, and
technology (and business reality) changes rapidly and unpredictably, so
multi-year projects almost always look much different at the end than
anticipated at the beginning.  So, some meta-requirements are:

*	The work must proceed by successive refinement, starting crude, and
iteratively fleshing out details based on feedback from the "customers" and
the experience of web services projects and products in the real world.  

*	The architecture must be modular and relatively decoupled (or
perhaps "must employ best practices to help ensure that it can evolve
gracefully as conditions and requirements change"). 

*	Time to market is indeed critical; if the architecture this group
defines diverges sharply from common practice, it will not have much impact
(the OSI 7-layer networking reference architecture is often cited as a bad
example here). 

*	Simplicity (in the sense of being understandable and implementable)
is also critical, partly because it supports the "time to market"
requirement, and partly so that it can be communicated to interested parties
as efficiently as possible.

 
d) Bare minimum requirements for the architecture itself are:
*	Provide for rigorous definition of web service invocation mechanisms
(URIs, SOAP, and something like WSDL) to ensure interoperability 

*	Support platform/vendor/language neutrality 

*	Suitability to real-world business needs (not just adding numbers or
checking stocks!)
*	Cover both synchronous and asynchronous message exchange patterns 

*	Define components that can ensure reliable messaging. 

*	Define components that guarantee secure and auditable/nonrepudiable
messaging
*	Support work flow  (== orchestration?) definition  [not sure if this
is an absolute requirement for v 1.0)
 
Finally, "what is a web service".  FWIW, I typed that string (and some
variants) into Google and got the following useful URLs:
http://www.oreillynet.com/pub/a/webservices/2002/02/12/webservicefaqs.html
<http://www.oreillynet.com/pub/a/webservices/2002/02/12/webservicefaqs.html>

http://www.xml.com/pub/a/2001/04/04/webservices/
<http://www.xml.com/pub/a/2001/04/04/webservices/> 
http://www.gotdotnet.com/playground/services/
<http://www.gotdotnet.com/playground/services/> 
http://www.zdnet.com/anchordesk/stories/story/0,10738,2847589,00.html
<http://www.zdnet.com/anchordesk/stories/story/0,10738,2847589,00.html> 
http://iwsun4.infoworld.com/articles/hn/xml/01/03/12/010312hnwebserv.xml
<http://iwsun4.infoworld.com/articles/hn/xml/01/03/12/010312hnwebserv.xml> 
http://www.devx.com/dotnet/articles/cp0901/cp0901-1/waws.asp
<http://www.devx.com/dotnet/articles/cp0901/cp0901-1/waws.asp> 
 
My best shot at a "strawman" definition that is consistent with the goals
and meta-goals I described above is:
 
"A web service is is a software application or component that can be
accessed over the Internet using a vendor/platform/language-neutral data
interchange format to invoke the service and supply the response, using a
rigorously defined message exchange pattern, and producing a result that is
sufficiently well-defined to be processed by a software application."
 
Some discussion points for this definition:
 
"Web" in my mind implies HTTP; I would assert that a 'web service' could be
accessed via BEEP, SMTP, raw sockets, UDP, or any other protocol that uses
IP as an underpinning.  So, "web services" are really "internet services"
IMHO.
 
I'd be happy to put substitute "XML" for "a vendor/platform/language-neutral
data interchange format" , but I'm not at all sure that XML is *really* a
requirement for what we're doing.  My thought is that SOAP 1.2 is defined on
the XML InfoSet rather than syntax and some other format that can map to the
infoset (e.g., a URI-encoded string representing an infoset) could in
principle be used.  I'm not sure we want to split this hair, and "XML" is
obviously a good shorthand for "some syntax that can be mapped into the XML
Infoset".
 
I don't currently believe that SOAP is integral to the *definition* of a web
service, but I might be persuaded otherwise ...
 
The "result that is sufficiently well-defined" bit is an attempt to
distinguish a 'web service' from any random page on the Web. 
 
I have avoided the whole issue of discovery; as far as I can see a "web
service" that is only discovered by human interaction is still a "web
service."  That doesn't mean we shouldn't address discovery in the
architecture ...
 
I avoided the security/reliability issues in the definition; an insecure web
service over an unreliable protocol is still a 'web service", albeit a lousy
one.
 
Again, this is a strawman definition, whack away!
 
 
 
 -----Original Message-----
From: Cutler, Roger (RogerCutler) [mailto:RogerCutler@chevrontexaco.com]
Sent: Saturday, February 16, 2002 12:00 PM
To: www-ws-arch@w3.org
Subject: Some Thoughts about Goals



I'd like to talk about goals for a minute from a slightly different
perspective.  Please forgive me if I dwell on the painfully obvious or
ramble a bit.  My objective here is not to substitute different goals for
the ones being discussed, but perhaps to find out if there is something
missing from them.

It seems that there is a slight level of discomfort in the group because we
do not have a clear definition of what a "web service" is.  I am personally
quite willing to discover this during the process, but I do admit that there
is a certain odd aspect to the situation.  On the other hand, the discomfort
level really does seem to be quite low.  Why is this?  Well, I think that
most people sort of feel, "I'm not sure I can define it, but I know it when
I see it".  Now why would this be?  Well, it seems to me that most people
have the feeling that web services should end up with at least some
reasonable subset of the functions of systems that they already know about
-- like CORBA and Grid.  So why not just use these systems that are already
there?  Probably because we want to have a standards-based solution on the
web that is used by a wider cross-section of end users and/or is less costly
than current solutions.  So one goal -- and this one is certainly painfully
obvious but perhaps worth stating anyway -- is that the architecture be
accepted by as many as the stakeholders as possible.  We want .Net-ers and
Java-ers, creators of open source and proprietary masterpieces, all to say,
"Yup, I can work in that framework".

So, are all the stakeholders at the table? 

I am a little concerned that I am getting the impression that systems like
CORBA and Grid are being used as models for goals but perhaps not EDI???  I
don't know the people in this group very well -- are there any EDI people
here?  I myself am hardly an EDI expert but I have access to them.  I could
imagine that EDI might be under-represented because at least some of these
folks seem to want to close their eyes until XML goes away.  I have heard,
in this community, the phrase "flavor of the month" used with the
implication that if you just wait a bit there will be some other enthusiasm
that will replace XML solutions.  I think we understand that this is a bad
call, and I think the EDI people are beginning to realize that too, but at
least among those I know there is still not a lot of active participation.

Now I personally think that the EDI model is very important.  One of the
things that we want web services to do -- a "goal" perhaps in a different
sense -- is to be capable of handling business transactions  EDI is a
mature, functioning system that does just that.  Web services should support
at least some subset of EDI functions.

As I said, I'm not an EDI expert, but let me guess some of the things that
are important in EDI that web services should probably also support:

*	Reliable messaging. 

*	Audit trails 

*	The usual security suspects - e.g. authorization, nonrepudiation,
secure transmission, etc 

*	Ability to transmit large volumes of data efficiently (?) 

*	Work flow definition 

*	Contingency processing (or something like that) 

*	???  Probably a bunch of important stuff I don't know about at the
moment ???? 


Soooo -- I guess I'm asking you folks:  Do you agree with these concerns?
If so, do the goals as presently articulated address them?