Copyright © 2005 retained by the authors.
All Rights Reserved.
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.
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/:
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
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.
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.
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 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 ].
Book_reservation[ ISBN => xsd#string, user_id => xsd#string, warehouse_id => xsd#string ].
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 ].
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 ].
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); ].
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)
book_search_response(ISBN: string, title: string, list_of [author: string])
shopping_cart_request(user_ID: string, ISBN: string)
book_availability_response(ISBN: string, title: string, list_of [author: string], ship_date: 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.
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:
book_search
)
requires a certain form of input (e.g., ISBN# and/or
book title and/or ...),
and there is an occurrence of that process, then a message
holding the required information in its payload
must have been produced (e.g., the the user) and read by
some Read_Message occurrence in the occurrence of Acme_Book_Sales.
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.
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
Warehouse_order_fulfillment
Bank_account_maintenance
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)
Bank_account_maintenance
).
Store_inventory(item_id:int,
quantity:int)
Store_inventory_maintenance
).
Warehouse_inventory(item_id:int,
quantity:int)
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)
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)
Good_in_transit
.
Wholesale_order_content_lists(wholesale_order_id:int,
item_id:int, quantity:int)
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)
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)
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)
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)
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)
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)
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)
acknowledge_account(account_id:int,
account_balance:int)
account_balance_inquiry(store_id:int;
account_id:int)
account_balance_report(account_id:int,
account_balance:int)
place_order(order_id:int,
store_id:int,
wholesale_order_id:int,
bank_account_id:int,
stop_attempt_date:date)
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)
Goods_in_transit
and
Transport_contents_lists
.)
reject_order(order_id:int)
bill_for_goods(account_id:int;
order_id:int,
bill_amount:int,
target_bank_id:int,
target_account_id:int)
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)
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
.
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:
place_order
, followed by a
Destroy_Message occurrence (which destroys the message just read).
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.)
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.
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).
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.
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).
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.