RE: Web Service Definition

Can we separate the definition from the architecture?

The definition might not mention SOAP or require security, but the
architecture would both mention SOAP and require a security component.  I
feel we will never get to the bottom of either the definition or the
architecture if we continue to intermix them.

Eric

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of mario.jeckle@daimlerchrysler.com
Sent: Sunday, February 24, 2002 11:57 PM
To: www-ws-arch@w3.org
Subject: Web Service Definition


> I think Web Services have three key elements:
> 1) Identified by URI
> 2) Accessible via standard web protocols
> 3) Capable of interacting with applications and programs that are not
> directly human-driven user interfaces, e.g. web browsers
+1

> "A web service is a software application or component identified by a
> URI that other software applications or components can directly interact
> with via web-based protocols, where said interactions do not require
> direct human involvement."
> Broad? Yes. But I think it's necessary to be broad.
+1

We wholeheartedly agree with that since we're currently not in the
position to decide on all the possible usages and technical
incarnations of web services.

> OK, but if we *define* a "web service" as something that uses
> WSDL to define
> the contract, a lot of people are going to be unhappy!
+1!

We would strongly suggest to keep our joint definition of "web
services" as technology neutral as possible. This is especially
true since our definition should hold even if some web service
related techniques change over time.

> I could live with an architecture that says that WSDL is the
> *preferred*
> contract language, but we are not discussing that yet, just
> trying to define
> "web service."  This is probably a candidate for the Issues List.
+1.

Suggestion: Use a formulation that defines the usage of WSDL as a
MAY requirement stating a preferred way to describe a web service
for interoperability's sake but do not preclude other ones.

> We might be converging on something here ... A web service is defined by
> the
> FUNCTIONALITY of SOAP, WSDL, and perhaps UDDI; those are in some sense
> "ideal type" definitions of a web service, but so long as the interface is
> rigorously defined using some combination of URIs and XML, we agree that
it
> is a "web service."  Are we getting there?
> Actually, discovery ("UDDI functionality") probably doesn't have to be as
> rigorously defined as the envelope format and message exchange pattern
> (SOAP's functionality) and the actual format of the invocation/response
> (WSDL's functionality).  An "invitation only" service is still a "web
> service" ... Does anyone disagree?

We would not define anything in a rigorous manner ...

> Some say that a Web service uses SOAP, WSDL, and UDDI.  But clearly UDDI
is
> not required, and WSDL is not always used.  So it would seem use of SOAP
is
> a minimum criterion.

Acting a little bit as devil's advocate here ... Should SOAP be
part of the definition? This would exile XForm based services out
of the Web Services context ...

>But it would seem inevitable that
> SOAP, WSDL, and UDDI -- perhaps more correctly the services and
> functionality they represent -- have a place in the scheme of things.

Sure. But in our opinion not compelling.

> Also I would go out on a limb to say that everyone agrees security is
> fundamental to the architecture, and probably management services.

Security _is_ fundamental. But we would not explicitly include it.
We think XMLP/SOAP's discussion would be re-cycled here: Anything
we could state about security could be divided into two disjunct
categories. The first category correlates with the camp of the
strong-security guys. Those would always come up with "the level
of security is not sufficient for this and that ..." (i.e. we did
to less). The other camp would always state "the mandated level of
security is really too much for my service ..." (i.e. we failed
again, by exaggerating the topic ...)

We think the best idea is it to keep the definition open for
security issues but not demanding any specific level of security
as a MUST have criterion.

> And  some
> kind of orchestration or choreography service for establishing
> relationships
> among Web services

We wouldn't overload the architecture with requirements. We prefer
to keep that point optional.

> 3 - I strongly favor functional definition of web service within a broad
> technical framework.  That is, I like saying that web services have to use
> URI's and XML, I don't like saying they have to use WSDL and/or UDDI.

+1

>  and is defined by a description of the data required
>  to invoke the service, such as a WSDL document;

_MAY_ be defined

> So we refine the web component into a web service by mentioning SOAP and
> WSDL.

We disagree to force a Web Service to use SOAP as a MUST
criterion. Ditto for WSDL. Optionally: yes, Required: No.

> I'm not too keen on the addition of "usefully processed by conventional
> software without human intervention." because I can't figure out how to
> define "conventional software" nor "usefully" processed".

+1

>It seems to me that if you don't use SOAP AND you don't use WSDL, you
>probably don't have a web service.  One criteria that I tend to like is
>that a Web service must have at least one of SOAP or WSDL.  If somebody
creates
>a non-soap XML document and ships it over HTTP to a URI that doesn't have a
>WSDL, that's just a web document/component.

We am not sure if we have to break that apart into that 2-phase
model (components and web services). But we're very much in favour
of a layered approach along the increasing levels of
interoperability. Perhaps the following could work (to be read
from the bottom):

Directory (e.g. UDDI, DISCO, ADS ...)
----------
Description (e.g WSDL, SDL, NASSL, IDL ...)
----------
Transport Protocol (e.g. SOAP, XML-RPC, Jabber ...)
----------
Content Vocabulary (e.g. XML, ASN.1, ASCII ...)
----------
Web Service basic definition

> Question: Is anything describable by WSDL, like an XHTML page described by
> WSDL, a web service?  I tend to think not,
+1.

But should we recommend that the vice versa interpretation (i.e.
every Web Service MUST have a WSDL description) is also true?

> I'm
> willing to say that we are talking about *XML* web services
> in which the
> service is identified by some combination of URIs and XML,
> and the result is
> an XML instance.

+1!

Along the lines of the layer model drafted above you could put
every technology TLA in front of "Web Service" to make the
realization of the interoperability explicit.

We think "XML Web Services" are just one (IMHO the most promising)
flavour of Web Services.

> On the other hand, I'm reluctant to say
> that "web services
> *require* SOAP, WSDL, or UDDI, although each obviously is an
> *example* of
> role that might be critical to our definition.

+1!

> So, I'd
> say that a web
> service is "unambiguously identified using Web technologies,
> including a URI
> and optionally an XML description such as a SOAP message".

+1.

> I'd amend
> the strawman to say that a web service must have a "clear
> description of the
> data required to invoke the service, such as a WSDL document."

Change it to "... _SHOULD_ have" and we'll buy it.

> How about saying that a web
> service must, by
> definition, "produce a result that can be processed by  conventional
> software without human intervention."

Sure, but this precludes "magic" web services providing a nice and
friendly interface to some miraculous machines over the web ;-)

> "A web service is is  a software application or component that:
> Is accessed over the Web (broadly defined) using  HTTP or another
> standard messaging protocol;
> Is identified and invoked using using Web technologies, including a
> URI and optionally an XML description such as a SOAP message, via a
> well-defined message exchange pattern;
> Is defined by an unambiguous description of the data required to
> invoke the service, such as a WSDL document;
> and Produces an XML result that can be usefully processed by
> conventional software without human intervention."

Good definition!

Perhaps the realization of an really unambiguous definition is
somewhat complicated ...

Should we limit ourself to services solely deploying XML as
communication mechanism? What about XForm-based services shipping
their input parameters via HTTP POST?

>Cheer up, it gets worse :~) We're going to encounter some semantic dragons
>if we try to limit web services to "XML"
+1

> I'm just saying that we have our work cut
> out to define "web service" without getting too picky about exactly what
> role "XML" must play in the definition.
+1

> Rather than trying to
> draw a hard line, let's accept that there is a large grey area in the
> middle, warn our readers that it exists, and illustrate our definition
with
> pure cases of web services and not-web-services, and clarify our position
> on
> some interesting corner cases, much like those that David Orchard outlined
> yesterday.

We think the layered approach suggested above could exactly do
that.

> I believe that our charter specifies that XML must be used. [1]
Sure, our solution "must be based on XML." But what about HTTP
(i.e. a non-XML protocol ;-) then?


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

No. An undescribed Web Service is still a Web Service.

>Please note that it is important that SOAP not be REQUIRED
>in order to qualify as a Web services.
Neither be WSDL.

> It is also important to note that the
> network protocol
> not be restrictive
+1

> 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.

> 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.

struggling, too.

> "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.
+1

> 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 ...

+1

> 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.

+1

> To develop a standard reference architecture for web services that:
> AG001 ensures the interoperability of web services software products from
> different implementors based on well-defined standards
+1

> AG002 provides modularity of web services components, allowing for a level
> of granularity sufficient to meet business goals
+1

> AG003 is sufficiently extensible to allow for future evolution of
> technology
> and of business goals
+1

> AG004 ensures platform independence of web services components in a way
> that
> does not preclude any programming model nor assume any particular mode of
> communication between the individual components
+1

> AG005 provides simplicity and ease-of-use that does not impose high
> barriers
> to entry for users of web services
+1

> AG006 addresses the security of web services across distributed domains
and
> platforms
-1. see above.

> AG008 is coherent and consistent in its definition
+1

> AG009 is aligned with the semantic web initiative at W3C and the overall
> existing web architecture
+1

> AG010 uses XML technologies in the development of the web services
> architecture to the extent that this is compatible with the overall goals
> of the group
+1

> AG011 is consistent with the existing web and its heterogenous environment
> and distributed architecture to the greatest extent possible.
+1

> In addition, the Working Group will also act to:
> AG012 evangelize and promote the benefits of web services to potential
> users, both consumers and producers
:-)

> AG013 co-ordinate the development of web services within W3C, together
with
> other W3C Working Groups where there is overlap among their problem
domains
+1

> AG014 serve as liaison with groups outside W3C who are working on web
> services in order to achieve interoperability and reduce duplication of
> effort
+1

Cheers,
 Mario and Barbara

-----------------------
Mario Jeckle
mario.jeckle@daimlerchrysler.com
DaimlerChrysler Corporate Research
DaimlerChrysler Forschungszentrum Ulm
PGP public key: http://www.jeckle.de/marioJeckle.pub

URL: http://www.jeckle.de
-----------------------

Received on Monday, 25 February 2002 16:46:15 UTC