Model-Driven Design and Development of Semantic Web Service

Model-Driven Design and Development of Semantic Web Service Applications

Marco Brambilla1, Irene Celino2, Stefano Ceri1, Dario Cerizza2, Emanuele Della Valle2, Federico Michele Facca1

1 Politecnico di Milano, Dipartimento di Elettronica e Informazione, 20133 Milano, Italy

{Marco.Brambilla, Stefano.Ceri, Federico.Facca}@polimi.it

2 CEFRIEL, 20133 Milano, Italy {celino,cerizza,dellavalle}@cefriel.it

Abstract. This paper proposes a model-driven methodology to design and develop Semantic Web Service applications and

their components, described according to the emerging WSMO initiative. In particular, we show the advantages of a top-

down approach that uses software engineering methods and tools, such as: formalized development processes, component-

based software design techniques, and computer-aided software design. This approach leads from an abstract view of the

business needs to application concrete implementation, by means of powerful code generators. Our method is based on

existing models for the specification of business processes (such as BPMN) combined with Web Engineering models for

designing and developing semantically rich Web applications implementing Service Oriented Architectures (such as

WebML) with the support of Semantic Web Service tools (such as WSMX and WSMT). The proposed framework increases

the efficiency of the whole design process, yielding to the construction of Semantic Web Service applications spanning over

several enterprises. In our paper, we show that business process and Web Engineering models have sufficient expressive

power to support the semi-automatic extraction of semantic descriptions (i.e., WSMO ontologies, goals, Web Services, and

mediators), thus hiding the complexity of dealing with semantics in a structured designed process.

Keywords: Business Process Modeling, Semantic Web Services, Software Engineering, Web Engineering, Model Driven

Design.

1 Introduction

One of the most challenging promises of the Semantic Web Services (i.e., OWL-S [36], WSMO [41], and

WSDL-S [44]) is to enable the construction of flexible business applications, spanning over several

enterprises and capable of dynamic composition for presenting to their clients the “best” business options.

These emerging initiatives propose to augment Web Services with semantic annotations and to operate

reasoners on top of such descriptions for performing business choices, thus matching user’s goals to

system’s resources. In this paper we use WSMO, one of the emerging Semantic Web Service initiatives,

because it provides a clear separation between well identified components, such as ontologies, goals, Web

Services and mediators, and because it is founded on the two clear principles of strong decoupling and

M. Brambilla et al. 2

strong mediation. While dwelling into the deep aspects of the Semantic Web Services (e.g. for building a

semantic execution environment such as WSMX [27]) is outside of the scope of this paper, we focus on

the design and re-engineering of software components so as to meet the Semantic Web Services

requirements; we show that advanced Software Engineering methods enable the development of software

interfaces which are compliant with WSMO. Our method overcomes one of the most critical obstacles to

the spreading of WSMO based solutions, i.e., the apparent difficulty of adapting current Web applications

to WSMO requirements. Our work shows that there is no contrast – but actually good continuity –

between modern model-driven software design methods and the Semantic Web Service concepts; in

particular, the current state of the art of model-driven software design offers rich and flexible enough

model descriptions to support almost all WSMO abstractions.

We exploit modern Web Engineering methods, including visual declarative modeling (based on the

WebML conceptual model), automatic code generation (locally executable using standard Web

technologies and globally executable across enterprise boundaries by delegating the execution to a

Semantic Execution Environment such as WSMX), and automatic elicitation of semantic descriptions for

the WSMO components (i.e., Ontologies, Goals, Web Services, and Mediators) from the design of the

application. Global choreography1, front-end, and services implementations are derived from Business

Process models and WebML models, whereas goals, descriptions of Web Services (both in terms of

capabilities and of their choreography interface), and descriptions of mediators are automatically

generated. In particular, we propose to cover the different aspects of the design by means of the following

techniques and notations:

• High-level design of the global choreography of the interaction between services: we adopt BPMN

(Business Process Management Notation) to build process models, involving several actors possibly

from different enterprises.

1 The term choreography assumes several meanings in different communities. We refer to W3C definition of choreography with the term “global choreography” (i.e., the choreography of an application made of WS), whereas we refer to WSMO choreography definition with the term “local choreography” (i.e., the choreography interface of a Web Service).

3 Model-Driven Design and Development of Semantic Web Service Applications

• Design of the underlying data model of the cross-enterprise application: we use extended E-R (Entity

Relationship) diagrams enriched with OQL derivation rules (whose expressive power is equivalent to

WSML Flight [12]) to model the local ontology of the application and to import existing ontologies

(possibly modeled in ontology engineering tools such as WSMT [31]), whenever they exist; we expose

the resulting set of ontologies to the underlying WSMX;

• Design of Web Services interfaces, of integration platform, and of application front end: we use visual

diagrams representing Web sites and services according to the WebML models [10], including specific

hypertext primitives for Web Service invocation and publishing [7] and explicit representation of

workflow concepts [8].

In this way, instead of coping with textual semantic annotations of Semantic Web Services, application

developers will obtain them from the use of abstractions that are supported by Software Engineering

tools. The use of automatic description generators, sometimes helped by designer’s annotations,

guarantees the benefits of Semantic Web Services at nearly zero extra-cost, thus positioning their cross-

enterprise applications within an infrastructure that allows for flexible and dynamic reconfiguration.

Current research efforts are converging on the proposal of combining Semantic Web Services and

Business Process Management to create one consolidated technology, which we call Semantic Business

Process Management (SBPM) [28]. The claim is based on the observation that the problem of

mechanization of BPM, i.e., the reduction of human intervention in associated tasks, can be traced back to

an ontological problem, i.e., the lack of machine-accessible semantics, and that the modeling constructs of

SWS frameworks, especially WSMO, are a natural fit to create such a representation.

This paper follows this trend towards SBPM and it refines our previous work [4] focusing on the

development process, explaining how we manage ontologies and providing a set of advanced primitives

for querying the ontologies.

The paper is structured as follows: Section 2 offers a view on the background of the research; Section 3

presents the running example that will be discussed throughout the paper; Section 4 describes the overall

methodology, presents the development process and addresses the main development steps, including the

definition, the importing, and the query primitives for ontologies; Section 5 presents the proposed

approach to the elicitation of semantic description of the application; Section 6 briefly outlines our


implementation experience; Section 7 introduces some considerations on the test and evaluation of the

current state of our framework; Section 8 reports some of the current research efforts related to our work;

and finally Section 9 presents our conclusions.

2 Background

Our approach relies on methodologies, tools and techniques from the fields of Software Engineering,

Web Engineering, and Business Process Management.

2.1 Modeling Business Processes

All the B2B Web applications implement a business process, which is represented by using a workflow

model. Several notations have been proposed for workflow design. For the visual representation of

workflows, we adopt Business Process Management Notation [9], which is associated to the BPML

standard, issued by the Business Process Management Initiative. We adopted BPMN since it is a well

know and widely used to model Business Processes and its notation is one of the most effective to

represents real IT processes. Furthermore it is based on an easy visual notation. Various proposals are

currently issued for serialization of workflow models in XML format. Among the most promising ones,

we can cite XPDL [50] introduced by the Workflow Management Coalition (WfMC).

The BPMN notation allows to represent all the basic process concepts defined by the WfMC model.

BPMN activities extend WfMC activities, as they can express various behaviors (looping execution,

compensation, internal sub-process structuring, event catching, and so on). BPMN activities can be

grouped into pools, and one pool contains all activities that are to be enacted by a given process

participant. Within a pool, we use BPMN lanes to distinguish different user types that interact with the

specific peer. The flow of the process is described by means of arrows, representing either the actual

execution flow, or the flow of exchanged messages. Another type of arrows represents the association of

data objects to activities; these are meant just as visual cues for the reader, and do not have an executable

meaning. Gateways are process flow control elements; typical gateways include decision, splitting,

merging and synchronization points. Table 1 briefly summarizes the main visual constructs provided by

BPMN. An example of full BPMN model is represented in Figure 4.


2.2 Model-driven Web application design

Several approaches in the Web engineering field provide methodologies, conceptual models, notations,

and tools for the design of Web applications (e.g., [42, 22, 21]). In this paper, we will adopt the WebML

methodology [10] since it provides an easily extensible model where each element has a well defined

semantic that can be exploited to reduce the annotation effort; furthermore WebML is supported by a en

effective CASE tool and runtime environment (WebRatio). The specification of a Web application

according to WebML consists of a set of models: the application data model (an extended Entity-

Relationship model), one or more hypertext models (i.e., different site views for different types of users),

expressing the navigation paths and the page composition of the Web application; the presentation model,

describing the visual aspects of the pages. A hypertext site view is a graph of pages; pages are composed

by units, representing publishing of atomic pieces of information, and operations for modifying data or

performing arbitrary bucsiness actions (e.g., sending e-mails). Units are connected by links, to allow

navigation, passing of parameters between the components, and computation of the hypertext.

The WebML conceptual model includes a service model comprising a set of Web Service units [7, 35],

corresponding to the WSDL classes of Web Service operations, and components for workflow

management and tracking. The Web Services units consist of Request-Response and One-Way operations,

which model services invocation and are triggered by the navigation of an input link; and of Notification

and Solicit-Response, that are triggered by the reception of a message, thus they represent the publishing

Table 1. BPMN main constructs.

O

Gateways

Events

Start End Intermediate

Or gateway

Name

Activity

Activities and Flows

