Toward UML-Compliant Semantic Web Services Development

Towards a UML-Compliant Semantic Web Services Development Diana M. Sánchez, César J. Acuña, José María Cavero, Esperanza Marcos Kybele Research Group Rey Juan Carlos University C/Tulipán S/N, 28933, Móstoles, Spain {diana.sanchez, cesar.acuna, josemaria.cavero, esperanza.marcos}@urjc.es

Abstract. The coming of the semantic web and, in particular, the coming of the semantic web services (SWS) technology demands the inclusion of new components in the applications involving semantic web services. So, web development methodologies must be tailored to support the systematic development of such new components. In previous works we have presented an UML profile, which extends the SOD-M method for service oriented Web Information System development of the MIDAS model-driven framework, to address the development of Semantic Web Services using WSMO (Web Service Modeling Ontology). The UML profile allows for the modeling of the new elements required by WSMO Web Services. This paper focuses on study the possibility of improving the proposed UML profile, including the OCL (Object Constraints Language) for the representation of WSMO logical axioms, through three case studies. This way the developers’ whose knowledge does not extend beyond UML must be able to develop applications that use semantic web services. Keywords: Semantic Web Services, UML Profile, OCL, MDA, SOD-M, MIDAS

1. Introduction Many different web development methodologies have arisen to address different aspects of web application development since the web appeared. These methodologies were later adapted to catch up the web applications evolution. As for example, with the coming of web technologies like web services, existing methodologies were modified to include, for example, new models for WSDL document generation [7], new models for services composition, etc. The Semantic Web Services (SWS) expand the capabilities of a web service by associating a semantic description of the service in order to enable automatic search, discovery, selection, composition, and integration [4]. The coming of the semantic web services technology demands the inclusion of new components in the applications involving them. Nevertheless, current web development methodologies in the state-of-the-art do not include specific techniques or models to develop the new elements required at the time to build SWS-based

applications. In general, SWS should be included in web application development methodologies for several reasons, but especially for the following two: (a) to enable the systematic development of new required components and (b) to promote the widespread adoption of SWS. Unfortunately, for the average software developer, the learning curve for semantically rich languages, used to semantically describe SWS, can be steep. This fact provides a barrier to adoption and widespread use [5]. To be widely adopted by users and to succeed in real-world applications, SWS development must catch up with mainstream software trends, as for example, the Model Driven Architecture [9]. Taking into account the above reasons, in [1] we have presented, through a case study, an UML profile for the modeling of the new element required by SWS-based applications. Such profile was developed as an extension of the SOD-M (Service Oriented Development Method) [3] included in the MIDAS framework. MIDAS is an MDA framework for the service-oriented WIS development. The motivation for that work has been the lack of specific techniques and methodological approaches to develop the SWS. Moreover, if we take into account that we propose to develop SWS in the frame of and MDA framework, the SWS development profit from the advantages of the MDA proposal. The motivation strengthen if we take into account that research in SWS area is now being promoted by several research projects where several companies are involved, we think that SWS has many chances to be adopted in web based applications in the short term. Then, it will be necessary to have specific techniques to develop SWS as the presented in this paper. The first version of the SWS UML profile allows the modeling of SWS based on the WSMO (Web Services Modeling Ontology) proposal [6]. In WSMO, a SWS description requires to define four basic components: ontologies, semantic web services, goals and mediators. So, the profile contains at PSM level four models, one per each WSMO modeling element. Starting from the UML models defined to model the SWS and generating the corresponding XMI [16] description, the WSML description of each element of WSMO could be generated through the implementation of mappings rules. The UML profile allows modeling the four main elements required by the WSMO proposal for the SWS description. Nevertheless the WSMO axioms were modeled by means of UML notes and using WSML code directly on the models. In this work we focus in the improvement of the UML profile with the aim of make the semantic web services development fully UML-compliant. So, we propose to complete the profile by using the Object Constraint Language (OCL) [10] for the representation of the WSMO axioms. Note that the OCL is language familiar for the average software developer. We analyze three case studies where have tried to convert a axiom, expressed in WSML, using OCL expressions. The rest of the paper is structured as follows: section 2 defines some previous concepts required in order to set up the context of this work. The section 3 presents in detail the three case studies and the section 4 sums up the main conclusions and future research.

