Re: potential users of web services

In the SQL world the distinction between machines and humans was somewhat clear
although the original vision included humans entering adhoc SQL queries and
scrolling through the results via a generic SQL client.

In the web world the distinction between humans and programs is a bit more
difficult to draw and with XML it has become less distinct.

While humans shouldn't be typing in raw SOAP RPC messages and programs shouldn't
have to screen scrape HTML pages, they both will likely be interacting with
services via XML schemas.

The issue is not so much human vs program as it is the tension between
convention 'API' model of a service and 'purer' XML/web models. Both are easy
for machines to understand (even if programmers are currently gravitating to the
'API' view as simpler).

Some services will be so complex that interacting with them will require service
specific clients. Other services will be simple enough for humans to use from a
general purpose 'browser' client as well as being practical for programs to use.

One of the critical issues facing this WG is how to architect web services to
maximize their generality and composability. While WUST does break down some
technology barriers faced by previous RPC technologies, it doesn't do much to
change the essential equation that 'APIs' are difficult to compose and don't
represent information very well.

-- Mark

Anne Thomas Manes wrote:
> 
> IMHO, a web service is a component that is invoked using a programmatic API,
> hence it is not a user-driven application. If a web service determines that
> it needs more input, then either it returns an error or it contains some
> logic that allows it to obtain more input. It can obtain that input by
> initiating an interaction with a user (which sounds to me like it's still
> service-driven, not user-driven), or it might queue a request up on a
> workflow process, or it might call some other service or program that knows
> how to obtain the input.
> 
> I'm not saying that you can't build a UI-driven application with web
> services. What I'm saying is that web services themselves aren't UI-driven.
> 
> I believe that it's important to distinguish between a web service and an
> application that has been constructed using web services. Let me illustrate
> with an analogy. A database is an example of a service. You communicate with
> it using a programmatic API (SQL). The database isn't a UI application, but
> you can certainly build UI applications that utilize the database service.
> 
> Anne
> 
> > -----Original Message-----
> > From: Timothy N. Jones [mailto:tim@crossweave.com]
> > Sent: Thursday, April 04, 2002 2:50 PM
> > To: Anne Thomas Manes
> > Cc: thomi@di.uoa.gr; www-ws@w3.org; www-ws-arch@w3.org
> > Subject: RE: potential users of web services
> >
> >
> >
> > I would have to object to the separation of UI and web service described
> > below on the grounds that it appears incompatible with the notion of
> > interactive web services.  For example, it seems reasonable that at some
> > point along a web service call chain a service could dynamically determine
> > that it needs additional information from the user to complete its task.
> > Unless UIs are able to themselves be web services I think the WS
> > architecture will not be able to support user-driven applications, which
> > would be an unfortunate limitation.
> >
> > Regards,
> > Tim Jones
> > CrossWeave, Inc.
> >
> > > Thomi,
> > > Ask five people the definition of "web service" and you'll get six
> > answers.
> > > I generally describe a web service as a service that
> > communicates over the
> > > web. A service is a component that exposes a programmatic interface. The
> > > service interface must be described; and the service implementation must
> > be
> > > discoverable.
> > > When you relate this abstract definition to current
> > technologies, you can
> > > implement a web service by creating a service that exposes a SOAP
> > interface,
> > > which is described by WSDL, and which is registered in UDDI. But I
> > wouldn't
> > > want to use current technologies to *define* the basic concept. I also
> > don't
> > > think that it's essential to use any of these technologies to
> > create a web
> > > service. I can certainly create a web service using XML-RPC or
> > RosettaNet
> > or
> > > a host of other technologies.
> > > That said, I would concur that web services are intended to be
> > consumed by
> > > applications rather than humans. But keep in mind that a user
> > interface is
> > > an application. If I wanted to arrange food for 500 people for two weeks
> > in
> > > Dubai, I would use a catering application, which in turn uses
> > web services
> > > to find caterers that can provide services in Dubai. The UI
> > isn't the web
> > > service. The UI uses web services to accomplish its work. Hence an ASP
> > page
> > > or HTML form aren't web services, they are an interface to web services.
> > > Best regards,
> > > Anne Thomas Manes
> > > CTO, Systinet
> > > > -----Original Message-----
> > > > From: www-ws-request@w3.org [mailto:www-ws-request@w3.org]On
> > > > Behalf Of Thomi Pilioura
> > > > Sent: Thursday, April 04, 2002 9:09 AM
> > > > To: www-ws@w3.org
> > > > Subject: potential users of web services
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > I'm little confused about the notion of the term "web services".
> > > > When I'm reading papers related to UDDI,WSDL,SOAP they present
> > > > web services
> > > > as a new age of distributed computing and as such they are only useful
> > to
> > > > developers (who are trying to build web applicattions) and not to the
> > > > end-users. But when I'm reading papers related to DAML-S the idea I'm
> > > > getting for web services is different. They are also useful to
> > > > end users as
> > > > it shown by DAML-S motivating scenarios:
> > > >
> > > > Web service discovery
> > > > Find me a shipping service that transports goods to Dubai.
> > > >
> > > > Web service invocation
> > > > Buy me 500 lbs. powdered milk from www.acmemoo.com
> > > >
> > > > Web service selection, composition and interoperation
> > > > Arrange food for 500 people for 2 weeks in Dubai.
> > > >
> > > > Web service execution monitoring
> > > > Has the powdered milk been ordered and paid for yet?
> > > >
> > > > There are also numerous papers that use the term service (and not "web
> > > > service") and are talking about UDDI, WSDL and DAML-S. What's the
> > > > difference
> > > > between "web service" and "service" if both of them work over
> > > > Internet? For
> > > > example, a search engine (such as google) is a service, but when it is
> > > > described in WSDL, published in UDDI and can be invoked using
> > > > SOAP becomes a
> > > > web service? Ia a asp or an HTML form a service or a web service?
> > > >
> > > > In summary which are the potential users of web services (web service
> > > > providers, developers, end-users)?
> > > >
> > > > could you please shed some light on this?
> > > > regards
> > > > Thomi Pilioura
> > > >
> > > >
> > > >
> > > >
> >
> >

Received on Thursday, 4 April 2002 22:34:16 UTC