W3C home > Mailing lists > Public > www-ws-desc@w3.org > February 2002

Initial Usecases List

From: Sadiq, Waqar <waqar.sadiq@eds.com>
Date: Mon, 18 Feb 2002 10:44:01 -0600
Message-ID: <9C79F2D39765D411B18900508BE326A20A82EE80@USPLM208>
To: www-ws-desc@w3.org
 
Hi all,
 
I have an initial and short list of use cases that I wanted to let everyone
take a peak at.  Prasad and I hope to add a few more to this before our next
con. Call but I thought it would not hurt to let the group see what we have
sooner.
 
 
 
////////////////////////////////////////////////////
UC0001 - Fire-and-forget: A metrics collection service exposes an interface
for applications running in an environment to report their application usage
metrics.  Instead of reporting individual metrics, these applications report
a computed sum that represents the summary of usage their usage.  Therefore,
the loss of a message is not important because the next update will again
provide an updated summary.  The target web service exposes an interface to
report those metrics.  In the interest of efficiency, the client
applications are not interested in receiving any faults because and just
want to send a message and forget about it until the next time.
 
UC0002 - One-way message with guaranteed delivery:  A web service provides a
messaging service.  This web service is a higher level interface over
enterprise messaging capabilities such as JMS.  On the publisher side, it
exposes an interface that allows applications to publish messages to a
logical messaging channel.  The publishing clients do not expect to receive
a response to their invocation however it is important for them to know that
the message has been delivered.  So while they make a one-way request, they
do want receive faults if the message could not be successfully published,
whether due to a system error on the server side or due to an application
error on the server side.
 
UC0003 - Multiple faults:  A web service interface method can fail due to
several reasons.  The faults raised by the method may be semantically
different from each other and further more, some of the faults may be
standard faults defined for a group of web services.  For example, in an
accounting system, there may be a general "creation fault" defined for
indicating the failure such as out of resources or PO already exists.  The
creation of PO could also fail because the data provided to initialize the
PO is invalid.  The web service method "createPO" might then fail because of
any of the reasons described above and may want to raise separate faults
depending on the reason for failure.
 
 
UC0004 - Service level attributes: Two web services, implementing the
interface for "looking up for insurance providers", from different sources
are offered in a registry.  One of the two services actually performs
extensive data validation on the data provided, for example making sure that
the zip codes in the address provided are valid", while the other web
service assumes that the data provided is valid and searches for insurance
providers has already been validated and uses it to perform its search
without any further validation.  The interface was developed by an industry
consortium that agreed to reflect the data validation capability of the
services as a service-level attribute.  Some intelligent registries may then
actually allow search criteria that can be predicated on these service-level
attributes or alternatively, the client application may check the value of
the service level attribute itself at runtime to find out its value.  The
service-level attribute may be mapped to accessor methods which can be
invoked either by the intelligent registry as part of executing the search
query or by the client application itself.
 
UC0005 - Operation-level attributes:  In an advanced architecture where
distributed transactions are supported, a web service may want to declare
some of its operations as transactional as opposed to the entire interface
being transactional.  A web service offering various financial related web
services may be able to verify a buyer's credit in a non-transactional
manner but may require the client application to start a transaction before
invoking the operation to prepare an invoice.  The target web service may
have a declarator on the method specification that indicates that the
operation for invoicing requires transaction.
 
 
UC0006 - Document centric computing: A web service is ebXML based web
service that requires document-oriented computing.  The operations that its
interface includes are all actually asynchronous messages with no
parameters.  All the data to the messages is sent as document attachments.
Its description document will then describe the data expected by its
operations in terms of the expected attachments and not in terms of its
parameters.
////////////////////////////////////////////////////
 
Thanks,
 
 
 
 
_______________________________________________
Waqar Sadiq
 
EDS EIT EASI - Enterprise Consultant
MS: H3-4C-22
5400 Legacy Drive
Plano, Texas 75024
 
phone: +01-972-797-8408 (8-837)
e-mail: waqar.sadiq@eds.com <mailto:waqar.sadiq@eds.com> 
fax: +01-972-605-4071
_______________________________________________
 
 
 
Received on Monday, 18 February 2002 11:44:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:18 GMT