1 Introduction - CiteSeerX

Model-Driven Design and Development of Semantic Web Service Applications Marco Brambilla1, Irene Celino2, Stefano Ceri1, Dario Cerizza2, Emanuele Della Valle2, Federico Michele Facca1 1

Politecnico di Milano, Dipartimento di Elettronica e Informazione, 20133 Milano, Italy {Marco.Brambilla, Stefano.Ceri, Federico.Facca}@polimi.it 2 CEFRIEL, 20133 Milano, Italy {celino,cerizza,dellavalle}@cefriel.it

Abstract. This paper proposes a model-driven methodology to design and develop Semantic Web Service applications and their components, described according to the emerging WSMO initiative. In particular, we show the advantages of a topdown approach that uses software engineering methods and tools, such as: formalized development processes, componentbased software design techniques, and computer-aided software design. This approach leads from an abstract view of the business needs to application concrete implementation, by means of powerful code generators. Our method is based on existing models for the specification of business processes (such as BPMN) combined with Web Engineering models for designing and developing semantically rich Web applications implementing Service Oriented Architectures (such as WebML) with the support of Semantic Web Service tools (such as WSMX and WSMT). The proposed framework increases the efficiency of the whole design process, yielding to the construction of Semantic Web Service applications spanning over several enterprises. In our paper, we show that business process and Web Engineering models have sufficient expressive power to support the semi-automatic extraction of semantic descriptions (i.e., WSMO ontologies, goals, Web Services, and mediators), thus hiding the complexity of dealing with semantics in a structured designed process.

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

1 Introduction One of the most challenging promises of the Semantic Web Services (i.e., OWL-S [36], WSMO [41], and WSDL-S [44]) is to enable the construction of flexible business applications, spanning over several enterprises and capable of dynamic composition for presenting to their clients the “best” business options. These emerging initiatives propose to augment Web Services with semantic annotations and to operate reasoners on top of such descriptions for performing business choices, thus matching user’s goals to system’s resources. In this paper we use WSMO, one of the emerging Semantic Web Service initiatives, because it provides a clear separation between well identified components, such as ontologies, goals, Web Services and mediators, and because it is founded on the two clear principles of strong decoupling and

M. Brambilla et al.

2

strong mediation. While dwelling into the deep aspects of the Semantic Web Services (e.g. for building a semantic execution environment such as WSMX [27]) is outside of the scope of this paper, we focus on the design and re-engineering of software components so as to meet the Semantic Web Services requirements; we show that advanced Software Engineering methods enable the development of software interfaces which are compliant with WSMO. Our method overcomes one of the most critical obstacles to the spreading of WSMO based solutions, i.e., the apparent difficulty of adapting current Web applications to WSMO requirements. Our work shows that there is no contrast – but actually good continuity – between modern model-driven software design methods and the Semantic Web Service concepts; in particular, the current state of the art of model-driven software design offers rich and flexible enough model descriptions to support almost all WSMO abstractions. We exploit modern Web Engineering methods, including visual declarative modeling (based on the WebML conceptual model), automatic code generation (locally executable using standard Web technologies and globally executable across enterprise boundaries by delegating the execution to a Semantic Execution Environment such as WSMX), and automatic elicitation of semantic descriptions for the WSMO components (i.e., Ontologies, Goals, Web Services, and Mediators) from the design of the application. Global choreography1, front-end, and services implementations are derived from Business Process models and WebML models, whereas goals, descriptions of Web Services (both in terms of capabilities and of their choreography interface), and descriptions of mediators are automatically generated. In particular, we propose to cover the different aspects of the design by means of the following techniques and notations: • High-level design of the global choreography of the interaction between services: we adopt BPMN (Business Process Management Notation) to build process models, involving several actors possibly from different enterprises.

1

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

3

Model-Driven Design and Development of Semantic Web Service Applications

• Design of the underlying data model of the cross-enterprise application: we use extended E-R (Entity Relationship) diagrams enriched with OQL derivation rules (whose expressive power is equivalent to WSML Flight [12]) to model the local ontology of the application and to import existing ontologies (possibly modeled in ontology engineering tools such as WSMT [31]), whenever they exist; we expose the resulting set of ontologies to the underlying WSMX; • Design of Web Services interfaces, of integration platform, and of application front end: we use visual diagrams representing Web sites and services according to the WebML models [10], including specific hypertext primitives for Web Service invocation and publishing [7] and explicit representation of workflow concepts [8]. In this way, instead of coping with textual semantic annotations of Semantic Web Services, application developers will obtain them from the use of abstractions that are supported by Software Engineering tools. The use of automatic description generators, sometimes helped by designer’s annotations, guarantees the benefits of Semantic Web Services at nearly zero extra-cost, thus positioning their crossenterprise applications within an infrastructure that allows for flexible and dynamic reconfiguration. Current research efforts are converging on the proposal of combining Semantic Web Services and Business Process Management to create one consolidated technology, which we call Semantic Business Process Management (SBPM) [28].

The claim is based on the observation that the problem of

mechanization of BPM, i.e., the reduction of human intervention in associated tasks, can be traced back to an ontological problem, i.e., the lack of machine-accessible semantics, and that the modeling constructs of SWS frameworks, especially WSMO, are a natural fit to create such a representation. This paper follows this trend towards SBPM and it refines our previous work [4] focusing on the development process, explaining how we manage ontologies and providing a set of advanced primitives for querying the ontologies. The paper is structured as follows: Section 2 offers a view on the background of the research; Section 3 presents the running example that will be discussed throughout the paper; Section 4 describes the overall methodology, presents the development process and addresses the main development steps, including the definition, the importing, and the query primitives for ontologies; Section 5 presents the proposed approach to the elicitation of semantic description of the application; Section 6 briefly outlines our

M. Brambilla et al.

4

implementation experience; Section 7 introduces some considerations on the test and evaluation of the current state of our framework; Section 8 reports some of the current research efforts related to our work; and finally Section 9 presents our conclusions.

2 Background Our approach relies on methodologies, tools and techniques from the fields of Software Engineering, Web Engineering, and Business Process Management.

2.1 Modeling Business Processes All the B2B Web applications implement a business process, which is represented by using a workflow model. Several notations have been proposed for workflow design. For the visual representation of workflows, we adopt Business Process Management Notation [9], which is associated to the BPML standard, issued by the Business Process Management Initiative. We adopted BPMN since it is a well know and widely used to model Business Processes and its notation is one of the most effective to represents real IT processes. Furthermore it is based on an easy visual notation. Various proposals are currently issued for serialization of workflow models in XML format. Among the most promising ones, we can cite XPDL [50] introduced by the Workflow Management Coalition (WfMC). The BPMN notation allows to represent all the basic process concepts defined by the WfMC model. BPMN activities extend WfMC activities, as they can express various behaviors (looping execution, compensation, internal sub-process structuring, event catching, and so on). BPMN activities can be grouped into pools, and one pool contains all activities that are to be enacted by a given process participant. Within a pool, we use BPMN lanes to distinguish different user types that interact with the specific peer. The flow of the process is described by means of arrows, representing either the actual execution flow, or the flow of exchanged messages. Another type of arrows represents the association of data objects to activities; these are meant just as visual cues for the reader, and do not have an executable meaning. Gateways are process flow control elements; typical gateways include decision, splitting, merging and synchronization points. Table 1 briefly summarizes the main visual constructs provided by BPMN. An example of full BPMN model is represented in Figure 4.

5


Table 1. BPMN main constructs. Events

Start

End

Intermediate

O

X

+

Or gateway

Xor gateway

And gateway

Gateways

Activities and Flows

Name Activity

Sequence flow

Message flow

Data Association

Pool and Lanes

2.2 Model-driven Web application design Several approaches in the Web engineering field provide methodologies, conceptual models, notations, and tools for the design of Web applications (e.g., [42, 22, 21]). In this paper, we will adopt the WebML methodology [10] since it provides an easily extensible model where each element has a well defined semantic that can be exploited to reduce the annotation effort; furthermore WebML is supported by a en effective CASE tool and runtime environment (WebRatio). The specification of a Web application according to WebML consists of a set of models: the application data model (an extended EntityRelationship model), one or more hypertext models (i.e., different site views for different types of users), expressing the navigation paths and the page composition of the Web application; the presentation model, describing the visual aspects of the pages. A hypertext site view is a graph of pages; pages are composed by units, representing publishing of atomic pieces of information, and operations for modifying data or performing arbitrary bucsiness actions (e.g., sending e-mails). Units are connected by links, to allow navigation, passing of parameters between the components, and computation of the hypertext. The WebML conceptual model includes a service model comprising a set of Web Service units [7, 35], corresponding to the WSDL classes of Web Service operations, and components for workflow management and tracking. The Web Services units consist of Request-Response and One-Way operations, which model services invocation and are triggered by the navigation of an input link; and of Notification and Solicit-Response, that are triggered by the reception of a message, thus they represent the publishing

