The SWSO concepts for service description (as described in Section 3 of this document), and the instantiations of these concepts that describe a particular service, are abstract specifications, in the sense that they do not specify the details of particular message formats, transport protocols, and network addresses by which a Web service is accessed. The role of the grounding is to provide these more concrete details.
The Web Services Description Language (WSDL), developed independently of SWSL and SWSO, provides a well developed means of specifying these kinds of details, and is already in widespread use within the commercial Web services community. Therefore, we can ground a SWSO service description by defining mappings from certain SWSO concepts to WSDL constructs that describe the concrete realizations of these concepts. (For example, SWSO's concept of message can be mapped onto WSDL's elements that describe messages.) These mappings are based upon the observation that SWSL's concept of grounding is generally consistent with WSDL's concept of binding. As a result, it is a straightforward task to ground a SWSL service description to a WSDL service description, and thus take advantage of WSDL features that allow for the lower-level specification of details related to interoperability between services and service users.
In this release of SWSF, we give a sketch of the essential elements of grounding to WSDL, rather than a complete specification. Our approach here is similar to the WSDL grounding specified in [OWL-S 1.1]. We rely upon the soon-to-be-finalized WSDL 2.0 specification [WSDL 2.0]), which is in last call as of this writing.
Note that SWSO groundings are deliberately decoupled from SWSO abstract service descriptions, so as to enable reusability. An abstract service specification (say, for a bookselling service) can be coupled with one grounding in one context (say, when deployed by one online bookseller) and coupled with a different grounding (when deployed by a second online bookseller). The two booksellers would have completely distinct groundings, which would of course specify different network addresses for contacting their services, but could also specify quite different message formats.
The approach described here allows a service developer, who is going to provide service descriptions for use by potential clients, to take advantage of the complementary strengths of these two specification languages. On the one hand (the abstract side of a service specification), the developer benefits by making use of SWSO's process model, and the expressiveness of SWSO ontologies, relative to what XML Schema Definition (XSD) provides. On the other hand (the concrete side), the developer benefits from the opportunity to reuse the extensive work done in WSDL (and related languages such as SOAP), and software support for message exchanges based on WSDL declarations, as defined to date for various protocols and transport mechanisms.
Whereas a default WSDL specification refers only to XSD primitive data types, and composite data types defined using XSD, a SWSO/WSDL specification can refer to SWSO classes and other types defined in SWSO (in addition to the XSD primitive and defined types). These types can, if desired, be used directly by WSDL-enabled services, as supported by WSDL type extension mechanisms. In this case the SWSO types can either be defined within the WSDL spec, or defined in a separate document and referred to from within the WSDL spec. However, it is not necessary to construct WSDL-enabled services that use SWSO types directly in this manner. When they are not used directly, translation mechanisms such as those outlined below may be used to spell out the relationships between the SWSO types and the corresponding XML Schema types used in the default style of WSDL definition.
We emphasize that an SWSO/WSDL grounding involves a complementary use of the two languages, in a way that is in accord with the intentions of the authors of WSDL. Both languages are required for the full specification of a grounding. This is because the two languages do not cover the same conceptual space. The two languages do overlap, to a degree, in that they both provide for the specification of "types" associated with message contents. WSDL, by default, specifies the types of message contents using XML Schema, and is primarily concerned with defining valid, checkable syntax for message contents. SWSO, on the other hand, does not constrain syntax at all, but rather allows for the definition of abstract types that are associated with logical assertions (IO fluents) in a knowledge base. WSDL/XSD is unable to express the semantics associated with SWSO concepts. Similarly, SWSO has no means to define legal syntax or to declare the binding information that WSDL captures. Thus, it is natural that a SWSO/WSDL grounding uses SWSO types as the abstract types of messages declared in WSDL, and then relies on WSDL binding constructs to specify the syntax and formatting of the messages.
Web services are inherently message-oriented, and messages are also the central concern in the grounding of a SWSO service. The essence of this grounding approach is to establish a mapping between selected message-oriented constructs in SWSO and their counterparts in WSDL service descriptions.
To elucidate the requirements for the grounding, and clarify the scope of the current effort, we consider a hypothetical service enactment environment, or execution engine, based on SWSO; that is, a software system that enacts processes described using SWSO's process model. We assume that this system incorporates a knowledge base that contains the relevant SWSO service descriptions, and manages the fluents associated with service execution, as described earlier in this document. We call a system of this type a Semantic Web Services Execution Environment (SWSEE).
The primary motivation for this grounding approach is to make it possible for a SWSEE to handle messages that conform to WSDL service specifications. We want to allow for scenarios in which a SWSEE plays the role of a service provider (that is, manages the communications associated with a service from the provider's point of view), a service user, or both. When acting as a service provider, a SWSEE will need to accept a WSDL input message, extract the needed pieces of information from its content, and assert them into the knowledge base in accordance with the SWSO declarations of input fluents. This step of handling an input message, as a service provider, would happen in correspondence with the execution of a Read_Message atomic process. In addition, a service-providing SWSEE will need to generate outputs in correspondence with Produce_Message atomics, by pulling information from its knowledge base and formatting it into appropriate WSDL-conformant output messages.
Conversely, when acting as a service user (invoker), a SWSEE will need to execute a Produce_Message atomic for the purpose of invoking a remote Web service. In correspondence with this atomic activity, the SWSEE will need to produce a WSDL-conformant message to send to the remote service. (This message will be an input from the WSDL perspective, but an output from the SWSEE perspective in this situation.) Following that, it may need to receive a return message from the WSDL service, and will this will be done by a Read_Message atomic.
In designing these basic grounding mechanisms, we are noncommittal about the architectural role of a SWSEE. So as to be general and avoid relying on any particular architectural commitments, our approach here is minimalist. For example, we do not explain the mechanisms by which a SWSEE might arrange to make a run-time selection and binding to a particular WSDL service. Rather, we are concerned only with essential representational requirements that will be needed by the builders of enactment environments: we seek to provide a common denominator of representation by which the relationships between elements of WSDL and SWSO service descriptions can be declared.
Thus, the role of the SWSO/WSDL grounding (or at least the most central role) may be conceived as follows: it provides a SWSEE with the information it needs at runtime to handle (both send and receive) messages associated with WSDL service descriptions. To do this, it must provide the following things:
In addition to the above, it is also desirable to provide the following:
We briefly describe each of these aspects of the grounding in turn. The needed mappings will be provided by introducing several new SWSO relations here. These relations differ from the process model relations of Section 3 in that they are not axiomatized. This is because they provide mappings to external entities (declared in WSDL) that are outside the scope of SWSO axiomatization.
In WSDL 2.0 an operation declares a set of messages that are used in accordance with a message pattern, as in this simple example from the [WSDL 2.0 Primer]:
<operation name="opCheckAvailability"
pattern="http://www.w3.org/2004/03/wsdl/in-out"
style="http://www.w3.org/2004/08/wsdl/style/uri"
safe = "true">
<input messageLabel="In"
element="ghns:checkAvailability" />
<output messageLabel="Out"
element="ghns:checkAvailabilityResponse" />
<outfault ref="tns:invalidDataFault" messageLabel="Out"/>
</operation>
Here the message pattern is in-out (declared elsewhere). Each
input/output message declaration gives an XML Schema
document type (e.g., ghns:checkAvailability) and a label (e.g., In)
that shows where the message is used in the pattern.
The correspondence to SWSO is this:
To indicate this mapping, we introduce a single SWSO relation:
activity_grounding(activity, wsdl_operation)
where activity refers to a complex activity declared in a SWSO service description, and wsdl_operation is a URL for a WSDL operation declaration.
As discussed in Section 3.1.4, SWSO's
process model is silent as to the concrete form (syntax,
serialization) associated with a message type. The nature of a
message type is characterized abstractly, by associating it with one
or more IO fluents, using the described_by relation. One central job of the
grounding, then, is to specify a concrete syntax for each
SWSO message type. In WSDL these concrete syntaxes are normally given
by "message types" declared using XML Schema declarations. To distinguish
these message types from those of SWSO, we refer to those of WSDL as "concrete
message types".
We note that WSDL allows for the use of type specifications using other mechanisms than XML Schema. In this document, however, for simplicity, we assume the use of XML Schema in WSDL service descriptions.
To specify the concrete syntax associated with a SWSO message type, we introduce the relation
message_type_grounding(msg_type, wsdl_operation, wsdl_message_label)
where msg_type is an identifier for a message type defined using SWSO, wsdl_operation is a URI for an operation defined in a WSDL specification, and wsdl_message_label is a label used within that operation definition. The meaning of an instance of this relation is simply that a message of the given SWSO message type corresponds to a WSDL message declared with the given label, within the given WSDL operation.
In addition to showing the correspondence of SWSO message types with
WSDL concrete message types, a grounding should indicate a precise method for
constructing WSDL message content from SWSO message content. For this
purpose we provide the message_serialization_method relation:
message_serialization_method(msg_type, wsdl_operation, wsdl_message_label, method)
The meaning of an instance of this relation is that a message of the given SWSO message type will be serialized appropriately for the WSDL message having the given label within the given operation. The serialization will be performed by the specified method.
In general this allows for an arbitrary method, which could be
external (e.g., it could be a Java method). Therefore, we do not
specify what kind of thing method refers to; this should be
defined by each particular SWSEE implementation.
The specified method retrieves the information associated with the given message type by querying the knowledge base (in particular, the IO fluents for that message type), and generates the appropriate WSDL message containing that information.
msg_type, wsdl_operation, and wsdl_message_label are as described for message_type_grounding.
In Section 4.2.5, we sketch a means by which this translation method can be specified in a more declarative style.
The grounding must also specify how the various parts of an individual
WSDL message get mapped into the fluents associated with that message
type. This is done using the message_deserialization_method relation:
message_deserialization_method(wsdl_operation, wsdl_msg_label, msg_type, method)
The meaning of an instance of this relation is that a WSDL message, having the given label within the given operation, will be deserialized into the given SWSO message type, by the specified method.
As with
message_serialization_method, method
is regarded as external and implementation-defined.
The specified method takes an arbitrary message of the kind specified by the given message label (within the given WSDL operation), extracts the information content from that message, and asserts the appropriate IO fluents into the knowledge base.
msg_type, wsdl_operation, and
wsdl_message_label are as described above for
message_type_grounding.
In Section 4.2.6, we sketch a means by which this translation method can be specified in a more declarative style.
Here, we sketch a general declarative means for specifying the
serialization of a message of a given SWSO message type into a
concrete message type specified in WSDL, which could be used as an
alternative to declaring a message serialization method. The idea
here is to use a knowledge base query to extract information from the
IO fluents within the SWSEE's knowledge base, and use a message
generation script to generate a message containing that information.
The information is passed from the query to the message generation
script by means of variable bindings. This approach is supported by
the message_serialization relation:
message_serialization(msg_type, wsdl_operation, wsdl_msg_label, kb_query, msg_generation_script)
msg_type refers to a SWSO message type.
The second and third arguments are references to a WSDL message element, as used in
message_serialization_method and
message_deserialization_method, above.
kb_query is a query expression, containing variables,
that extracts the needed information from IO fluents in the knowledge
base and binds the variables to that information. We do not specify a
particular query language in this document. A SWSL-based
query language, yet to be developed, is a possibility.
msg_generation_script is a script in a language such as
XSLT [XSLT] that is suitable for
generating an XML document. Variables mentioned in the script would
correspond to variables mentioned in the KB query, and would be bound
to the query's return values before the script is executed.
The meaning of an instance of this relation is that a message of the given SWSO message type will be serialized appropriately into the WSDL message having the given label within the given operation. The serialization will result by running the message generation script with variables bound as described above.
Here, we sketch a general declarative means for specifying the
deserialization of a message of a given concrete message type (as specified
in WSDL). This approach may be regarded as the inverse functionality
of that specified using message_serialization. The idea
here is to use a document query language to extract information from
the concrete message content, and use an update script to insert that
information into a SWSEE's knowledge base. The information is passed
from the document query to the update script by means of variable
bindings. This approach is
supported by the message_deserialization relation:
message_deserialization(wsdl_operation, wsdl_msg_label, msg_type, msg_query, kb_update_script)
The first two arguments, as above, refer to a WSDL message declaration (within an operation declaration), and the third refers to a SWSO message type.
msg_query is a document query expression, containing variables,
that extracts the needed information from in the knowledge
base and binds the variables to that information. We do not specify a
particular document query language in this document, but XQuery
[XQuery 1.0] would be a natural candidate.
kb_update_script is a script in a knowledge base update language. Variables
bound in the update script would correspond to variables mentioned
in the message query, and would be bound to the query's return values
before the script is executed.