Sequence flow Message flow Data AssociationPool and Lanes

X +Xor gateway And gateway


of a Web Service, which is exposed and can be invoked by third party applications. The model supports

both the grounding of Web Services to the XML format of Web Service messages, and data-mediation

capabilities.

Figure 1 shows an hypertext example that includes the model of a Web Service call and of the called

service. Supply Area of Figure 1(a) is an area of a Web site for supply management. The employee can

browse to the SupplySearch page, in which the SearchProducts entry unit permits the input of search

criteria. From this information, a request message is composed and sent to the RemoteSearch operation of

a Web Service. The user then waits for the response message, containing a list of products satisfying the

search criteria. From these options, a set of instances of Product are created, and displayed to the user by

means of the Products index unit in the Products page; the user may continue browsing, e.g., by choosing

one of the displayed products and looking at its details. Figure 1(b) represents the model of the

RemoteSearch service invoked by the previously described hypertext. The interaction starts with the

solicit SearchSolicit unit, which denotes the reception of the message. Upon the arrival of the message, an

XML-out operation extracts from the local data source the list of desired products and formats the

resulting XML document. The SearchResponse unit produces the response message for the invoking Web

Service.

WebML covers also the development of B2B Web applications implementing business processes, thereby

supporting collaborative workflow-based applications, spanning multiple individuals, services, and

organizations. The data model is extended with the meta-data necessary for tracking the execution of the

business process, by registering the execution advancement of cases (i.e., instances of processes) and

activities as relational data. The hypertext model is extended by specifying activity boundaries and

business-dependent navigation links. Activities are represented by areas tagged with a marker “A”;

workflow links traverse the boundaries of activity areas and are associated with workflow logic: every link

(a) (b)

Figure 1. Example of WebML hypertext model with invocation of remote service


entering an activity starts the execution of the activity; every outgoing link ends the activity. If and switch

units can be used to express navigation conditions. Distributed processes can be obtained by combining

the workflow primitives with Web Services primitives [8]2.

2.3 Semantic Web Services

Currently several initiatives aim to bring Semantic Web technology to Web Services (i.e., OWL-S [36],

WSMO [41], WSDL-S [44]). In this paper we will adopt the Web Service Modeling Ontology (WSMO)

because of its strong decoupling of the different components and its high leverage on the mediation to

allow interoperability. The WSMO [19] initiative aims at providing a comprehensive framework for

handling Semantic Web Services which includes the WSMO conceptual model, the WSML language [12]

and the WSMX execution environment [27], which also include design tools such as WSMT [31].

WSMO is an ontology for describing various aspects related to Semantic Web Services. The objective of

WSMO and its accompanying efforts is to solve the application integration problem for Web Services by

defining a coherent technology for Semantic Web Services. We briefly present the basic concepts of

WSMO with respect to its conceptual specification.

WSMO defines four modeling elements (ontologies, goals, Web Services and mediators) to describe

several aspects of Semantic Web Services, based on the conceptual grounding of the Web Service

Modeling Framework (WSMF) [20]. Ontologies provide the formal semantics to the information used by

all other components. They serve in defining the formal semantics of the information, and in linking

machine and human terminologies. WSMO specifies different constituents as part of the description of an

ontology, like concepts, relations, axioms, instances and so on. Web Services represent the functional and

behavioral aspects, which must be semantically described in order to allow semi-automated use. Each

Web Service represents an atomic piece of functionality that can be reused to build more complex ones.

Web Services are described in WSMO from three different points of view: besides non-functional

properties, the core description includes functionality and behavior. The functionalities are described as

2 Reference [8] uses an earlier notation where process metadata are managed using ad-hoc operations, instead of representing them explicitly with areas and links.


capabilities, while the behavior is described in Web Service interface. A Web Service can be described

by multiple interfaces, but has one and only one capability. Moreover, the interface of a Web Service

describes the behavior of the Web Service from two perspectives: communication and collaboration.

Goals specify objectives that a client might have when consulting a Web Service. In WSMO, a goal is

characterized in a dual way with respect to Web Services: goal’s descriptions include the requested

capability and the requested interface. Finally, mediators provide interoperability facilities among the

other elements. They describe elements that aim to overcome structural, semantic or conceptual

mismatches that appear between the different components that build up a WSMO description.

WSMO offers four mediators to solve heterogeneity issues and support efficiently Goal driven Web

Service discovery: ooMediators import (parts of) ontologies and resolve heterogeneity between them;

wwMediators connect two different Web Services, resolving any data, process and protocol heterogeneity

between them; the ggMediators connect different goals, enabling goals to refine more general goals and

thus enabling reuse of goal definitions; and finally wgMediators connect goals and Web Services,

resolving any data, process and protocol heterogeneity.

The Web Service Modeling Language (WSML) offers a set of language variants for describing WSMO

elements that enable modellers to balance between expressivity and tractability according to different

knowledge representation paradigms. The most basic, and least expressive, variant is WSML-Core, which

is based on DLP [26] as a least common denominator for description logic (DL) and logic programming

(LP). WSML Core is separately extended in the directions of these two paradigms by the variants

WSML-DL and WSML-Flight, respectively. In particular WSML-Flight is an extension of WSML-Core

which includes concepts, attributes, binary relations and instances, as well as concept and relation

hierarchies and support for data types. WSML-Flight is based on a logic programming variant of F-Logic

[32] and is semantically equivalent to Datalog with inequality and (locally) stratified negation.

The Web Service Execution Environment (WSMX) is a framework for the automation of discovery,

selection, mediation, and invocation of Semantic Web Services. WSMX is based on WSMO and, at the

same time, it is a reference implementation of it. The framework also includes design tools, Web Service

Management Tools (WSMT), for modelling ontologies and describing goals, Web Services and

mediators.


2.4 Web Service discovery

Service Discovery is a normal task manually accomplished in many present business scenarios (e.g.,

finding a shipment service). Web Services certainly reduced the effort required in invoking a remote

service exposed by a business partner, but their discovery (i.e., using UDDI [47]) always involves a

human in the loop. Given that, in practice, automatic discovery of Web Services is not used.

Ontologies can play a key role in automating Web Service Discovery [46, 33, 40].

In this work we will adopt Glue as Web Service discovery engine. Glue [14, 15] is based on a novel

approach that refines the conceptual model for WSMO Web Service discovery as well as the reference

architecture and the related execution semantics. At a conceptual level Glue approach introduces the

notion of class of goals and class of Web Service descriptions and gives mediators a central role in

discovery. Glue approach recommends to use: ggMediators (goal to goal Mediators), for automatically

generating a set of goals semantically equivalent to the one expressed by the requester but expressed with

a different form or using different ontologies, and wgMediators (Web Service to goal Mediators), as the

conceptual element responsible for evaluating the matching. The resulting discovery mechanism is a

composite procedure where the discovery of the appropriate mediators and the discovery of the

appropriate services is combined.

3 Running example

For the discussion we will consider a running example derived by the Purchase Order Mediation scenario

and the Shipment Discovery scenario proposed at the Semantic Web Service Challenge 2006 [16],

properly extended to show all the components of a classical B2B application. In this scenario, two big

companies, Blue and Moon, need to integrate their processes in order to create a new business

partnership. In summary, as displayed by Figure 2, the architecture includes the two companies Blue and

Moon, the mediation service between them, and a general-purpose Web Service built by Blue for

interacting with external services and an external discovery engine.


Blue usually handles its purchase orders towards its partners by using a standard RosettaNet PIP 3A4

conversation, while the Moon partner offers a set of Legacy Web Services for products purchase. Blue

employees, in the Purchase department, want to “talk” in a transparent way with their counterparts in the

Moon partner – using their usual RosettaNet Purchase Order Interface, therefore a mediation component

is needed between the two. The mediator is in charge of (i) transforming the single RosettaNet message

(containing all the order details) to the various messages needed by Moon to create and handle a purchase

order; and (ii) of translating the set of confirmation messages by Moon into a whole RosettaNet Purchase

Order Confirmation to be sent back to Blue. Thus, the mediation requires a data mediation and a relevant

process mediation between the two totally different purchase processes of RosettaNet and Moon legacy

system. The RosettaNet Purchase Order Interface offers the possibility to import products ontologies

published by partners and select from them the products to be added to the Purchase Order. After

completing the purchase of a set of products, Blue employees organize the shipment of the products

Figure 2. The B2B scenario derived from the Semantic Web Service Challenge 2006.


through the Shipment Organize Interface. This interface relies on a Web Service internally developed by

Blue and offered to Blue partners too. The internal orchestration of the Web Service relies on a WSMX

compliant Discovery Engine for retrieving available shipment services, and hence needs to describe the

shipment goal according to the WSMO standard. When the Discovery Engine returns a list of Web

Services offering a shipment service compatible with the original Goal, the Shipment Web Service

invokes the returned Web Services to obtain actual shipment offers and proceeds with its orchestration.

4 Design of Semantic Web Service applications

This section describes our proposal for semi-automatically generating WSMO-compliant semantic

specifications of a Web application. Our approach extends the WebML methodology presented in Section

2.3 towards the design of Semantic Web Services and Web applications.

4.1 Development process

The phases of the development process of a Semantic Web application are shown in Figure 3. In line with

the classic Boehm’s Spiral model and with modern methods for Web and Software Engineering, the

development phases must be applied in an iterative and incremental manner, in which the various tasks

are repeated and refined until results meet the business requirements.