M. Brambilla et al.

6

(a) (b) Figure 1. Example of WebML hypertext model with invocation of remote service of a Web Service, which is exposed and can be invoked by third party applications. The model supports both the grounding of Web Services to the XML format of Web Service messages, and data-mediation capabilities. Figure 1 shows an hypertext example that includes the model of a Web Service call and of the called service. Supply Area of Figure 1(a) is an area of a Web site for supply management. The employee can browse to the SupplySearch page, in which the SearchProducts entry unit permits the input of search criteria. From this information, a request message is composed and sent to the RemoteSearch operation of a Web Service. The user then waits for the response message, containing a list of products satisfying the search criteria. From these options, a set of instances of Product are created, and displayed to the user by means of the Products index unit in the Products page; the user may continue browsing, e.g., by choosing one of the displayed products and looking at its details. Figure 1(b) represents the model of the RemoteSearch service invoked by the previously described hypertext. The interaction starts with the solicit SearchSolicit unit, which denotes the reception of the message. Upon the arrival of the message, an XML-out operation extracts from the local data source the list of desired products and formats the resulting XML document. The SearchResponse unit produces the response message for the invoking Web Service. WebML covers also the development of B2B Web applications implementing business processes, thereby supporting collaborative workflow-based applications, spanning multiple individuals, services, and organizations. The data model is extended with the meta-data necessary for tracking the execution of the business process, by registering the execution advancement of cases (i.e., instances of processes) and activities as relational data. The hypertext model is extended by specifying activity boundaries and business-dependent navigation links. Activities are represented by areas tagged with a marker “A”; workflow links traverse the boundaries of activity areas and are associated with workflow logic: every link

7


entering an activity starts the execution of the activity; every outgoing link ends the activity. If and switch units can be used to express navigation conditions. Distributed processes can be obtained by combining the workflow primitives with Web Services primitives [8]2.

2.3 Semantic Web Services Currently several initiatives aim to bring Semantic Web technology to Web Services (i.e., OWL-S [36], WSMO [41], WSDL-S [44]). In this paper we will adopt the Web Service Modeling Ontology (WSMO) because of its strong decoupling of the different components and its high leverage on the mediation to allow interoperability. The WSMO [19] initiative aims at providing a comprehensive framework for handling Semantic Web Services which includes the WSMO conceptual model, the WSML language [12] and the WSMX execution environment [27], which also include design tools such as WSMT [31]. WSMO is an ontology for describing various aspects related to Semantic Web Services. The objective of WSMO and its accompanying efforts is to solve the application integration problem for Web Services by defining a coherent technology for Semantic Web Services. We briefly present the basic concepts of WSMO with respect to its conceptual specification. WSMO defines four modeling elements (ontologies, goals, Web Services and mediators) to describe several aspects of Semantic Web Services, based on the conceptual grounding of the Web Service Modeling Framework (WSMF) [20]. Ontologies provide the formal semantics to the information used by all other components. They serve in defining the formal semantics of the information, and in linking machine and human terminologies. WSMO specifies different constituents as part of the description of an ontology, like concepts, relations, axioms, instances and so on. Web Services represent the functional and behavioral aspects, which must be semantically described in order to allow semi-automated use. Each Web Service represents an atomic piece of functionality that can be reused to build more complex ones. Web Services are described in WSMO from three different points of view: besides non-functional properties, the core description includes functionality and behavior. The functionalities are described as

2

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

M. Brambilla et al.

8

capabilities, while the behavior is described in Web Service interface. A Web Service can be described by multiple interfaces, but has one and only one capability. Moreover, the interface of a Web Service describes the behavior of the Web Service from two perspectives: communication and collaboration. Goals specify objectives that a client might have when consulting a Web Service. In WSMO, a goal is characterized in a dual way with respect to Web Services: goal’s descriptions include the requested capability and the requested interface. Finally, mediators provide interoperability facilities among the other elements. They describe elements that aim to overcome structural, semantic or conceptual mismatches that appear between the different components that build up a WSMO description. WSMO offers four mediators to solve heterogeneity issues and support efficiently Goal driven Web Service discovery: ooMediators import (parts of) ontologies and resolve heterogeneity between them; wwMediators connect two different Web Services, resolving any data, process and protocol heterogeneity between them; the ggMediators connect different goals, enabling goals to refine more general goals and thus enabling reuse of goal definitions; and finally wgMediators connect goals and Web Services, resolving any data, process and protocol heterogeneity. The Web Service Modeling Language (WSML) offers a set of language variants for describing WSMO elements that enable modellers to balance between expressivity and tractability according to different knowledge representation paradigms. The most basic, and least expressive, variant is WSML-Core, which is based on DLP [26] as a least common denominator for description logic (DL) and logic programming (LP). WSML Core is separately extended in the directions of these two paradigms by the variants WSML-DL and WSML-Flight, respectively. In particular WSML-Flight is an extension of WSML-Core which includes concepts, attributes, binary relations and instances, as well as concept and relation hierarchies and support for data types. WSML-Flight is based on a logic programming variant of F-Logic [32] and is semantically equivalent to Datalog with inequality and (locally) stratified negation. The Web Service Execution Environment (WSMX) is a framework for the automation of discovery, selection, mediation, and invocation of Semantic Web Services. WSMX is based on WSMO and, at the same time, it is a reference implementation of it. The framework also includes design tools, Web Service Management Tools (WSMT), for modelling ontologies and describing goals, Web Services and mediators.

9


2.4 Web Service discovery Service Discovery is a normal task manually accomplished in many present business scenarios (e.g., finding a shipment service). Web Services certainly reduced the effort required in invoking a remote service exposed by a business partner, but their discovery (i.e., using UDDI [47]) always involves a human in the loop. Given that, in practice, automatic discovery of Web Services is not used. Ontologies can play a key role in automating Web Service Discovery [46, 33, 40]. In this work we will adopt Glue as Web Service discovery engine. Glue [14, 15] is based on a novel approach that refines the conceptual model for WSMO Web Service discovery as well as the reference architecture and the related execution semantics. At a conceptual level Glue approach introduces the notion of class of goals and class of Web Service descriptions and gives mediators a central role in discovery. Glue approach recommends to use: ggMediators (goal to goal Mediators), for automatically generating a set of goals semantically equivalent to the one expressed by the requester but expressed with a different form or using different ontologies, and wgMediators (Web Service to goal Mediators), as the conceptual element responsible for evaluating the matching. The resulting discovery mechanism is a composite procedure where the discovery of the appropriate mediators and the discovery of the appropriate services is combined.

3

Running example

For the discussion we will consider a running example derived by the Purchase Order Mediation scenario and the Shipment Discovery scenario proposed at the Semantic Web Service Challenge 2006 [16], properly extended to show all the components of a classical B2B application. In this scenario, two big companies, Blue and Moon, need to integrate their processes in order to create a new business partnership. In summary, as displayed by Figure 2, the architecture includes the two companies Blue and Moon, the mediation service between them, and a general-purpose Web Service built by Blue for interacting with external services and an external discovery engine.

M. Brambilla et al.

10

Figure 2. The B2B scenario derived from the Semantic Web Service Challenge 2006. Blue usually handles its purchase orders towards its partners by using a standard RosettaNet PIP 3A4 conversation, while the Moon partner offers a set of Legacy Web Services for products purchase. Blue employees, in the Purchase department, want to “talk” in a transparent way with their counterparts in the Moon partner – using their usual RosettaNet Purchase Order Interface, therefore a mediation component is needed between the two. The mediator is in charge of (i) transforming the single RosettaNet message (containing all the order details) to the various messages needed by Moon to create and handle a purchase order; and (ii) of translating the set of confirmation messages by Moon into a whole RosettaNet Purchase Order Confirmation to be sent back to Blue. Thus, the mediation requires a data mediation and a relevant process mediation between the two totally different purchase processes of RosettaNet and Moon legacy system. The RosettaNet Purchase Order Interface offers the possibility to import products ontologies published by partners and select from them the products to be added to the Purchase Order. After completing the purchase of a set of products, Blue employees organize the shipment of the products

11


Figure 3. Phases in the development process of data- and process-intensive semantic Web applications. through the Shipment Organize Interface. This interface relies on a Web Service internally developed by Blue and offered to Blue partners too. The internal orchestration of the Web Service relies on a WSMX compliant Discovery Engine for retrieving available shipment services, and hence needs to describe the shipment goal according to the WSMO standard. When the Discovery Engine returns a list of Web Services offering a shipment service compatible with the original Goal, the Shipment Web Service invokes the returned Web Services to obtain actual shipment offers and proceeds with its orchestration.

4 Design of Semantic Web Service applications This section describes our proposal for semi-automatically generating WSMO-compliant semantic specifications of a Web application. Our approach extends the WebML methodology presented in Section 2.3 towards the design of Semantic Web Services and Web applications.

