SWSF Application Scenarios

Version 1.0

Authors:
Steve Battle (Hewlett Packard)
Abraham Bernstein (University of Zurich)
Harold Boley (National Research Council of Canada)
Benjamin Grosof (Massachusetts Institute of Technology)
Michael Gruninger (NIST)
Richard Hull (Bell Labs Research, Lucent Technologies)
Michael Kifer (State University of New York at Stony Brook)
David Martin (SRI International)
Sheila McIlraith (University of Toronto)
Deborah McGuinness (Stanford University)
Jianwen Su (University of California, Santa Barbara)
Said Tabet (The RuleML Initiative)

Abstract

This document presents several use cases that illustrate SWSO -- the Semantic Web Services Ontology, and SWSL -- the Semantic Web Services Language developed by the committee.

Status of this document

This is one of four documents that make up the initial report of the Semantic Web Services Language Committee of the Semantic Web Services Initiative. The report defines the Semantic Web Services Framework (SWSF).

History of publication at http://www.daml.org/services/swsl/report/applications/:

History of publication at http://www.daml.org/services/swsf/applications/:


Table of contents

1 Introduction
2 Use Cases Illustrating the Conceptual Model
3 The Amazon E-commerce Service
4 Service Discovery with SWSL-Rules
5 Policy Rules for E-Commerce
6 Using Defaults in Domain-Specific Service Ontologies
7 Glossary
8 References


1 Introduction


This document is part of the technical report of the Semantic Web Services Language (SWSL) Committee of the Semantic Web Services Initiative (SWSI). The overall structure of the report is described in the document titled Semantic Web Services Framework Overview. The present document discusses a number of use cases that illustrate the Semantic Web Services Ontology (SWSO), which is defined in a separate document, and the Semantic Web Services Language (SWSL), which is also described separately.

Section 2 presents use cases that illustrate various aspects of SWSO with emphasis on the process model. Section 3 considers a particular use case, the Amazon.com service, and shows how SWSO and SWSL can be used to describe this service. Section 4 focuses on the problem of Web service discovery and shows how services, user goals, mediators, and the discovery engine itself can be defined in SWSL-Rules, which is a sublanguage of SWSL. Section 5 presents use cases for policy specification in e-commerce and shows how these cases can be specified in SWSL-Rules. Finally, Section 6 uses SWSL-Rules to illustrate the need for non-monotonic inheritance and overriding in domain-specific service ontologies.

2 Use Cases Illustrating the Conceptual Model

We introduce here several examples, which are useful in illustrating selected aspects of the Process Model portion of the Conceptual Model underlying the FLOWS Ontology. Section 2.1 focuses on human-machine interactions, and describes a hypothetical on-line bookseller. The example illustrates aspects of atomic processes, fluents, and messages. Section 2.2 focuses on machine-machine interaction, and illustrates the use of channels, and the possible FLOWS-Core extensions for Guarded Automata and Meta-Server. Finally, Section 2.3, illustrates the flexibility of the conceptual model, by showing briefly how it can be applied to specify services coordination in a telecommunications context.

2.1 Illustration of Atomic Processes and Messages

This example focuses on a web service Acme_Book_Sales, that provides support for the external web presence of the hypothetical Acme book selling business. We focus primarily on the occurrences of the Acme_Book_Sales service that interact with end-users (modeled abstractly as service occurrences), and mention only at a high level some aspects of the interaction of occurrences of this service with other services (e.g., to arrange for credit card charges and shipping). In the following we describe (i) three of the domain-specific fluents manipulated by occurrences of Acme_Book_Sales, (ii) four atomic processes used by Acme_Book_Sales, (iii) four of the types of message that Acme_Book_Sales can send or receive, and (iv) finally a typical process flow in occurrences of Acme_Book_Sales.

Note that the domain-specific fluents described here might be accessed by services operated by Acme other than the service Acme_Book_Sales, and perhaps accessed by services operated by enterprises other than Acme. (E.g., a shipper might have read or read/write access on some of these fluents.) Likewise, the atomic processes used in the service Acme_Book_Sales might be used in the specification of other services (supported by Acme or other enterprises).

