How To Write A Paper On The Semantics Of A Web Service

29  Download (0)

Full text

(1)

of Semantic Web Service Applications

MARCO BRAMBILLA, STEFANO CERI, FEDERICO MICHELE FACCA Politecnico di Milano

and

IRENE CELINO, DARIO CERIZZA and EMANUELE DELLA VALLE CEFRIEL

This paper proposes a model-driven methodology to design and develop semantic Web service applications and their components, described according to the emerging WSMO standard. In particular, we show that business processes 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 partially hiding the complexity of dealing with seman-tics. Our method is based on existing models for the specification of business processes (BPMN) combined with Web engineering models for designing and developing semantically rich Web ap-plications (WebML). The proposed approach leads from an abstract view of the business needs to a concrete implementation of the application, by means of several design steps; high level models are transformed into software components. Our framework increases the efficiency of the whole design process, yielding to the construction of semantic Web service applications spanning over several enterprises.

Categories and Subject Descriptors: D.2.2 [Software Engineering]: Design Tools and Tech-niques—Computer-aided software engineering (CASE); D.2.10 [Software Engineering]: De-sign—Methodologies, representation; H.3.5 [Information Storage and Retrieval]: Online In-formation Services—Web-based services

General Terms: Design, Languages

Additional Key Words and Phrases: Semantic Web Service, WebML, WSMO

1. INTRODUCTION

Web services have been devised as the architectural solution to modularize en-terprise software. One of the promises of Service Oriented Architecture (SOA) is the ease of integration of different, loosely coupled services across Internet and Intranets. Still, the discovery and the integration of a new service in an existing infrastructure is not automatic and requires a lot of human efforts. As a possible solution to this issue, many researches endorsed Berners-Lee [2001] vision: the

“Se-Authors’ address: Marco Brambilla, Stefano Ceri, Federico M. Facca, Dipartimento di Elettronica e Informazione, Politecnico di Milano, P.zza L. da Vinci 32, 20133 Milano, Italy; Irene Celino, Dario Cerizza, Emanuele Della Valle, CEFRIEL, via Fucini 2, 20133 Milano, Italy. Contact Author email: Federico.Facca@polimi.it.

Permission to make digital/hard copy of all or part of this material without fee for personal or classroom use provided that the copies are not made or distributed for profit or commercial advantage, the ACM copyright/server notice, the title of the publication, and its date appear, and notice is given that copying is by permission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists requires prior specific permission and/or a fee.

c

(2)

mantic Web”, a Web designed not only for human use, but for automatic interaction between machines thanks to the formal description (i.e., by means of ontologies) of its resources (e.g., Web services). Several proposals for semantic Web services were submitted to W3C (i.e., OWL-S [Martin et al. 2005], WSMO [Fensel et al. 2006], and WSDL-S [Akkiraju et al. 2005]); one of their most challenging promise 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.

Dwelling into the deep aspects of semantic Web services (e.g. for building a semantic execution environment such as WSMX [Haller et al. 2005]) is outside of the scope of this paper; instead we focus on the design and re-engineering of software components so as to meet semantic Web services requirements; we show that advanced software engineering methods enable the development of software interfaces which are compliant with semantic frameworks. Our method overcomes one of the most critical obstacles to the spreading of semantic Web services, i.e., the difficulty of describing current Web applications with semantic technologies. Our work shows that there is no contrast – but actually good continuity – between modern model-driven software design methods and semantic Web service concepts; in particular, the current state of the art of model-driven software design offers rich model descriptions to support semantic Web service abstractions.

Current methodologies [Jaeger et al. 2005; Patil et al. 2004] and tools [Elenius et al. 2005; Kerrigan 2005] to create semantic Web services keep the development of semantic descriptions separate from the actual development of the underlying services. In our opinion, the creation of semantic annotations should occur dur-ing the development of the services; this process should be supported by proper methodologies which should combine the best practices in service development and semantics specification.

In this paper we use WSMO as semantic service modeling framework, 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 prin-ciples of strong decoupling and mediation. We exploit modern Web engineering methods, including visual declarative modeling (based on the WebML conceptual model), automatic code generation, and semi-automatic elicitation of semantic de-scriptions for the WSMO components from the design of the application.

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: we adopt BPMN (Business Process Management Notation) to build process models, involving several actors possibly from different enterprises.

—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 [de Bruijn et al. 2006]) to model the local ontology of the application and to import existing ontologies (possibly modelled through tools such as WSMT [Kerrigan 2005]); we expose the resulting set of ontologies to the underlying WSMX execution environment. —Design of Web service interfaces, of integration platform, and of application front

(3)

end: we use visual diagrams representing Web sites and services according to the WebML models [Ceri et al. 2002], including specific hypertext primitives for Web service invocation and publishing [Manolescu et al. 2005] and explicit representation of workflow concepts [Brambilla et al. 2006c].

Global choreography1, goals, descriptions of Web services (both in terms of

ca-pabilities and of their choreography interface), and descriptions of mediators are derived from business process models and WebML models, whereas the implemen-tation of the application front-end and of the services is automatically generated from the high-level models.

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 semi-automatic description generators, helped by designer’s annotations, guarantees the benefits of semantic Web services at low extra-cost, thus positioning their cross-enterprise applications within an infrastructure that allows for flexible and dynamic reconfiguration.

The paper is structured as follows: Section 2 overviews the background of the research; Section 3 presents the running example that will be discussed throughout the paper; Section 4 describes the development process and addresses its main devel-opment steps, including definition, importing, and query primitives for ontologies; Section 5 presents the proposed approach for the elicitation of semantic description of the application; Section 6 briefly outlines our implementation experience; Section 7 gives an evaluation of the advantages and limitations of our approach; Section 8 reports the related work; and finally Section 9 presents our conclusions.