2. Previous Concepts This section introduces some previous concepts required in order to frame this work. The Section 2.1 briefly describes SOD-M, a method for the service oriented development of Web Information System. Section 2.2 describes WSMO, which is the proposal we have adopted for SWS description and the Section 2.3 partially present the UML profile for the SWS modeling. 2.1 SOD-M: A Service Oriented Development Method SOD-M is a method for the service oriented development of WIS. It follows a service oriented approach for the modeling and development of SIW. SOD-M provides a set of business and behavior models in different level of abstraction and it a set of mapping rules to navigate between different levels of abstraction. That way, starting from the high level business modeling, SOD-M allows obtaining specific models for different services technologies, as for example, web services. The work presented in [1] and its improvement presented in this work intends to extend the SOD-M for the inclusion of the SWS technology. SOD-M is part of the MIDAS framework, which is a MDA framework for WIS development. SOD-M is focus on the behavior aspect of the MIDAS framework, but MIDAS also takes into account other aspects of the WIS modeling [2], [8], [13]. 2.2 WSMO: Web Service Modeling Ontology WSMO Submission is a semantic web services description proposal submitted to the W3C by the DERI 1. WSMO is ontology for describing various aspects related to SWS. The conceptual grounding of WSMO [6] defines four main components: − Ontologies: are the key to linking conceptual real-world semantics defined and agreed upon by communities of users. − Goals: Goals are representations of an objective for which fulfillment is sought through the execution of a Web service. − Web Services: WSMO Web service descriptions consist of functional, nonfunctional and the behavioral aspects of a Web service. A Web service is a computational entity which is able (by invocation) to achieve a user’s objective. A service, in contrast, is the actual value provided by this invocation. − Mediators: describe elements that overcome interoperability problems between different WSMO elements. Mediators are the core concept to resolve incompatibilities on the data, process and protocol level, i.e. in order to resolve mismatches between different terminologies used (data level), in how to communicate between Web services (protocol level) and on the level of combining Web services (and goals) (process level). Within the WSMO proposal, the Web Service Modeling Languaje (WSML) aims at providing means to formally describe all the elements defined in WSMO. More details about WSML are given in section 3.

1

Digital Enterprise Research Institute. http://www.deri.org

2.3 An UML profile for Semantic Web Service Modeling For the modeling of the SWS following the WSMO proposal, the UML profile includes four models, one model per each WSMO main element: Ontology Model, Web Service Model, Goal Model and Mediator Model. The figure 1 shows the relationship of such models with respect to the MDA four-layer metamodeling architecture. The Meta-Object Facility (MOF) [11] specification is used to specify the WSMO metamodel placed at the metamodel layer (M2). The metamodels of the four new models are placed at the same level. These metamodels refine the WSMO metamodel elements. The different metamodels allow representation, through the M1 models, of all WSMO elements, with their own particularities.

Fig. 1. Model architecture for WSMO elements modeling

In order to make use of graphical modeling capabilities of UML, each model has a corresponding UML Profile. These profiles support UML notation and enable graphical editing of WSMO elements using UML diagrams. For clarity reasons the UML profiles were not included in figure 1 but belong to the M2 level of the metamodeling architecture. The instances of the defined models, that is, the concrete ontologies, goals, Web services and mediators, are placed in level M0. From now on, as an example, we partially present the profile by introducing the Ontology Model, the idea is use this model in order to show how it can be improved using OCL. To model the WSMO ontologies we have decided to split its modeling in two related models: The ontology context model and the ontology content models. This separation is due to in WSML ontology definition, we can clearly distinguish contextual information of ontologies from content information.

Fig. 2. Ontology Context Meta-Model

The ontology context model, extends the UML package diagram and collects information about the context of the ontology, that is to say, information about namespaces, imported ontologies and used mediators. Figure 2 shows the Ontology context metamodel. The ontology content model represents the different elements of the modeled ontology: classes, properties, instances, axioms, etc. The ontology content model extends the UML class diagram. The figure 3 shows the corresponding metamodel. 1