The description here is intended to illustrate certain aspects of the process model of the SWSL conceptual model, and is not intended to provide a complete specification of the Acme_Book_Sales service. (In any event, recall that SWSL can support both complete and incomplete specifications of services.) We focus on three domain-specific fluents:

      Book_info[ 
	  ISBN => xsd#string,
	  Title => xsd#string,
	  Author => xsd#string
      ].
    
For each book that Acme is selling, this fluent holds a record (i,t,a) for each author of the book, where i is the ISBN number, t is the title, and a is the author name.

(For simplicity of exposition, this is not, in the parlance of relational databases, in Third Normal Form.) Note that some books listed in Book_info may not be in Acme's stock at a given time.

      Book_inventory[
	  ISBN => xsd#string
	  warehouse_id => xsd#string,
	  quantity_on_hand => xsd#integer
      ].
    
We assume that the Acme company operates multiple warehouses, and that copies of a given book might be available from one or more of these warehouses.
      Book_reservation[
	  ISBN => xsd#string,
	  user_id => xsd#string,
	  warehouse_id => xsd#string
      ].
    
When a user puts a book in their shopping cart, this corresponds to a commitment by Acme that it will actually ship the book if the user commits to the purchase (and the payment details are successful). To this end, Acme has to reserve a copy of the book while the user is deciding whether to commit. The fluent Book_reservations is intended to hold triples of the form (u,i,w), that will indicate that a copy of the book with ISBN number i is being held at warehouse w for user u.