2. BACKGROUND

Our approach relies on selected models, methods, and tools from the fields of busi-ness processes, Web engineering, and semantic Web services. In the sequel, we describe the models that will be used throughout the paper, and present simple examples of their use.

2.1 Modeling business processes

Among the existing notation for workflow modeling, we use the Business Process Management Notation [OMG 2006a], because of its spreading adoption, intuitive-ness, and effectiveness to represents real IT processes. BPMN splits processes into activities which are connected by control flows; activities are placed into lanes rep-resenting a given role played by the process users. The control flow uses branching points and synchronization points, with associated semantics (conjunctive, disjunc-tive, exclusive). When the control flows from one lane to another, communication can take place through shared data or messages.

Figure 1 shows a very simple BPMN model representing the interaction between a buyer (top lane) and a seller (bottom lane). The process starts when the buyer

asks for a quote (first activity in the diagram). The request is sent to the seller

1The 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).

(4)

Ask for

a quote Receive quote

Bu ye r Se lle r Send quote Evaluate

Customer Calculate quote Drop request Receive

request

Receive rejection

Fig. 1: A BPMN model representing the workflow between a buyer and a seller.

through amessage link. An Ack message is immediately sent back, and then the

seller performs some internal activities, connected bycontrol flow links, and takes

some decisions, i.e., whether to provide the quote or not. The diamond represents a gateway, i.e., a branching point. Gateways are flow control elements that allow decisions, splitting, merging and synchronizations. Finally, a message is sent back to the buyer that closes the process.

2.2 Model-driven Web application design

The specification of a Web application [Ceri et al. 2002] according to WebML

consists of three models: thedata model, an extended entity-relationship model; one

or more hypertext models, expressing the application logics; and the presentation

model, describing the visual aspects of the pages.

A WebML hypertext model consists of several site views, each one dedicated to given groups of users. Site views typically include pages, which in turn include units and are connected by links; site views may be substructured into areas which represent a set of logically interrelated pages. A page encloses content units, repre-senting atomic pieces of information to be published, such as indexes listing items from which the user may select a particular object, units presenting the details of a single object or of a set of objects, input forms, and so on. Content units may have a selector, which is a predicate identifying the entity instances to be extracted from the underlying database. Pages and units can be connected through links of different types to express all possible logical navigations; links carry with them pa-rameters. Besides content publishing, WebML allows specifying operations, placed along links, for performing business actions, such as content management, sending e-mails, logging users into applications, and so on; since they do not display data, operations are placed outside of pages.

Originally, WebML was focusing on data-intensive Web applications, i.e. appli-cations dedicated to presenting contents on the Web; then, the model has evolved [Manolescu et al. 2005] to embrace the larger class of service-oriented Web ap-plications, where WebML is used to express application logics that can be split

over different services. The service model of WebML supports the invocation and

publishing of Web services, as well as the grounding of Web services to the XML message format, and data-mediation capabilities. We next show the WebML rep-resentation of a simple hypertext including a Web service invocation and of the corresponding Web service publication.

(5)

(a)

(b)

Fig. 2: Example of WebML hypertext model with invocation of remote service.

management. A user enters proper search criteria into the Search Product entry

unit, placed in the Search Product page. From the information provided in the

entry unit, a request message is composed and sent to theRemoteSearchoperation

of a Web service, a request response unit, that models services invocation. The response message contains a list of products satisfying the search criteria; they are

displayed by aProducts index unit, placed in theProducts page; the user chooses

one of the displayed products and looks at its details.

Figure 2b represents the model of the Product Management port of the Web

service invoked by the previously described hypertext. The hypertext starts with theSearch Solicit unit, which denotes the reception of the message and thus rep-resents the publishing of a Web service, which is exposed and can be invoked by third party applications. Upon the arrival of the message, an XML-out operation extracts from the local data source the list of desired products and formats the

re-sulting XML document. TheSearchResponse unit produces the response message

for the invoker. Of course, units have associated parameters which allow designer to define the details of each operation.

More recently, WebML has been extended with primitives for implementing busi-ness processes [Brambilla et al. 2006c], 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

ad-vancement ofcases (i.e., instances of processes) andactivities. Thehypertext model

is extended by specifying activity boundaries (represented by areas tagged with a marker ‘A’) and process-dependent navigation links that traverse the boundaries of activity areas and are associated with workflow logic (every link entering an activity

starts the execution of the activity, every outgoing link ends the activity). If and

switchunits can be used to express navigation conditions. Distributed processescan be obtained by combining the workflow primitives with Web services primitives.

(6)

2.3 Semantic Web services

WSMO [Fensel et al. 2006] is a comprehensive semantic Web services framework which includes the WSMO conceptual model, the WSML language [de Bruijn et al. 2006], the WSMX execution environment [Haller et al. 2005], and the WSMT mod-eling tool [Kerrigan 2005]. WSMO relies on the Web service Modmod-eling Framework (WSMF) [Fensel and Bussler 2002], comprising four main elements:

—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. Ontologies are composed of

concepts,relations, axioms,instances, and other elements.

—Web services model the functional and behavioral aspects, which must be se-mantically 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 from three different points of view: non-functional properties, functionality, and behavior. The functionalities are

described ascapabilities(e.g., booking of airplane tickets) which include:

precon-ditions (i.e., the required state of the information space before the Web service

execution),assumptions (i.e., the state of the world which is assumed before the

execution),postconditions (i.e., the state of the information space reached after

the successful execution), and effects (i.e., the state of the world reached after

the successful execution). Theinterface of a Web service describes the behavior