+So urceA ttrib ute

+targe tA ttri bute

1

+SourceAttribute

Att

+ownedEnd

Axiom

Class ( from Kernel )

1

-ofType [0..1 ] : String 1

«enumeration» AttFeatureType

Classifier ( from Kernel )

InverseOf

-AxiomDefinition [1 ] : String

1

AttValue 1

Concept

-hasValue [1..*] : String

+owningConcept

1

+ownedEnd

+targetConcept

*

1 + owningInstance

1

1

1 Instance

ImpliesType 1

1

Association (from Kernel )

1

1 Association (from Kernel )

Transitive InverseOf Symetric Reflexive

ElementInstance

- AttFeature [0..1 ] : AttFeatureType

InstanceRelation Relation -Parameter [1 ..*] : String

1

1 1

1

+belongs to

-Values [1..*] : String

MemberOf

Fig. 3. Ontology Content Meta-Model

In the ontology content meta-model the axioms were originally represented by UML class stereotyped with with the axiom definition as a tagged value of type string (see the dotted area in the figure 3). The axiom definition typically includes a portion of WSML code representing the axiom. In order to fill this tagged value for each axiom definition, the developer still needs to know about WSML in order to write the axiom definition, this is preciselly the aspect we will try to solve in this work by using OCL to represent the axioms.

3. Using OCL to Represent WSMO Axioms The aim of this section is to analyze if it is possible to complete the UML Profile (briefly introduced in section 2.3 and presented in [1]) by adding OCL as way to represent axioms. It is important remind to the reader that this profile is intended to be used for people who are familiarized with the UML and want to use it to represent SWS. Using this profile, with the improvements discussed here, the developers’ whose knowledge does not extend beyond UML should be able to develop applications that use semantic web services. The axioms in the frame of the WSMO proposal are written in WSML [14], and they are used to specify a logic expression which helps to formalize one or several features of SWSs. WSML is a formal language created following the WSMO proposal in order to define a syntax that allow define ontologies and web services. WMSL has been developed taking as starting point three logical formalisms: Description Logics, First-Order Logic and Logic Programming; however this language has four variants. Each variant is based or extends a specific part of those formalisms. For example, WSML-Core (the smallest version of WSML) is based on

the part of Description Logics (a part of First-Order Logic) that describe types. The remaining versions of WSML extend the language from First-Order Logic or Logic Programming according to the desired level of expressiveness [14]. Axioms represent constraints which act over SWS elements and which must be satisfied. Axioms provide completeness to the SWS model and, in the scope of WSMO, they are typically used for: a) to restrict an attribute into a concept, b) to define or restrict the extension of a concept, c) to extend relations and define functions and d) to define preconditions, postconditions, assumptions and effects of a web service capability. So, our proposal is obtain a good and easy way to represent these axioms. WSML is a formal young language which is developing now. While, the developers need concrete solutions that allow them create SWS. Therefore, the main requirement to choose how to represent axioms is to be able to represent everything that can be represented using WSML. The Object Constraint Language (OCL) has been created to complete and provide with more expressivity to UML models. Expressions written with OCL are used to specify invariant conditions that must hold for the system being modeled or queries over objects described in a model [10]. Since OCL belongs to the UML family, OCL is quite easy to read and write. So, people without strong mathematical o logical background are able to write constraints in OCL easier than in other formal logic languages. OCL is useful in the following cases: a) as a query language, b) to specify invariants on classes and types, c) to specify type invariant for Stereotypes, d) to describe pre- and post conditions on operations and methods, e) to specify target (sets) for messages and actions, f) to specify constraints on operations, g) to specify derivation rules for attributes for any expression over a UML model. The OCL is based on First-Order Logic and Set Theory. Therefore both languages, OCL and WSML, are linked each other through First-Order Logic. Both have similar notations and are based on the same part of First-Order Logic to define theirs main elements: concepts in WSML and sets in the case of OCL. If we compare the different uses listed for the axioms in WSMO and for OCL in UML we find some equivalence among them, so it is possible to think that OCL is a suitable manner to express axioms in our profile. However, in order to check the suitability of OCL to express all aspects that could be expressed in WSML, we propose analyze some case studies. These case studies have been chosen taking into account the different uses given to the axioms in WSMO. So, three WSML codes are going to be taken, studied and we will try to convert to OCL code. These case studies will help us to know if it is possible to use OCL to represent WSML axioms. 3.1 Case studies The following case studies have been classified according to the role and the function of an axiom in the Ontology Model: axioms that define or restrict a concept, axioms that specify a relation or function between concepts and axioms that define capabilities. The starting point for each case study is a WSML code where an axiom is declared. Next, the UML Profile presented in section 2.3 is applied to represent the concepts and attributes. Finally we translate the axioms expressed in WSML to OCL, preserving their meaning. Case studies were obtained from WSMO Primer [15], a