4.1 Development process The phases of the development process of a Semantic Web application are shown in Figure 3. In line with the classic Boehm’s Spiral model and with modern methods for Web and Software Engineering, the development phases must be applied in an iterative and incremental manner, in which the various tasks are repeated and refined until results meet the business requirements. Requirements specification is the activity in which the application analyst collects and formalizes the essential information about the application domain and expected functions. Process design focuses on the high-level schematization of the (possibly distributed) processes underlying the application. Process

M. Brambilla et al.

12

design and distribution influence the next steps of the development, which should take into account process requirements. Data design is the phase in which the data expert organizes the main information objects identified during requirements specification into a comprehensive and coherent domain model, that may comprise importing of existing ontologies. Hypertext design is the activity that transforms the functional requirements identified during requirements specification into one or more Web Services and Web site views embodying the needed retrieval and manipulation methods. Hypertext design may comprise importing or referencing existing services and goals. It exploits high level models, which let the architect specify how content elements are published within pages, how services provide information to requestors, and how hypertext elements are connected by links to form a navigable structure. This paper is focused on Semantic description of the application, a new design phase which is required to provide WSMO compatibility; it consists in a set of tasks, partially automated, that aim at providing a set of semantic specifications of the application to be implemented. The other phases of Figure 3 are outside the scope of this paper. A comprehensive description of them can be found in [10].

4.2 Design of the business process The business process (BP) design task, focusing on the high-level schematization of the processes underlying the application, results in one or more Business Process diagrams. The Business Process design is a high level conceptual task. The resulting BP diagram is a representation of the sequences and constraints among the tasks to be executed at abstract level, therefore it does not reflect the structure of the application yet. Business Processes can be internally structured using a variety of constructs: sequences of activities, AND, OR, XOR and complex conditional gateways for splitting and merging of branches, iterations of one or more activities, pre- and post-conditions, and so on. Once the specification of the control flow is defined, the designer can annotate the model by selecting the kind of expected implementation of each activity and service. In particular, with respect to service invocation, it is possible to specify whether the service has to be modeled and implemented internally (internal), shall be invoked as a non-semantic already implemented service (external), or needs to be searched and invoked by means of semantic discovery and invocation techniques (semantic). The BP diagram of the running case is represented in Figure 4: for sake of clarity, the process is split into two

13


Figure 4. Workflow representing the interaction of the running example (BPMN notation). sub-processes: part (a) describes the purchase and part (b) describes the shipment management. Notice that the two processes shall be executed sequentially in the full scenario. We assume that the MOON services are external, the mediator services are internal, and the shipment services are semantic. In the following, we will exemplify the design of the mediator of part (a), and the extraction of ontology, capability and choreography of part (b). Note that the two workflow diagrams have well-defined

M. Brambilla et al.

14

workflow semantics (once iteration conditions and conditional branches are fully specified), while the representation of Figure 2 doesn’t. Building a BPMN (or equivalent) representation of the business process is a first step of the model driven design of any complex software system.

4.3 Design of the data model and extraction of the ontologies The elicitation of the ontologies involved in the application is addressed by four distinct steps, each addressing different aspects of the application ontology: 1. First, existing remote ontologies, possibly provided by third parties, can be imported. 2. Then, the data model is considered as a piece of ontology. This means that an appropriate transformation of the WebML data model transform the extended E-R internal representation of the data into a WSMO-compliant ontology, which is then registered on the WSMX resource manager [27]. The expressive power of the WebML E-R model can be compared to the WSML-Flight language. Table 2 shows the comparison of the expressive power of WebML in respect to OWL-DL and WSMLFlight extending the comparison presented in [13]. Similar to WSML-Flight, the WebML data model comprises a rule language called WebML-OQL, which allows for calculating derived information, but not for defining constraints. Moreover, as WSML Flight, WebML doesn’t have neither Thing nor Nothing concepts, but, differently from WSML Flight, it cannot deal with equality related constructors (i.e., EquivalentClasses, SameIndividual, DisjointClasses, DifferentIndividuals, and Fuctional/InverseFuctional properties). In any case, the similarity between WebML extended E-R

and WSML-Flight is enough to enable a partial extraction of WSMO ontologies. 3. Then, the process ontology is extracted from the BPMN specification of the underlying business process of the application. The elements of the workflow model (e.g., activity names, lanes, and so on) are extracted as semantic concepts and used to build an additional piece of the ontology that will be useful in defining the state signature of the choreography interfaces of the Web Services;

15


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

4. Finally, the BPMN model and the WebML data model are annotated with concepts imported from existing ontologies This approach is oriented towards T. Berners-Lee vision for Web applications connected by concepts annotations [2], since it provides a framework for importing existing ontologies and defining new ones, thus sharing knowledge among different applications on the Web. Figure 5 shows the E-R diagram used by the Shipment Web Service to describe goals and to invoke the external Shipment Web Services. The E-R has three main domain entities Shipment, describing each shipping, ShipmentService, describing BLUE shipment partners, and Location, describing the

M. Brambilla et al.

16

Figure 5. A portion of the WebML E-R diagram used by the Shipment Web Service. geographical entities involved in the shipment process. The E-R diagram includes also the two process entities used to describe the status of the process (see Section 3.3). Each Shipment instance is related to a ShipmentService, to a origin and a destination Location and, finally to an Activity to indicate its current state. The ShipmentService entity is connected to the Location entity through the shipTo relationship, i.e., each shipment partner has a set of possible shipment locations, and through the hasLocation relationship, each carrier has a set of valid pick up points. Both the Location and the ShipmentService entities have some sub entities in order to easily specialize their characteristics. The process of WSML ontologies generation starts by importing external ontologies used in the WebML E-R model to enrich WebML data types definitions. Then, for each entity in the E-R, a correspondent WSML concept is generated with its super direct concept, attributes (also E-R relationships are mapped to attributes) and possible axioms. Axioms are derived from WebML OQL expressions defined on the data. WebML E-R model can be easily converted to a WSML-Flight ontology maintaining all its constraints. For instance, the EuropeanShipmentService entity is a sub entity of the InternationalShipmentService that is located in Europe. This subentity is described in the WebML-OQL syntax as: InternationalShipmentService(as SuperEntity) where InternationalShipmentService.hasLocation isa Europe.

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

17

Model-Driven Design and Development of Semantic Web Service Applications concept ShipmentService hasName ofType _string hasLocation ofType (0 *) Location ... concept EuropeanShipmentService subConceptOf InternationalShipmentService nfp dc#relation hasValue { EuShipmentServiceDef } endnfp axiom EuShipmentServiceDef definedBy ?x memberOf InternationlShipmentService and hasLocation(?x,?nation) and ?nation memberOf Europe implies ?x memberOf EuropeanShipmentService.

4.4 Querying ontologies A large part of the design of Semantic Web applications (i.e., WSMO semantic description, extraction of ontologies) can be performed by means of existing design tools and primitives, some additional elements might be needed for addressing complex query and reasoning over native semantic data. Hence we enhanced WebML modifying existing primitives and introducing new ones to allow a native interaction with ontologies. The aim of this new primitives that are able to perform query over ontological data is not to replace the original ones: even if part of the information underlying the system is represented by ontological knowledge, we think that for substantial sections of Web applications conventional (e.g., relational) representation of data is still effective. Therefore, we claim that integrating ontologies and relational data and allowing seamless interaction between them is a desiderata of Semantic Web applications. Thanks to the unit-based model of WebML, where each unit exchanges data with other units by passing parameters over links, interaction between ontology's instances and database instances can be quite straightforward. The main asset of WebML, i.e., its ability of effectively capturing the parameters passed between the different components (units) of the Web application, is still valid even when we are considering Semantic Web applications. Indeed, it does not matter if the underlying data are extracted from ontologies or databases; a Web application is anyway composed by the same hypertextual primitives. Parameters on the links become the actual contact point between traditional and semantic data. In this way, we achieve a good orthogonalization between data model and hypertext model of the applications. 4.4.1 Basic primitives for queries on ontologies Basic WebML primitives for data access can be exploited for queries over ontologies: Index unit, Multidata unit, and Data unit are traditionally used to navigate database instances, but their semantic is general purpose, and hence their paradigm is suitable to navigate and show ontology instances too. They

M. Brambilla et al.

18