of the Web service from two perspectives: communication (i.e., choreography)

and collaboration (i.e.,orchestration).

—Goals specify objectives that a client might have when consulting a Web service (e.g., find a low cost flight from Milan to Munich). In WSMO, a goal is charac-terized in a dual way with respect to Web services: goal descriptions include the

requested capability and therequested interface.

—Mediators provide interoperability facilities among the other elements to support efficiently goal driven Web service interaction. They describe elements that aim to overcome structural, semantic or conceptual mismatches that appear between

the different components. There are four types of mediator: ooMediators

im-port (parts of) ontologies and resolve heterogeneities;wwMediators connect two

different Web services, resolving any data, process and protocol heterogeneity;

ggMediators connect different goals, enabling goals to refine more general goals

and thus enabling reuse of goal definitions; and finallywgMediators 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 expressive-ness and tractability according to different knowledge representation paradigms. The most basic, and least expressive, variant is WSML-Core, which is based on DLP [Grosof et al. 2003] 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, the flavour adopted in this paper, is an extension of WSML-Core based on a logic programming variant of F-Logic [Kifer et al. 1995] and

(7)

is equivalent to Datalog with inequality and (locally) stratified negation. Examples of WSML-Flight are provided in the running example throughout the paper.

2.3.1 Web service discovery. Service discovery is a task manually accomplished

in many business scenarios (e.g., finding a shipment service). Web services certainly reduced the effort required in invoking a remote service, but their discovery (i.e., using UDDI [OASIS 2004]) always involves a human in the loop. Ontologies can play a key role in automating Web service discovery [Li and Horrocks 2004; Paolucci et al. 2002; Trastour et al. 2001].

In this work we adopt Glue [Della Valle and Cerizza 2005b], a WSMO-compliant Web service discovery engine, 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, the Glue approach intro-duces 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: ggMe-diators, for automatically generating a set of goals semantically equivalent to the requests, and wgMediators as the conceptual element responsible for evaluating the matching. The resulting discovery is a composite procedure where the discovery of the appropriate mediators and 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 [DERI Stanford 2006], 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. The architecture, as displayed by Figure 3, 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 [RosettaNet 2007], 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 usualRosettaNet 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, a data mediation and a relevant process mediation are required between the two totally different purchase

processes of RosettaNet and Moon legacy system. TheRosettaNet Purchase Order

Interfaceoffers 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 through theShipment Organize Interface. This interface relies on

(8)

Legacy CRM System

Legacy OM System

Legacy System to Rosetta PO Interface Mediator Rosetta PO Interface to Legacy System Mediator

Customer Order Management Interface Rosetta Purchase Order Interface Organize Shipment Interface Receive PO Obtain moons internal customer id Create order using internal customer id

Send line item n

Close order confirmLineItem operation Send POC searchCostumer operation createNewOrder operation addLineItem operation closeOrder operation Confirm/Refuse Line Item SearchString CustomerObject CustomerId OrderId LineObject LineConfirmation OrderId ConfimationObject PIP3A4 PO AckOfReceipt AckOfReceipt PIP3A4 POC Customer Shipment WS searchShipOffer operation confirmShipOffer operation ShipmentObject ShipmentOffer ShipmentOfferId Confirmation BLUE MOON Discovery Eng. achieveGoal operation Goal GoalCompliantWS Send Goal WS Offer Invoker WS Purchase Invoker Shipment Web Services

Fig. 3: The B2B scenario derived from the Semantic Web Service Challenge 2006.

internal orchestration of the Web service relies on a WSMO 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 Blue 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.2 toward the design of semantic Web services and Web applications.

(9)

MODEL DRIVEN DESIGN Business Requirements PROCESS DESIGN REQUIREMENTS SPECIFICATION DATA DESIGN HYPERTEXT DESIGN

TESTING & EVALUATION

ARCHITECTURE DESIGN IMPLEMENTATION

MAINTENANCE & EVOLUTION SEMANTIC DESCRIPTION

Existing Ontologies Existing Services and Goals

Fig. 4: Phases in the development process of semantic Web applications.

4.1 Development process

The phases of the development process of a semantic Web application are shown in Figure 4. In line with the classic Boehm’s Spiral model and with modern meth-ods 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 un-derlying the application. Process 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 ob-jects identified during requirements specification into a comprehensive and coherent

domain model, that may comprise importing of existing ontologies. Hypertext

de-sign is the activity that transforms the functional requirements into one or more

Web services and Web site views embodying the needed retrieval and manipula-tion 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 requesters, 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 4 are outside our scope (see [Ceri et al. 2002] for additional details).

4.2 Design of the business process

The business process design task, focusing on the high-level schematization of the processes underlying the application, results in one or more business process dia-grams, representing the tasks to be executed at abstract level. The designer can annotate the model by selecting the kind of expected implementation of each task,

(10)

Send PO Receive POC RosettaNet System (BLUE) Med iat or Close Order Legacy System (MOON) Close Order Send POC Obtain Customer ID Search

Customer Add Line

Send Lines Create new Order Create Order Confirm Lines Confirm Line Receive PO (a) C u stomer Shipment Service

Invoke Offer Services

Discover y Engine AchieveGoal Shipment WS Invoke Purchase Service Generate Shipment Offer Send Goal Send

Shipment Request Choose Best Offer

RosettaNet System

(BLUE) Receive

Confirmation

Aggregate and Send Offers

Evaluate Request

Send Confirmation Receive

Shipment Request Receive Chosen Offer

(b)