Requirements specification is the activity in which the application analyst collects and formalizes the

essential information about the application domain and expected functions. Process design focuses on the

high-level schematization of the (possibly distributed) processes underlying the application. Process

Figure 3. Phases in the development process of data- and process-intensive semantic Web applications.


design and distribution influence the next steps of the development, which should take into account

process requirements. Data design is the phase in which the data expert organizes the main information

objects identified during requirements specification into a comprehensive and coherent domain model,

that may comprise importing of existing ontologies. Hypertext design is the activity that transforms the

functional requirements identified during requirements specification into one or more Web Services and

Web site views embodying the needed retrieval and manipulation methods. Hypertext design may

comprise importing or referencing existing services and goals. It exploits high level models, which let the

architect specify how content elements are published within pages, how services provide information to

requestors, and how hypertext elements are connected by links to form a navigable structure. This paper

is focused on Semantic description of the application, a new design phase which is required to provide

WSMO compatibility; it consists in a set of tasks, partially automated, that aim at providing a set of

semantic specifications of the application to be implemented. The other phases of Figure 3 are outside the

scope of this paper. A comprehensive description of them can be found in [10].

4.2 Design of the business process

The business process (BP) design task, focusing on the high-level schematization of the processes

underlying the application, results in one or more Business Process diagrams. The Business Process

design is a high level conceptual task. The resulting BP diagram is a representation of the sequences and

constraints among the tasks to be executed at abstract level, therefore it does not reflect the structure of

the application yet. Business Processes can be internally structured using a variety of constructs:

sequences of activities, AND, OR, XOR and complex conditional gateways for splitting and merging of

branches, iterations of one or more activities, pre- and post-conditions, and so on.

Once the specification of the control flow is defined, the designer can annotate the model by selecting the

kind of expected implementation of each activity and service. In particular, with respect to service

invocation, it is possible to specify whether the service has to be modeled and implemented internally

(internal), shall be invoked as a non-semantic already implemented service (external), or needs to be

searched and invoked by means of semantic discovery and invocation techniques (semantic). The BP

diagram of the running case is represented in Figure 4: for sake of clarity, the process is split into two


sub-processes: part (a) describes the purchase and part (b) describes the shipment management. Notice

that the two processes shall be executed sequentially in the full scenario.

We assume that the MOON services are external, the mediator services are internal, and the shipment

services are semantic.

In the following, we will exemplify the design of the mediator of part (a), and the extraction of ontology,

capability and choreography of part (b). Note that the two workflow diagrams have well-defined

Figure 4. Workflow representing the interaction of the running example (BPMN notation).


workflow semantics (once iteration conditions and conditional branches are fully specified), while the

representation of Figure 2 doesn’t. Building a BPMN (or equivalent) representation of the business

process is a first step of the model driven design of any complex software system.

4.3 Design of the data model and extraction of the ontologies

The elicitation of the ontologies involved in the application is addressed by four distinct steps, each

addressing different aspects of the application ontology:

1. First, existing remote ontologies, possibly provided by third parties, can be imported.

2. Then, the data model is considered as a piece of ontology. This means that an appropriate

transformation of the WebML data model transform the extended E-R internal representation of the

data into a WSMO-compliant ontology, which is then registered on the WSMX resource manager [27].

The expressive power of the WebML E-R model can be compared to the WSML-Flight language.

Table 2 shows the comparison of the expressive power of WebML in respect to OWL-DL and WSML-

Flight extending the comparison presented in [13]. Similar to WSML-Flight, the WebML data model

comprises a rule language called WebML-OQL, which allows for calculating derived information, but

not for defining constraints. Moreover, as WSML Flight, WebML doesn’t have neither Thing nor

Nothing concepts, but, differently from WSML Flight, it cannot deal with equality related constructors

(i.e., EquivalentClasses, SameIndividual, DisjointClasses, DifferentIndividuals, and

Fuctional/InverseFuctional properties). In any case, the similarity between WebML extended E-R

and WSML-Flight is enough to enable a partial extraction of WSMO ontologies.

3. Then, the process ontology is extracted from the BPMN specification of the underlying business

process of the application. The elements of the workflow model (e.g., activity names, lanes, and so on)

are extracted as semantic concepts and used to build an additional piece of the ontology that will be

useful in defining the state signature of the choreography interfaces of the Web Services;


4. Finally, the BPMN model and the WebML data model are annotated with concepts imported from

existing ontologies

This approach is oriented towards T. Berners-Lee vision for Web applications connected by concepts

annotations [2], since it provides a framework for importing existing ontologies and defining new ones,

thus sharing knowledge among different applications on the Web.

Figure 5 shows the E-R diagram used by the Shipment Web Service to describe goals and to invoke the

external Shipment Web Services. The E-R has three main domain entities Shipment, describing each

shipping, ShipmentService, describing BLUE shipment partners, and Location, describing the