only need to be extended to support different kinds of data sources (in particular, ontologies) and some additional options for the queries. For instance, the Index unit can be used to produce lists of instances of a particular class of the domain ontology. A needed feature is the possibility to show only direct instances or also inferred instances. Moreover, an Index unit that express a query over an ontology class may show also the direct or the inferred subclasses of the selected class. The developer can choose at design time the combination he prefers. The same discussion applies to Multidata unit and Data unit. WebML already introduced the concept of Hierarchical Index unit, which acquires a first class role in the context of Semantic Web applications. Hierarchical Index unit is ideal to publish a portion of a ontology: i.e., the hierarchic tree underlying a certain class comprising its subclasses and instances. 4.4.2 Advanced primitives for queries on ontologies The evolution of the basic data access primitives, introduced in the previous paragraph, is not enough to exploit the rich set of possible queries over semantic instances and classes. Therefore, we introduce a new set of operational primitives to describe advanced queries over ontological data. We introduce a first set of units representing the basic ontological queries and inferences for Classes, Instances, and Properties. The units are aggregate primitives that, depending on the type of parameters, execute differently. Table 3 summarizes the syntax and the semantics of such units. Note that these units are natively able to manage ontological data sources, therefore they can manage concepts and references by means of the standard uri (Uniform Resource Identifier) mechanism, while the original WebML units only rely on OID identification mechanisms.

19


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

Subproperty

[Property1=?] [Property2=?]

Input

Output

c1, c2

true if c1 is subclass of c2

c1, ?

the list of superclasses of c1

?, c2

the list of subclasses of c2

i, c

true if i is instance of c

i, ?

the list of classes for i

?, c

the list of instances of the class c

c, p

true if the class c has the property p

c, ?

the list of properties of the class c

?, p

the list of classes having p

p, v

true if the property p has value v

p, ?

the list of possible values for the property p

?, v

the list of properties with value v

p1, p2

true if p1 is subproperty of p2

p1, ?

the list of superproperties of p1

?, p2

the list of subproperties of p2

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

Given a class and an instance, it returns true if the object is instance of the class. Given a class, it returns the list of its instances. Given an instance, it returns the list of the classes it belongs to. Given a class and a property, it returns true if the class includes the property. Given a class, it returns the list of its properties. Given a property, it returns the list of the classes it belongs to. Given a property and a value, it returns true if the property assumes that value. Given a property, it returns the list of all the possible values of the property. Given a value, it returns the list of properties with that value. Given two properties, it returns true if the first is subproperty of the second. Given a property, it returns the list of its subproperties or superproperties.