We now overview four atomic processes used by Acme_Book_Sales. The description here is somewhat informal and is intended to provide an intuitive understanding, not a formal specification.

      book_search[
	  input => book_descriptor[ISBN => xsd#string,
                                   title => xsd#string,
				   authors => Person,
                                   keywords => xsd#string],
	  output => book_record[ISBN => xsd#string, 
	                        title => xsd#string, 
	                        authors => xsd#string],
	  effect => Formula  // focused on output only
      ].
    
This process supports searches against the full catalog of books sold by the bookseller. The input argument for this may include precise information such as ISBN, title, author, and/or may include more open-ended information such as key-words (in the title), partial author names, etc. This atomic process returns a (possibly empty) list of books that satisfy the search criteria. There are no side-effects.
      book_reserve[
	  input => reservation_input[user_id => xsd#integer,
                                     ISBN => xsd#string],
	  output => reservation_output[warehouse => xsd#string,
                                       expected_ship_date => xsd#date],
	  effect => Formula
	     // the effect is supposed to be: if the book is available, then
             // decrement quantity of book for this warehouse,
	     // insert record into the "reserved" relation
	     // if not, then no effect
      ].
    
Intuitively, this process corresponds to a user putting a book into her shopping cart. In this case, Acme commits that it can in fact ship the book. So it decrements the quantity of copies available from one of the warehouses, and puts a record into the Book_reservations fluent.
      reservation_cancel[
	  input => cancellation_result[user_ID => xsd#integer, ISBN => xsd#string],
	  output => success_flag_type,
	  effect => Formula 
             // Intended effect:
	     //    If the book is reserved for this user
	     //    remove appropriate records from "reserved" relation,
	     //    increment quantity of book for appropriate warehouse,
	     //    set success_flag to true;
	     //    if not set success_flag to false;
      ].
    
      book_shipment[
	  input => ship_type[user_ID => xsb#integer,
                                ISBN => xsd#string],   // list of ISBNs
	  output => xsb#integer,                      // confirmation_#;
	  effect => Formula
	     // Intended effect: Assuming no exceptions,
	     //    remove appropriate records from "reserved" relation,
	     //    (possibly, move a copy of book to loading dock);
      ].
    
These atomic processes deal with "clean up" concerning reserved books. reservation_cancel effectively cancels out the reservation of the book, and book_shipment records the fact that the book should really be shipped (and might include physically moving a copy of the book to a loading dock).

So far we have focused on how occurrences of Acme_Book_Sales "interacts" with domain-specific fluents. What about interaction with other services, and with humans (which are modeled as services)? Some of the messages that Acme_Book_Sales can send and receive include the following. As before, the description of argument types is for intuitive purposes only.

      book_search_request(User_ID: string, search_criteria: search_criteria_type)
    
A user can send a message of this type to an occurrence of Acme_Book_Sales. The single argument is an amalgam of whatever search criteria the user has specified. In practice we would expect this argument to be assembled by the user interface code running on the user's web browser and Acme's web server, based on the inputs of the user into her browser.
      book_search_response(ISBN: string, title: string, list_of [author: string])
    
This message can be sent by an occurrence of Acme_Book_Sales to a user, indicating information about zero or more books that Acme is selling.
      shopping_cart_request(user_ID: string, ISBN: string)
    
This message can be sent by a user to an occurrence of Acme_Book_Sales, indicating that the user wants the specified book to be put into her shopping cart.
      book_availability_response(ISBN: string, title: string,
                                 list_of [author: string], ship_date: date)
    
This message can be sent by an occurrence of Acme_Book_Sales to a user, indicating that the indicated book is available, and can be shipped to the user on ship_date.

Acme_Book_Sales is capable of sending and receiving several other types of message. This includes messages from the user to commit to a purchase, and to put in credit card information, and messages back to the user to confirm various operations. It includes messages between occurrences of Acme_Book_Sales and banking services, and between Acme_Book_Sales and shipping services.

Acme_Book_Sales process flow

Figure 2.1: Part of process flow for Acme_Book_Sales service activity

Example 2.1(a): Atomic Processes and Internal Process Model. We now briefly discuss a partial specification of the permitted process flow of atomic process occurrences in interpretations of the theory for this application domain. Figure 2.1 illustrates a portion of this process flow, using a flow-chart paradigm. In terms of a formal domain theory, this (or something equivalent) could be specified using the Control Constructs extension of FLOWS-Core, or by using more primitive PSL-OuterCore predicates such as soo_precedes.

A notable aspect of the process flow indicated in Figure 2.1 is that there is not necessarily a one-to-one correspondence between messages being sent by a user and invocations of atomic processes in the occurrence of Acme_Book_Sales. Specifically, after an Read_Message occurrence of kind book_search_request, there will be an occurrence in Acme_Book_Sales of the atomic process book_search, with the appropriate input argument. If zero or more than one books is output from this atomic process occurrence, then there is a Produce_Message occurrence that creates a message of type book_search_response. (Presumably, this is followed by an appropriate Read_Message occurrence in the end-user.) However, if exactly one book was returned by the book_search occurrence, then in the occurrence of Acme_Book_Sales there is an occurrence of book_reserve. Intuitively, this is a pro-active step by Acme_Book_Sales, in order to provide for the user information about availability and possible shipping date of this book. If the book is available, then in Acme_Book_Sales there is a Produce_Message occurrence that produces a message of type book_availability_response. (If the book is not available, then in Acme_Book_Sales there would be a Produce_Message occurrence that creates a message of type book_search_response, or perhaps of a different type, that includes the fact that the book is currently unavailable.)

(We note that if the end-user has a Produce_Message occurrence that creates a message of type book_search_request then the response message may have one of two kinds. We assume that the Acme web server and the user's web browser software will present these to the user in an appropriate manner.)

It is possible, using the knowledge pre-conditions and conditional effects portion of the FLOWS-Core ontology, to precisely characterize the flow of information between atomic process occurrences in an occurrence of the Acme_Book_Sales service. One application of this capability would be to support a form of de-bugging, in which one could verify that a domain theory for a service such as Acme_Book_Sales provides for the flow of information needed to support a desired objective. Another application of this capability is presented in the next example.

Example 2.1(b): Inferring Message Production and Reads We now consider a variation, in which the domain theory T for Acme_Book_Sales includes two parts:

Here, the family T2 of constraints might be used in a variety different contexts involving services that embody many different variations of Acme_Book_Sales.

Imagine now that we want to study the possible occurrences satisfying the theory T1 union T2, in which a user's goal is to buy a book with a given ISBN#. Suppose further that o is an occurrence of the overall system in which the user's goal is achieved. From the constraints in T1 one can infer properties of o concerning the actual ordering of the domain-specific atomic process occurrences, the input and output values associated to those occurrences, and the values of the domain-specific fluents. Furthermore, one can use T2, along with axioms from the FLOWS-Core ontology, to infer that certain messages must have been produced and read in o, and infer some of the characteristics of the payloads of those messages. Thus, assuming that an appropriate family T2 of constraints is specified, one can specify the full behavior of a web service by specifying only the domain-specific atomic processes involved that service. In particular, the message-handling atomic processes of the service can be inferred, and do not have to be specified explicitly.

2.2 Illustration of Channels, Meta-Service, Guarded Automata

We now describe the Store-Warehouse-Bank example, which is based loosely on an example in [Bultan03] (see also [Hull03]). As suggested in Figure 2.2 below, we assume the existence of three entities, namely a (bricks-and-mortar) Store, a Warehouse, and a Bank. (Unlike the example of Subsection 2.1, the store here is assumed to maintain a physical inventory on premises.) For each entity we focus on one of the several web services that it might perform; these have the following names:

Store_inventory_maintenance
A "back-office" service, that attempts to ensure that the for each item sold by the store, the available stock at the store remains above some threshold.
Warehouse_order_fulfillment
This service running at the Warehouse responds to orders from the Store. As part of its operation it charges an account of the Store held at the Bank.
Bank_account_maintenance
This service running at the Warehouse responds to orders from the Store. As part of its operation it charges an account of the Store held at the Bank.

In the following we describe, for the three services, (a) the domain-specific fluents they can access and manipulate, (b) the atomic domain-specific atomic processes in them, and (c) the kinds of messages that they can create, read, and destroy.

(FLOWS-Core does not consider parameter typing, but we include types here as an intuitive convenience. The use of structured values in message parameters, and atomic process outputs, can in principle be provided in extensions of FLOWS-Core, such as Relation-valued Parameters and XML-valued Parameters; see Section 3.7.2.)

For this example, we assume the following service-specific fluents and relations:

Bank_accounts(account_id:int, owner_id:int, balance:int)
This fluent holds data on bank accounts. It is accessed and maintained exclusively by some services associated with the Bank (including Bank_account_maintenance).
Store_inventory(item_id:int, quantity:int)
This fluent holds data on inventory held by the store. It is accessed and maintained exclusively by some services associated with the Store (including Store_inventory_maintenance).
Warehouse_inventory(item_id:int, quantity:int)
This fluent holds data on inventory held by the warehouse. It is accessed and maintained exclusively by some services associated with the Warehouse (including Warehouse_order_fulfillment. (For simplicity, we assume that the Store and Warehouse use the same numbering system.)
Goods_in_transit(shipment_id:int, shipping_date:date, expected_delivery_date:date, transport_content_list_id:int)
This fluent holds data on goods that are being shipped (from the Warehouse to the Store). For this example, we assume that it can be viewed by some services associated with the Warehouse and the Store. (In practice, this fluent might be maintained by yet another service, e.g., operated by an entity Shipper. In that case, services associated with the Store and Warehouse might "read" information in Goods_in_transit by exchanging messages with a service operated by Shipper.)
Transport_content_lists(transport_content_list_id:int, item_id:int, quantity:int)
This relation holds the contents of shipments. (The approach to modeling taken by this fluent is suggestive of how the extension Relation-Valued Parameters on FLOWS-Core might be constructed.) It can be accessed by the same services that can access Good_in_transit.
Wholesale_order_content_lists(wholesale_order_id:int, item_id:int, quantity:int)
Similar to Transport_content_lists, this relation holds the contents of orders (made by the Store against the Warehouse). This fluent can be read by some services associated with the Store and the Warehouse. (The reader may wonder why this is not a fluent. The answer is that the association between wholesale_order_id's and the item_id,quantity pairs need not vary over time -- it can be viewed as fixed for the duration of the execution of the overall system being modeled. In particular, a given wholesale_order_id will be used in exactly one message payload, and so there is no need to override the item_id,quantity pairs associated to it.)

At least the following kinds of domain-specific atomic processes can be performed by the various services.

Create_account(owner_id:int, account_id:int, initial_balance:int)
Modify_account_balance(account_id:int, amount:int)
These have the expected semantics, and can be performed by occurrences of Bank_account_maintenance (and perhaps other services associated with the Bank).
Transfer_funds(source_account_id:int, target_bank_id:int, target_account_id:int, amount)
This atomic activity is performed by occurrences of Bank_account_maintenance (and perhaps other services associated with the Bank). The source account must be maintained by the Bank service (the target might be another bank), and the source account must have enough funds to cover the transfer.
Send_shipment_from_warehouse(shipment_id:int, transport_content_list_id:int, ship_date:date)
This atomic activity is performed by occurrences of the Warehouse_order_fulfillment service. It corresponds intuitively to the situation where a physical shipment is created by the warehouse (for the store). The primary pre-condition is that there is enough inventory in Warehouse_inventory; the conditional effect is to update Warehouse_inventory, Goods_in_transit and Transport_contents_lists appropriately. In practice, occurrences of this atomic activity will occur after a message is received from the Store, requesting a shipment of goods.
Receive_shipment_to_store(shipment_id:int, transport_content_list_id:int, receive_date:date)
This atomic activity is performed by occurrences of the Store_inventory_maintenance service. It corresponds intuitively to the situation where a physical shipment is received by the store (from the warehouse). One pre-condition is that there is a record in Goods_in_transit with this shipment_id. (Additional pre-conditions might be based on dates.) The primary conditional effect is that the Store_inventory and Goods_in_transit are updated appropriately.

We mention two additional atomic domain-specific activities that are associated with the Store and Bank, respectively, but which do not arise in the services Store_inventory_maintenance or Warehouse_order_fulfillment.

Sell_to_buyer(buyer_id:int, retail_order_id:int, price:int)
This atomic activity corresponds intuitively to the situation where an individual makes a purchase at the store. As with orders against the Warehouse, an additional fluent Retail_order_content_lists(retail_order_id:int, item_id:int, quantity:int) can be maintained to hold the list of goods involved in a retail order. The pre-condition on this atomic activity is that there is sufficient inventory at the Store, and the conditional effect is that the Store_inventory is updated appropriately.
Receive_shipment_to_warehouse(shipment_id:int, transport_content_list_id:int, ship_date:date)
This atomic activity corresponds intuitively to the situation where a physical shipment is received by the warehouse (from a service not discussed in the example). The conditional effect is to update Warehouse_inventory appropriately.

Finally, we turn to the kinds of messages that the three services can exchange.

request_account_creation(store_id:int; account_amount:int)
Intuitively, this message requests establishment of an account by the Bank for the Store in the given amount.
acknowledge_account(account_id:int, account_balance:int)
Intuitively, this message acknowledges the establishment of an account by the Bank for the Store, and provides the (newly created) account_id, along with current balance.
account_balance_inquiry(store_id:int; account_id:int)
Intuitively, this message requests the current balance of a bank account.
account_balance_report(account_id:int, account_balance:int)
Intuitively, this message gives the current balance in an account.
place_order(order_id:int, store_id:int, wholesale_order_id:int, bank_account_id:int, stop_attempt_date:date)
Intuitively, this message places an order by the Store against the Warehouse. It will fail if there is not sufficient inventory in the Warehouse to fill the order. In that case, the Store wants the Warehouse to keep trying to fill the order until stop_attempt_date. (The list of things ordered is found in the fluent Wholesale_order_contents_lists, associated with the value of wholesale_order_id; see Example 2.2(a) below.)
fulfill_order_commitment(order_id:int; shipment_id:int)
Intuitively, this message indicates that an order against the Warehouse will be filled, and provides the shipment_id. (Further information on the shipment can be obtained from the fluents Goods_in_transit and Transport_contents_lists.)
reject_order(order_id:int)
Intuitively, this message indicates that an order against the Warehouse cannot be filled.
bill_for_goods(account_id:int; order_id:int, bill_amount:int, target_bank_id:int, target_account_id:int)
Intuitively, this message indicates that the Warehouse is sending a bill to the Bank for payment from the specified account. Here the value of target_account_id is intended to be a bank account of the Warehouse; it might be maintained by the Bank highlighted in this example or by some other bank (as indicated by the value of target_bank_id).
payment_for_goods(account_id:int; order_id:int, payment_amount:int target_account_id:int)
Intuitively, this message indicates that the Bank is making a payment of the specified amount to the Warehouse.

Example 2.2(a): Relation-valued parameters. Using the above we can illustrate concretely the approach described in Subsection 3.7.2 for supporting in FLOWS-Core parameters having the form of relations (rather than having form essentially equivalent to single objects or scalars). Consider the message type place_order, whose third argument is wholesale_order_id. Speaking intuitively, to understand the information conveyed by the third argument, one must look at the relation Wholesale_order_content_lists(wholesale_order_id, item_id, quantity). In particular, a given value W for wholesale_order_id will be associated by Wholesale_order_content_lists with a set of item_id,quantity pairs; these will correspond to the set of items (with quantities) that the Store is ordering.

In a similar manner, the output parameter transport_content_list_id of atomic process Send_shipment_from_warehouse identifies a set of item-quantity pairs, according to the relation Transport_content_lists.

FSM corresponding to process model
						 of Warehouse_order_fulfillment

Figure 2.2: Informal specification of representative process model for Warehouse_order_fulfillment, using paradigm of Guarded Automaton

Example 2.2(b): Guarded Automata. We now consider one approach to formally specifying a representative process flow for the activity associated with service Warehouse_order_fulfillment. This is illustrated in Figure 2.2, which shows informally a Guarded Automaton that specifies a possible behavior. This follows the spirit of the potential PSL extension of FLOWS-Core described in Subsection 3.7.6.

Intuitively, a typical flow of activity for (occurrences of) this service could be as follows:

  1. At the beginning, there would be a Read_Message atomic process occurrence of kind place_order, followed by a Destroy_Message occurrence (which destroys the message just read).
  2. An occurrence of atomic process Send_shipment_from_warehouse is next. Note that the automaton state reached after this occurrence has three out-edges. These are guarded by conditions, which in this case are disjoint. (In general, the conditions of edges from a given state of a guarded automaton may be overlapping, which models a form of non-determinism.)
  3. If this atomic process occurrence fails (e.g., because the warehouse does not have sufficient inventory) then the occurrence of Warehouse_order_fulfillment will include additional occurrences of atomic process Send_shipment_from_warehouse, if the current time precedes the stop_attempt_date specified as an argument of the place_order message that was initially read.
  4. If there is a successful occurrence of Send_shipment_from_warehouse, then there is a Produce_Message occurrence that creates a message of type fulfill_order_commitment (intended for the Store), and there is a Produce_Message occurrence that creates a message of type bill_for_goods (intended for the Bank).
  5. If there is no successful occurrence of Send_shipment_from_warehouse, then there is a Produce_Message occurrence that creates a message of type reject_order.

Can a single occurrence of Warehouse_order_fulfillment accommodate many orders, or in other words, can it include many occurrences of the Read_Message atomic process of kind book_search_request? As specified in Figure 2.2, this is not possible; rather, a new occurrence of the service Warehouse_order_fulfillment will be needed for each message of type place_order coming from the Store. An alternative design for Warehouse_order_fulfillment would be to add transitions from the two final states shown in Figure 2.2, which point back to the start state. This would enable a form of sequential handling of order requests. A problem with this design is that it may take a long period of time to process a single order (in the case where there is looping on attempts to have successful execution of Send_shipment_from_warehouse). The next example describes how the use of a meta-service can enable a better design.

Example 2.2(c): Meta-Service In Subsection 3.7.1 above a potential extension for FLOWS-Core is described, in which "Servers" are used to support the orderly creation of occurrences of a given service. We illustrate that notion here, in the context of the Store-Warehouse-Bank example. In particular, we assume now that are Formal Servers Store_server, Warehouse_server, and Bank_server associated with the Store, Warehouse, and Bank.

We assume that server_service(Warehouse_server, Warehouse_order_fulfillment) holds. The fluent server_service might also associate other services with Warehouse_server, e.g., for making orders against manufacturing enterprises, for managing its own bank account, etc.

Suppose now that the service Warehouse_order_fulfillment has been specified so that an occurrence of this service is focused on fulfilling a single order placed by the Store (or other entities), basically as in Figure 2.2. If we use Warehouse_server, then the messages of type place_order will be read and destroyed by Warehouse_server. When such a message is read, then an occurrence of service Warehouse_order_fulfillment will come into existence. It would be typical for this new occurrence to start with a Read_Message occurrence, which reads a message produced by Warehouse_server (which might be essentially a copied version of the place_order message.) The new occurrence of Warehouse_order_fulfillment could then operate as specified in Figure 2.2.

Channels associated with services of Store-Warehouse-Bank example

Figure 2.3: Channels for the Store-Warehouse-Bank example

Example 2.2(d): Static and Dynamic Channels. We now consider how channels might be used in the Store-Warehouse-Bank example. Figure 2.3, illustrates how six pre-defined channels might be established between the three services (see Subsection 3.1.5). The figure also shows how the various message types are assigned to the channels. In a domain theory over FLOWS-Core, this would be achieved by asserting constraints such as channel_source(C5, Warehouse_order_fulfillment), channel_target(C5, Bank_account_maintenance), and channel_mtype(C5, bill_for_goods).

Suppose that constraints of this sort are specified in a domain theory, and also that a constraint is specified stating that all messages must be placed on a channel. Then specification of service behavior can be simplified. To illustrate, consider a Produce_Message atomic process that is a subactivity of Warehouse_order_fulfillment, and that creates messages of type bill_for_goods. For any occurrence of this atomic process, the message created will necessarily be placed on channel C5. Furthermore, only occurrences of the service Bank_account_maintenance will be able to read this message.

Suppose now that new Warehouses can be added to the overall system at arbitrary times. For example, suppose that a new service Alternative_warehouse_order_fulfillment becomes available at some time t. It might be natural in this case to create new channels C7 and C8, analogous to C3 and C4, but connecting Store_inventory_maintenance to Alternative_warehouse_order_fulfillment rather than to Warehouse_order_fulfillment. After this, occurrences of Store_inventory_maintenance could make orders against either warehouse.

A different approach to using the new warehouse service Alternative_warehouse_order_fulfillment would be to modify channel C3 by adding Alternative_warehouse_order_fulfillment as a new target, and to modify channel C4 by adding Alternative_warehouse_order_fulfillment as a new source. In an associated application domain theory, the destination of place_order messages might be non-deterministic, or might be determined by properties of the message payload and/or relevant fluents (e.g., the inventory at the two warehouses).

2.3 Illustration of Rich Internal Process Model

This brief example is intended to illustrate the flexibility of the FLOWS-Core ontology. Specifically, we illustrate how the framework can be applied in the context of services coordination for telecommunications, a discipline which has characteristics somewhat different than traditional e-commerce oriented, transaction-based web services. A basic building block in the deployment of telecommunications services is the notion of "session" (e.g., in which several people are in communication, possibly by multiple media), and a basic concern in telecommunications is dealing with asynchronous events (such as wireless connections dropping or pre-pay accounts running out) that might occur at essentially any time. The IETF Session Initiation Protocol (SIP) provides an extensible family of standardized protocols for initiating and maintaining communication sessions; this operates at a fairly low level in the network, tends to focus on a single media at a time, and addresses a variety of details concerning both signaling and real-time packet streams, the selection of codecs, etc. The 3GPP IP Multimedia Subsystem (IMS) reference architecture provides an architectural framework and a broad family of protocols extending core SIP, with a focus on enabling rich, flexible, and scalable communication services. We focus here on the use of the FLOWS-Core ontology for describing session management and orchestration at an even higher level, which can be realized on top of the SIP and IMS layers.

To illustrate, we describe a simple environment which includes 3 core services, namely, audio_bridge, video_server, teleconf_manager; and includes in essence a service corresponding to each kind of end-user device, say, device_1, ..., device_n. (E.g., perhaps we could have a service device_i for each style of cell phone currently available.)

The audio_bridge would support messages of the sort "initiate_audio_bridge" (in-going), "audio_bridge_initiated(bridge_id:)" (out-going), "add_end_point(bridge_id, end_point_id)" (in-going), "drop_end_point(bridge_id, end_point_id)" (in-going), and "cancel_audio_bridge(bridge_id)" (in-going). Atomic processes internal to the audio_bridge would include things like "add_to_bridge(bridge_id, end_point_id)", which would have the real-world effect of establishing a real-time packet (RTP) stream between the physical bridge server and the physical end-point. To represent this real-world situation a domain-specific fluent active_audio_sessions(bridge_id, end_point_id), can be used, where a pair (b, e) in this fluent would indicate that end-point e is currently connected to bridge b. Note that a failure in the network could lead to breaking the RTP stream, and in turn the removal of pairs from the fluent, at essentially any (non-deterministic) time during processing.

The video_server would support similar messages for enabling one or more end-points to connect to the server, support atomic processes for establishing RTP streams to end-points, and rely on a fluent active_video_sessions(session_id, end_point_id) analogous to active_audio_sessions. In addition, for a given video session s, there will be the state of the video server, which is whether it is currently streaming a video clip, or whether an end-user has requested fast-forward, fast-reverse, or scene-based look-up request. Thus, the video_server can support incoming messages of the sort "play_video(session_id, video_id)", "fast_forward(session_id)", "fast_reverse(session_id)", "indexed_scene_selection(session_id,index)". Additional atomic processes in video_server would include capabilities for manipulating the content of those streams. A corresponding domain-specific fluent video_session_status(session_id, current_video_id, play_back_state, video_location) is used to track the status of each video session. (PSL is based on discrete time, so this fluent is assumed to work with discrete time as well.)

The conference_manager can serve as a single point of access, so that end-points can enter into multi-media multi-party teleconferences, and take advantage of additional features not directly available from the audio_bridge and video_server services. This might include mute capabilities, the establishment of "whisper" sessions (e.g., in which a subset of the teleconference participants temporarily drop out of the primary audio session and create a separate, private audio session just for themselves), the possibility that only a subset of the participants are watching the video, an awareness of who is speaking at a given moment (so that it can be delivered through a web portal to end-users), etc. The conference_manager might also take care of billing considerations, using messages to and from a billing server. In practice, the conference_manager will need to maintain the state of all of the conferences it is managing. One natural way to represent this would be using one or more domain-specific fluents, which are accessible only by occurrences of conference_manager.

We note that the process model used inside the conference_manager might be based on explicit support for sessions and subsessions, rather than being based on flowchart-based constructs as found in [BPEL 1.1] or [OWL-S 1.1]. In particular, it would be natural for the internal process model to support in essence spawning of an unbounded number of sub-processes (sub-activity occurrences), where each one corresponds to the addition of one more participant into a teleconference. This is reminiscent of the ability of many process algebras to support process spawning, but is not supported in BPEL 1.1. (Such unbounded spawning is supported in BPML [BPML].) Furthermore, it is important that the internal model for conference_manager be able to accommodate specifications for what should happen if asynchronous events of various types should arise at essentially any time. There is evidence that it is cumbersome to specify the treatment of such asynchronous events in BPEL, because the BPEL constructs related to "waiting" for asynchronous events are generally tied to scopes. In a telecom context, the natural treatments for several kinds of asynchronous events cut across the scoping that is convenient to establish in a BPEL specification. In any case, the needed internals of conference_manager can be modeled accurately using FLOWS-Core.

Finally, there are services associated with the end-points. These will include the capability for sending messages to the conference_manager to request a teleconference and perhaps to request information about an ongoing teleconference (e.g., who is speaking now?). Atomic processes would include the ability to start receiving or sending an RTP stream, the initiation or cancellation of presentation/display of audio/video output to the end-user, and maintenance of information in connection with the RTP streams.






7 Glossary


8 References