The World-Wide-Web is now a ubiquitous, global tool, used for finding information, communicating ideas, carrying out distributed computation, and conducting business, learning and science. Web services and the Semantic Web are emerging as a powerful infrastructure for distributed computing. However, even though standard methods that define semantics of Web services, such as OWL-S, may aid in the development and deployment of these services, they are hardly designed to be easily understandable and usable by developers. Complexity and lack of accessibility of Web services and the Semantic Web hinders their usage by the information industry. OPM/S, which is based on ObjectProcess Methodology (OPM), offers a bi-modal visuallingual representation that is both intuitive for humans and formal for machines. Utilization of ontologies and interoperability are two issues addressed by the OPM/S modeling environment. Ontologies are expressed as meta-libraries, which are specified in OPM or OWL, and can be dynamically linked to semantic Web services in a distributed environment. Interoperability is achieved using a transparent reuse method that enables dynamic development of Web services and their integration into more complex Web services. Using a running example, the paper presents OPM/S and its mapping to OWL-S. The benefits and shortcomings are discusses and compared with other OWL-S modeling methods.
The Web is highly dynamic in the quantity and nature
of the information that it encompasses, posing a host
of challenges in managing distributed information and
computation over the Web. Access to the Web may be
from a variety of devices and interfaces, by different
users at different locations, and at varying times.
Thus, there is a need for standard languages that
capture information semantics and not just syntax. Web
services and the Semantic Web are powerful
infrastructures that enable easy integration, automatization,
and reuse of different information and process formats
in a distributed environment. Since Web services are
distributed, dynamic, and can be utilized as
lightweight components within a broader and loosely
coupled framework, common semantics is required so
differences in terminology and definitions can be
automatically resolved. While the World Wide Web
provides a repository for Web services, the Semantic
Web [
As of today, the usage of OWL-S has not crossed the
boundary between academia and industry. Based on
their experience, Sabou et al. [
The second OPM/S mechanism is transparent reuse
[
The rest of the article is structured as follows. Section 2 reviews existing OWL-S engineering methods and briefly presents OPM. Section 3 introduces the OPM/S framework and explains how it supports the different OWL-S ontologies. Finally, Section 4 discusses the benefits and shortcomings of OPM/S and refers to future research plans.
Web services are automated resources accessed via the Internet, using an XML interface. The exponential growth of the Web and the progress of Internet-based architectures have set the stage for the proliferation of Web services and corresponding ontologies. However, despite the fact that these systems employ common XML or even RDF interfaces, semantic gaps among these ontologies cause problems in various scenarios. The problem of semantic reconciliation arises, for example, when integrating two systems that utilize different semantics to refer to entities that are conceptually identical. Such semantic differences must be resolved manually, a costly process that is unavoidably error-prone.
Trying to solve these problems, the Semantic Web
provides an infrastructure for concepts to be specified
formally, so relations between different concepts can
be reasoned automatically, providing a basis for
automated semantic reconciliation processes. Several
standards have emerged to support the Semantic Web
vision, including Web Ontology Language (OWL) [
In order to search for Web services and use them, a
software agent needs a computer-interpretable
de-2scription of the service and means to access it.
OWLS [
Even though OWL-S had gained a considerable
momentum in the Semantic Web community, several
shortcomings prevent OWL-S from being more
widely adopted by the software engineering industry.
The main problem is that OWL-S is relatively
complex and inaccessible for humans [
In an attempt to overcome the complexity of OWL-S,
two approaches to creating OWL-S scripts have been
developed: automatic generation and modeling.
Automatic generation relies on tools that create OWL-S
descriptions from existing concrete artifacts, such as
programming code or WSDL specifications [
Several OWL-S modeling methods rely on Unified
Modeling Language (UML) [
DUET [7] is a software tool that implements an OWL-S modeling solution based on UML activity diagrams. Each process is represented by an activity, while composite processes contain descendant activities. Inputs and preconditions are modeled as entry actions that occur when the activity is executed. Outputs and effects are modeled as exit actions that are executed when the activity ends. This modeling framework ignores several elements of the OWL-S Process Model ontology, such as conditions and conditional outputs. Another drawback of this solution is that it is limited only to the Process Model ontology, neglecting the OWL-S Service Profile and Service Grounding ontologies.
Object-Process Methodology (OPM) [
Contrary to the object-oriented approach, processes in OPM can stand alone, allowing intuitive modeling of the system's behavior that involves several object classes, possibly cutting across the system's structure. Processes are connected to the involved objects through procedural links, which are classified into enabling links, transformation links, condition links, and event links. The same and only diagram type provides also for modeling the system's structure, including the fundamental aggregation, generalization, exhibition, and classification relations alongside any other user-defined structural relation.
Two semantically equivalent modalities, one graphic
and the other textual, jointly express the same OPM
model. A set of inter-related Object-Process Diagrams
(OPDs) constitute the graphical, visual OPM
formalism. Each OPM element is denoted in an OPD by a
graphic symbol, and the OPD syntax specifies correct
and consistent ways by which entities can be linked.
Table 1 lists the fundamental OPM elements along
with their symbols and semantics. The Object-Process
Language (OPL) is the textual counterpart modality of
the graphical OPD set. As a dual-purpose language,
OPL is oriented towards humans as well as machines.
Catering to human needs, OPL is designed as a
constrained subset of English, which serves domain
experts engaged in analyzing and designing a system (or
a Web service). Every OPD construct is expressed by
a semantically equivalent OPL sentence or phrase.
Designed also for machine interpretation, OPL
provides a solid basis for automatically generating the
designed application. This dual representation of
OPM increases the processing capability of humans
according to Mayer's theory [
OPM is supported by the OPCAT [
The OPM/S modeling framework wraps OWL-S, reflecting the characteristics and features of semantic Web services. Contrary to OWL-S, which requires using three different types of ontologies with overlapping concepts, OPM/S employs its single frame of reference that can be presented at different abstraction levels. The combination of the single OPM view with its bimodal presentation increases the accessibility and usability of the OPM/S modeling framework to humans as well as machines (e.g., code generators and automatic translators).
The OWL-S ontologies are mapped to OPM/S as follows. The Service Profile is represented in OPM/S as the top level Object-Process Diagram (called the System Diagram, SD) along with its corresponding Object-Process Language paragraph. The Process Model is expressed by zooming into the top-level specification to expose the process structure and flows. From the top-level processes and downwards in the process containment hierarchy of OWL-S, each composite process is in-zoomed in OPM/S to reveal its subprocesses and their IOPE sets. The Service Grounding ontology is expressed by the interfaces of the atomic processes, which are unfolded at the deepest level of the process hierarchy. Table 2 summarizes the mapping between each of the three OWL-S ontologies and the corresponding OPM/S concepts. Two mechanisms are employed in order to support the dynamic and distributed nature of Web services: meta-libraries and transparent reuse. The rest of this section describes these mechanisms and explains their application to modeling the Service Profile and the Process Model in OPM/S. In order to demonstrate our approach, we use a running example of a book-buying service offered by the Web service provider Congo Inc. [6]. The OPM/S representation of the Service Grounding ontology is out of the scope of this paper.
Figure 1 is an OPM/S model of the Service Profile ontology of the Congo Book Buying service. The toplevel, main process in this model, Congo Book Buying Service, is surrounded by its inputs, outputs, preconditions, and effects, which are all objects. These objects are connected to the Congo Book Buying Service via procedural links that denote the role of each one of the objects in the top-level process. As the condition links from the objects Credit and Account to the Congo Book Buying Service process denote, the existence of these two objects is a precondition for the execution of the Congo Book Buying Service. The corresponding OPL sentence, which is "Congo Book Buying Service occurs if Account exists and Credit exists”, reinforces this condition semantics. Similarly, the objects Book Name, Account Info, Sign In Info, Credit Card Info, and Delivery Details are the process inputs, as the instrument links from each one of them to the Congo Book Buying Service process denote. The equivalent OPL sentence is "Congo Book Buying Service requires Book Name, Account Info, Sign In Info, Credit Card Info, and Delivery Details." The process outputs are Receipt, Shipping Order, and Account -5
Output. This is expressed by the result links in the OPD and by the corresponding result sentence in the OPL paragraph. The effect link between Buy Effect and the Congo Book Buying Service specifies that the process changes the object during its execution. The service itself exhibits the attributes Service Name, Text Description, Contact Information, and several Quality Ratings. The Contact Information section can contain many points of contact, each represented by an Actor. The Quality Ratings are matrices that express various quality measurement of the service. Multiple matrices can characterize the same service. The thick contours of Quality Rating and Actor indicate that further refinement of the objects exists, i.e., in our case they are unfolded in separate diagrams (not shown here due to space limitations) of their internal structure.
The Congo Book Buying Service is refined through zooming into two sub-processes, Full Congo Buy and Express Congo Buy, each describing different type of the Congo Book Buying Service. Express Congo Buy, which is an atomic process (not shown here), is a "one shot" service for buying a book with Congo, Inc. Figure 3 refines the composite process Full Congo Buy as a two-step buying procedure, in which the book is first located (Locate Book) and then bought (Buy Book).
For comparison purposes, the OWL-S specification of
the Full Congo Buy process is listed in Figure 3. The
XML statements contain the process type and its
control flows. As noted, an OWL-S process can be of
type composite, simple, or atomic. OPM/S, in
contrast, defines a single concept—a process class, the
complexity of which is determined by its position in
the process hierarchy of the OPM model. OPM/S
processes that are refined into subprocesses are
mapped to OWL-S composite processes. A refined
OPM/S process, such as Buy Book, is denoted by the
fact that the contour of its ellipse, which is originally
thin, becomes thick. Processes that are not in-zoomed
(and hence remain with thin contours) are mapped to
either atomic or simple OWL-S processes. Atomic
processes differ from simple ones in that the former
contain folded binding information (expressed in the
service grounding ontology), while the latter do not.
Another difference between OPM/S and OWL-S is
the way they treat control flows. OWL-S enables
explicit selection of a control flow construct for defining
an ordering or conditional execution of sub-processes.
Examples of these constructs include Sequence, Split,
Split+Join, Choice, Unordered, Condition,
If-ThenElse, Iterate, Repeat-While, and Repeat-Until.
OPM/S, on the other hand, utilizes the limited set of
basic elements supplied by OPM, namely procedural
links, to specify control flows. Process sequences are
denoted by the relative vertical position of the
subprocesses, taking into account that the time line flows
from the top of the diagram downwards. In Figure 3,
for example, the process Buy Book is executed after
Locate Book. Two processes with the same vertical
position are executed in parallel or as alternatives. An
invocation link, which specializes a procedural link,
can override this convention [
<process:listOfInstancesOf rdf:parseType="Collection"> <owl:Class rdf:about="#LocateBook" /> <owl:Class rdf:about="#CongoBuyBook" /> </process:listOfInstancesOf> </owl:Class> </owl:allValuesFrom> </owl:Restriction> </owl:intersectionOf> </owl:Class> Figure 3: OWL-S specification of the Full Congo
Conditional flow constructs, such as if-then-else or case statements, are specified in OPM/S by setting a decision object (which is Boolean for binary decisions). Each state of this object is linked via a condition link to the process that needs to happen if the object is at that state. In Figure 2, for example, Buy Book is executed only if Located Book exists, i.e., only if the book was found. OPM/S also supports modeling of iterative control flows (such as loops) by combining condition links to express the halting conditions and an invocation link to enable the iterations. Adding an invocation link in Figure 2 from Buy Book to the complete Full Congo Buy specifies that this process is executed until the requested book is not found.
OPM/S models are not only readable and
comprehensible; they are also consistent across the various
abstraction levels of the same Web service. The OPM
consistency rules [
The consistency of an OPM/S specification is conserved also within the same Process Model displayed at various refinement levels. For example, in Figure 4, the Buy Book composite process is zoomed into, exposing its Buy Sequence, Specify Delivery Details, and Finalize Buy sub-processes. Buy Sequence, in turn, is also a composite process, responsible for handling shopping carts, customers, and accounts. Specify Delivery Details and Finalize Buy, on the other hand, are atomic processes. The single instrument link from Delivery Details to Buy Book in Figure 2 is refined in Figure 4 into three instrument links from Delivery Address, Packaging Type, and Delivery Type (which are attributes of Delivery Details), to Specify Delivery Details. Changing one of these links to an effect link will automatically change the link between Delivery Details and Buy Book in the higher-level specification (shown in Figure 2) to an effect link, denoting that Buy Book somehow changes Delivery Details.
There are three kinds of OPM/S typing methods: basic types, roles, and enumerations. These are demonstrated in Figure 4. Basic types includes all the primitive types, such as xs:int and xs:string, and user-defined types. The type of Credit Card Number and Delivery Address in Figure 4, for example, is XS:string. Roles denote the ontological context, according to a given meta-library. Credit Card Expiration, for example, is declared as an Instant from the Time ontology, which is represented by an OWL meta-library. Role names are recorded in the upper-left corner of an object box or a process ellipse.
Enumerations are specified in OPM/S by states. States define the set of possible situations an object can be at or legal values an object can assume. At any point in time an object is in exactly one of its states or in transition between states. States can change only through the occurrence of a process. In the graphical OPD notation, states are denoted as rounded-corner rectangles inside an object. Packaging Type in Figure 4, for example, can be gift-wrap or ordinary. -7
Meta-libraries are used to specify and utilize ontologies and domain knowledge in a dynamic and distributed environment. A meta-library captures domain knowledge as an OPM model or as an OWL specification. For instance, a meta-library concerning ecommerce will contain concepts such as product, customer, order, invoice, and so fourth. It will also contain static and dynamic constraints among these concepts, such as how many products can be ordered in a single order, should the paying certification precede the supplying process, etc.
Product exhibits Identifier and Description.
Description is of type Xs:string.
E-Commerce Process requires many Products.
E-Commerce Process yields an optional Confirmation.
Figure 5: An E-Commerce meta-library Figure 5 is an OPM model of a simple e-commerce meta-library. According to this e-commerce ontology, Product exhibits two attributes, Identifier and Description. This e-commerce meta-library also introduces dynamic constraints on the E-Commerce Process: the process requires one or more Products and yields an optional Confirmation.
When defining a Web service, one or more metalibraries are imported by selecting a local file or a URI, or by searching through UDDI registries. After the meta-library is imported, the Web service model dynamically references it. The references are refreshed each time a design session is initiated, ensuring that every change in the meta-library would be reflected to all the Web service models that import it. Each element in a Web service model can be assigned to one or more roles each of which corresponds to an element of the meta-library. Buy Book in Figure 2, for example, plays the role of an E-Commerce Process. Hence, it requires Products, Located Books in this case, and yields a Receipt, which plays the role of a Certification. Buy Book also requires additional information (Credit Card Info, Sign In Info, Account Info, and Delivery Details) and yields Shipping Order and Account Output. Furthermore, the Located Book (input) object fulfills the structural constraints of a Product, enforces by the e-commerce metalibrary: it exhibits Book ISBN (the product identifier) and Book Description (the product description). A special algorithm (not described in this paper) validates that the Web service model fulfills the metalibrary (static and dynamic) constraints. -8
The interoperability of semantic Web services is
supported by applying OPM's transparent reuse method
[
As an example to the transparent reuse method, consider a case in which Finalize Buy from Figure 4 is not specified in the Congo Book Buying Service. In this case, Finalize Buy would be marked as an environmental and, correspondingly, Receipt would be marked as an environmental object (in all levels of the OPM model), enabling the reuse of external services for finalizing a buy. An example of such a service can be the FedEx Service, whose interface includes delivery details (as an input) and a receipt (as an output) in special formats. When binding the FedEx Service to the Congo Book Buying Service (as a Finalize Buy process), the integrated Web service uses FedEx in order to deliver books from the Congo provider. A supervision mechanism is employed in order to detect changes in Web services that might affect other Web services. The designer receives a list of warnings regarding broken bindings between Web services, as well as suggestions to alternative substitutions for the broken bindings.
The dynamic nature of the Web and its heterogeneous information formats require addressing semantic issues when searching and developing Web-based systems, such as Web services. Using OWL-S for specifying semantic Web service holds great opportunities for automating Web service discovery, invocation, composition, interoperation, and execution monitoring. However, current OWL-S modeling and engineering methods need to be improved in order to make them accessible and useful for humans as well. This work has proposed OPM, which is a general system engineering method, as a convenient, intuitive, yet formal language for wrapping and expressing OWL-S specifications. A small set of about a dozen OPD symbols, along with a semi natural language, Object-Process Language (OPL), simplify the definition of Web services for humans. Ontologies and domain knowledge are handled in the OPM/S modeling framework using meta-libraries which are dynamically imported and shared by multiple Web services. In order to support interoperability between Web services, OPM's transparent reuse method is adopted as a way to integrate Web services. Transparent reuse enables ongoing changes in the integrated models, while alerting the designer about influences of the changes on other Web services.
The usage of objects and processes in OPM along with its three built-in complexity mechanisms enable modeling the Service Profile, Process Model, and Service Grounding ontologies of a Web Service in a single framework, using a single (bimodal) modeling language. The complexity management mechanisms also ensure that a Web service model is internally consistent.
OPM/S expressiveness should be further improved to support all types of OWL-S logical expressions, such as complex branches. The research plans also include implementing an OWL-S translator, which will enable bi-directional conversion of OPM/S models to OWLS specifications and vice versa. In addition, development guidelines will be defined for specifying semantic Web services in OPM/S and OWL-S. -9[6] DAML.org, Congo Buy Specification, http://www.daml.org/services/owls/0.9/CongoService.owl [7] DARPA, CODIP Project, DUET: DAML UML Enhanced Tool, http://grcinet.grci.com/maria/www/CodipSite.