W3C home > Mailing lists > Public > public-ws-chor@w3.org > May 2003

Handling phone and fax using WSDL

From: Assaf Arkin <arkin@intalio.com>
Date: Tue, 20 May 2003 14:37:43 -0700
Message-ID: <3ECAA027.30500@intalio.com>
To: public-ws-chor@w3.org

This is a use case I submitted before. One of the issues we had to 
tackle was the unfortunate but very realistic fact that not all 
communication is done using SOAP. Some is and will forever be done using 
alternative technologies like phone, fax and snailmail.

The question then becomes, can you write a choreography that uses 
technologies like WSDL and still doesn't get confused when things happen 
offline. There are a lot of creative ways to extend WSDL/SOAP, perhaps 
by proposing bindings to VoiceML and FaxML ;-) But I think the simple 
answer lies in how systems are used right now to handle voice-based 
protocols, hardcopy documents, etc.

Supply Acme Co. has an automated system for fulfilling orders. The
supplier works with some customers that have an automated procurement
system and both use SOAP to conduct transactions electronically.
However, some customers have not automated their system. Acme Co. would
like to conduct business with these customers and do so in an automated

Acme Co. develops a Web-based front end system for these customers using
HTTP and HTML technologies. Customers log into the system using their
customer identifier and are able to place orders, track their status and
print out invoices. Acme Co. also has a helpdesk which allows customers
to conduct transactions offline. A customer may send an order by fax, or
call to check the order status, and an Acme Co representative would use
the Web-based front end system to perform an online operation on their

Acme Co would like to have one definition for all transactions involving
its customers regardless of technology. The business semantics are
identical whether information is exchanged using SOAP, through the
Web-based front-end or with the help of a representative. Acme Co
realizes that reducing the number of business processes it needs to
support would improve its efficiency.

Acme Co choses the proxy approach. It defines a single choreography that
would be used for all transactions with its customers. The choreography
is expressed in the form of WSDL operations that are performed by its
order fulfillment service and the customer's procurement service.
Protocol bindings and service end-points are defined for those customers
that use SOAP. The Web-based front end and helpdesk systems are defined
as services that implement the role of a procurement system as defined
by the customer process in that choreography. In this particular case it
uses SOAP to communicate with fulfillment system.

Although the Web-based front end is running in the same environment as
the order fulfillment service, it is considered to be a customer
service. When it exchanges messages it uses the security credentials
given to the customer and not those of Acme Co to prevent one customer
from learning about orders belonging to other customers.

This distinction is important. From a technological perspective both
Acme Co's and the customer's service run in the same domain of control.
However, from a business perspective these are two different domains of
controls, and customers are identified as different non-overlapping
domains of control. Acme Co manages its policy with regards to each
customer in a uniform manner regardless of which technology is used to
conduct the transaction or how far SOAP messages have to travel.

Once completed, Acme Co has:

- A uniform representation of the choreography between its fulfillment
service the the customer procurement service
- A single business process to maintain
- The means to support customers that do not have automated processes
using the uniform model
- A mechanism to support its security policies regardless of "location"
of the customer service
Received on Tuesday, 20 May 2003 17:40:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:05 UTC