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

Transcription

1 Model-Driven Design and Development 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 semantics. 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 applications (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 Techniques Computer-aided software engineering (CASE); D.2.10 [Software Engineering]: Design Methodologies, representation; H.3.5 [Information Storage and Retrieval]: Online Information 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 enterprise 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, Milano, Italy; Irene Celino, Dario Cerizza, Emanuele Della Valle, CEFRIEL, via Fucini 2, Milano, Italy. Contact Author 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 20YY ACM /20YY/ $5.00 ACM Journal Name, Vol. V, No. N, Month 20YY, Pages 1 29.

2 2 Marco Brambilla et al. 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 during 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 principles 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 descriptions 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 Model-Driven Design and Development of Semantic Web Service Applications 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 choreography 1, goals, descriptions of Web services (both in terms of capabilities and of their choreography interface), and descriptions of mediators are derived from business process models and WebML models, whereas the implementation 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 development 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 business 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, intuitiveness, and effectiveness to represents real IT processes. BPMN splits processes into activities which are connected by control flows; activities are placed into lanes representing a given role played by the process users. The control flow uses branching points and synchronization points, with associated semantics (conjunctive, disjunctive, 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 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).

4 4 Marco Brambilla et al. Buyer Ask for a quote Receive rejection Receive quote Receive request Drop request Seller Evaluate Customer Calculate quote Send quote Fig. 1: A BPMN model representing the workflow between a buyer and a seller. through a message link. An Ack message is immediately sent back, and then the seller performs some internal activities, connected by control 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: the data 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, representing 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 parameters. Besides content publishing, WebML allows specifying operations, placed along links, for performing business actions, such as content management, sending s, 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. applications 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 applications, 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 representation of a simple hypertext including a Web service invocation and of the corresponding Web service publication. The Product Area of Figure 2a is an area of a Web site dedicated to supply

5 Model-Driven Design and Development of Semantic Web Service Applications 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 the RemoteSearch operation 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 a Products index unit, placed in the Products 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 the Search Solicit unit, which denotes the reception of the message and thus represents 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 resulting XML document. The SearchResponse 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 business processes [Brambilla et al. 2006c], thereby supporting collaborative workflowbased applications, spanning multiple individuals, services, and organizations. The data model is extended with the meta-data necessary for tracking the execution advancement of cases (i.e., instances of processes) and activities. The hypertext 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 switch units can be used to express navigation conditions. Distributed processes can be obtained by combining the workflow primitives with Web services primitives.

6 6 Marco Brambilla et al. 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 modeling tool [Kerrigan 2005]. WSMO relies on the Web service Modeling 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 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 from three different points of view: non-functional properties, functionality, and behavior. The functionalities are described as capabilities (e.g., booking of airplane tickets) which include: preconditions (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). The interface 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 characterized in a dual way with respect to Web services: goal descriptions include the requested capability and the requested 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 import (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 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 expressiveness 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 Model-Driven Design and Development of Semantic Web Service Applications 7 is equivalent to Datalog with inequality and (locally) stratified negation. Examples of WSML-Flight are provided in the running example throughout the paper 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 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, 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 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, a data mediation and a relevant process mediation are required 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 through the Shipment Organize Interface. This interface relies on a Web service internally developed by Blue and offered to Blue partners too. The

8 8 Marco Brambilla et al. MOON Rosetta PO Interface to Legacy System Mediator Obtain moons internal customer id SearchString CustomerObject Legacy CRM System searchcostumer operation Legacy OM System Create order using internal customer id CustomerId OrderId createneworder operation BLUE Send line item n LineObject LineConfirmation addlineitem operation Customer Order Management Interface PIP3A4 PO AckOfReceipt Receive PO Close order OrderId closeorder operation Rosetta Purchase Order Interface Legacy System to Rosetta PO Interface Mediator AckOfReceipt PIP3A4 POC Send POC confirmlineitem operation ConfimationObject Confirm/Refuse Line Item Customer Shipment WS Discovery Eng. ShipmentObject ShipmentOffer searchshipoffer operation Send Goal Goal GoalCompliantWS achievegoal operation Organize Shipment Interface ShipmentOfferId Confirmation confirmshipoffer operation WS Offer Invoker WS Purchase Invoker Shipment Web Services Fig. 3: The B2B scenario derived from the Semantic Web Service Challenge 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 WSMOcompliant 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 and Development of Semantic Web Service Applications 9 Business Requirements Existing Ontologies Existing Services and Goals REQUIREMENTS SPECIFICATION PROCESS DESIGN MODEL DRIVEN DESIGN DATA DESIGN HYPERTEXT DESIGN SEMANTIC DESCRIPTION ARCHITECTURE DESIGN TESTING & EVALUATION IMPLEMENTATION Fig. 4: Phases in the development process of semantic Web applications. MAINTENANCE & EVOLUTION 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 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 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 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 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 diagrams, 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 10 Marco Brambilla et al. RosettaNet System (BLUE) Send PO Receive POC Receive PO Mediator Obtain Customer ID Create Order Send Lines Close Order Confirm Line Send POC Legacy System (MOON) Search Customer Create new Order Add Line Close Order Confirm Lines (a) RosettaNet System (BLUE) Send Shipment Request Choose Best Offer Receive Confirmation Customer Shipment Service Receive Shipment Request Send Goal Invoke Offer Services Aggregate and Send Offers Receive Chosen Offer Invoke Purchase Service Send Confirmation Discovery Engine AchieveGoal Shipment WS Generate Shipment Offer Evaluate Request (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 invocation, it is possible to specify whether the service has to be modeled and implemented 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 sequentially 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 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 workflow semantics (once iteration conditions and conditional 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 Model-Driven Design and Development of Semantic Web Service Applications 11 Table I: Expressive power comparison between ontology languages. OWL Abstract Syntax DL syntax WSML-F WebML E-R and OQL Axioms Class(A partial C 1... C n) A C i + + (C i ; A ) Class(A complete C 1... C n) A C 1... C n + + (A, C i ; T ) EnumeratedClass(Ao 1... o n) A {o 1,..., o n} SubClassOf(C 1C 2) C 1 C EquivalentClasses(C 1... C n) C 1... C n + DisjointClasses(C 1... C n) C i C j + ObjectProperty(R super(r 1)... super(r n) R R domain(c 1)... domain(c n) T R.C i + + (C i ) range(c 1)... range(c n) T R. C i + + (C i ) [inverseof(r 0)] R R [Symmetric] R R + (R and R with same name) [Functional] T 1R + [InverseFunctional] T 1R + [Transitive]) Trans(R) + SubPropertyOf(R 1... R 2) R 1 R (domain(r i), range(r i) T ) EquivalentProperty(R 1... R n) R 1... R n + + (domain(r i), range(r i) T ) Individual(o type(c 1)... type(c n) o C i + + value(r 1o 1)... value(r no n)) < o, o i > R i + + SameIndividual(o 1... o n) o 1... o n DifferentIndividuals(o 1... o n) o i o j, i j * * Descriptions (C) A (URI Reference) A + + owl:thing T owl:nothing intersectionof(c 1... C n) C 1... C n + rhs** unionof(c 1... C n) C 1... C n lhs*** rhs** complementof(c 0) C 0 oneof(o 1... o n) {o 1... o n} lhs*** restriction(r somevaluesfrom(c)) R, D lhs*** rhs** restriction(r allvaluesfrom(c)) R, D rhs** rhs** restriction(r value(o)) R, o + 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. * 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 12 Marco Brambilla et al. (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 importing 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 comparison 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 constraints. Moreover, as WSML Flight, WebML does not have either Thing or Nothing concepts, but, differently from WSML Flight, it cannot deal with equality related constructors (i.e., EquivalentClasses, SameIndividual, DisjointClasses, DifferentIndividuals, and Functional/InverseFunctional properties). 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 shipment partners; and Location, describing the geographical entities involved in the shipment process. Each Shipment is related to a ShipmentService and to an origin and destination Location. Each ShipmentService is connected to several Location entities representing shipment locations and pick up points. Both the Location and 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 entity Activity registers all the activity instances performed within every Case. 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, the EuropeanShipmentService entity is a sub entity of the InternationalShipmentService that is located in Europe. This

13 Model-Driven Design and Development of Semantic Web Service Applications 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.hasLocation isa Europe. A fragment of the WSML-Flight translation of the E-R in Figure 6 and its WebML-OQL constraints is: 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 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 14 Marco Brambilla et al. Table II: The new WebML units for advanced queries on ontologies. Name Symbol Input Output SubclassOf c 1, c 2 true if c 1 is subclass of the class c 2 subclassof c 1,? the list of superclasses of the class c 1 [ClassName1=?] [ClassName2=?]?, c 2 the list of subclasses of the class c 2 InstanceOf i, c true if i is an instance of the class c instanceof i,? the list of classes to which the instance i belongs [ClassName=?] [Instance=?] HasProperty?, c the list of instances of the class c c, p true if the class c has the property p hasproperty haspropertyvalue subpropertyof [ClassName=?] [Property=?] Has PropertyValue [Property=?] [Value=?] Subproperty [Property1=?] [Property2=?] c,? the list of properties of the class c?, p the list of classes having the property p p, v the list of URIs where property p has value v p,? the list of possible values for the property p?, v the list of properties with value v p 1, p 2 true if the property p 1 is subproperty of p 2 p 1,? the list of superproperties of the property p 1?, p 2 the list of subproperties of the property p 2 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) 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. 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 actual 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 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 Model-Driven Design and Development of Semantic Web Service Applications 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 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 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 summarizes 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 Identifier) 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 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 machineconsumed 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 specialized XSLT stylesheets that process the internal lanes of the BPMN model and

16 16 Marco Brambilla et al. 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., Solicit units 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 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 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) storing internal application data. In any case, the designer is in charge of refining and detailing the specification of the hypertext models. Figure 8 shows the WebML specification of the hypertext of the Blue Shipment

17 Model-Driven Design and Development of Semantic Web Service Applications 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, the searchshipmentsolicit unit implements the first activity of the lane, waiting for an incoming message. The ShipmentRequest is received by searchshipmentsolicit and is passed to the Send Goal activity. The Goal Composition unit fills 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 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 repeated 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 the Lowering 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 Offers unit), 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, the Receive Chosen Offer activity is triggered (lower part in the Figure 8). The confirmshipoffersolicit receives the message and the previously stored offer is retrieved within the Invoke 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 ShipmentConfirmationResponse 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 called Select Order to Ship allows 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 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

18 18 Marco Brambilla et al. 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 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 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 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.2. 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 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 BPMN data 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 WSML pre-conditions and post-conditions. More details can be extracted from the WebML models: WSML pre-conditions are obtained from

19 Model-Driven Design and Development of Semantic Web Service Applications 19 The WebML XML description of the Blue Shipment Web Service The automatically generated WSML description <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> 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] memberof ConfirmShipOfferRequest) implies exists?confirmation (?Confirmation[ offerid hasvalue?oid, confirmationid hasvalue?cid ] memberof ShipmentConfirmation )) 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 automatically generated WSML description of its capabilities. In particular, Figure 11 illustrates 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 information 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 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 analysing the order of invocation of the different