document written by WMSL creators that presents WSMO and some examples about this proposal. We chose these examples because we consider the book as a reliable source for WSML examples. Each case study is introduced by a brief explanation of the case and of the axiom. Then, the WSML code and its translation into OCL are shown. Case 1: Axioms that define or restrict a concept. Here, the axiom is used to explicitly express the meaning of a concept. This case represents a concept called tripFromAustria which is a sub-concept of trip concept. The trip concept is composed of four attributes: origin and destination, which type is location, and arrival and departure, which type is date. The location type is defined in an external ontology which is referenced by loc expression. Here, the way to specify the features that describe the new concept is through an axiom that specifies particular conditions of concept. The WSML code and its conversion to OCL code is shown in Figure 4. concept trip origin impliesType loc#location destination impliesType loc#location departure ofType _date arrival ofType _date concept tripFromAustria subConceptOf trip nonFunctionalProperties dc#relation hasValue tripFromAustriaDef endNonFunctionalProperties axiom tripFromAustriaDef definedBy forall {?x ,?origin} (?x memberOf tripFromAustria implies ? x[origin hasValue ?origin] and ?origin[loc#locatedIn hasValue loc#austria ] The subconcept is defined into axiom, and axiom code is written separately forall : Express a rule that must be true for any X member of the concept tripFromAustria

origin

destination

arrival

departure

trip



tripFromAustriaDef

tripFromAustria

context tripFromAustria inv: origin = "A ustria"

The OCL code must be associated to an element of the model and an Axiom element. The code is written by means of a note inv: express a condition that must be true into its context (in this case tripFromAustria )

Fig. 4. An axiom that specifies a new concept.

Case 2: Axioms that specify a relation or a function. In this case, the logical expression contained in the axiom expresses a relation. A relation describes interrelation between a set of parameters while a function is a special kind of relation where one parameter returns the result of a function [15]. The example presents the relation validCreditCard that is applied on the credit card concept. A credit card is considered valid until its expiry date. In this case, the OCL code is not associated to an element, but an element. The WSMO proposal defines relations in terms of logical expressions, so a relation is a kind of axiom that describes interrelation between a set of parameters. WSML allows two ways to write the code of a relation: a) inside definition of a relation or b) in an axiom defined out of relation definition but that is associated to the relation. In this case the axiom is defined out of relation. The WSML code and its equivalence in our profile using OCL are shown in figure 5.

Fig. 5. An axiom that is used to specify a relation

Case 3: Axioms that define capabilities Another use of axioms is to define capabilities. Capabilities describe the functionality of SWS in terms of preconditions, postconditions, assumptions and effects [15]. This case shows the capability to book a ticket where all parts of a capability are showed. In WSML, the first part of a capability is definition of variables, the second part specifies preconditions, then assumptions and finally postconditions. In this case we analyze each part separately. At the end of the case we show all parts together. The first part of capability shows the definition of five variables; these variables are used in the precondition part to validate the integrity of information as it is shown in the description tag of the WSML code: capability BookTicketCapability sharedVariables { ?creditCard, ?initialBalance, ?trip, ?reservationHolder, ?ticket} precondition definedBy ?reservationRequest [reservationItem hasValue ?trip, reservationHolder hasValue ?reservationHolder ] memberOf tr#reservationRequest and ?trip memberOf tr#tripFromAustria and ?creditCard [balance hasValue ?initialBalance] memberOf po#creditCard.

