Re: Initial Usecases List

Waqar, et al:

Good list of use cases.  I will have a few to add as well.

Just so there is no misunderstanding, ebXML message services support both 
data and document transfers.  Your UC006 would certainly qualify as an 
ebXML document transfer (e.g., scanned physician prescription), but a 
document attachment is an option, not a requirement, of ebXML messaging.

Alan Kotok
Editor, < E-Business*Standards*Today />
http://www.disa.org/dailywire/
Data Interchange Standards Association
akotok@disa.org
+1 703-518-4174



At 10:44 AM 2/18/02 -0600, Sadiq, Waqar wrote:

>
>
>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: <mailto:waqar.sadiq@eds.com>waqar.sadiq@eds.com
>
>fax: +01-972-605-4071
>
>_______________________________________________
>
>
>
>
>
>

Received on Tuesday, 19 February 2002 10:54:09 UTC