Fig. 5: Workflow representing the interaction of the running example (BPMN notation).

by mapping some of them to services. In particular, with respect to service invo-cation, it is possible to specify whether the service has to be modeled and

imple-mented within the system (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 BPMN diagram of the running case is represented in Figure 5: for sake of clarity, the process is split into two sub-processes that shall be executed sequen-tially in the full scenario: part (a) describes the purchase and part (b) describes

the shipment management. We assume that the Moon services are external, the

mediator services areinternal, and the shipment services aresemantic. In the

fol-lowing, 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 workflow semantics (once iteration conditions and con-ditional branches are fully specified), while the representation of Figure 3 does not. Building a BPMN (or equivalent) representation of the business process is a first step of the model driven design of any complex software system.

(11)

Table I: Expressive power comparison between ontology languages.

OWL Abstract Syntax DL syntax WSML-F WebML E-R and OQL Axioms Class(ApartialC1. . . Cn) A⊆Ci + + (Ci6=⊥;A6=⊥) Class(AcompleteC1. . . Cn) A≡C1∩. . .∩Cn + + (A, Ci6=⊥;T) EnumeratedClass(Ao1. . . on) A≡ {o1, . . . , on} − − SubClassOf(C1C2) C1⊆C2 + + EquivalentClasses(C1. . . Cn) C1≡. . .≡Cn + − DisjointClasses(C1. . . Cn) Ci∩Cj⊆ ⊥ + −

ObjectProperty(Rsuper(R1) . . . super(Rn) R⊆R1 + + domain(C1) . . . domain(Cn) T⊆ ∀R−.Ci + + (Ci6=⊥)

range(C1) . . . range(Cn) T⊆ ∀R.Ci + + (Ci6=⊥)

[inverseOf(R0)] R≡R−0 + +

[Symmetric] R≡R− + ∼ (R and R− with

same name) [Functional] T⊆≤1R + − [InverseFunctional] T⊆≤1R− + − [Transitive]) Trans(R) + − SubPropertyOf(R1. . . R2) R1⊆R2 + + (domain(Ri), range(Ri)6=T) EquivalentProperty(R1. . . Rn) R1≡. . .≡Rn + + (domain(Ri), range(Ri)6=T)

Individual(otype(C1) . . . type(Cn) o∈Ci + +

value(R1o1) . . . value(Rnon)) < o, oi>∈Ri + + SameIndividual(o1. . . on) o1≡. . .≡on − − DifferentIndividuals(o1. . . on) oi6=oj, i6=j −* −* Descriptions (C) A(URI Reference) A + + owl:Thing T − − owl:Nothing ⊥ − − intersectionOf(C1. . . Cn) C1∩. . .∩Cn + rhs** unionOf(C1. . . Cn) C1∪. . .∪Cn lhs*** rhs** complementOf(C0) ¬C0 − − oneOf(o1. . . on) {o1. . . on} lhs*** − restriction(RsomeValuesFrom(C)) ∃R, D lhs*** rhs** restriction(RallValuesFrom(C)) ∀R, D rhs** rhs** restriction(Rvalue(o)) ∃R, o + rhs** restriction(RminCardinality(1)) ≥1R − rhs** restriction(RminCardinality(n)) (n >1) ≥nR − rhs** restriction(RmaxCardinality(n)) ≤nR rhs** rhs** + The language fully support the related concept.

−The language does not support the related concept.

* Notice that already all individuals in an WSML Flight knowledge base and WebML repository are different; therefore, an explicit assertion would be superfluous.

** May only be used in partial class definitions and on the right-hand side (as the second argument) of SubClassOf.

*** May only be used on the left-hand side (as the first argument) of SubClassOf.

4.3 Design of the data model and extraction of the ontologies

The definition of the ontologies involved in the application is addressed by four distinct steps, each addressing different aspects of the application:

(1) First, existing remote ontologies, possibly provided by third parties, can be imported. This step is not always needed, as many applications can be served by an ontology which is based upon autonomously defined information. This step requires the manual selection of concepts to be imported from remote sources.

(2) Then, the data model is considered as a piece of ontology. An appropriate transformation of the WebML data model translates the extended E-R internal representation of the data into a WSMO-compliant ontology, which is then registered on the WSMX resource manager [Haller et al. 2005].

(12)

(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 can be annotated with concepts imported from existing ontologies during step 1. This step can be partially automatized.

This approach is oriented towards Tim Berners-Lee vision for Web applications connected by concept annotations [2003], since it provides a framework for im-porting existing ontologies and defining new ones, thus sharing knowledge among different applications on the Web.

The similarity between our extended E-R and WSML-Flight is enough to enable a partial extraction of WSMO ontologies. The expressive power of the WebML E-R model can be compared to the WSML-Flight language. Table I shows the com-parison of the expressive power of WebML with respect to OWL-DL and WSML-Flight, extending the comparison that was presented in [de Bruijn et al. 2005]. Similar to WSML-Flight, the WebML data model comprises a rule language called WebML-OQL, suitable for calculating derived information, but not for defining

con-straints. Moreover, as WSML Flight, WebML does not have eitherThing or

Noth-ing concepts, but, differently from WSML Flight, it cannot deal with equality

re-lated constructors (i.e.,EquivalentClasses,SameIndividual,DisjointClasses,

DifferentIndividuals, andFunctional/InverseFunctionalproperties). Figure 6 shows the E-R diagram used by the Shipment Web service to describe goals and to invoke the external shipment services. The E-R has three main domain

entities: Shipment, describing each shipping;ShipmentService, describing Blue

ship-ment partners; and Location, describing the geographical entities involved in the

shipment process. EachShipment is related to aShipmentServiceand to an origin

and destination Location. Each ShipmentService is connected to severalLocation

entities representing shipment locations and pick up points. Both theLocationand

the ShipmentService entities have some sub entities in order to easily specialize their characteristics. The model is complemented with OQL expressions defining data derivations.

The E-R diagram includes also a very simple model for describing the status

of the process (see Section 4.2): entity Case tracks the execution of the process

instances and entityActivity registers all the activity instances performed within

everyCase. Notice that more complex models could be adopted, for registering the

user performing the activities and other information.

The process of ontology generation starts by importing external ontologies used in the WebML E-R model to enrich WebML definitions of data types. Then, for each entity in the E-R, a correspondent WSML concept is generated with its direct super concept, attributes (also E-R relationships are mapped to attributes) and possible axioms. Axioms are derived from WebML OQL expressions defined on the data. An E-R model can be easily converted to a WSML-Flight ontology which

preserves all its constraints. For instance, theEuropeanShipmentService entity is

(13)

Fig. 6: A portion of the WebML E-R diagram used by the Shipment Web service.

subentity is described in the WebML-OQL syntax as:

InternationalShipmentService(as SuperEntity)where

InternationalShipmentService.hasLocationisaEurope.

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

conceptShipmentService hasNameofType string

hasLocationofType(0∗) Location ...

conceptEuropeanShipmentServicesubConceptOf

InternationalShipmentService

nfpdc#relation hasValue{EuShipmentServiceDef}endnfp axiomEuShipmentServiceDef

definedBy

?xmemberOfInternationlShipmentService

andhasLocation(?x,?nation)and?nationmemberOfEurope

implies?xmemberOfEuropeanShipmentService.

4.4 Querying ontologies

While a large part of the design of semantic Web applications can be performed by means of existing design tools and primitives, some additional elements might be needed for addressing complex queries and reasoning over ontologies; hence we enhanced WebML by modifying existing primitives and by introducing new ones dedicated to content extraction from ontologies. The aim of the new primitives

(14)

Table II: The new WebML units for advanced queries on ontologies.

Name Symbol Input Output

subClassOf

[ClassName1=?] [ClassName2=?]

SubclassOf c1, c2 trueifc1 is subclass of the classc2 c1,? the list of superclasses of the classc1 ?, c2 the list of subclasses of the classc2

instanceOf

[ClassName=?] [Instance=?]

InstanceOf i, c trueifiis an instance of the classc

i,? the list of classes to which the instanceibelongs ?, c the list of instances of the classc

hasProperty

[ClassName=?] [Property=?]

HasProperty c, p trueif the classchas the propertyp

c,? the list of properties of the classc ?, p the list of classes having the propertyp

hasPropertyValue

[Property=?] [Value=?]

Has

PropertyValue p, v the list of URIs where propertyphas valuev

p,? the list of possible values for the propertyp ?, v the list of properties with valuev

subPropertyOf

[Property1=?] [Property2=?]

Subproperty p1, p2 trueif the propertyp1is subproperty ofp2 p1,? the list of superproperties of the propertyp1 ?, p2 the list of subproperties of the propertyp2

for querying ontological data is not to replace the original ones: even if part of the information underlying the system is represented by ontological knowledge, for substantial sections of Web applications, conventional (e.g., relational) representa-tion 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. To this purpose, we exploit the main asset of WebML, i.e., its ability of effectively capturing the parameters passed on the links between the different components (units) of the Web application. Parameters become the ac-tual contact point between semantic and conventional data, since objects extracted from ontological sources are mapped to internal parameters of the Web application and to conventional data; the mapping uses powerful defaults to limit the amount of designer-defined specifications.

4.4.1 Basic primitives for queries on ontologies. Basic WebML units that are

used for accessing relational data are also suitable to navigate ontology instances. They only need to be extended to support some additional query options to support the new expressive power of the ontologies. For instance, the Index unit can be extended: (1) to show either not only the direct instances, but also the inferred instances of a specific concept, and (2) to show the direct or the inferred subconcepts

(15)

Fig. 7: Hypertext examples that exploit the new ontological units.

of the specified concept. The same extensions apply to other WebML units. In particular, the Hierarchical Index unit perfectly fits as a publishing primitive for portions of ontologies. For instance, given a concept, it can extract the hierarchical tree of all 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 ex-ploit the rich set of possible queries over semantic instances and classes. Therefore, we introduce a new set of 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 II summa-rizes the syntax and the informal behavior 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

Identi-fier) mechanism, while the original WebML units only rely on OID identification mechanisms.

Besides the units for ontological data query, we introduce the Describe unit,

which returns the RDF description of an uri, thus enabling automatic Web page

annotation and data exporting.

Advanced querying units can be used to express reasoning tasks over ontological data. The example in Figure 7 shows the search for products similar to a certain

product; the search starts with the HasPropertyValue unit for extracting a set of

URIs of instances (belonging to any class) having the value of the po:similarTo

property equal to the submitted value. The set of URIs is then passed to the

InstanceOf unit that checks whether they are instances of the class Product. In such case, the URIs are passed through the link to an Index unit showing the list of extracted Products.

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 pro-cess, 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 an XML serialization. Transformations are performed by means of

(16)

Fig. 8: The Blue Shipment Web service.

produce 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) populated with a default unit (i.e.,Solicitunits for the BPMN activities that

receive messages from external lanes, Response units for the ones that send back

messages, Request-Responseunits for the ones that call remote Web services and

genericOperation 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 data model is enriched with Case and Activity concepts (cfr. Section 4.3) that are populated, during the life of the application, according to the enactment of the BPMN model (a case instance is created at the start of a new process and an activity instance is created at the start of a new activity).

Our BPMN tool allows to represent only valid diagrams so that the translation to WebML is always guaranteed. 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, that concretely means designing the hypertext describing navigations and business actions performed within the 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. For instance, if an activity must perform a standard Web service invocation, it can be translated into a chain of operations consisting of: (a) transforming application data into suitable format for the subsequent Web service call (lowering); (b) invoking the remote service with the specified parameters; (c) transforming the response data into suitable internal format (lifting); and (d) stor-ing internal application data. In any case, the designer is in charge of refinstor-ing and detailing the specification of the hypertext models.

(17)

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

service. The hypertext skeleton has been automatically generated from the BPMN specification of Figure 5 and then has been manually refined by the designer. It

implements the Customer Shipment Service lane of the BPMN diagram. In the

upper part of Figure 8, thesearchShipmentSolicit unit implements the first activity

of the lane, waiting for an incoming message. TheShipmentRequest is received

bysearchShipmentSolicit and is passed to theSend Goal activity. TheGoal Com-position unit fills a goal template with the required instances, obtaining a goal description for the WSMX compliant discovery engine; the generated goal

descrip-tion is passed to theSend Goal which sends the goal to a Web service exposed by

the discovery engine. The discovery engine returns a set of Web services compatible with the 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, the Invoke Offer Services activity is

re-peated for each valid Web service returned. The activity consists of a request for a

shipment offer, made by the WS Offer Invoker. The proper XSLT stylesheets for

theLowering and Lifting are selected according to the results of discovery engine.

Each offer returned by a shipment Web service is stored by Add Offer. Finally,

Aggregate and Send Offers activity prepares the results of the Shipment Request (Extract Valid Offersunit), converts them to the Blue data model (Lowering unit)

and returns them to the service requester (ShipmentOfferResponse unit).

Once the service requester selects one of the offers, theReceive Chosen Offer

ac-tivity is triggered (lower part in the Figure 8). TheconfirmShipOfferSolicitreceives

the message and the previously stored offer is retrieved within theInvoke Purchase

Service activity (Extract Confirmed Offer unit). Then the purchase message is

composed by Lowering with the appropriate XSTL stylesheet and WS Purchase

Invoker sends the message to the discovered shipment Web service. Finally Ship-mentConfirmationResponse sends a confirmation message to the requester about the result of the shipment Web service.

Figure 9 shows a WebML hypertext model representing a fragment of the Blue

Web application: a home page calledSelect Order to Shipallows the user to choose

an Order (with Status “Not shipped”) from the Order List index unit. When an order is chosen, the ‘S’-link starts the Organize Shipment activity, showing theOrder Details data unit in theOrganize Shipment page, together with a form (Search Shipment Offers). The data submission triggers the invocation of a remote

(18)

Fig. 10: Overall picture of the extraction of semantic description of Web services.

service (searchShipmentOffers request-response unit), whose results are lifted by

the storeShipmentOffer XML-in unit. The activity is completed (‘C’-link) 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 theconfirmShipmentOffer 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 is not concerned with many implementation details. Indeed, they are left to the design tool, capable of deploying the code for arbitrary choices of data source and server-side architecture.

5. EXTRACTION OF THE WSMO DESCRIPTION OF THE WEB SERVICES

In this section we show that some substantial pieces of WSMO-compliant descrip-tion of Web services can be semi-automatically derived from the design specificadescrip-tion. 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.2. The various steps produce some intermediate artifacts (BPMN models, WebML skeletons, data models, hypertext models), pos-sibly enriched by imported ontological descriptions (on top of Figure 10) and are exploited 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 (Section 5.1); the choreography information is derived from BP model (Section 5.2); 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 BPMNdata and message flows 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 WSMLpre-conditionsandpost-conditions. More details

(19)

capability

sharedVariables(?Req) precondition

definedBy

(?Req memberOf ShipmentRequest)or (?Req memberOf ConfirmShipOfferRequest). postcondition

definedBy (?Req[

pickupdate hasValue?pkd, deliverydate hasValue?dd, start hasValue?s, destination hasValue?dest, weight hasValue?w, maxCost hasValue?maxc ]memberOf ShipmentRequest)

implies exists?Res (

?Res memberOf ShipOfferContainer and forall?offer (

?Res [offers hasValue?offer] implies(

?offer [

offerID hasValue ?OID, pickupdate hasValue?pkd, deliverydate hasValue?dd, start hasValue?s, destination hasValue?dest, weight hasValue?w, cost hasValue?c] memberOf ShipmentOffer and ?c<=?maxc

)))) and

(?Req[ offerID hasValue?OID]memberOfConfirmShipOfferRequest) implies

exists ?Confirmation ( ?Confirmation[

offerID hasValue?OID, confirmationID hasValue?CID ] memberOf ShipmentConfirmation

)) <SERVICEVIEW id="wsv3" name="ShipmentWS" secure="no">

<PORT id="port3" name="searchShipOffer" secure="no"> <OPERATIONUNITS>

<SOLICITUNIT id="slu6" name="searchShipmentSolicit" nsURI="blue">

...

<SOLICITPARAMETER id="slp3" name="ShipmentRequest" type="ShipmentObject [element]" xmlSchema="shipment.xsd"/> </SOLICITUNIT>

<SOLICITUNIT id="slu7" name="ConfirmShipOfferSolicit" nsURI="blue">

...

<SOLICITPARAMETER id="slp4" name="ConfirmShipOfferRequest" type="ShipmentOfferConfirmation [element]"

xmlSchema="shipment.xsd"/> </SOLICITUNIT>

...

<RESPONSEUNIT id="rsu6" name="ShipmentOfferResponse" nsURI="blue">

<RESPONSEPARAMETER id="rsp5" name="ShipOfferContainer" type="ShipmentOffers [element]" xmlSchema="shipment.xsd"/> </RESPONSEUNIT>