This WSML code shows that three attributes of the concept reservationRequest and one attribute of the concept creditCard must have a valid value. In OCL, the initialization of a variable is done by an init expression and the specification of a set of preconditions is done using the pre expression. Here, the preconditions cover the validation of valid values for some attributes. Next is presented an equivalent OCL code to represent this precondition: context r: reservation::bookTicket(iB:Integer, rH:String, t: trip, k: ticket) init: self.reservationRequest.reservationItem = t init: self.reservationRequest.reservationHolder= rH init: self.creditCard.balance = iB; pre: c.balance ''” and t '' and rH ''

Following the WSML code the next section is the assumption part, in which it is specified the conditions that must be true and must be known before starting the

execution of the capability. In this example, the credit card presented by a requester must be one of two possible cards: assumption definedBy po#validCreditCard(?creditCard) and ( ?creditCard[type hasValue "PlasticBuy"] or ?creditCard[type hasValue "GoldenCard"]).

Like in cases 1 and 2, a condition that must be true can be written in OCL using an inv (invariant) expression. So, this assumption can be re-written in OCL as: inv: self.creditCard.validCreditCard() and (self.creditCard.type = 'PlasticBuy' or self.creditCard.c.type = 'GoldenCard')

The next parts of the WSML code are the postcondition and effect parts. Postconditions part shows the result of the execution of the SWS. In our case, postconditions tell us that a reservation has correct information and a reservation holder is created. The effect is that the price of a ticket is deducted from the credit card. The WSML code for postcondition and effect parts are presented next: postcondition definedBy ?reservation memberOf tr#reservation [ reservationItem hasValue ?ticket, reservationHolder hasValue ?reservationHolder] and ?ticket[trip hasValue ?trip] memberOf tr#ticket. effect definedBy ticketPrice(?ticket, "euro", ?ticketPrice) and ?finalBalance= (?initialBalance - ?ticketPrice) and ?creditCard[po#balance hasValue ?finalBalance ] .

Postconditions are expressed in OCL using the post expression. This block must always be at the end of the code. On the other hand, the effect block describes actions that change the state of some elements, so it is possible to group these actions in a body block in OCL. So, taking into account that the order of blocks must be changed for language specifications, this code could be re-written in OCL as follows: body: c.initialBalance = c.initialBalance - tk.ticketPrice post:self.reservationItem = k and self.reservationHolder = rH and self.ticket.trip = t

Figure 6 shows a complete draw about how this capability can be represented in our profile. Left side shows general parts of WSML code to specify the capability; however dots of each section can be replaced to the WSML code presented in this case, respectively. Right side shows the representation of the capability using our profile. As in case 2, the OCL code is not associated to an element specifically. Instead of, this code is associated to precondition, assumption, postcondition and effect elements because in WSML all axioms that define this elements are written into each one.

Fig. 6. Axioms to specify the capability of a SWS

Taking into account that the previous case studies represent the common uses of axioms into WSMO, we can conclude that there is a wide set of cases where we can use OCL to define axioms according to WSMO proposal without lose expressivity and maintain the semantics of the restriction.

4. Conclusions and Future Works The SWS technology demands the inclusion of new components in the applications involving semantic web services. So, web development methodologies must be tailored to support the systematic development of such new components. In previous works we have presented an UML profile, which extends the SOD-M of the MIDAS model-driven framework to address the development of Semantic Web Services using WSMO (Web Service Modeling Ontology). The UML profile allows for the modeling of the new elements required by WSMO Web Services. In this paper we have focused on the study of OCL as tool to refine such UML profile in order to represent the axiom definition using a language closer to the developers than the WSML. As part of UML family, we consider that OCL is a good choice to represent those logical expressions. The usage of OCL for the representation of WSMO axioms has been validated through several case studies where three of them were discussed in this paper. The selected case studies represent different uses of the axioms. For each case the conversion to OCL was possible in a straightforward way. As result of this study we have concluded that there is wide set of cases where is possible write the WMSO axioms using OCL and without know the WMSL rules. As future works we will try to build a correspondence between WSML and OCL, adding a formal study of the languages.