Table 2. Expressive power comparison between WebML data model and other ontology languages. OWL Abstract Syntax DL syntax WSML-Flight WebML E-R and OQL Axioms Class(A partial C1 ... Cn) iCA⊆ + + )T;( ≠≠⊥ ACi Class(A complete C1 ... Cn) nCCA ∩∩≡ K1 + + )T;,( ≠⊥iCA EnumeratedClass(A o1 ... on) },{ 1 nooA K≡ − − SubClassOf(C1 C2) 21 CC ⊆ + + EquivalentClasses(C1 ... Cn) nCC ≡≡K1 + − DisjointClasses(C1 ... Cn) ⊆⊥∩ ji CC + − ObjectProperty(R super(R1) ... super(Rn) iRR ⊆ + + domain(C1) ... domain(Cn) iCR .T −∀⊆ + + )( ≠⊥iC Range(C1) ... range(Cn) iCR.T ∀⊆ + + )( ≠⊥iC [inverseOf(R0)] −≡ 0RR + + [Symmetric] −≡ RR + ~ (R and R− with the same name) [Functional] R1T ⊆≤ + − [InverseFunctional] −⊆≤ R1T + − [Transitive]) Trans(R) + − SubPropertyOf(R1 R2) 21 RR ⊆ + + (domain(Ri), range(Ri) ≠ T) EquivalentProperty(R1 ... Rn) nRR ≡≡K1 + + (domain(Ri), range(Ri) ≠ T) Individual(o type (C1) ... type(Cn) iCo∈ + + value(R1 o1) ... value(Rn on)) ii Roo ∈, + + SameIndividual(o1 ... on) noo ≡≡K1 − − DifferentIndividual(o1 ... on) jioo ji ≠≠ , −*** −*** Descriptions (C) A (URI Reference) A + + owl:Thing T − − owl:Nothing ⊥ − − intersectionOf(C1 ... Cn) nCC ∩∩K1 + rhs** unionOf(C1 ... Cn) nCC ∪∪K1 lhs* rhs** complementOf(C0) 0C¬ − − oneOf(o1 ... on) {o1 ... on} lhs* − restriction(R someValuesFrom(C)) DR,∃ lhs* rhs** restriction(R allValuesFrom(C)) DR,∀ rhs** rhs** restriction(R value(o)) oR,∃ + rhs** restriction(R minCardinality(1)) ≥ 1R − rhs** restriction(R minCardinality(n)) (n>1) ≥ nR − rhs** restriction(R maxCardinality(n)) ≤ nR rhs** rhs** + The language fully support the related concept − The language does not support the related concept * May only be used on the left-hand side (as the first argument) of SubClassOf ** May only be used in partial class definitions and on the right-hand side (as the second argument) of SubClassOf *** Notice that already all individuals in an WSML Flight knowledge base and WebML repository are different; therefore, an

explicit assertion would be superfluous


geographical entities involved in the shipment process. The E-R diagram includes also the two process

entities used to describe the status of the process (see Section 3.3). Each Shipment instance is related to a

ShipmentService, to a origin and a destination Location and, finally to an Activity to indicate its current

state. The ShipmentService entity is connected to the Location entity through the shipTo relationship, i.e.,

each shipment partner has a set of possible shipment locations, and through the hasLocation relationship,

each carrier has a set of valid pick up points. Both the Location and the ShipmentService entities have

some sub entities in order to easily specialize their characteristics.

The process of WSML ontologies generation starts by importing external ontologies used in the WebML

E-R model to enrich WebML data types definitions. Then, for each entity in the E-R, a correspondent

WSML concept is generated with its super direct concept, attributes (also E-R relationships are mapped to

attributes) and possible axioms. Axioms are derived from WebML OQL expressions defined on the data.

WebML E-R model can be easily converted to a WSML-Flight ontology maintaining all its constraints.

For instance, the EuropeanShipmentService entity is a sub entity of the InternationalShipmentService that

is located in Europe. This subentity is described in the WebML-OQL syntax as:

InternationalShipmentService(as SuperEntity) where InternationalShipmentService.hasLocation isa Europe.

A fragment of the WSML-Flight translation of the E-R in Figure 5 and its WebML-OQL constraints is:

Figure 5. A portion of the WebML E-R diagram used by the Shipment Web Service.


concept ShipmentService hasName ofType _string hasLocation ofType (0 *) Location ... concept EuropeanShipmentService subConceptOf InternationalShipmentService nfp dc#relation hasValue { EuShipmentServiceDef } endnfp axiom EuShipmentServiceDef definedBy ?x memberOf InternationlShipmentService and hasLocation(?x,?nation) and ?nation memberOf Europe implies ?x memberOf EuropeanShipmentService.

4.4 Querying ontologies

A large part of the design of Semantic Web applications (i.e., WSMO semantic description, extraction of

ontologies) can be performed by means of existing design tools and primitives, some additional elements

might be needed for addressing complex query and reasoning over native semantic data.

Hence we enhanced WebML modifying existing primitives and introducing new ones to allow a native

interaction with ontologies. The aim of this new primitives that are able to perform query over ontological

data is not to replace the original ones: even if part of the information underlying the system is

represented by ontological knowledge, we think that for substantial sections of Web applications

conventional (e.g., relational) representation of data is still effective. Therefore, we claim that integrating

ontologies and relational data and allowing seamless interaction between them is a desiderata of Semantic

Web applications. Thanks to the unit-based model of WebML, where each unit exchanges data with other

units by passing parameters over links, interaction between ontology's instances and database instances

can be quite straightforward. The main asset of WebML, i.e., its ability of effectively capturing the

parameters passed between the different components (units) of the Web application, is still valid even

when we are considering Semantic Web applications. Indeed, it does not matter if the underlying data are

extracted from ontologies or databases; a Web application is anyway composed by the same hypertextual

primitives. Parameters on the links become the actual contact point between traditional and semantic data.

In this way, we achieve a good orthogonalization between data model and hypertext model of the

applications.

4.4.1 Basic primitives for queries on ontologies

Basic WebML primitives for data access can be exploited for queries over ontologies: Index unit,

Multidata unit, and Data unit are traditionally used to navigate database instances, but their semantic is

general purpose, and hence their paradigm is suitable to navigate and show ontology instances too. They


only need to be extended to support different kinds of data sources (in particular, ontologies) and some

additional options for the queries. For instance, the Index unit can be used to produce lists of instances of

a particular class of the domain ontology. A needed feature is the possibility to show only direct instances

or also inferred instances. Moreover, an Index unit that express a query over an ontology class may show

also the direct or the inferred subclasses of the selected class. The developer can choose at design time the

combination he prefers. The same discussion applies to Multidata unit and Data unit.

WebML already introduced the concept of Hierarchical Index unit, which acquires a first class role in the

context of Semantic Web applications. Hierarchical Index unit is ideal to publish a portion of a ontology:

i.e., the hierarchic tree underlying a certain class comprising its subclasses and instances.

4.4.2 Advanced primitives for queries on ontologies

The evolution of the basic data access primitives, introduced in the previous paragraph, is not enough to

exploit the rich set of possible queries over semantic instances and classes. Therefore, we introduce a new

set of operational primitives to describe advanced queries over ontological data. We introduce a first set

of units representing the basic ontological queries and inferences for Classes, Instances, and Properties.

The units are aggregate primitives that, depending on the type of parameters, execute differently. Table 3

summarizes the syntax and the semantics of such units.

Note that these units are natively able to manage ontological data sources, therefore they can manage

concepts and references by means of the standard uri (Uniform Resource Identifier) mechanism, while the

original WebML units only rely on OID identification mechanisms.


Besides the units for ontological data query, we introduce a unit to compose the uri sets returned by other

units (Figure 6). The Set Composition operation unit is able to perform classic set operations over 2 input

sets of uris (i.e., union, intersection, difference). The operations are performed by taking into account the

hierarchical structure of the uris involved in the operation: e.g. suppose we have two set of classes

A={wine, liquor, food} and B={drink, food}, and assume that the drink class is a superclass of wine and

liquor; then A INTERSECTION B gives {wine, liquor, food} and A UNION B gives {drink, food}. The

Import Ontological Source unit adds a remote or local data source that must be consistent with

ontological model of the Web application (it's validated against it before being added to the ontology

model). It is also possible to express the url of an ooMediator to be used to import the ontology and

Table 3. The new WebML units for advanced queries on ontologies. Unit name and

Symbol Input Output Description

c1, c2 true if c1 is subclass of c2

c1, ? the list of superclasses of c1

?, c2 the list of subclasses of c2

Given two classes, it returns true if the first is subclass of the second. Given a class, it returns the list of its subclasses or superclasses.

i, c true if i is instance of c

i, ? the list of classes for i

?, c the list of instances of the class c

Given a class and an instance, it returns true if the object is instance of the class. Given a class, it returns the list of its instances. Given an instance, it returns the list of the classes it belongs to.

c, p true if the class c has the property p

c, ? the list of properties of the class c

?, p the list of classes having p

Given a class and a property, it returns true if the class includes the property. Given a class, it returns the list of its properties. Given a property, it returns the list of the classes it belongs to.

p, v true if the property p has value v

p, ? the list of possible values for the property p

?, v the list of properties with value v

Given a property and a value, it returns true if the property assumes that value. Given a property, it returns the list of all the possible values of the property. Given a value, it returns the list of properties with that value.

p1, p2 true if p1 is subproperty of p2

p1, ? the list of superproperties of p1

[Property1=?][Property2=?]

Subproperty

?, p2 the list of subproperties of p2

Given two properties, it returns true if the first is subproperty of the second. Given a property, it returns the list of its subproperties or superproper-ties.


convert it to the internal ontological model. The Describe unit returns the RDF description of an uri, thus

enabling automatic Web page annotation and data exporting.

Advanced querying units can be used to compose reasoning tasks over ontological data: e.g., suppose that

we want to find the set of common properties between two classes representing different products

categories (e.g., Digital Photo Camera and Mobile Phone), first we can use two HasProperty units to

extract the two set of properties characterizing the two classes; and finally we can find the common set of

properties by means of the SetComposition unit (e.g., Pixel, Storage, …). The same idea may apply if we

want to discover the common super concepts between two ontology instances: in this case, instead of the

HasProperty units, we can use two InstanceOf units to extract the two set of super classes to which the

two instance belongs to; then we can find the common set of superclasses by means of the

SetComposition unit.

Figure 7 shows a portion of the Purchase Order Interface used to navigate the Product ontology and to

import ontologies provided by business partners in the contest of our B2B scenario. In the Import

Ontologies page, users can fill the form with url to remote ontologies and to the suitable ooMediator, if

the ontology provided by the business partner is not consistent with the internal ontological model. When

the user submits the filled form, the Import Ontology unit uses the data in the form to acquire the

ontology and eventually to call the ooMediator needed to import the new ontology. Available

ooMediators are published by a WSMX repository and designed with the tool WSMT. Once an ontology

datasource is successfully imported, the user is redirected to the Select Product page, where pre-existing

data and newly imported are visible. In the Select Product page, the hierarchical unit Products Hierarchy

shows a tree with the class hierarchy pertaining to the concept Product: all its direct and derived

subclasses are shown on the tree. When the user selects one of the concepts in the class hierarchy, the

Index unit Product Instances is populated with all the instances of the selected concept. From the Index

unit Product Instance, the user can navigate to the Product Details page where the Data unit product

Figure 6. Ontology management WebML units.


shows details on the selected product according to its class and the related properties. The Index unit

Accessories shows all the product instances and classes that have has the current product uri as value of

the property isAccessoryOf. Finally the user can view all the classes to which the current product instance

belongs: the uri of the current product instance is passed to the InstanceOf unit that extracts all the direct

and derived classes corresponding to the passed instance. Hence the set of classes uri returned by the

InstanceOf unit is used to populate the Index unit Related Product Classes.

4.5 Design of the service and the user interfaces in WebML

Once the business process has been designed, workflow constraints must be turned into navigation

constraints among the pages of the activities of the hypertext and into data queries on the workflow

metadata for checking the status of the process, thus ensuring that the data shown by the application and

user navigation respect the constraints described by the process specification. This applies both to the

human-consumed pieces of contents (i.e., site interfaces) and to the machine-consumed contents (i.e.,

Semantic Web Services interactions).

In our framework both BPMN diagrams and WebML diagrams are stored by means of a XML

serialization. Transformations are performed by means of specialized XSLT stylesheets that process the

internal lanes of the BPMN model producing the XML serialization of a WebML model: e.g., for a Web

Service lane, each activity in the BPMN model is converted in a WebML activity (an ‘A’-labeled area)

Figure 7. The Area used to select products to be ordered using business partner ontologies.


populated with a default unit (i.e., Solicit units for the BPMN activities that receive messages from

external lanes, Response units for the ones that send back messages, Request-Response units for the ones

that call remote Web Services and generic Operation units for the others); then the WebML activities are

connected by proper links with a well defined semantic to indicate the begin of an activity (‘S’-labeled

links) or its end (‘C’-labeled links). Finally the datamodel is enriched with Case and Activity concepts

(cfr. Section 4.3) that are populated according to the BPMN model (a case instance for each BPMN lane

and an activity instance for each BPMN activity). Our BPMN tool allows to represent only valid diagrams

so that the translation to WebML is always guaranteed. The produced WebML model shall consist of

application data model, workflow metadata, and hypertext diagrams. Since no a-priori semantics is

implied by the activity descriptions, the generated skeleton can only implement the empty structure of

each activity along with the hypertext and queries that are needed for enforcing the workflow constraints.

The designer remains in charge of implementing the internals of each activity. Additionally, it is possible

to annotate the activities, thus allowing the designer to map the activity to a coarse hypertext that

implement the specified behavior on the specified data. The designer is in charge of refined specification

of the hypertexts. For instance, Figure 8 shows a possible WebML specification of the hypertext of the

Blue Shipment service.

Figure 8. The Blue Shipment Web Service.


In the upper part of Figure 8, the ShipmentRequest is received by searchShipmentRequest and is passed

to the Goal Composition that fill a Goal Template with the required instances, obtaining a goal

description for the WSMX compliant Discovery Engine; the generated goal description is passed to the

Send Goal which sends the goal to a Web Service exposed by the Discovery Engine. The Discovery

Engine returns as result a set of Web Services compatible with the original shipment goal and, for each

returned Web Service, an appropriate XSLT stylesheet describing the Lowering and Lifting operations;

the results of the Web Service call are stored by Store Goal Result. Then, for each valid Web Service

returned, a request for a shipment offer is made by WS Offer Invoker. The XSLT stylesheets for the

Lowering and Lifting are selected for each valid Web Service according to the results returned by the

Discovery Engine. Each offer returned by a Shipment Web Service is stored by Add Offer. The results for

the current Shipment Request are selected by Extract Valid Offers and converted to the Blue data model

by Lowering and the set of offers is returned the service requester by SendShipOffer. Once the service

requester selects one of the offers and he sends the ConfirmShipOfferRequest to the

confirmShipOfferRequest (lower part in the Figure 8), the previously stored offer is retrieved (Extract

Confirmed Offer), hence the offer purchase message is composed by Lowering wih an approriate XSTL

stylesheet and WS Purchase Invoker sends the message to the Shipment Web Service. Finally Send

ShipmentConfirmation sends a confirmation message to the service requester according to the answer

received by the invoked Shipment Web Service.

Figure 9 shows a WebML hypertext model representing a fragment of the Blue Web application: a home

page called Select Order to Ship allows the user to choose an Order (with Status “Not shipped”) from the

Figure 9. The Blue Web interface to organize shipments for successful orders.


Order List index unit. When an order is chosen, the “S” link starts the Organize Shipment activity,

showing the Order Details data unit in the Organize Shipment page, together with a form (Search

Shipment Offers). The data submission triggers the invocation of a remote service (searchShipmentOffers

request-response unit), whose results are lifted by the storeShipmentOffer XML-in unit. The activity is

completed (link “C”) and following one is started. The Select Shipment Offer page is shown, containing a

list of Shipment Offers (an index unit displaying the results of the service). The user chooses an offer and thus

triggers the confirmShipmentOffer request response, whose results are stored locally. Finally, the user is

redirected to the home page.

One should notice that this high level visual programming of Web applications, although of lower level if

compared to BPMN specifications, is not concerned with many implementation details, which are left to the

design tool, capable of deploying the code for arbitrary choices of data management and Web server

architecture. Moreover, this visual programming style is natively supporting change management and

reengineering.

5 Extraction of the WSMO description of the Web Services

In this section we show that the WSMO-compliant description of Web Services can be semi-

automatically derived from the design specification.

Figure 10 summarizes the extraction of semantic description of services from the application design. The

design flow represents the main steps of the development process presented in Section 4.1. The various

steps produce some intermediate artifacts (BPMN models, WebML skeletons, data models, hypertext

models), possibly enriched by imported ontological descriptions (on top of Figure 10) and are exploited

Automatic code

generation

Business process modeling

WSML Goal

Ontology importing and/or semantic annotation

WF-driven WebML

generator

Web application modelingBPMN

modelWebML skeleton

Running application

WebML data

model

WebML hypertext

model

WSML WS Choreography

WSMLWS Capability

WSMLMediator

Figure 10. Overall picture of the extraction of semantic description of Web Services.


for devising the set of WSMO specifications (at the bottom of Figure 10): the description of the mediator

can be extracted from the hypertext describing the mediator (see Section 5.4); the Web Services

capability description is derived from hypertext model; the choreography information is derived from BP

model; and the user goals (Section 5.3) are derived from the BP model and the hypertext model.

5.1 Extraction of Web Services capabilities

The BPMN and WebML models of the Web Services provide enough information for describing its

behaviour. Assuming a BPMN activity as an atomic Web Service call, we can exploit the BPMN data

flow for providing good hints for the extraction of inputs and outputs of the service. Indeed, the data flow

specifies the objects that are passed between the various activities. By isolating a single activity, it is

possible to extract the WSML pre-conditions (inputs) and post-conditions (outputs).

WSML pre-conditions are obtained from the first unit of WebML chain describing a Web Service

operation (Solicit Unit), while post-conditions are obtained from the last one (Response Unit). These two

units contain information about the exact structure of the exchanged message and eventually the mapping

of message elements to the domain model and hence to the extracted ontologies (see Section 4.4). Effects

are extracted searching for WebML units that modify or create instances of entities that are related to the

activities involved by the process described in WebML Web Service. Shared variables are obtained from

the different generated conditions by grouping all the variables involved in the operations data flow.

Figure 11. A portion of the WebML XML serialization and the generated WSML description.


Figure 11 shows a portion of the WebML XML serialization for the Blue Shipment Web Service,

introduced in Section 4.4 and its correspondences with the automatically generated WSML description of

its capabilities. In particular, Figure 11 illustrates how parameters of the Solicit Unit in WebML

(SolicitParameter) corresponds to WSML pre-conditions, and how parameters of the Response Unit in

WebML (ResponseParameter) corresponds to WSML post-conditions. The WebML XML serialization

contains also a reference to the XSD file describing the structure of the exchanged messaged

(shipment.xsd) while the WSML description contains information about the structure of the exchanged

messages (surrounded by a green box): both these parts are obtained from the data model introduced in

Section 4.3.

5.2. Extraction of the service choreography

The service choreography is a piece of information that typically requires some annotation by the

designer, in order to establish all the possible interaction sequences with the service. However, at least

one of the choreography sequences can be extracted from the BPMN model, by analyzing the order of

invocation of the different operations of the service. Obviously, this does not guarantee that all the

possible scenarios are considered, since only one enactment can be analyzed. The extraction of this kind

of information is rather simple: provided that a lane describes a single Web Service, we can assume that

all the control flow links traversing its borders contribute to specifying a possible invocation order of the

operations, i.e., a choreography interface of the Web Service.

The following is the WSML description of the Web Service choreography interface automatically

generated.

interface choreography stateSignature in ShipmentRequest withGrounding […] ConfirmShipOfferRequest withGrounding […] out ShipOfferContainer withGrounding […] ShipmentConfirmation withGrounding […] controlled oasm#ControlState transitionRules forall {?x, ?state} with ( ?state[oasm#value hasValue oasm#InitialState] memberOf oasm#ControlState and ?x memberOf ShipmentRequest ) do add(?state[oasm#value hasValue ShipmentOfferRequested]) delete(?state[oasm#value hasValue oasm#InitialState]) add(_# memberOf ShipmentOfferContainer)


endForall forall {?x, ?state} with ( ?state[oasm#value hasValue ShipmentOfferRequested] and ?x memberOf ConfirmShipOfferRequest) do add(_# memberOf ShipmentConfirmation) endForall

5.3. Extraction of the service orchestration

The process that leads to the extraction of the service orchestration is very similar to the previously

introduced process for the extraction of the service choreography. While the WSMO choreography

describe the supposed order of call of the operation provided by a Web Service, the WSMO orchestration

describes how a published Web Service internally interacts with other Web Services. At the moment the

language to describe the WSMO orchestration interface [43] is still under development, but we already

know that it will be based on the same ASM model used to describe WSMO choreography interface. For

example, taking into account the second lane of the BPMN diagram in Figure 4(a), that represents the

Web Service that provides the implementation of a Web Service to Web Service Mediator (wwMediator),

we are able to automatically extract the orchestration sequences considering all the control flow links

traversing its borders with the bellow lane, containing the operations of the remote Web Service.

5.4 Extraction of user’s goal

Extraction of user’s goals can be performed combining information available at the BPMN level with

information available at the WebML level. A first level of goal elicitation can be achieved by extracting

the sequence of conditions and objects passed to the Web Services by the user’s lane in the BPMN

diagram.

A deeper level of details requires using the WebML hypertext models and analyzing the semantics

embedded in the navigation and composition of the pages. Such refined goal is detailed in terms of the

tasks performed by the user and of the data manipulated, thus increasing the significance of the WSMO

goals that can be generated. Goals are generated in correspondence with Web Service call to provide a

semantic description of the objective persecuted by the user/machine invoking the Web Service. In the

scenario we introduced, for example, a Goal template description is automatically generated a design time

and populated at runtime to describe the user’s aims implied by the Organize Shipment Interface

interaction with the Shipment Web Service. In particular, the shared variables are extracted from the data


instances passed to the Web Service operation call, while the effects are obtained considering the WebML

operations modifying data associated to the extracted shared variables. For example, the XML-In unit in

Figure 9, stores the confirmed shipment orders creating a shipment data instance with a particular status.

The following is the WSML description of a Goal automatically generated.

capability sharedVariables ?shipment postcondition definedBy ?shipment [ requestedPickupLocation hasValue stanford, requestedDeliveryLocation hasValue rome, requestedDeliveryDateTime hasValue _date(2006,4,28), goodDimension hasValue _d [ l hasValue 10, w hasValue 50, h hasValue 100] memberOf dimension, maxAcceotedShipmentPrice hasValue 50 ] memberOf requestsShipmentService. Given that goals capture user’s needs, this part of the process is perhaps the least easy to automatize, and

manual verification and intervention is generally required.

5.5 Design of wwMediators with WebML

One of the main strength points of the approach is the ease of design and implementation of complex

wwMediators. If a lane is identified as a wwMediator at the BPMN level, the basic information about the

design of the mediation services can be extracted from the high-level BPMN description of the

interactions (in particular, information about possible choreography of the service and basic interface and

parameter specification). The skeleton model of the mediator is automatically generated and the designer

can refine it at a conceptual design level. Then, the WSMO description of the mediator can be derived

from the WebML diagrams.

Figure 12 presents the detailed specification of the wwMediator within WebML. This specification can be

used to generate a working Web Service providing mediation between Blue and Moon Web Service. The

WebML specification includes some Lowering and Lifting operations corresponding to WSMO

ooMediators and provides mediation between the data model of the source Web Service and the

destination one. In WebML this mediation consists in XSLT stylesheets generated by a graphic tool

described in Section 6.1. Note that the mediation activities are in one-to-one correspondence with the

BPMN activities of Figure 4. The chain of operation consists of: (a) receiving a Web Service call


invocation; (b) transforming input application data into suitable internal format (lifting); (c) storing

internal application data; (d) transforming application data into suitable format for the subsequent Web

Service call (lowering); (e) calling the next Web Service in the chain; (f) tracking the status change of the

wwMediator (with no manual intervention).

The following WSML description of the wwMediator, need to register it on the WSMX runtime, is

generated at deploy time:

wwMediator _... nonFunctionalProperties dc#type hasValue _"http://www.wsmo.org/2004/d2/v1.2/#mediators" endNonFunctionalProperties source _"http://blue.org/RosettaPurchaseOrder" target _"http://moon.org/OMService"

6 Implementation

A proof of concepts of the integration with the semantic aspects discussed in this paper has been

presented at the SWS Challenge 2006 [5, 16]. The two phases of the challenge allowed us to prove the

advantages of a Software Engineering approach to Semantic Web Services design. In particular, in the

first phase we presented the WebML design and implementation of the wwMediator of the running case

Figure 12. The WebML model of wwMediator Web Service.


addressed in this paper (Figure 12) and the usage of the CASE tool WebRatio in the context of Semantic

Web applications. Moreover, we integrated Glue WSMO discovery engine by invoking the Web Services

that Glue exposes both for publishing a new shipment service and for discovering the most convenient

shipment service. In the second phase we proved to be able to deal with changes without writing

additional code, but only modeling the additional requirements and exploiting the same framework

adopted in the first phase.

6.1 WebRatio

The presented approach relies on solid implementation of the background concepts: the WebML

methodology is supported by a commercial CASE tool called WebRatio [49], providing visual design

interfaces and automatic code generation. The architecture of the tool enabling semantic Web design is an

extension of the WebRatio architecture [11]. At compile time (Figure 13, top), each application

specification is used to generate an XML descriptor for each unit, link, Web page, service call, and

service publishing primitive. At runtime (lower part of Figure 13) the application is instantiated and

executed. Clients issue requests to the server, which in turn calls the execution engine; the generated code

includes customized JSP tags that define the placement of the WebML units into the pages. The content

JSP engine

Browser

Web Server

RDBMS LDAP XML ...

Unit descriptor 1

Unit descriptor n

Message decomposer

SOAP sender / listener

Message composer

...

...

ConversationManager

Standard components interactions

Processing of messages received by the site

Construction of messages sent by the site

WebML runtime

Automatic WebML site generator

WebML site specification

Compile (design) time

Runtime

JSP pagesBusiness

Layer

DataLayer

Presentation Layer

Client Layer

Figure 13. Architecture of WebRatio Web application design tool.


required by the user is assembled by the WebML runtime component, using the descriptors and the data

sources in the Data Layer.

Web Service calls are managed by a SOAP sender/listener, and a Conversation Manager for conducting

long-running interactions with a service.

Design support for the grounding of services is provided too. In particular, we developed a prototype

mapping tool for visual lowering and lifting of data. The tool allows to design content transformation

from local domain ontologies to XML format and vice-versa. With this tool we don’t aim at covering as

much as possible of query power. What is needed is a simple and intuitive, yet formal, modeling of

typical XML transformations in the context of semantic Web. The designer can ground a service to an

XML implementation by specifying a set of lowering and lifting transformations defined by drawing

simple lines between the origin and target format. The full description of the tool can be found in [6],

while a snapshot of the GUI is visible in Figure 14. The information about the transformation drawn by

the designer is stored into an XML file, which is used to create appropriate XSL files to be used in

Adapter Units within WebML applications, for applying transformations on the actual XML documents.

6.2 BPMN editor and WebML generator

The modeling of the business process requirements and their transformation into WebML skeletons are

implemented in a prototype tool [3] that allows to design BPMN diagrams and to automatically generate

the corresponding WebML hypertext models. The workflow schema is stored as an XML document and

WebML models are generated using XSLT technology. In addition, the transformation takes into account

the annotations that the designer provided on the kind of implementation of the services (internal,

Figure 14. Snapshot of the visual mapping tool for content lowering and lifting


external, semantic). Generation rules for the hypertext have been built based on the experience and the

theory presented in [8].

6.3 WSML descriptions generators

For validating our approach, we developed several prototypical transformers that generate WSMO-

compliant descriptions of Web applications and services starting from WebML models of the applications

and BPMN specifications of the processes. The pieces of WSMO specification presented in Sections 4.3,

4.5, and 5.3 are samples of the generated output of the transformations. Since both WebRatio and the

BPMN editor are designed to be flexible and extensible, and they can manage user-defined properties of

objects and new XSLT transformations of the workflow models, we added our generation engines for

semantic description of the application directly to the tools.

6.4 GLUE discovery engine

Web Service discovery has been addressed by black-box invocation of Glue WSMO discovery engine

which provides the basis for introducing discovery in a variety of applications that are easy to use for

requesters, and that provides efficient pre-filtering of relevant services and accurate discovery of services

that fulfil a given requester goal.

Following the process described in [15], Glue was configured by

1. importing the ontologies generated following the approach described in Section 4.3;

2. importing the classes of shipment Web Services and of goals generated following the approach

described in Section 5; and

3. manually modeling the required wgMediator that encodes the rules for matching a request for shipmen

(modeled as an instance of shipment goal) against the published instances of shipment Web Services.

7 Effectiveness of the proposed approach

The proposed approach results particularly efficient and convenient for the developers, in terms of

productivity, ease of use, and scalability.


7.1 Productivity evaluation

Productivity advantages have been achieved thanks to the powerful automatic generation of code and

semantic annotations. WebRatio is capable of fully automatically generating J2EE code of an application

starting from WebML specifications. In turns, WebML diagrams are partially automatically generated

from high level business process specification. Thus, in conventional Web applications, programming is

confined to componentization of special or existing parts of an application, while WebRatio is the glue

covering the application design lifecycle, including redesign and maintenance. Previous work [23]

describes how function points analysis can be integrated with WebML application modeling. A prototype

exists for calculating the number of (unbalanced) function points given a WebML model of a Web

application. Extensive experiments show that development of traditional Web applications conducted

according to the WebML approach and the WebRatio tool allows an average increase of productivity of

more that 50%.

Our approach to the deployment of Semantic Web applications has been validated on a realistic scenario

represented by the SWS challenge case study. In the design and implementation steps of the development,

we followed the process presented in Section 4.1. The semantic description that feed the WSMX runtime

engine have been partially generated automatically and then integrated and refined by the designers.

Table 4 reports details on the models, the semantic descriptions, and the running code: for each of them,

we indicate the percentage of automatically generated software. For models and code generation,

Table 4. Average percentage of automatically generated pieces of software DESIGN % of automatic model generation

Business process design (BPMN) 0 %

Data model design (extended E-R) 30 %

Service and the user interfaces design (WebML) 20 %

wwMediators design (WebML) 20 %

SEMANTIC DESCRIPTION EXTRACTION % of automatic description generation Extraction of the ontologies (imports excluded) 70 %

Extraction of Web Services capabilities 75 %

Extraction of the service choreography 60 %

Extraction of the service orchestration 70 %

Extraction of user’s goal 40 %

APPLICATION CODE GENERATION % of automatic code generation Traditional (non-semantic) parts of the applications 100 %

Semantic parts of applications (descriptions excluded) 75 %


percentages have been calculated by considering the number of function points that were automatically

generated with respect to the total number of function points of the application. For semantic descriptions,

percentages are calculated in terms of lines of WSML automatically generated (and not refined by the

designer) with respect to the total ones.

Productivity is increased by our approach also thanks to the well formalized development process, the

adherence to a top-down design process, and the standardization of the application architecture: model

driven development reduces the risk of bugs in the code, thanks to the reuse of well tested components.

Moreover, when new components are needed, they are developed according to strict guidelines and tested

with state of the art automatic code testing technologies.

7.2 Ease of use

The visual modeling of the application provides a great advantage to designers and developers. BPMN

models proved to be quite intuitive also for non-expert designers such as business experts, and an average

knowledge of the full WebML approach can be achieved within a week of training. Then, designers need

to include semantic descriptions in the form of tagging and annotations; their specification will be

facilitated by means of wizards and verification tools that we plan to incorporate within future versions of

our tool. Developers do not need a high level of technical expertise, as they are not bothered with time-

expensive code development and debugging: the environment allows for multi-platform code generation

without any additional effort. Further advantages are available thanks to the WebRatio CASE tool:

• Automatic project documentation: the tool generates the application documentation (in a style called

WebMLdoc, very similar to the well known JavaDoc format) starting from the plain WebML models,

possibly enriched with designer comments; such documentation will include Semantic Web

annotations.

• Model checking: the tool is able to perform syntactical and limited semantic analysis of the WebML

models, providing the developer with error and warning messages, thus providing early feedback to the

designer; such analysis will be extended to the semantic components of the models.

• Fast prototyping: thanks to visual design and automatic generation of the code, a fast prototyping

design process can be adopted, with very short design cycles.


7.3 Scalability

The WebRatio approach demonstrated to perform very well when scaling to big applications, both at

design time and runtime. This has been proved widely for traditional applications, with models composed

by thousands of pages and components.

Design productivity scales easily thanks to the good modularization of diagrams and models, to the

integration of the CASE tool with team-oriented editing (with classical check-in/check-out operations and

reconciliation support), and to industrial-strength support to code documentation and production within

standard repositories. Future increases of scalability in WebRatio are planned with the integration of the

business process layer, already planned regardless of the Semantic Web extension; the other aspects of

design scalability more specific to the Semantic Web will next be considered.

Runtime scalability is granted thanks to the adherence of the generated running code to standard, state of

the art platforms (J2EE, Jakarta Struts, WSMX). The components are developed according to the best

practices of the respective platforms. Runtime performances and scalability is therefore limited only by

performance constraints of the platforms of choice.

8 Related work

In the last years, the Semantic Web has become an hot topic and many researchers turned their interests

towards to its development; as a result, some of the ideas and promises of the Semantic Web are

becoming real: technology has been pushed, new standards have been envisioned, the first real-world

applications have been developed (e.g., MultimediaN N9C Eculture [37], eMerges [18]) and consequently

an increasing number of big industries are starting to invest in this area (e.g., SAP, IBM, Oracle, and

Nokia). However, limited research efforts are concerned with the environments, methods, and tools for

the systematic development of Semantic Web applications. A number of researches concentrated on tool

development for supporting the generation of semantic descriptions for existing Web Resources (e.g.,

Services) [17,31], but these in general require the mastering of the annotation language to be used (e.g.,

OWL-S or WSMO) and hence do not help widening the adoption of Semantic Web and Semantic Web

Services. In the rest of this section, we summarize other approaches, sharing with us the goal of easing

application development for the Semantic Web. We note the partial development of methods, without


tools, or of tools, without methods, while the integration of both aspects is still very preliminary. For

many aspects, our research effort is coherent with the recent efforts of the Object Management Group

(OMG). The OMG proposed the Ontology Definition Metamodel (ODM) [39] to define a suitable

language for modeling Semantic Web ontology languages and hence Semantic Web applications in the

context of the Model Driven Architecture [37].

MIDAS is a framework, based on MDA, for modeling and developing Semantic Web applications,

introduced in [1]. The framework focuses on the creation of Semantic Web Services and associated

WSML descriptions using a UML model according to the MDA approach. This proposal inherits the

limits of the MDA approach: the use of a UML model is not simpler than using a Semantic Web

language, and the model is too far from the implementation to allow for an effective automatic code

generation. Furthermore, MIDAS still does not provide a comprehensive method covering all the phases

of the design of Semantic Web applications.

The research proposed in [24] aims at generating OWL-S specifications and grounding starting from

standard UML diagrams; however, only the semantic description of the Web Services is covered, while

their actual design and implementation are omitted: semantic descriptions are not inferred from the design

of the programming logic of the Web Service, they must be annotated by means of a UML formalism.

Similar to our approach, Torres et al. [45] propose a first idea of a method based on Web Engineering

research concentrating on the generation of Semantic Web Service descriptions. This proposal refers to

OOWS – an extension of the UML based OO-Method [22] – as Web Engineering method and aims to

generate OWL and OWL-S descriptions. In comparison, our approach covers a wider are of aspects

related to Semantic Web Services (e.g., wwMediators, discovery integration, …) due to the greater

richness and expressivity of our models, that allow to cover with fine details the execution semantics of

hypertexts and services.

In the last years, after realizing the benefits offered by the Semantic Web platform (e.g., interoperability,

inference capabilities, increased reuse of the design artifacts, etc.), many efforts have been directed

towards the extensions of existing Web Information Systems design methods to include aspects of the

Semantic Web. Traditional design methodologies like OOHDM [34] are now focusing on designing

Semantic Web applications. New methodologies like Hera [48] were specifically designed by considering


the Semantic Web peculiarities. These methodologies are not fully supported by effective and mature

CASE tools and concentrate on Semantic Portals rather than Semantic Services.

9 Conclusions and future work

This paper presented an overall approach for designing Semantic Web applications by exploiting software

engineering techniques. The following results have been shown:

• Ontologies can be imported as models of the data necessary for the cross-enterprise application. They

can be extended for addressing the specific needs of the application and registered as shared resources

in WSMX.

• WSMO Web Services functional capabilities for delegating sub-processes execution from one

enterprise to another are automatically provided for each Web Service modelled in WebML.

• Choreography interfaces can be derived by combining information in the Business Process Model and

in the WebML hypertext model. In particular, the local choreography can be derived by taking the

point of an external observer of the Web Services that must know the order in which operation can be

invoked and the constrains for their successful invocation. In a similar manner we can derive the

orchestration interface by translating in WSMO some aspects of the BPMN model of the application,

as sketched in Section 5.2.

• WSMO goals can be produced (e.g., goals that triggers the discovery component of WSMX) from

gathering data required to perform a given action of the business process, whereas its choreography

interface is derived by the explicit representation of workflow primitives within the hypertext.

• mediation services can be modeled as WebML applications and registered in WSMX according to

their roles (e.g., a wwMediator).

In summary, in this paper we propose a complete method for the semi-automatic extraction of the

components of the WSMO architecture by using existing software engineering abstractions. In our

previous work [4] we presented a first sketch of the approach, with special attention to the extraction of

the semantic description of services and design of wwMediators (i.e., current Sections 5.1 and 5.4). The

current paper extends and details the existing preliminary work, by defining the extraction mechanisms

for goals and orchestration, as well as specifying in details and by example the transformations that are


needed. Moreover, we provide now a comprehensive view of the methodology and we propose a self-

contained design approach for Semantic Web applications and services. We now provide the possibility

of importing ontologies, services and mediators descriptions, and we define a set of new hypertext

primitives for querying ontological information. Finally, we compared the expressive power of WebML

information modeling with respect to well known ontology definition languages.

At the current stage of development, by means of “conventional design” (although supported by an

advanced visual design studio), we build software that can run on conventional Web technology and at

the same time is ready to become part of a WSMO execution environment (i.e., WSMX). Our future

research agenda, which we will schedule in parallel with the wide-spreading and enhancement of WSMO

standards, will concentrate upon empowering our design abstractions by incorporating the WSMO

concepts as “first-class citizens” in the design process, lifting them up in the artifacts design hierarchy, so

as to further improve and simplify the design of native WSMO components.

References 1. Acuña, C. J., Marcos, E.: Modeling semantic web services: a case study. In Proceedings of the 6th International Conference

on Web Engineering (ICWE 2006), Palo Alto, California, USA, 32-39. 2. Berners-Lee, T.: Web Services - Semantic Web Talk. Available at: http://www.w3.org/2003/Talks/08-mitre-tbl 3. Brambilla, M.: Generation of WebML Web Application Models from Business Process Specifications. In proceedings of

the Sixth International Conference on Web Engineering (ICWE 2006). In print. 4. Brambilla, M., Celino, I., Ceri, S., Cerizza, D., Della Valle, E., Facca, F. M.: A Software Engineering Approach to Design

and Development of Semantic Web Service Applications. Technical Report 2006.47, Politecnico di Milano. Also submitted to ISWC 2006, Milan, 2006. Available at: http://webml.org/webml/upload/ent5/1/BCC2006.pdf

5. Brambilla, M., Ceri, S., Cerizza, D., Della Valle, E., Facca, F. M., Fraternali, P., Tziviskou, C.: Web Modeling-based Approach to Automating Web Services Mediation, Choreography and Discovery. In Semantic Web Service Challenge 2006 Phase I, Stanford University, Palo Alto, CA, March 2006. Available at: http://sws-challenge.org/wiki/index.php/Workshop_Stanford.

6. Brambilla, M., Ceri, S., Comai, S., Tziviskou, C.: A visual data mapping tool for software components interactions in service-oriented architectures. In Proceedings of the 2006 IASTED International Conference on Software Engineering (SE 2006). January 2006, Innsbruck, Austria, 33–38.

7. Brambilla, M., Ceri, S., Fraternali, P., Acerbis, R., Bongio, A.: Model-driven Design of Service-enabled Web Applications. In proceedings of the ACM SIGMOD International Conference on Management of Data, Baltimore, Maryland, USA, June 14-16, 2005, 851–856.

8. Brambilla, M., Ceri, S., Fraternali, P., Manolescu, I.: Process Modeling in Web Applications. In ACM TOSEM, 2006. In print.

9. Business Processing Modeling Notation (BPMN), OMG, Version 1.0, 2006. Available at: http://www.bpmn.org. 10. Ceri, S., Fraternali, P., Bongio, A., Brambilla, M., Comai, S., Matera, M.: Designing Data-Intensive Web Applications.

Morgan-Kaufmann, December 2002. 11. Ceri, S., Fraternali, P., Acerbis, R., Bongio, A., Butti, S., Ciapessoni, F., Conserva, C., Elli, R., Greppi, C., Tagliasacchi,

M., Toffetti, G.: Architectural Issues and Solutions in the Development of Data-Intensive Web Applications. In Proceedings of the VLDB First Biennial Conference on Innovative Data Systems Research (CIDR2003), Asilomar, January 2003.

12. de Bruijn, J., Lausen, H., Krummenacher, R., Polleres, A., Predoiu, L., Kifer, M., Fensel, D.: The Web Service Modeling Language WSML, March 2005. Available at: http://www.wsmo.org/TR/d16/d16.1/v0.2/

13. de Bruijn, J., Polleres, A., Lara, R., Fensel, D.: OWL flight, October 2004. Available at: http://www.wsmo.org/2004/d20/d20.3/v0.1

14. Della Valle, E., Cerizza, D.: Cocoon glue: a prototype of WSMO discovery engine for the healthcare field. In Proceedings of 2nd WSMO Implementation Workshop WIW’2005, 2005.


15. Della Valle, E., Cerizza, D.: The mediators centric approach to autmatic webservice discovery of Glue. In Hepp, M., Polleres, A., van Harmelen, F., Genesereth, M.R., editors, Proceedings of the First International Workshop on Mediation in Semantic Web Services (MEDIATE 2005), Amsterdam, The Netherlands, December 12, 2005, CEURWorkshop Proceedings, 8, 35–50.

16. DERI Stanford. Semantic Web Services Challenge 2006. http://sws-challenge.org. 17. Elenius D., Denker G., Martin D., Gilham F., Khouri J., Sadaati S., Senanayake R.: The owl-s editor – a development tool

for semantic Web services. In 2nd European Semantic Web Conference, May 2005. 18. eMerges, Spatial Data Integration with Semantic Web Services, 2006. http://irs-test.open.ac.uk/sgis-dev/ 19. Feier, C., Domingue, J.: WSMO Primer. Available at: http://www.wsmo.org/TR/d3/d3.1/v0.1/ 20. Fensel, D., Bussler, C.: The Web Service Modeling Framework WSMF. In Electronic Commerce Research and

Applications, 1(2), 113–137, 2002. 21. Fernandez, M.F., Florescu, D., Levy, A.Y., Suciu, D.: Declarative Specification of Web Sites with Strudel. In VLDB

Journal, 9 (1), 38-55, 2000. 22. Fons, J., Pelechano, V., Albert, M. and Pastor, Ó. Development of Web Applications from Web Enhanced Conceptual

Schemas. In Song, I., Liddle, S.W., Wang Ling, T., Scheuermann, P., editors, Proceedings of the 22nd International Conference on Conceptual Modeling (ER 2003), Chicago, Illinois, October 2003, Lecture Notes in Computer Science, 2813, 232–245, 2003.

23. Fraternali, P., Tisi, M., Bangio, A.: Automating function point analysis with model driven development. In Proceedings of the 2006 conference of the Center for Advanced Studies on Collaborative research (CASCON '06), Toronto, Canada, 2006.

24. Gannod, G. C., Timm, J. T. E., Brodie, R. J.: Facilitating the Specification of Semantic Web Services using Model-Driven Development. In International Journal of Web Services Research, 3(3), July-September 2006, 61–81.

25. Garrigós, I., Gómez, J. and Cachero, C., Modelling Dynamic Personalization in Web Applications. In Proceedings of the Web Engineering, International Conference (ICWE 2003), Oviedo, Spain, July 14-18, 2003, 472–475, 2003.

26. Grosof, B., Horrocks, I., Volz, R., Decker, S.: Description Logic Programs: Combining Logic Programs with Description Logics. In Proceedings of the Twelfth International World Wide Web Conference (WWW2003), Budapest, Hungary, 20-24 May 2003, 48–57, 2003.

27. Haller, A. , Cimpian, E., Mocan, A., Oren, E., Bussler, C.: WSMX - A Semantic Service-Oriented Architecture. In Proceedings of the 2005 IEEE International Conference on Web Services (ICWS 2005), 11-15 July 2005, Orlando, FL, USA, 321–328, 2005.

28. Hepp, M., Leymann, F., Domingue, J., Wahler, A., Fensel, D.: Semantic Business Process Management: A Vision Towards Using Semantic Web Services for Business Process Management. In Proceedings of the IEEE International Conference on e-Business Engineering (ICEBE 2005), October 18-20, 2005, Beijing, China, 535–540, 2005.

29. Keller, U., Lara, R., Lausen, H., Polleres, A., Fensel, D.: Automatic location of services. In The Semantic Web: Research and Applications, Proceeding of the Second European Semantic Web Conference (ESWC 2005), Heraklion, Crete, Greece, May 29 - June 1, 2005, Lecture Notes in Computer Science, 3532, 1–16, 2005.

30. Keller, U., Lara, R., Lausen, H., Polleres, A., Predoiu, L., Toma, I.: D10 WSMX Discovery. Technical report, 2005. 31. Kerrigan, M.: The WSML Editor Plug-in to the Web Services Modeling Toolkit. In Proceedings of 2nd WSMO

Implementation Workshop (WIW2005), Innsbruck, Austria, 2005. 32. Kifer, M., Lausen, G., Wu, J.: Logical foundations of object-oriented and frame-based languages. In Journal of ACM, 42,

741–843, 1995. 33. Li, L., Horrocks, I.: A software framework for matchmaking based on semantic Web technology. In International Journal

of Electronic Commerce, 8(4), 39–60, 2004. 34. Lima, F., Schwabe, D.: Application Modeling for the Semantic Web. In 1st Latin American Web Congress (LA-WEB

2003), Empowering Our Web, 10-12 November 2003, Santiago, Chile, 93–102. IEEE Computer Society, 2003. 35. Manolescu, I., Brambilla, M., Ceri, S., Comai, S., Fraternali, P.: Model-Driven Design and Deployment of Service-Enabled

Web Applications. In ACM TOIT, 5 (3), 439–479, 2005. 36. Martin, D. L., Paolucci, M., McIlraith, S. A., Burstein, M. H., McDermott, D.V., McGuinness, D. L., Parsia, B., Payne,

T.R., Sabou, M., Solanki, M., Srinivasan, N., Sycara, K. P.: Bringing Semantics to Web Services: The OWL-S Approach. In Cardoso, J., Sheth, A. P., editors, Proceedings of the First International Workshop on Semantic Web Services and Web Process Composition (SWSWPC 2004), San Diego, CA, USA, July 6, 2004, 26–42, 2004.

37. MultimediaN N9C Eculture project, 2006. http://e-culture.multimedian.nl/ 38. OMG: MDA Guide v1.0.1, June 2003. Available at: http://www.omg.org/docs/omg/03-06-01.pdf 39. OMG: Ontology Definition Metamodel, June 2006. Available at: http://www.omg.org/docs/ad/06-05-01.pdf 40. Paolucci, M., Kawamura, T., Payne, T.R., Sycara, K.P.: Semantic matching of Web services capabilities. In The Semantic

Web, Proceedings of the First International Semantic Web Conference (ISWC 2002), Sardinia, Italy, June 9-12, 2002, Lecture Notes in Computer Science, 2342, Springer, 333–347, 2002.

41. Roman, D., Keller, U., Lausen, H., de Bruijn, J., Lara, R., Stollberg, M., Polleres, A., Feier, C., Bussler, C., Fensel, D.: Web Service Modeling Ontology. Applied Ontology, 1(1): 77–106, 2005.

42. Schwabe, D. and Rossi, G. The Object-Oriented Hypermedia Design Model. In Communications of the ACM, 38 (8), 45–46, 1995.

43. Scicluna, J., Polleres, A., Roman, D., Fensel, D.: Ontology-based Choreography and Orchestration of WSMO Services, February 2006. Available at: http://www.wsmo.org/TR/d14/v0.2/


44. Sheth, A. , Verma, K., Miller, J., Rajasekaran, P.: Enhancing Web Service Descriptions using WSDL-S. In Research-Industry Technology Exchange at EclipseCon 2005, Burlingame, CA, Feb. 28 - Mar. 3, 2005.

45. Torres, V., Pelechano, V., Pastor, O.: Building Semantic Web Services Based on a Model Driven Web Engineering Method. In Advances in Conceptual Modeling - Theory and Practice, ER 2006 Workshops, Proceedings, Tucson, AZ, USA, November 6-9, 2006, , Lecture Notes in Computer Science, 4231, 173–182, 2006.

46. Trastour, D., Bartolini, C., Gonzalez-Castillo, J.: A semantic Web approach to service description for matchmaking of services. In Proceedings of The first Semantic Web Working Symposium (SWWS01), Stanford University, California, USA, July 30 - August 1, 2001, 447–461, 2001.

47. Universal description discovery and integration (UDDI), 2001. http://www.uddi.org 48. Vdovjak, R., Frasincar, F., Houben, G. J., Barna, P.: Engineering Semantic Web Information Systems in Hera. J. Web Eng.,

2(1-2):3–26, 2003. 49. Web Models: Webratio, 2007. http://www.webratio.com 50. WfMC: Workflow Process Definition Interface - XML Process Definition Language (XPDL), October 2005. Available at:

http://www.wfmc.org/standards/docs/TC-1025_xpdl_2_2005-10-03.pdf

Documents

Model-Driven Design and Development of Semantic Web Service