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

WSDL defines the location (access point) for a web service. That location
is not restricted to be
a URI, although there is no doubt that this will be the most common usage.
It could also be
a set of properties required to set up the access.  I have seen examples of
this approach
when addressing messaging systems. One could always argue that the set of
properties
could be represented as a URI convention.

WSDL does not force you to use a XML protocol. Binary protocols can be used
and may be
popular within enterprises. Of course, your potential client base may be
reduced.

Heather

"David Orchard" <david.orchard@bea.com>@w3.org on 02/21/2002 03:43:07 PM

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


To:    <www-ws-arch@w3.org>
cc:
Subject:    RE: Web Service Definition [Was "Some Thoughts ..."]



If we think of the web as URIs, HTML, HTTP, we probably should touch on how
web services are similar/different from the web.

A definition that I tend to like for web is "The web consists of resources
identified by URIs that send/receive markup formatted messages, typically
XML or HTML, and accessed via network protocols such as HTTP".  I lobbied
for this kind of definition in the upcoming TAG Web architecture document.
The TAG discussed this at the F2F [1], though we have't formally captured
this yet.

From the core 3 web protocols, it seems that web services loosen the html
definition into markup of either html or xml and further loosens the HTTP
definition into network protocols.  I firmly believe that the web services
definition should completely fit inside the web definition.

I'm struggling with the fact that the IBM definition does not mention URIs
nor does it require markup.  Further, it allows an HTML page (with WSDL) to
classify as a web service.  A different wording might be "Web services are
web resources that are described by WSDL".  Another wording might be "Web
services are web resources that are accessed using SOAP and possibly
defined
by WSDL".  Yet another definition is "Web services are web resources that
are either accessed using SOAP or defined by WSDL".  I think it's important
for us to distinguish between the web and web services in a very clear
manner, and that web services definition should be completely contained (ie
a refinement) of the web definition.

Cheers,
Dave

[1] http://www.w3.org/2002/02/12-tagmem-irc.html



> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Heather Kreger
> Sent: Thursday, February 21, 2002 12:18 PM
> To: www-ws-arch@w3.org
> Subject: 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/webserv
> icefaqs.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/010312hnw
> ebserv.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 16:10:12 UTC