We also are working to integrate the UML profile for SWS development and the correspondences between OCL and WSML presented in this paper in M2DAT [12], an MDA tool that integrates all the techniques proposed in MIDAS for the semiautomatic generation of WIS.

Acknowledgement This work is partially financed by the Spanish Ministry of Education and Science under the project GOLD (TIN2005-0010), the Rey Juan Carlos University and the regional government of Madrid under the project FoMDAs (URJC-CM-2006-CET0387) and by the Spanish project "Agreement Technologies" (CONSOLIDER CSD2007-0022, INGENIO 2010)

References 1. Acuña C. and Marcos E. Modeling Semantic Web Services: A Case Study. Proceedings of the 6th International Conference on Web Engineering. ACM Press. Editores D. Wolber, Neil Calder, Chris Brooks and Athula Ginije. pp 32-39, USA, 2006 2. De Castro V., Marcos, E., Cáceres P., A User Service Oriented Method to Model Web Information Systems. X. Zhou et al. (Eds.): Web Information System Engineering 2004 (WISE 2004), LNCS 3306, pp. 41–52, 2004. 3. De Castro V., Marcos E. and López M. A model driven method for service composition modelling: a case study. International Journal of Web Engineering and Technology 2006 Vol. 2, No.4 pp. 335 – 353. 4. Fensel, D., Bussler, C.: The Web Service Modeling Framework WSMF. Electronic Commerce Research and Applications. 1(2). 2002 5. Gannon G. and Timm J. An MDA-based Approach for Facilitating Adoption of Semantic Web Service. In Proceedings of the IEEE EDOC Workshop on Model-Driven Semantic Web (MDSW 04), September 2004. 6. Lausen H, Polleres A. and Roman D. (Eds). Web Service Modeling Ontology Submission. Retrieved From: http://www.w3.org/Submission/WSMO/, 2005 7. Lausen H, de Brujin J, Polleres A, Fensel D. WSML - a Language Framework for Semantic Web Services. Position Paper for the W3C rules workshop, Washington DC, USA, April 2005. Retrieved from: http://www.w3.org/2004/12/rules-ws/paper/44/ 8. Marcos, E., Vela, B., Cavero, J.M.: Methodological Approach for Object-Relational Database Design using UML. Journal on Software and Systems Modeling (SoSyM). Springer-Verlag. France, R., Rumpe, B. (eds.). Volume SoSyM 2, pp.59-72, 2003. 9. Miller, J., Mukerji, J. (eds.). MDA (2001) ‘OMG Model Driven Architecture’, Document number ormsc/2001-07-01. Retrieved from: http://www.omg.com/mda. 10. OCL 2.0 Specification. Object Management http://www.omg.org/docs/ptc/05-06-06.pdf

Group

(OMG).

Retrieved

from

11. The Object Management Group: Meta-Object Facility, version 1.4. Retrieved from: http://omg.org/technology/documents/formal/mof.htm, 2002

12. Vara, J.M., De Castro, V. and Marcos, E. WSDL automatic generation from UML models in a MDA framework In International Journal of Web Services Practices. Volume 1 – Issue 1 & 2. November 2005, pp.1 – 12. 2005. 13. Vela, B., Acuña, C. and Marcos, E. A Model Driven Approach for XML Database Development, 23rd. International Conference on Conceptual Modeling (ER2004). LNCS 3288. Springer Verlag, pp. 780-794. 2004. 14. WSML Final Draft 5. DERI. http://www.wsmo.org/TR/d16/d16.1/v0.21/#sec:wsml-xml

Retrieved

from:

15. WSMO Primer. Retrieved from: http://www.wsmo.org/TR/d3/d3.1/v0.1/, 2005 16. XML

Metadata Interchange (XMI). Retrieved http://ww.omg.org/technology/documents/formal/xmi.htm, 2005

form: