Model-based Discovery of Web Services Jan Hendrik Hausmann, Reiko Heckel, Marc Lohmann Department of Computer Science University of Paderborn Germany hausmannreiko
[email protected] Abstract Web Services are software components that can be discovered and employed at runtime using the Internet. Conflicting requirements towards the nature of these services can be identified. From a business perspective, Web Services promise to enable the formation of ad-hoc cooperation’s on a global scale. From a technical perspective, a high degree of standardization and rigorous specifications are required to enable the automated integration of Web Services. A suitable technology for Web Services has to mediate these needs for flexibility and stability. In this paper, a new approach to the description of Web Service semantics is introduced. It is a visual approach based on the use of software models and graph transformations and allows for the description of innovative services while providing a precise matching concept. An implementation using current standards and tools is available.
1. Introduction The global connection of computers by the Internet has made a huge impact on the life of many people. It is now possible to gather information on almost every conceivable subject by just using the WWW. Additionally, the advances in eCommerce have also made it possible to request services by the same medium, e.g. booking flights, buying books and making payments. Yet, most of these tasks require (sometimes rather complex) interactions with a human user. The vision of Web Services is to make these (and other kinds of) services available to machines. This means that programs should be able to locate and invoke needed services dynamically at runtime over the Internet. Web Services follow therefore the Service Oriented Architecture (SOA), which defines the roles of Provider, Requestor, and central discovery services. Providers advertise their offered Web Services by publishing descriptions on a discovery service. When clients (requestors) are looking for a specific kind of ser-
vice, they query this discovery service and receive a list of suitable services. After selecting the best of these services, the client is able to use the Web Service directly by contacting the provider. Economically, this scenario integrates B2B and B2C eCommerce solutions on a global scale: basic services like authentication, payments, and shipping can be obtained from suitable service providers and be combined into innovative and attractive product offers to customers. Technologically, the scenario presents many problems typical for distributed component-based computing. From these two aspects of Web Services, requirements toward a suitable technology can be identified: One of the central characteristics of electronic commerce is its highly dynamic nature. New companies might spring up overnight (and close down just as fast) and new kinds of services can be introduced with a very low overhead (as compared to traditional markets). The Web Service technology must reflect this. This concern especially the discovery process as it must be able to cope with such a continuously evolving market. Flexibility is the ability to match offers to requests in a way that satisfies both parties, but is not restricted to a simple identity function. Providers might describe their services in a specialized way while clients might formulate their requests in a more general fashion to get many competing offers. In any case the discovery process must be dependable in that it finds all offers that match the request and that all returned results are adequate to the request. From the technical viewpoint, ease of use is an issue. On the one hand, it is clear that Web Services need to be independent from the implementation technologies used by the requestor and the provider. On the other hand, one should also keep in mind that Web Services are not a standalone product but that they require a tight integration with the surrounding software and the technologies used to implement it. This does especially mean that developers (of service requesting as well as service providing software) need to understand about the connections between the Web Service parts and the rest of their application. Current technologies and research approaches do not
meet (all of) these criteria (see Sect. 2 for a discussion). We do thus propose an innovative approach to the definition of Web Services which is based on models (Sect. 3). By employing visual notations known to software developers (UML diagrams [18]) it integrates easily with the development of systems on requestor as well as on provider side. How this integration can be achieved employing existing standards and tools is shown in Sect. 5. By using graph transformations as the underlying mechanism of our approach, we have a well-known formal basis, which allows for precise formulation of matching concepts while retaining an intuitive interpretation. In combination with the concept of ontologies, graph transformations provide the required flexibility in describing the semantics of innovative services and allow for a reliable matching process (as described in Sect. 4).
2. Existing Standards and Scientific Approaches This section will provide an overview of today’s standards concerning Web Services. Scientific approaches to enhance these standards are evaluated in Sect. 2.2.
2.1. Web Service Standards The vision of SOA is that an application can use Web Services as support for its processing. The application can discover Web Services and invoke them at runtime fully automated to achieve a specified result. Recent efforts around WSDL and UDDI try to enable this discovery and invocation process. The Web Service Description Language (WSDL) [5] is an XML format for describing the interfaces offered by a Web Service as a collection of operations. For each operation its input and output parameters are described. This description can be registered at a UDDI server. UDDI (Universal Description Discovery and Integration) [23] is an industrial initiative whose aim is to create a registry for businesses and Web Services they offer along with keywords for categorization and search facilities. If we consider the discovery process enabled by these standards, we note that these standards are not sufficient to enable the vision of SOA. E.g., it is not possible to formulate a request that allows a discovery service to find a proper service provider automatically. For it, it would be essential that the service provider and the service requestor use the same vocabulary for the description of a service and the request for a service. Furthermore, if the service requestor gets some results from the discovery service, it is unclear which service and how a service can be invoked. Nowadays, these problems are solved by integrating a developer in the discovery process during the development of an application.
Tools like WebSphere Studio [10] allow to browse the services offered at a discovery service. The developer can decide by categorization, additional descriptions and mainly by human intuition which service he wants to use. Then, WebSphere Studio can e.g. automatically generate a Java proxy from the WSDL file offered for the selected Web Service. The developer can use this proxy during the development. At runtime, the application can only try to execute the selected service by using this proxy. If the service is not available, e.g. due to network problems, the program cannot even automatically discover identical replacement services. This is quite far from the idea of dynamically discovering adequate services. Different proposals that employ semantic web technologies for service descriptions try to approach the problems mentioned above. OWL (Web Ontology Language) [7] and DAML+OIL [6] are the first step towards the creation of semantic web enabled Web Services. They enable the creation of ontologies for any domain and the instantiation of these ontologies for the description of specific Web Sites or Web Services. A problem is that they concentrate on the description of static information and do not facilitate the description of services executed by a Web Service except that standardized services are part of an ontology. This contradicts the demand of a flexible description of innovative Web Services in the dynamic nature of eBusiness. OWL-S (formerly DAML-S) [22] is based on OWL and provides an ontology markup language to represent capabilities and properties of Web Services. Its goals are to achieve automatic Web Service discovery, invocation, composition, and execution monitoring. OWL-S allows describing the functionality of a Web Service by their input, output parameters, and additionally by external conditions that must be true for the execution of the service (pre-conditions) and side effects of the execution of a Web Service (effects). The usage of pre-conditions and effects allows describing the semantic of a Web Services, but as long as every pre-condition and effect has to be pre-defined in an ontology OWL-S is not flexible enough for supporting innovative services.
2.2. Related Work The problem of describing Web Services in a way to enable their truly dynamic discovery at runtime has been the focus of a number of scientific publications. In [15] a semantic markup of Web Services based on DAML is proposed, which allows for the definition of special kinds of services in an ontology. The ontologies used in the examples are very specific, up to containing special product information (e.g. there is a term buyLufthansaTicket in an ontology relating to air travel business). While the paper shows how this detailed information may be employed to select suit-
able Web Services according to complex strategies, encoding this information in an ontology contradicts the dynamic nature of the eBusiness. Every time a new brand would be introduced or an old one disappeared (e.g. by renaming) the ontology would have to be changed accordingly. Since changing an ontology is a process of (international) agreement, it may take a lot of time. Additionally applications using the ontology have to be adapted for using the changed ontology. Because of this agreement and adaptation process, ontologies often contain only very common terms to ensure a broad applicability. In [8] e.g. classifications based on type of service (tangible/intangible) or industry branches are proposed. This is clearly not detailed enough to actually distinguish specific services. Trying to describe a service with a single term also ignores the operational nature of Web Services. When executing a Web Service one expects certain changes, i.e. the real world is altered in some significant way (e.g., an order is created, a payment made or an appointment is fixed). The description of Web Services should reflect this functional nature, e.g. by providing a semantic description in the form of pre- and post-conditions (a style of description also known from contract-based programming [16]). This kind of semantic description can be found in [19, 21]. The pre- and post-conditions are once again expressed in terms of specialized ontologies. While [19] shows the matching only for single input and output concepts, [21] combines a number of predefined terms to express the pre- and post-conditions (e.g. CardCharged-TicketBookedReadyforPickup). Using this style of description it is possible to distinguish between rather similar services (e.g. booking a ticket, which is sent to the customer vs. booking a ticket, which he has to pick up) without coining special phrases for each in the ontology. While this combination of terms points in the right direction, we believe that this concept should be taken one-step further to building structures over the terms of an ontology. From the examples provided in the above mentioned papers it can also be seen that the XML encoding of these concepts becomes quite lengthy and is hardly suitable for human consumption. In the following section, we will thus introduce a novel approach to the description of Web Services that is visual and that allows for flexible and detailed descriptions.
ware engineers are faced with the task of integrating the Web Service technology with the rest of the system. For a provider this means to decide which of the operations in the application is suitable to be published as a Web Service interface. Then one has to translate this interface into the descriptions of WSDL. If the service has a complex structure (i.e. it possibly consists of a sequence of operation calls) it is necessary to encode this in a BPEL4WS specification. A layer that enables the translation of SOAP based communications into method invocations has to be provided and a UDDI server must be used to publish the descriptions. If ontologies are to be used, some dialect of the DAML or OWL languages needs to be employed, too. Not only is this a vast body of different languages and technologies that is being employed, but these languages often encode similar information in different ways. Without suitable support for planning, implementing, testing and documenting this part of the system, it is highly doubtful whether the Web Service part of a system will be reliable and consistent with the rest of the application (and almost more important: whether it will stay that way during the next changes to the system). From the requestor’s view, additional problems arise from the need for an automated comparison of offers and an automated integration of an offered service (i.e. constructing necessary input data and interpreting results). The usage of models is a significant step toward the solution of these problems. Models provide an abstraction from the detailed problems of the implementation technology and allow the developer to focus on the more abstract tasks. Especially the diagrams of the industry standard UML (Unified Modeling Language) have become very successful and are now an established part of a system’s development. With the advent of the Model Driven Architecture [17] models become even more crucial to software development, as implementation artifacts can automatically be generated from the models, thus saving time and guaranteeing consistency. Extending the modeling support to the development of Web Services would have several advantages:
3. Modeling the Semantics of Web Services with Ontologies and Graph Transformation Rules
• Models are visual. Structures (like ontologies) can be understood much more intuitively if they are presented in a visual manner (as compared to pages of XML code). UML class diagram representation of ontologies can be easily translated into machine-readable representations like DAML+OIL or OWL [2]. It is even possible to present mappings between different representations of the same information visually [12].
3.1. The case for models Web Services are not a stand-alone technology. They rather provide interfaces to either publish or request certain functionalities of a complex software system. Thus, soft-
• Models are independent of the target language(s). It is thus possible to derive the different specifications consistently from one source. The actual WSDL files could be re-generated every time a change affected the Web Service model.
• Models are becoming more important and a number
of tools for using models in the development of software are available. Basing the integration of Web Services on this standard does allow reusing existing information and tools, thus integrating the development of Web Services in the development of the surrounding software. Due to these reasons, we chose a technique that is highly compatible with the modeling of UML.
3.2. Combining Ontologies and Graph Transformation Rules An ideal technology for Web Services should - according to the requirements in Sect. 1 - be both flexible and reliable. These requirements are conflicting. To actually be sure that an offered Web Service fulfills a given request, a comparison of request and description is necessary. This implicates that requestor and provider share a common language to communicate. Ontologies are such standardized collections of conceptualizations [9] and can thus form such a language. But as already stated in Sect. 2.2, ontologies resist change. As they are often the product of an (international) agreement, it is hard work to create them and changes are not easily facilitated by applications using an ontology. This greatly hinders the dynamic nature of eBusiness and its supporting Web Services.
the buyer and his credit card and will effect a new order for the specified book and a bill to be created for this customer. The link between the object CreditCard and Bill denotes that the bill is payed by credit card after the execution of the service. The detailed meaning of an object or a link between two objects is described by the ontology, where the structural information within a class diagram is detailed by additional textual information describing the meaning of the elements within the class diagram if necessary. Using this mechanism it becomes easy to describe all kinds of different services in this area. One might e.g. formulate descriptions for Services, which add items to existing orders or delete items or which offer books without any payment information. As real ontologies are vastly bigger than the small example presented here, many services can be described by constructing this kind of description. ccp : CreditCard ccp : CreditCard pay by
op : Order
bp : Book
dap : DeliveryAdress
bp : Book
bip : Bill
dap : DeliveryAdress
Figure 2. Provider Rule Order
Bill 1
1 1
1
payBy 1
Payment
1
1 *
DeliveryAdress
Book
BankAccount
CreditCard
Figure 1. Ontology for a bookselling
We therefore developed a technique, which is based on ontologies but uses the mechanism of Graph Transformation Rules to allow for the flexible formulation of new services. Before we introduce the technical details let us look at an example. Fig. 1 provides a small sample ontology for bookselling. It provides the basic terminology and is depicted as a UML class diagram. A generalization relationship indicates that CreditCard and BankAccount are specializations of the basic concept Payment. If a vendor now wants to express that his service is able to handle orders for books which are payable by credit card, he can formulate the rule in Fig. 2. The rule expresses that the Web Service needs data on a book to order, the delivery address of
Formally, a Graph Transformation Rule consists of two graphs (left and right hand side), which are in our case visualized by using UML object diagrams. Each of the graphs is typed over the ontology. Refer to [20] for the technical details. The basic intuition is that every object or link, which is only present in the right hand side of the rule, is newly created and every object or link, which is present only in the left hand side of the rule, is being deleted. Objects or links which are present on both sides are unaffected by the rule. If only one object of a type exists, it can remain anonymous, if a distinction between different objects of one type is necessary, then they carry names, separated from their type by a colon. If an even closer resemblance to standard UML concepts is called for, it is also possible to encode Graph Transformations in UML Collaboration Diagrams [14]. Graph Transformation Rules can serve as both: a description of an offered service and as the formulation of a request. From a providers point of view the left hand side of the rule specifies the pre-condition of his service, i.e. the situation that must be present or the information that must be available for the service to perform its task. The right hand side of the rule depicts the post-condition, i.e. it characterizes the situation after the successful execution of the Web Service. From a requestors point of view the left hand side
ccr1 : CreditCard
ccr1 : CreditCard
or1 : Order
br1 : Book
dar1 : DeliveryAdress
br1 : Book
dar1 : DeliveryAdress
Figure 3. Requestor Rule 1
of the rule represents the information he is willing to provide to the service and the right hand side of the rule represents the situation he wants to achieve by using the service. Such a rule from a requestors point of view can be found in Fig. 3. This rule expresses that the client is able to provide information on a book, a credit card, and his delivery address and is looking for a provider, which is able to construct an order for him based on these information. This means he is looking for a book-seller and intuitively the provider rule from Fig. 2 should be a suitable candidate for this request, because in this rule a order is created (for more examples of this matching concept see [11]). The next section provide in-depth information on the formalization of this “intuitive” matching concept.
4. Matching Service Descriptions and Requirements As with any software, the motivation for implementing a Web Service is to satisfy some demand, formally expressed in a requirements specification. What is more specific (albeit not new if we consider component-based systems) is that, often, the desired functionality is not entirely implemented by the service alone, but in part provided by other services, not necessarily known at design time. When a service R (the requestor) finds and binds dynamically to a service P (the provider), R has to be sure that P provides its functionality in a way that is consistent with the assumptions about the required services made in R’s implementation. These assumptions are expressed in the requestor rule r. The discovery service compares r to the available provider rules p which represent descriptions of actually implemented services. The desired result is the set of those provider rules, whose services fulfill the requirements expressed in r. In this section, we give a formal explanation of what it means that rule p fulfills the requirements of rule r, or briefly, that p matches r. We also give an operational interpretation of this statement and discuss its consequences and benefits for the testing of Web Services.
4.1. Specification Matching The assumptions made in R about P are captured in the requestor rule r : L r → Rr . Its left-hand side L r declares the objects and links whose existence is guaranteed by R when the service is invoked. For example, in the requestor rule of Fig. 3 these are the objects ccr1:CreditCard, br1:Book, dar1:DeliveryAddress. Note that object identities in rules act like logic variable names: if consistently substituted, the meaning does not change. The effects that R hopes to achieve by means of the invocation of a service are deduced by comparing r’s left- and right-hand side: objects and links in L r \ Rr are meant to be deleted, objects and links in R r \ Lr are meant to be newly created, while objects and links in the intersection L r ∩ Rr are meant to be preserved, when they are present. In our example rule, no deletion is specified, so the objects on the left are also part of the intersection, but an object or1:Order with two links should be created. The provider rule p : L p → Rp has a slightly different interpretation. It requires the existence of all objects and links in Lp as a pre-condition and guarantees as effect the creation of Rp \ Lp , the deletion of L p \ Rp , and the preservation of L p ∩Rp . That means for the provider rule of Fig. 2, objects ccp:CreditCard, bp:Book, dap:DeliveryAddress are required, it is guaranteed that these are preserved and that, moreover, objects op:Order, bip:Bill and four links are created. Matching provider and requestor now means to compare the guarantees given by either side to the assumptions of the other: the requestor’s pre-condition must entail the provider’s pre-condition and the provider’s effects must entail the requestor’s effects. Considering our sample rules, this is easily seen to be the case. Formally, it results in the following definition: A provider rule p : L p → Rp matches a requestor rule r : Lr → Rr if there exists a structure-compatible partial one-to-one correspondence h ⊆ L p ∪ Rp × Lr ∪ Rr such that 1. ∀x ∈ Lp ∃y ∈ Lr : x h y, i.e., everything in L p must have a correspondence in L r ; 2. ∀y ∈ Lr \ Rr ∃x ∈ Lp \ Rp : x h y, i.e., everything in Lr meant to be deleted by r, must correspond via h to an item that is indeed deleted by p; 3. ∀y ∈ Lr ∩Rr ∃x ∈ Lp ∪Rp : x h y =⇒ x ∈ Lp ∩Rp , i.e., everything in L p corresponding via h to an item meant to be preserved by r, must indeed be preserved by p; 4. ∀y ∈ Rr \ Lr ∃x ∈ Rp \ Lp : x h y, i.e., everything in Rr meant to be created by r, must correspond via h to an item that is indeed created by p;
The partial correspondence represents a renaming relation h ⊆ Lp ∪ Rp × Lr ∪ Rr , i.e., a set of pairs (x, y) relating elements of its source x ∈ L p ∪Rp to elements of its target y ∈ Lr ∪ Rr . Related objects and links must be of compatible type, and related links must have related source and target objects. Partiality means that not all objects and links of the source or target have to occur in the relation, while by one-to-one we mean that every object or link can occur at most once. Renaming is necessary because, as in our example, items occurring in provider and requestor rules may have different identities that are, however, not of interest as long as the structure is the same. Let us apply this definition to the rule in Fig. 2 for p and Fig. 3 for r. In order to satisfy 1, the correspondence has to include the pairs {(ccp, ccr1), (bp, br1), (dap, dar1)} ⊆ h1 , whose corresponding elements are of the same type. Item 2 requires an inclusion of the deleted elements of r into those of p, which is trivial because these sets are empty for both rules. For the same reason, intersections L r ∩Rr = Lr and Lp ∩ Rp = Lp are, in fact, isomorphic via h. Finally, 4 requires that all elements created in r (i.e., the object or1:Order with its two (anonymous) links) are in correspondence with elements created in p. Thus, the relation h1 must be extended to include the pair (op, or1) as well as the links from or1 and their corresponding ones from op. btr2 : BankAccount
ccr2 : CreditCard
btr2 : BankAccount
ccr2 : CreditCard
or2 : Order
br2 : Book
dar2 : DeliveryAdress
br2 : Book
with elements of the same kind in p, while in 3 elements that are in correspondence must be of the same kind. Thus, objects that are in L r ∩ Rr (required to be preserved by the requestor) are optional in the sense that they need not be present in the provider, but if they are they must not be deleted.
4.2. Operational Interpretation Specification matching provides us with a static check for the interoperability of provider and requestor, assuming that the respective rules faithfully reflect the needs and provisions of the implementations of provider and requestor. Their relation is represented in Fig. 5 from an operational point of view. The picture shows the invocation of P by R, as well as P ’s reply, together with the relevant preconditions and effects.
Requestor (R) preR
effectR
call
return
preP
effectP
Provider (P) Figure 5. Operational interpretation
dar2 : DeliveryAdress
Figure 4. Requestor Rule 2
The situation is a little more subtle if we consider the requestor rule in Fig. 4. The correspondence h2 = {(ccp, ccr2), (bp, br2), (dap, dar2)} satisfies requirement 1. Notice that the new object btr2:BankAccount in Lr is not part of the correspondence, because this data is not assumed by the provider. However, it is included in the requestor rule to make it as flexible as possible, thus returning more matches. The sets of deleted and created elements are similar to the first rule, but as the elements required to be preserved by the requestor we have btr2, ccr2, br2, dar2 in the intersection L r ∩ Rr . The set of elements of p corresponding to these via h 2 is ccp, bp, dap, and these are indeed preserved, as required by item 3 above. This explains the difference with items 2 and 4, where elements of the respective kind in r must be in correspondence
1. When the call is issued, R guarantees that its precondition L r holds. 2. P can assume its pre-condition L p , which is entailed by Lr , and thus call its operation. 3. P guarantees the effects specified in its rule p. 4. R may assume the effects specified by its rule r, which are entailed by p. Thus, we essentially save with each invocation the checks for 2 and 4, which are provided by the matching. This not only saves time, but more importantly, the effort for the handling of errors should these checks fail. However, in order to make sure that the service implemented by R with the help of P works as expected, we have to verify that the guarantees given in 1 and 3 are indeed implemented, and that the assumptions derived from 2 and 4 are indeed sufficient to ensure the correct function of P and R. This is not a problem of matching specifications, but one of establishing the correctness of the implementations of P and R w.r.t. these specifications.
Using the terminology of testing, specification matching can replace integration testing, where the correct interaction of services is analyzed, but not unit testing where the correctness of individual services w.r.t. their requirements and assumptions is checked [13].
5. A Prototypical Tool Chain In the following, we want to describe a prototypical tool chain developed at our research group. Its objective is to allow visual editing of service descriptions and requests (cf. Sect. 3) and to demonstrate our matching concept (Sect. 4) by using available semantic Web languages and tools. We use AGG (The Attributed Graph Grammar System) [1] to model pre- and post-conditions by graph transformation rules, typed over a type graph. In our case, the type graph serves as an abstract representation of a UML class diagram [3] respectively an ontology. This allows us to specify service descriptions and requirements over a given ontology as described in Sect. 3. In the current implementation, we use DAML+OIL as RDF-file format for representing the ontology of a specific domain. For using AGG, we have implemented a Javabased tool Daml2Agg that translates a DAML+OIL ontology into a type graph represented by the file format of AGG. With AGG we are able to create graph transformation rules typed over this ontology visually. For translating a graph transformation rule back to a common textual semantic Web language we have implemented a second tool Agg2Daml. As a result, we get a DAML+OIL representation of a graph transformation rule consisting of a pre- and post-condition. The DAML+OIL presentation for ontologies, pre-, and post-conditions is based on RDF graphs. Thus, the matching of rules can be described in terms of the matching of RDF graphs. We have implemented a matching algorithm in Java based on the open source semantic Web toolkit Jena [4]. Especially, we use the RDQL (a query language for RDF) implementation of Jena. It provides a way of specifying a graph pattern that is matched against a graph to yield a set of matches. Given graph transformation rules for provider P and requestor R, for computing a matching in Jena, we have to realize the four items of Sect. 4.1 by the testing of subgraph relations. First, our algorithm composes a RDQL query from the pre-condition of P that is executed against the pre-condition of R to test if the requestor’s pre-condition entails the provider’s pre-condition. Second, our algorithm computes the effects of both P and R by comparing their pre- and post-conditions. Finally, our algorithm composes a RDQL query from the effects of R, executing it against the effects of P to test if the provider’s effects entail the requestor’s effects. If both RDQL queries have been successful (the graph pattern specified by a RDQL query could be
embedded in the target graph), we have found a valid matching.
6. Conclusion and Future Work In this paper, we have provided a novel approach to the specification of Web Service semantics, which combines formal rigor with an intuitive visual representation. Initial experiences with the approach indicate directions for future research. Graph transformation rules as used in this paper do only capture information about structural changes, disregarding vertex attributes of pre-defined data types, like strings, natural numbers, etc. Further, the theory of graph transformation provides concepts like negative pre-conditions, optional, or set-valued objects in rules, etc. to enhance the expressiveness and flexibility of rule-based specifications. However, such extensions would require a new, more sophisticated notion of matching.
References [1] AGG, The Attributed Graph Grammar System: An Interpreter for Attributed Graph Transformation with Integration of Java Programs, 2003. http://tfs.cs. tu-berlin.de/agg/index.html. [2] K. Baclawski, M. K. Kokar, P. A. Kogut, L. Hart, J. Smith, W. S. H. III, J. Letkowski, and M. L. Aronson. Extending UML to support ontology engineering for the semantic web. In M. Gogolla and C. Kobryn, editors, UML 2001, LNCS. Springer-Verlag, 2001. [3] Baresi and Heckel. Tutorial introduction to graph transformation: A software engineering perspective. In International Conference on Graph Transformation, ICGT, LNCS, volume 1, 2002. http://wwwcs.upb.de/cs/ ag-engels/ag_engl/People/Heckel/talks/ Agtive2003%Tutorial/. [4] J. J. Carroll, I. Dickinson, C. Dollin, D. Reynolds, A. Seaborne, and K. Wilkinson. Jena: Implementing the semantic web recommendations. Technical Report HPL-2003146, Hewlett Packard Laboratories, Dec. 24 2003. [5] R. Chinnici, M. Gudgin, J.-J. Moreau, J. Schlimmer, and S. Weerawarana. Web services description language (WSDL) version 2.0 part 1: Core language. W3C working draft, W3C, March 2004. http://www.w3.org/TR/ wsdl20/. [6] D. Connolly, F. van Harmelen, I. Horrocks, D. L. McGuinness, P. F. Patel-Schneider, and L. A. Stein. DAML+OIL (March 2001) reference description. W3C note, W3C, Mar. 2001. http://www.w3.org/TR/daml+ oil-reference. [7] M. Dean, G. Schreiber, F. van Harmelen, J. Hendler, I. Horrocks, D. L. McGuinness, P. F. Patel-Schneider, and L. A. Stein. OWL web ontology language reference. W3C working draft, W3C, Mar. 2003. http://www.w3.org/TR/ 2003/WD-owl-ref-20030331/.
[8] M. Dumas, J. O’Sullivan, M. Heravizadeh, D. Edmond, and A. Hofstede. Towards a semantic framework for service description. In Proc. of the IFIP Conference on Database Semantics. Kluwer Academic Publishers, April 2001. [9] D. Fensel and C. Bussler. The web service modeling framework. Technical report, Vrije Universiteit Amsterdam (VU), January 2002. http://www.csd.uch.gr/˜hy565/ Papers/wsmf.pdf. [10] G. Flurry. Web Services Development and Deployment with WebSphere V5 Tools and Technologies – Part 2: Publishing and Finding a Web Service in a UDDI Registry, 2003. http://www7b.software.ibm.com/ wsdd/library/techarticles/0302\_flurry/ fl%urry2.html. [11] J. H. Hausmann, R. Heckel, and M. Lohmann. Towards automatic selection of web services using graph transformation rules. In R. Tolksdorf and R. Eckstein, editors, Berliner XML Tage. XML-Clearinghouse, 2003. [12] J. H. Hausmann and S. Kent. Visualizing model mappings in UML. In S. Diehl, J. T. Stasko, and S. N. Spencer, editors, Proceedings ACM 2003 Symposium on Software Visualization (SOFTVIS), San Diego, California, USA, June 11-13, 2003, pages 169–178. ACM, 2003. [13] R. Heckel and M. Lohmann. Towards contract-based testing of web services. In International Workshop on Test and Analysis of Component Based Systems (TACoS) 2004, 2004. [14] R. Heckel and S. Sauer. Strengthening UML collaboration diagrams by state transformations. In H. Hussmann, editor, Proc. of 4th International Conference on the Fundamental Approaches to Software Engineering (FASE 2001), volume 2029 of LNCS, pages 109–123. Springer, April 2001. [15] S. McIlraith, T. C. Son, and H. Zeng. Semantic web services. IEEE Intelligent Systems. Special Issue on the Semantic Web, 16(2):46–53, March/April 2001. [16] B. Meyer. Object-Oriented Software Construction. Prentice-Hall, Englewood Cliffs, NJ 07632, USA, second edition, 1997. [17] Object Management Group. Model driven architecture, 2001. http://www.omg.org/mda. [18] Object Management Group. UML specification version 1.5, March 2003. http://www.omg.org/docs/formal/ 03-03-01.pdf. [19] M. Paolucci, T. Kawmura, T. Payne, and K. Sycara. Semantic matching of web services capabilities. In First Int. Semantic Web Conf., 2002. [20] G. Rozenberg, editor. Handbook of Graph Grammars and Computing by Graph Transformation, Volume 1: Foundations. World Scientific, 1997. [21] K. Sivashanmugam, K. Verma, A. Sheth, and J. Miller. Adding semantics to web services standards. In Proceedings of the 1st International Conference on Web Services (ICWS’03), 2003. [22] The OWL Services Coalition. OWL-S specification version 1.0, November 2003. http://www.daml.org/ services/. [23] UDDI Consortium. UDDI Technical White Paper, Sept. 2000. http://www.uddi.org/pubs/Iru\_UDDI\ _Technical\_White\_Paper.PDF.
