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

As long as we are offering up definitions,
Here is a definition of a Web service that we actually agreed upon within
IBM.

'Web services are software components described via WSDL which are capable
of
being accessed via standard network protocols such as SOAP over HTTP"

Please note that it is important that SOAP not be REQUIRED in order to
qualify
as a Web services. It is also important to note that the network protocol
not be restrictive -
i.e. HTTP or 'Web Protocols'.  Even the term 'internet' protocol needs to
be
interpreted correctly... is that anything over TCP/IP?  Or only things
defined by
the IETF?

We recognize that SOAP and HTTP are critical to interoperability between
vendors,
but the internal application integration application of Web services do not
require it.
The way we are phrasing this is that SOAP and HTTP are important and the
fact
that they are the only bindings in use today is a function of the maturity
of this
emerging industry, not an indicator that they are the only ones that we
need.


Heather Kreger
IBM Web Services Lead Architect

"Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com>@w3.org on
02/17/2002 03:17:14 PM

Sent by:    www-ws-arch-request@w3.org


To:    "'Champion, Mike'" <Mike.Champion@softwareag-usa.com>,
       www-ws-arch@w3.org
cc:
Subject:    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)


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  ork flow (== orchestration?)  efinition   [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.xml.com/pub/a/2001/04/04/webservices/
http://www.gotdotnet.com/playground/services/
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://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?

Received on Thursday, 21 February 2002 15:18:14 UTC