<RESPONSEUNIT id="rsu8" name="ShipmentConfirmationResponse" nsURI="blue">

<RESPONSEPARAMETER id="rsp6" name="ShipmentConfirmation" type="ShipmentConfirmation [element]" xmlSchema="shipment.xsd"/> </RESPONSEUNIT> </OPERATIONUNITS> </PORT> </SERVICEVIEW>

The WebML XML description of the Blue Shipment Web Service The automatically generated WSML description

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

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 the mapping of message elements to the domain model and hence to the extracted

ontologies (see Section 4.3). 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 shows a portion of the WebML XML serialization for the Blue Shipment Web service, introduced in Section 4.5 and the correspondence with the automati-cally generated WSML description of its capabilities. In particular, Figure 11 illus-trates how parameters of the Solicit Unit in WebML (SolicitParameter) correspond 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 message (shipment.xsd) while the WSML description contains informa-tion about the structure of the exchanged messages (surrounded by a light box): both these parts are obtained from the data model introduced in Section 4.3.

Notice that only pre- and post-conditions already defined in the data and in the service model and can be semi-automatically derived. The same applies to effects. Assumptions and other capabilities not explicitly present in the model have to be added manually (e.g., because they are hidden in the implementation of Web service invoked by the modeled Web application).

5.2 Extraction of the service choreography and orchestration