Besides the units for ontological data query, we introduce a unit to compose the uri sets returned by other units (Figure 6). The Set Composition operation unit is able to perform classic set operations over 2 input sets of uris (i.e., union, intersection, difference). The operations are performed by taking into account the hierarchical structure of the uris involved in the operation: e.g. suppose we have two set of classes A={wine, liquor, food} and B={drink, food}, and assume that the drink class is a superclass of wine and liquor; then A INTERSECTION B gives {wine, liquor, food} and A UNION B gives {drink, food}. The Import Ontological Source unit adds a remote or local data source that must be consistent with ontological model of the Web application (it's validated against it before being added to the ontology model). It is also possible to express the url of an ooMediator to be used to import the ontology and

M. Brambilla et al.

20

Figure 6. Ontology management WebML units. convert it to the internal ontological model. The Describe unit returns the RDF description of an uri, thus enabling automatic Web page annotation and data exporting. Advanced querying units can be used to compose reasoning tasks over ontological data: e.g., suppose that we want to find the set of common properties between two classes representing different products categories (e.g., Digital Photo Camera and Mobile Phone), first we can use two HasProperty units to extract the two set of properties characterizing the two classes; and finally we can find the common set of properties by means of the SetComposition unit (e.g., Pixel, Storage, …). The same idea may apply if we want to discover the common super concepts between two ontology instances: in this case, instead of the HasProperty units, we can use two InstanceOf units to extract the two set of super classes to which the two instance belongs to; then we can find the common set of superclasses by means of the SetComposition unit. Figure 7 shows a portion of the Purchase Order Interface used to navigate the Product ontology and to import ontologies provided by business partners in the contest of our B2B scenario. In the Import Ontologies page, users can fill the form with url to remote ontologies and to the suitable ooMediator, if the ontology provided by the business partner is not consistent with the internal ontological model. When the user submits the filled form, the Import Ontology unit uses the data in the form to acquire the ontology and eventually to call the ooMediator needed to import the new ontology. Available ooMediators are published by a WSMX repository and designed with the tool WSMT. Once an ontology datasource is successfully imported, the user is redirected to the Select Product page, where pre-existing data and newly imported are visible. In the Select Product page, the hierarchical unit Products Hierarchy shows a tree with the class hierarchy pertaining to the concept Product: all its direct and derived subclasses are shown on the tree. When the user selects one of the concepts in the class hierarchy, the Index unit Product Instances is populated with all the instances of the selected concept. From the Index unit Product Instance, the user can navigate to the Product Details page where the Data unit product

21


Figure 7. The Area used to select products to be ordered using business partner ontologies. shows details on the selected product according to its class and the related properties. The Index unit Accessories shows all the product instances and classes that have has the current product uri as value of the property isAccessoryOf. Finally the user can view all the classes to which the current product instance belongs: the uri of the current product instance is passed to the InstanceOf unit that extracts all the direct and derived classes corresponding to the passed instance. Hence the set of classes uri returned by the InstanceOf unit is used to populate the Index unit Related Product Classes.

4.5 Design of the service and the user interfaces in WebML Once the business process has been designed, workflow constraints must be turned into navigation constraints among the pages of the activities of the hypertext and into data queries on the workflow metadata for checking the status of the process, thus ensuring that the data shown by the application and user navigation respect the constraints described by the process specification. This applies both to the human-consumed pieces of contents (i.e., site interfaces) and to the machine-consumed contents (i.e., Semantic Web Services interactions). In our framework both BPMN diagrams and WebML diagrams are stored by means of a XML serialization. Transformations are performed by means of specialized XSLT stylesheets that process the internal lanes of the BPMN model producing the XML serialization of a WebML model: e.g., for a Web Service lane, each activity in the BPMN model is converted in a WebML activity (an ‘A’-labeled area)

M. Brambilla et al.

22

Figure 8. The Blue Shipment Web Service. populated with a default unit (i.e., Solicit units for the BPMN activities that receive messages from external lanes, Response units for the ones that send back messages, Request-Response units for the ones that call remote Web Services and generic Operation units for the others); then the WebML activities are connected by proper links with a well defined semantic to indicate the begin of an activity (‘S’-labeled links) or its end (‘C’-labeled links). Finally the datamodel is enriched with Case and Activity concepts (cfr. Section 4.3) that are populated according to the BPMN model (a case instance for each BPMN lane and an activity instance for each BPMN activity). Our BPMN tool allows to represent only valid diagrams so that the translation to WebML is always guaranteed. The produced WebML model shall consist of application data model, workflow metadata, and hypertext diagrams. Since no a-priori semantics is implied by the activity descriptions, the generated skeleton can only implement the empty structure of each activity along with the hypertext and queries that are needed for enforcing the workflow constraints. The designer remains in charge of implementing the internals of each activity. Additionally, it is possible to annotate the activities, thus allowing the designer to map the activity to a coarse hypertext that implement the specified behavior on the specified data. The designer is in charge of refined specification of the hypertexts. For instance, Figure 8 shows a possible WebML specification of the hypertext of the Blue Shipment service.

23


Figure 9. The Blue Web interface to organize shipments for successful orders. In the upper part of Figure 8, the ShipmentRequest is received by searchShipmentRequest and is passed to the Goal Composition that fill a Goal Template with the required instances, obtaining a goal description for the WSMX compliant Discovery Engine; the generated goal description is passed to the Send Goal which sends the goal to a Web Service exposed by the Discovery Engine. The Discovery Engine returns as result a set of Web Services compatible with the original shipment goal and, for each returned Web Service, an appropriate XSLT stylesheet describing the Lowering and Lifting operations; the results of the Web Service call are stored by Store Goal Result. Then, for each valid Web Service returned, a request for a shipment offer is made by WS Offer Invoker. The XSLT stylesheets for the Lowering and Lifting are selected for each valid Web Service according to the results returned by the Discovery Engine. Each offer returned by a Shipment Web Service is stored by Add Offer. The results for the current Shipment Request are selected by Extract Valid Offers and converted to the Blue data model by Lowering and the set of offers is returned the service requester by SendShipOffer. Once the service requester selects one of the offers and he sends the ConfirmShipOfferRequest to the confirmShipOfferRequest (lower part in the Figure 8), the previously stored offer is retrieved (Extract Confirmed Offer), hence the offer purchase message is composed by Lowering wih an approriate XSTL stylesheet and WS Purchase Invoker sends the message to the Shipment Web Service. Finally Send ShipmentConfirmation sends a confirmation message to the service requester according to the answer received by the invoked Shipment Web Service. Figure 9 shows a WebML hypertext model representing a fragment of the Blue Web application: a home page called Select Order to Ship allows the user to choose an Order (with Status “Not shipped”) from the

M. Brambilla et al.

24 Ontology importing and/or semantic annotation

Business process modeling

BPMN model

WF-driven WebML generator

WSML Goal

WebML skeleton

Web application modeling

WSML WS Choreography

WebML data model

WSML WS Capability

WebML hypertext model

Automatic code generation

Running application

WSML Mediator

Figure 10. Overall picture of the extraction of semantic description of Web Services. Order List index unit. When an order is chosen, the “S” link starts the Organize Shipment activity, showing the Order Details data unit in the Organize Shipment page, together with a form (Search Shipment Offers). The data submission triggers the invocation of a remote service (searchShipmentOffers request-response unit), whose results are lifted by the storeShipmentOffer XML-in unit. The activity is completed (link “C”) and following one is started. The Select Shipment Offer page is shown, containing a list of Shipment Offers (an index unit displaying the results of the service). The user chooses an offer and thus triggers the confirmShipmentOffer request response, whose results are stored locally. Finally, the user is redirected to the home page. One should notice that this high level visual programming of Web applications, although of lower level if compared to BPMN specifications, is not concerned with many implementation details, which are left to the design tool, capable of deploying the code for arbitrary choices of data management and Web server architecture. Moreover, this visual programming style is natively supporting change management and reengineering.

5 Extraction of the WSMO description of the Web Services In this section we show that the WSMO-compliant description of Web Services can be semiautomatically derived from the design specification. Figure 10 summarizes the extraction of semantic description of services from the application design. The design flow represents the main steps of the development process presented in Section 4.1. The various steps produce some intermediate artifacts (BPMN models, WebML skeletons, data models, hypertext models), possibly enriched by imported ontological descriptions (on top of Figure 10) and are exploited

25


Figure 11. A portion of the WebML XML serialization and the generated WSML description. for devising the set of WSMO specifications (at the bottom of Figure 10): the description of the mediator can be extracted from the hypertext describing the mediator (see Section 5.4); the Web Services capability description is derived from hypertext model; the choreography information is derived from BP model; and the user goals (Section 5.3) are derived from the BP model and the hypertext model.

5.1 Extraction of Web Services capabilities The BPMN and WebML models of the Web Services provide enough information for describing its behaviour. Assuming a BPMN activity as an atomic Web Service call, we can exploit the BPMN data flow for providing good hints for the extraction of inputs and outputs of the service. Indeed, the data flow specifies the objects that are passed between the various activities. By isolating a single activity, it is possible to extract the WSML pre-conditions (inputs) and post-conditions (outputs). WSML pre-conditions are obtained from the first unit of WebML chain describing a Web Service operation (Solicit Unit), while post-conditions are obtained from the last one (Response Unit). These two units contain information about the exact structure of the exchanged message and eventually the mapping of message elements to the domain model and hence to the extracted ontologies (see Section 4.4). Effects are extracted searching for WebML units that modify or create instances of entities that are related to the activities involved by the process described in WebML Web Service. Shared variables are obtained from the different generated conditions by grouping all the variables involved in the operations data flow.

M. Brambilla et al.

26

Figure 11 shows a portion of the WebML XML serialization for the Blue Shipment Web Service, introduced in Section 4.4 and its correspondences with the automatically generated WSML description of its capabilities. In particular, Figure 11 illustrates how parameters of the Solicit Unit in WebML (SolicitParameter) corresponds to WSML pre-conditions, and how parameters of the Response Unit in WebML (ResponseParameter) corresponds to WSML post-conditions. The WebML XML serialization contains also a reference to the XSD file describing the structure of the exchanged messaged (shipment.xsd) while the WSML description contains information about the structure of the exchanged messages (surrounded by a green box): both these parts are obtained from the data model introduced in Section 4.3.

5.2. Extraction of the service choreography The service choreography is a piece of information that typically requires some annotation by the designer, in order to establish all the possible interaction sequences with the service. However, at least one of the choreography sequences can be extracted from the BPMN model, by analyzing the order of invocation of the different operations of the service. Obviously, this does not guarantee that all the possible scenarios are considered, since only one enactment can be analyzed. The extraction of this kind of information is rather simple: provided that a lane describes a single Web Service, we can assume that all the control flow links traversing its borders contribute to specifying a possible invocation order of the operations, i.e., a choreography interface of the Web Service. The following is the WSML description of the Web Service choreography interface automatically generated. interface choreography stateSignature in ShipmentRequest withGrounding […] ConfirmShipOfferRequest withGrounding […] out ShipOfferContainer withGrounding […] ShipmentConfirmation withGrounding […] controlled oasm#ControlState transitionRules forall {?x, ?state} with ( ?state[oasm#value hasValue oasm#InitialState] memberOf oasm#ControlState and ?x memberOf ShipmentRequest ) do add(?state[oasm#value hasValue ShipmentOfferRequested]) delete(?state[oasm#value hasValue oasm#InitialState]) add(_# memberOf ShipmentOfferContainer)

27

Model-Driven Design and Development of Semantic Web Service Applications endForall forall {?x, ?state} with ( ?state[oasm#value hasValue ShipmentOfferRequested] and ?x memberOf ConfirmShipOfferRequest) do add(_# memberOf ShipmentConfirmation) endForall

5.3. Extraction of the service orchestration The process that leads to the extraction of the service orchestration is very similar to the previously introduced process for the extraction of the service choreography. While the WSMO choreography describe the supposed order of call of the operation provided by a Web Service, the WSMO orchestration describes how a published Web Service internally interacts with other Web Services. At the moment the language to describe the WSMO orchestration interface [43] is still under development, but we already know that it will be based on the same ASM model used to describe WSMO choreography interface. For example, taking into account the second lane of the BPMN diagram in Figure 4(a), that represents the Web Service that provides the implementation of a Web Service to Web Service Mediator (wwMediator), we are able to automatically extract the orchestration sequences considering all the control flow links traversing its borders with the bellow lane, containing the operations of the remote Web Service.

5.4 Extraction of user’s goal Extraction of user’s goals can be performed combining information available at the BPMN level with information available at the WebML level. A first level of goal elicitation can be achieved by extracting the sequence of conditions and objects passed to the Web Services by the user’s lane in the BPMN diagram. A deeper level of details requires using the WebML hypertext models and analyzing the semantics embedded in the navigation and composition of the pages. Such refined goal is detailed in terms of the tasks performed by the user and of the data manipulated, thus increasing the significance of the WSMO goals that can be generated. Goals are generated in correspondence with Web Service call to provide a semantic description of the objective persecuted by the user/machine invoking the Web Service. In the scenario we introduced, for example, a Goal template description is automatically generated a design time and populated at runtime to describe the user’s aims implied by the Organize Shipment Interface interaction with the Shipment Web Service. In particular, the shared variables are extracted from the data

M. Brambilla et al.

28

instances passed to the Web Service operation call, while the effects are obtained considering the WebML operations modifying data associated to the extracted shared variables. For example, the XML-In unit in Figure 9, stores the confirmed shipment orders creating a shipment data instance with a particular status. The following is the WSML description of a Goal automatically generated. capability sharedVariables ?shipment postcondition definedBy ?shipment [ requestedPickupLocation hasValue stanford, requestedDeliveryLocation hasValue rome, requestedDeliveryDateTime hasValue _date(2006,4,28), goodDimension hasValue _d [ l hasValue 10, w hasValue 50, h hasValue 100] memberOf dimension, maxAcceotedShipmentPrice hasValue 50 ] memberOf requestsShipmentService.

Given that goals capture user’s needs, this part of the process is perhaps the least easy to automatize, and manual verification and intervention is generally required.

5.5 Design of wwMediators with WebML One of the main strength points of the approach is the ease of design and implementation of complex wwMediators. If a lane is identified as a wwMediator at the BPMN level, the basic information about the design of the mediation services can be extracted from the high-level BPMN description of the interactions (in particular, information about possible choreography of the service and basic interface and parameter specification). The skeleton model of the mediator is automatically generated and the designer can refine it at a conceptual design level. Then, the WSMO description of the mediator can be derived from the WebML diagrams. Figure 12 presents the detailed specification of the wwMediator within WebML. This specification can be used to generate a working Web Service providing mediation between Blue and Moon Web Service. The WebML specification includes some Lowering and Lifting operations corresponding to WSMO ooMediators and provides mediation between the data model of the source Web Service and the destination one. In WebML this mediation consists in XSLT stylesheets generated by a graphic tool described in Section 6.1. Note that the mediation activities are in one-to-one correspondence with the BPMN activities of Figure 4. The chain of operation consists of: (a) receiving a Web Service call

29


Figure 12. The WebML model of wwMediator Web Service. invocation; (b) transforming input application data into suitable internal format (lifting); (c) storing internal application data; (d) transforming application data into suitable format for the subsequent Web Service call (lowering); (e) calling the next Web Service in the chain; (f) tracking the status change of the wwMediator (with no manual intervention). The following WSML description of the wwMediator, need to register it on the WSMX runtime, is generated at deploy time: wwMediator _... nonFunctionalProperties dc#type hasValue _"http://www.wsmo.org/2004/d2/v1.2/#mediators" endNonFunctionalProperties source _"http://blue.org/RosettaPurchaseOrder" target _"http://moon.org/OMService"

6 Implementation A proof of concepts of the integration with the semantic aspects discussed in this paper has been presented at the SWS Challenge 2006 [5, 16]. The two phases of the challenge allowed us to prove the advantages of a Software Engineering approach to Semantic Web Services design. In particular, in the first phase we presented the WebML design and implementation of the wwMediator of the running case

M. Brambilla et al.

30

WebML site specification Automatic WebML site generator

Compile (design) time Runtime

Browser

Client Layer Web Server JSP pages JSP engine

SOAP sender / listener

Message composer

Message decomposer

Presentation Layer Business Layer

Unit descriptor 1

...

WebML runtime

Unit descriptor n

Conversation Manager Processing of messages received by the site

...

RDBMS

LDAP

XML

...

Data Layer

Construction of messages sent by the site Standard components interactions

Figure 13. Architecture of WebRatio Web application design tool. addressed in this paper (Figure 12) and the usage of the CASE tool WebRatio in the context of Semantic Web applications. Moreover, we integrated Glue WSMO discovery engine by invoking the Web Services that Glue exposes both for publishing a new shipment service and for discovering the most convenient shipment service. In the second phase we proved to be able to deal with changes without writing additional code, but only modeling the additional requirements and exploiting the same framework adopted in the first phase.

6.1 WebRatio The presented approach relies on solid implementation of the background concepts: the WebML methodology is supported by a commercial CASE tool called WebRatio [49], providing visual design interfaces and automatic code generation. The architecture of the tool enabling semantic Web design is an extension of the WebRatio architecture [11]. At compile time (Figure 13, top), each application specification is used to generate an XML descriptor for each unit, link, Web page, service call, and service publishing primitive. At runtime (lower part of Figure 13) the application is instantiated and executed. Clients issue requests to the server, which in turn calls the execution engine; the generated code includes customized JSP tags that define the placement of the WebML units into the pages. The content

31


Figure 14. Snapshot of the visual mapping tool for content lowering and lifting required by the user is assembled by the WebML runtime component, using the descriptors and the data sources in the Data Layer. Web Service calls are managed by a SOAP sender/listener, and a Conversation Manager for conducting long-running interactions with a service. Design support for the grounding of services is provided too. In particular, we developed a prototype mapping tool for visual lowering and lifting of data. The tool allows to design content transformation from local domain ontologies to XML format and vice-versa. With this tool we don’t aim at covering as much as possible of query power. What is needed is a simple and intuitive, yet formal, modeling of typical XML transformations in the context of semantic Web. The designer can ground a service to an XML implementation by specifying a set of lowering and lifting transformations defined by drawing simple lines between the origin and target format. The full description of the tool can be found in [6], while a snapshot of the GUI is visible in Figure 14. The information about the transformation drawn by the designer is stored into an XML file, which is used to create appropriate XSL files to be used in Adapter Units within WebML applications, for applying transformations on the actual XML documents.

6.2 BPMN editor and WebML generator The modeling of the business process requirements and their transformation into WebML skeletons are implemented in a prototype tool [3] that allows to design BPMN diagrams and to automatically generate the corresponding WebML hypertext models. The workflow schema is stored as an XML document and WebML models are generated using XSLT technology. In addition, the transformation takes into account the annotations that the designer provided on the kind of implementation of the services (internal,

M. Brambilla et al.

32

external, semantic). Generation rules for the hypertext have been built based on the experience and the theory presented in [8].

6.3 WSML descriptions generators For validating our approach, we developed several prototypical transformers that generate WSMOcompliant descriptions of Web applications and services starting from WebML models of the applications and BPMN specifications of the processes. The pieces of WSMO specification presented in Sections 4.3, 4.5, and 5.3 are samples of the generated output of the transformations. Since both WebRatio and the BPMN editor are designed to be flexible and extensible, and they can manage user-defined properties of objects and new XSLT transformations of the workflow models, we added our generation engines for semantic description of the application directly to the tools.

6.4 GLUE discovery engine Web Service discovery has been addressed by black-box invocation of Glue WSMO discovery engine which provides the basis for introducing discovery in a variety of applications that are easy to use for requesters, and that provides efficient pre-filtering of relevant services and accurate discovery of services that fulfil a given requester goal. Following the process described in [15], Glue was configured by 1. importing the ontologies generated following the approach described in Section 4.3; 2. importing the classes of shipment Web Services and of goals generated following the approach described in Section 5; and 3. manually modeling the required wgMediator that encodes the rules for matching a request for shipmen (modeled as an instance of shipment goal) against the published instances of shipment Web Services.

7 Effectiveness of the proposed approach The proposed approach results particularly efficient and convenient for the developers, in terms of productivity, ease of use, and scalability.

33


Table 4. Average percentage of automatically generated pieces of software DESIGN

% of automatic model generation

Business process design (BPMN)

0%

Data model design (extended E-R)

30 %

Service and the user interfaces design (WebML)

20 %

wwMediators design (WebML)

20 %

SEMANTIC DESCRIPTION EXTRACTION

% of automatic description generation

Extraction of the ontologies (imports excluded)

70 %

Extraction of Web Services capabilities

75 %

Extraction of the service choreography

60 %

Extraction of the service orchestration

70 %

Extraction of user’s goal

40 %

APPLICATION CODE GENERATION

% of automatic code generation

Traditional (non-semantic) parts of the applications

100 %

Semantic parts of applications (descriptions excluded)

75 %

7.1 Productivity evaluation Productivity advantages have been achieved thanks to the powerful automatic generation of code and semantic annotations. WebRatio is capable of fully automatically generating J2EE code of an application starting from WebML specifications. In turns, WebML diagrams are partially automatically generated from high level business process specification. Thus, in conventional Web applications, programming is confined to componentization of special or existing parts of an application, while WebRatio is the glue covering the application design lifecycle, including redesign and maintenance. Previous work [23] describes how function points analysis can be integrated with WebML application modeling. A prototype exists for calculating the number of (unbalanced) function points given a WebML model of a Web application. Extensive experiments show that development of traditional Web applications conducted according to the WebML approach and the WebRatio tool allows an average increase of productivity of more that 50%. Our approach to the deployment of Semantic Web applications has been validated on a realistic scenario represented by the SWS challenge case study. In the design and implementation steps of the development, we followed the process presented in Section 4.1. The semantic description that feed the WSMX runtime engine have been partially generated automatically and then integrated and refined by the designers. Table 4 reports details on the models, the semantic descriptions, and the running code: for each of them, we indicate the percentage of automatically generated software. For models and code generation,

M. Brambilla et al.

34

percentages have been calculated by considering the number of function points that were automatically generated with respect to the total number of function points of the application. For semantic descriptions, percentages are calculated in terms of lines of WSML automatically generated (and not refined by the designer) with respect to the total ones. Productivity is increased by our approach also thanks to the well formalized development process, the adherence to a top-down design process, and the standardization of the application architecture: model driven development reduces the risk of bugs in the code, thanks to the reuse of well tested components. Moreover, when new components are needed, they are developed according to strict guidelines and tested with state of the art automatic code testing technologies.

7.2 Ease of use The visual modeling of the application provides a great advantage to designers and developers. BPMN models proved to be quite intuitive also for non-expert designers such as business experts, and an average knowledge of the full WebML approach can be achieved within a week of training. Then, designers need to include semantic descriptions in the form of tagging and annotations; their specification will be facilitated by means of wizards and verification tools that we plan to incorporate within future versions of our tool. Developers do not need a high level of technical expertise, as they are not bothered with timeexpensive code development and debugging: the environment allows for multi-platform code generation without any additional effort. Further advantages are available thanks to the WebRatio CASE tool: • Automatic project documentation: the tool generates the application documentation (in a style called WebMLdoc, very similar to the well known JavaDoc format) starting from the plain WebML models, possibly enriched with designer comments; such documentation will include Semantic Web annotations. • Model checking: the tool is able to perform syntactical and limited semantic analysis of the WebML models, providing the developer with error and warning messages, thus providing early feedback to the designer; such analysis will be extended to the semantic components of the models. • Fast prototyping: thanks to visual design and automatic generation of the code, a fast prototyping design process can be adopted, with very short design cycles.

35


7.3 Scalability The WebRatio approach demonstrated to perform very well when scaling to big applications, both at design time and runtime. This has been proved widely for traditional applications, with models composed by thousands of pages and components. Design productivity scales easily thanks to the good modularization of diagrams and models, to the integration of the CASE tool with team-oriented editing (with classical check-in/check-out operations and reconciliation support), and to industrial-strength support to code documentation and production within standard repositories. Future increases of scalability in WebRatio are planned with the integration of the business process layer, already planned regardless of the Semantic Web extension; the other aspects of design scalability more specific to the Semantic Web will next be considered. Runtime scalability is granted thanks to the adherence of the generated running code to standard, state of the art platforms (J2EE, Jakarta Struts, WSMX). The components are developed according to the best practices of the respective platforms. Runtime performances and scalability is therefore limited only by performance constraints of the platforms of choice.

8 Related work In the last years, the Semantic Web has become an hot topic and many researchers turned their interests towards to its development; as a result, some of the ideas and promises of the Semantic Web are becoming real: technology has been pushed, new standards have been envisioned, the first real-world applications have been developed (e.g., MultimediaN N9C Eculture [37], eMerges [18]) and consequently an increasing number of big industries are starting to invest in this area (e.g., SAP, IBM, Oracle, and Nokia). However, limited research efforts are concerned with the environments, methods, and tools for the systematic development of Semantic Web applications. A number of researches concentrated on tool development for supporting the generation of semantic descriptions for existing Web Resources (e.g., Services) [17,31], but these in general require the mastering of the annotation language to be used (e.g., OWL-S or WSMO) and hence do not help widening the adoption of Semantic Web and Semantic Web Services. In the rest of this section, we summarize other approaches, sharing with us the goal of easing application development for the Semantic Web. We note the partial development of methods, without

M. Brambilla et al.

36

tools, or of tools, without methods, while the integration of both aspects is still very preliminary. For many aspects, our research effort is coherent with the recent efforts of the Object Management Group (OMG). The OMG proposed the Ontology Definition Metamodel (ODM) [39] to define a suitable language for modeling Semantic Web ontology languages and hence Semantic Web applications in the context of the Model Driven Architecture [37]. MIDAS is a framework, based on MDA, for modeling and developing Semantic Web applications, introduced in [1]. The framework focuses on the creation of Semantic Web Services and associated WSML descriptions using a UML model according to the MDA approach. This proposal inherits the limits of the MDA approach: the use of a UML model is not simpler than using a Semantic Web language, and the model is too far from the implementation to allow for an effective automatic code generation. Furthermore, MIDAS still does not provide a comprehensive method covering all the phases of the design of Semantic Web applications. The research proposed in [24] aims at generating OWL-S specifications and grounding starting from standard UML diagrams; however, only the semantic description of the Web Services is covered, while their actual design and implementation are omitted: semantic descriptions are not inferred from the design of the programming logic of the Web Service, they must be annotated by means of a UML formalism. Similar to our approach, Torres et al. [45] propose a first idea of a method based on Web Engineering research concentrating on the generation of Semantic Web Service descriptions. This proposal refers to OOWS – an extension of the UML based OO-Method [22] – as Web Engineering method and aims to generate OWL and OWL-S descriptions. In comparison, our approach covers a wider are of aspects related to Semantic Web Services (e.g., wwMediators, discovery integration, …) due to the greater richness and expressivity of our models, that allow to cover with fine details the execution semantics of hypertexts and services. In the last years, after realizing the benefits offered by the Semantic Web platform (e.g., interoperability, inference capabilities, increased reuse of the design artifacts, etc.), many efforts have been directed towards the extensions of existing Web Information Systems design methods to include aspects of the Semantic Web. Traditional design methodologies like OOHDM [34] are now focusing on designing Semantic Web applications. New methodologies like Hera [48] were specifically designed by considering

37


the Semantic Web peculiarities. These methodologies are not fully supported by effective and mature CASE tools and concentrate on Semantic Portals rather than Semantic Services.

9 Conclusions and future work This paper presented an overall approach for designing Semantic Web applications by exploiting software engineering techniques. The following results have been shown: •

Ontologies can be imported as models of the data necessary for the cross-enterprise application. They can be extended for addressing the specific needs of the application and registered as shared resources in WSMX.

•

WSMO Web Services functional capabilities for delegating sub-processes execution from one enterprise to another are automatically provided for each Web Service modelled in WebML.

•

Choreography interfaces can be derived by combining information in the Business Process Model and in the WebML hypertext model. In particular, the local choreography can be derived by taking the point of an external observer of the Web Services that must know the order in which operation can be invoked and the constrains for their successful invocation. In a similar manner we can derive the orchestration interface by translating in WSMO some aspects of the BPMN model of the application, as sketched in Section 5.2.

•

WSMO goals can be produced (e.g., goals that triggers the discovery component of WSMX) from gathering data required to perform a given action of the business process, whereas its choreography interface is derived by the explicit representation of workflow primitives within the hypertext.

•

mediation services can be modeled as WebML applications and registered in WSMX according to their roles (e.g., a wwMediator).

In summary, in this paper we propose a complete method for the semi-automatic extraction of the components of the WSMO architecture by using existing software engineering abstractions. In our previous work [4] we presented a first sketch of the approach, with special attention to the extraction of the semantic description of services and design of wwMediators (i.e., current Sections 5.1 and 5.4). The current paper extends and details the existing preliminary work, by defining the extraction mechanisms for goals and orchestration, as well as specifying in details and by example the transformations that are

M. Brambilla et al.

38

needed. Moreover, we provide now a comprehensive view of the methodology and we propose a selfcontained design approach for Semantic Web applications and services. We now provide the possibility of importing ontologies, services and mediators descriptions, and we define a set of new hypertext primitives for querying ontological information. Finally, we compared the expressive power of WebML information modeling with respect to well known ontology definition languages. At the current stage of development, by means of “conventional design” (although supported by an advanced visual design studio), we build software that can run on conventional Web technology and at the same time is ready to become part of a WSMO execution environment (i.e., WSMX). Our future research agenda, which we will schedule in parallel with the wide-spreading and enhancement of WSMO standards, will concentrate upon empowering our design abstractions by incorporating the WSMO concepts as “first-class citizens” in the design process, lifting them up in the artifacts design hierarchy, so as to further improve and simplify the design of native WSMO components.

References 1. Acuña, C. J., Marcos, E.: Modeling semantic web services: a case study. In Proceedings of the 6th International Conference on Web Engineering (ICWE 2006), Palo Alto, California, USA, 32-39. 2. Berners-Lee, T.: Web Services - Semantic Web Talk. Available at: http://www.w3.org/2003/Talks/08-mitre-tbl 3. Brambilla, M.: Generation of WebML Web Application Models from Business Process Specifications. In proceedings of the Sixth International Conference on Web Engineering (ICWE 2006). In print. 4. Brambilla, M., Celino, I., Ceri, S., Cerizza, D., Della Valle, E., Facca, F. M.: A Software Engineering Approach to Design and Development of Semantic Web Service Applications. Technical Report 2006.47, Politecnico di Milano. Also submitted to ISWC 2006, Milan, 2006. Available at: http://webml.org/webml/upload/ent5/1/BCC2006.pdf 5. Brambilla, M., Ceri, S., Cerizza, D., Della Valle, E., Facca, F. M., Fraternali, P., Tziviskou, C.: Web Modeling-based Approach to Automating Web Services Mediation, Choreography and Discovery. In Semantic Web Service Challenge 2006 Phase I, Stanford University, Palo Alto, CA, March 2006. Available at: http://swschallenge.org/wiki/index.php/Workshop_Stanford. 6. Brambilla, M., Ceri, S., Comai, S., Tziviskou, C.: A visual data mapping tool for software components interactions in service-oriented architectures. In Proceedings of the 2006 IASTED International Conference on Software Engineering (SE 2006). January 2006, Innsbruck, Austria, 33–38. 7. Brambilla, M., Ceri, S., Fraternali, P., Acerbis, R., Bongio, A.: Model-driven Design of Service-enabled Web Applications. In proceedings of the ACM SIGMOD International Conference on Management of Data, Baltimore, Maryland, USA, June 14-16, 2005, 851–856. 8. Brambilla, M., Ceri, S., Fraternali, P., Manolescu, I.: Process Modeling in Web Applications. In ACM TOSEM, 2006. In print. 9. Business Processing Modeling Notation (BPMN), OMG, Version 1.0, 2006. Available at: http://www.bpmn.org. 10. Ceri, S., Fraternali, P., Bongio, A., Brambilla, M., Comai, S., Matera, M.: Designing Data-Intensive Web Applications. Morgan-Kaufmann, December 2002. 11. Ceri, S., Fraternali, P., Acerbis, R., Bongio, A., Butti, S., Ciapessoni, F., Conserva, C., Elli, R., Greppi, C., Tagliasacchi, M., Toffetti, G.: Architectural Issues and Solutions in the Development of Data-Intensive Web Applications. In Proceedings of the VLDB First Biennial Conference on Innovative Data Systems Research (CIDR2003), Asilomar, January 2003. 12. de Bruijn, J., Lausen, H., Krummenacher, R., Polleres, A., Predoiu, L., Kifer, M., Fensel, D.: The Web Service Modeling Language WSML, March 2005. Available at: http://www.wsmo.org/TR/d16/d16.1/v0.2/ 13. de Bruijn, J., Polleres, A., Lara, R., Fensel, D.: OWL flight, October 2004. Available at: http://www.wsmo.org/2004/d20/d20.3/v0.1 14. Della Valle, E., Cerizza, D.: Cocoon glue: a prototype of WSMO discovery engine for the healthcare field. In Proceedings of 2nd WSMO Implementation Workshop WIW’2005, 2005.

39


15. Della Valle, E., Cerizza, D.: The mediators centric approach to autmatic webservice discovery of Glue. In Hepp, M., Polleres, A., van Harmelen, F., Genesereth, M.R., editors, Proceedings of the First International Workshop on Mediation in Semantic Web Services (MEDIATE 2005), Amsterdam, The Netherlands, December 12, 2005, CEURWorkshop Proceedings, 8, 35–50. 16. DERI Stanford. Semantic Web Services Challenge 2006. http://sws-challenge.org. 17. Elenius D., Denker G., Martin D., Gilham F., Khouri J., Sadaati S., Senanayake R.: The owl-s editor – a development tool for semantic Web services. In 2nd European Semantic Web Conference, May 2005. 18. eMerges, Spatial Data Integration with Semantic Web Services, 2006. http://irs-test.open.ac.uk/sgis-dev/ 19. Feier, C., Domingue, J.: WSMO Primer. Available at: http://www.wsmo.org/TR/d3/d3.1/v0.1/ 20. Fensel, D., Bussler, C.: The Web Service Modeling Framework WSMF. In Electronic Commerce Research and Applications, 1(2), 113–137, 2002. 21. Fernandez, M.F., Florescu, D., Levy, A.Y., Suciu, D.: Declarative Specification of Web Sites with Strudel. In VLDB Journal, 9 (1), 38-55, 2000. 22. Fons, J., Pelechano, V., Albert, M. and Pastor, Ó. Development of Web Applications from Web Enhanced Conceptual Schemas. In Song, I., Liddle, S.W., Wang Ling, T., Scheuermann, P., editors, Proceedings of the 22nd International Conference on Conceptual Modeling (ER 2003), Chicago, Illinois, October 2003, Lecture Notes in Computer Science, 2813, 232–245, 2003. 23. Fraternali, P., Tisi, M., Bangio, A.: Automating function point analysis with model driven development. In Proceedings of the 2006 conference of the Center for Advanced Studies on Collaborative research (CASCON '06), Toronto, Canada, 2006. 24. Gannod, G. C., Timm, J. T. E., Brodie, R. J.: Facilitating the Specification of Semantic Web Services using Model-Driven Development. In International Journal of Web Services Research, 3(3), July-September 2006, 61–81. 25. Garrigós, I., Gómez, J. and Cachero, C., Modelling Dynamic Personalization in Web Applications. In Proceedings of the Web Engineering, International Conference (ICWE 2003), Oviedo, Spain, July 14-18, 2003, 472–475, 2003. 26. Grosof, B., Horrocks, I., Volz, R., Decker, S.: Description Logic Programs: Combining Logic Programs with Description Logics. In Proceedings of the Twelfth International World Wide Web Conference (WWW2003), Budapest, Hungary, 20-24 May 2003, 48–57, 2003. 27. Haller, A. , Cimpian, E., Mocan, A., Oren, E., Bussler, C.: WSMX - A Semantic Service-Oriented Architecture. In Proceedings of the 2005 IEEE International Conference on Web Services (ICWS 2005), 11-15 July 2005, Orlando, FL, USA, 321–328, 2005. 28. Hepp, M., Leymann, F., Domingue, J., Wahler, A., Fensel, D.: Semantic Business Process Management: A Vision Towards Using Semantic Web Services for Business Process Management. In Proceedings of the IEEE International Conference on e-Business Engineering (ICEBE 2005), October 18-20, 2005, Beijing, China, 535–540, 2005. 29. Keller, U., Lara, R., Lausen, H., Polleres, A., Fensel, D.: Automatic location of services. In The Semantic Web: Research and Applications, Proceeding of the Second European Semantic Web Conference (ESWC 2005), Heraklion, Crete, Greece, May 29 - June 1, 2005, Lecture Notes in Computer Science, 3532, 1–16, 2005. 30. Keller, U., Lara, R., Lausen, H., Polleres, A., Predoiu, L., Toma, I.: D10 WSMX Discovery. Technical report, 2005. 31. Kerrigan, M.: The WSML Editor Plug-in to the Web Services Modeling Toolkit. In Proceedings of 2nd WSMO Implementation Workshop (WIW2005), Innsbruck, Austria, 2005. 32. Kifer, M., Lausen, G., Wu, J.: Logical foundations of object-oriented and frame-based languages. In Journal of ACM, 42, 741–843, 1995. 33. Li, L., Horrocks, I.: A software framework for matchmaking based on semantic Web technology. In International Journal of Electronic Commerce, 8(4), 39–60, 2004. 34. Lima, F., Schwabe, D.: Application Modeling for the Semantic Web. In 1st Latin American Web Congress (LA-WEB 2003), Empowering Our Web, 10-12 November 2003, Santiago, Chile, 93–102. IEEE Computer Society, 2003. 35. Manolescu, I., Brambilla, M., Ceri, S., Comai, S., Fraternali, P.: Model-Driven Design and Deployment of Service-Enabled Web Applications. In ACM TOIT, 5 (3), 439–479, 2005. 36. Martin, D. L., Paolucci, M., McIlraith, S. A., Burstein, M. H., McDermott, D.V., McGuinness, D. L., Parsia, B., Payne, T.R., Sabou, M., Solanki, M., Srinivasan, N., Sycara, K. P.: Bringing Semantics to Web Services: The OWL-S Approach. In Cardoso, J., Sheth, A. P., editors, Proceedings of the First International Workshop on Semantic Web Services and Web Process Composition (SWSWPC 2004), San Diego, CA, USA, July 6, 2004, 26–42, 2004. 37. MultimediaN N9C Eculture project, 2006. http://e-culture.multimedian.nl/ 38. OMG: MDA Guide v1.0.1, June 2003. Available at: http://www.omg.org/docs/omg/03-06-01.pdf 39. OMG: Ontology Definition Metamodel, June 2006. Available at: http://www.omg.org/docs/ad/06-05-01.pdf 40. Paolucci, M., Kawamura, T., Payne, T.R., Sycara, K.P.: Semantic matching of Web services capabilities. In The Semantic Web, Proceedings of the First International Semantic Web Conference (ISWC 2002), Sardinia, Italy, June 9-12, 2002, Lecture Notes in Computer Science, 2342, Springer, 333–347, 2002. 41. Roman, D., Keller, U., Lausen, H., de Bruijn, J., Lara, R., Stollberg, M., Polleres, A., Feier, C., Bussler, C., Fensel, D.: Web Service Modeling Ontology. Applied Ontology, 1(1): 77–106, 2005. 42. Schwabe, D. and Rossi, G. The Object-Oriented Hypermedia Design Model. In Communications of the ACM, 38 (8), 45– 46, 1995. 43. Scicluna, J., Polleres, A., Roman, D., Fensel, D.: Ontology-based Choreography and Orchestration of WSMO Services, February 2006. Available at: http://www.wsmo.org/TR/d14/v0.2/

M. Brambilla et al.

40

44. Sheth, A. , Verma, K., Miller, J., Rajasekaran, P.: Enhancing Web Service Descriptions using WSDL-S. In ResearchIndustry Technology Exchange at EclipseCon 2005, Burlingame, CA, Feb. 28 - Mar. 3, 2005. 45. Torres, V., Pelechano, V., Pastor, O.: Building Semantic Web Services Based on a Model Driven Web Engineering Method. In Advances in Conceptual Modeling - Theory and Practice, ER 2006 Workshops, Proceedings, Tucson, AZ, USA, November 6-9, 2006, , Lecture Notes in Computer Science, 4231, 173–182, 2006. 46. Trastour, D., Bartolini, C., Gonzalez-Castillo, J.: A semantic Web approach to service description for matchmaking of services. In Proceedings of The first Semantic Web Working Symposium (SWWS01), Stanford University, California, USA, July 30 - August 1, 2001, 447–461, 2001. 47. Universal description discovery and integration (UDDI), 2001. http://www.uddi.org 48. Vdovjak, R., Frasincar, F., Houben, G. J., Barna, P.: Engineering Semantic Web Information Systems in Hera. J. Web Eng., 2(1-2):3–26, 2003. 49. Web Models: Webratio, 2007. http://www.webratio.com 50. WfMC: Workflow Process Definition Interface - XML Process Definition Language (XPDL), October 2005. Available at: http://www.wfmc.org/standards/docs/TC-1025_xpdl_2_2005-10-03.pdf