The service choreography is a piece of information that typically requires some an-notation 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 ex-tracted from the BPMN model, by analysing the order of invocation of the different

(20)

operations of the service. Obviously, this does not guarantee that all the possible scenarios are considered, since only one enactment can be analysed. The extrac-tion of this kind of informaextrac-tion 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 Web service choreography interface automatically generated.

interface choreography stateSignature in ShipmentRequestwithGrounding[...] ConfirmShipOfferRequestwithGrounding[...] out ShipOfferContainerwithGrounding[...] ShipmentConfirmationwithGrounding[...] controlledoasm#ControlState transitionRules

forall{?x, ?state}with (

?state[oasm#valuehasValueoasm#InitialState]

memberOfoasm#ControlStateand

?xmemberOfShipmentRequest ) do

add(?state[oasm#valuehasValueShipmentOfferRequested]) delete(?state[oasm#valuehasValueoasm#InitialState])

add( #memberOfShipmentOfferContainer)

endForall

forall{?x, ?state}with (

?state[oasm#valuehasValueShipmentOfferRequested]and

?xmemberOfConfirmShipOfferRequest) do

add( #memberOfShipmentConfirmation)

endForall

The process that leads to the extraction of the service orchestration is very sim-ilar to the previously introduced process for the extraction of the service choreog-raphy. While the WSMO choreography describes the supposed order of call of the operations 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 is still under develop-ment, but we already know that it will be based on the same ASM model used to describe WSMO choreography interface [Roman et al. 2007]. For example, taking into account the second lane of the BPMN diagram in Figure 5a, that represents the Web service providing the implementation of a Web service to Web service me-diator (wwMeme-diator), we are able to semi-automatically extract the orchestration sequences considering all the control flow links traversing its borders with the below lane, containing the operations of the remote Web service.

(21)

5.3 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 analysing 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 at 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 by creating a shipment instance with a particular status. The following is the WSML description of a goal automatically generated.

capability

sharedVariables?shipment

postcondition definedBy

?shipment [

requestedPickupLocationhasValuestanford, requestedDeliveryLocationhasValuerome,

requestedDeliveryDateTimehasValue date(2006,4,28), goodDimensionhasValue d [

lhasValue10, w hasValue50,

hhasValue100]memberOfdimension, maxAcceptedShipmentPricehasValue50 ]memberOfrequestsShipmentService.

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 always required.

5.4 Design of wwMediators with WebML

One of the main strength points of the approach is the ease of design and imple-mentation of complex wwMediators. If a lane is identified as a wwMediator at the BPMN level, the basic information about the design of the mediation service can be extracted from the high-level BPMN description of the interactions (in particu-lar, information about possible choreography of the service and basic interface and parameter specification). The skeleton model of the mediator is automatically gen-erated by applying a standard translation of each BPMN activity into a predefined chain of operations. Then, the designer need to refine the operation details and parameters to make them work properly. The chain of operations is dual to the

(22)

one generated for Web service call activities. If consists of: (a) receiving a Web ser-vice 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 resulting specification can be used to generate a working mediation service and a WSMO description of the mediator, needed to register it on the WSMX runtime.

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 [DERI Stanford 2006]. The two phases of the challenge allowed us to prove the advantages of a software engi-neering 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 addressed in this paper 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 phase2.

6.1 WebRatio

The WebML methodology is supported by a commercial CASE tool called We-bRatio [WebModels s.r.l. 2007], providing visual design interfaces and automatic code generation. The architecture of the tool enabling semantic Web design is an extension of the WebRatio architecture [Ceri et al. 2003]. At compile time, each application specification is used to generate an XML descriptor for each unit, link, Web page, service call, and service publishing primitive. At runtime the application is instantiated and executed. Clients issue requests to the server, which in turn calls the execution engine. The content required by the user is assembled by the WebML runtime component, using the descriptors and the data sources in the Data Layer.

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 that allows to design BPMN diagrams and to automatically generate the corresponding WebML hypertext mod-els. The workflow schema is stored as an XML document and WebML models are generated using XSLT technology. In addition, the transformation takes into ac-count the annotations that the designer provided on the kind of implementation of

the services (internal,external,semantic). Generation rules for hypertexts and

ser-vices have been built based on the experience and the theory presented in [Brambilla 2006].

(23)

6.3 WSML description generator

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. WSMO specifications presented in Sections 4.3 and 5 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 descriptions directly to the tools.

6.4 GLUE discovery engine

Web service discovery has been addressed by black-box invocation of Glue, a WSMO compliant discovery engine.Following the process described in [Della Valle and Cer-izza 2005a], Glue was configured for the shipment service discovery by:

(1) importing the ontologies generated (see Section 4.3);

(2) importing the classes of shipment Web services and of goals (see Section 5); (3) manually modeling the required wgMediator that encodes the rules for

match-ing a request for shipment (modeled as an instance of shipment goal) against the published instances of shipment Web services.

7. EVALUATION OF THE APPROACH

The proposed approach results efficient and convenient for the developers, in terms of productivity, ease of use, and scalability. This is due to the reduction of the manual intervention of the designer in the development cycle. However, part of the semantic definitions need to be manually coded.

7.1 Productivity evaluation

Productivity advantages of our method are mostly due to the availability of the automatic generation of code and semantic annotations. WebRatio is capable of generating J2EE code of an application starting from WebML specifications and has been largely adopted in several industrial project (e.g., Acer-Europe Web sites). In turns, WebML diagrams are partially automatically generated from high level business process specification. Previous work [Fraternali et al. 2006] also explored how function points analysis can be integrated with WebML application modeling. Extensive experiments show that development of traditional Web applications con-ducted according to the WebML approach and the WebRatio tool allows an average increase of productivity of more than 50%.

Our approach to the deployment of semantic Web applications has been vali-dated on a realistic scenario represented by the SWS challenge case study. In the design and implementation steps of the development, we followed the process pre-sented in Section 2.2. We were able to automatically generate a good percentage of descriptions, nevertheless manual refinements were needed to deploy fully work-ing semantic Web services. Table III reports details on the models, the semantic descriptions, and the running code: for each of them, we indicate the percentage of automatically generated software and semantic descriptions. For models and

(24)

Table III: 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 Generation % 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%

code generation, percentages have been calculated by considering the number of function points that were automatically generated with respect to the total num-ber 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. However, several points still need to involve the manual specification by the designer: this applies particularly to the definition of business constraints and rules, goals, and application-specific be-haviors. Productivity is increased also thanks to the well formalized development process, the adherence to a top-down design process, and the standardization of the application architecture.

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 seman-tic 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 code development and debugging: the en-vironment 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 documen-tation (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 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.

(25)

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 compo-nents.

Runtime scalability is granted thanks to the adherence of the generated run-ning 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 per-formance constraints of the platforms of choice.

8. RELATED WORK

In the last years, the semantic Web became an hot topic and many researchers turned their interests towards it: technology has been pushed, new standards have been envisioned, first real-world applications have been developed (e.g., Multime-diaN N9C Eculture [MultimeMultime-diaN 2007], eMerges [KMI 2007]) and consequently an increasing number of big industries started 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) [Elenius et al. 2005; Kerrigan 2005; Patil et al. 2004], and consider the annotation process as a completely separated process from the actual service devel-opment. These in general require the mastering of the annotation languages (e.g., OWL-S or WSMO) and hence do not help widening the adoption of semantic Web and semantic Web services.

In our previous work [Brambilla et al. 2006] 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.3). The cur-rent paper extends and details the existing preliminary work, by presenting 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 possi-bility 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.

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 alter-native definition of methods or tools, while the integration of both aspects is still very preliminary. For many aspects, our research effort is coherent with the recent activities of the Object Management Group (OMG). The OMG proposed the On-tology Definition Metamodel (ODM) [OMG 2006b] to define a suitable language for modeling semantic Web ontology languages and hence semantic Web applications in the context of the Model Driven Architecture (MDA) [OMG 2003].

(26)

MIDAS is a MDA-based framework for modeling and developing semantic Web

applications [Acu˜na and Marcos 2006]. 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 often a UML model is not simpler than 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 [Gannod et al. 2006] aims at generating OWL-S speci-fications 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 de-sign of the programming logic of the Web service, they are annotated by means of a UML formalism.

Similar to our approach, Torres et al. [2006] 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 [Fons et al. 2003] – as Web engineering method and aims to generate OWL and OWL-S descriptions. In comparison, our approach covers a wider set of aspects related to semantic Web services (e.g., wwMediators, discovery integration, . . . ) thanks to the richness of our models, that allow to cover with fine details the execution semantics of hypertexts and services.

Many current research efforts are converging on the proposal of combining seman-tic Web services and business process management to create one consolidated tech-nology, called Semantic Business Process Management (SBPM) [Hepp et al. 2005]. 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 modelling constructs of semantic Web service frameworks, especially WSMO, are a natural solution to create such a representation. Our work follows this trend.

Finally, many efforts have been directed toward the extensions of existing Web information systems design methods to include aspects of the semantic Web. Tradi-tional design methodologies like OOHDM [Lima and Schwabe 2003] are now focus-ing on designfocus-ing semantic Web applications. New methodologies like Hera [Vdovjak et al. 2003] 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

In this paper we presented an overall approach for designing semantic Web appli-cations by exploiting software engineering techniques. In summary, in this paper we propose a complete method for the semi-automatic extraction of WSMO com-ponents by using existing software engineering abstractions.

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

Figure

Updating...

References