Structural Matching Algorithm

The ARIS software tools support the WSDL standard version 1.1 [WSD01]. The content of the WSDL file is represented in the ARIS modelling language using UML diagrams. For example, a WSDL porttype is mapped to an “UML interface” and the belonging operations to “UML operations”. XSD files can be imported in the same way. The content of those files is also represented using UML models. Those UML models are not meant to be used by business experts. Therefore, an abstraction is introduced by using software service types and software service operation types. Also, a business expert is not expected to deal with XSD data definitions. These data definitions are mapped to a logical data model, which consists of the object types “technical term”, “cluster”, “entity type” or “class”. The mapping between the different abstraction levels is established by relating the UML objects to the more abstract object types in different model types. The structural matching algorithm uses this mapping information to discover services by navigating from the logical data constructs used in the business process model to the technical constructs provided by

Function Business Object Business Object Business Object Business Object

…

…

operation parameters (Input/Output) Extract matching operation for

each matched parameter (Input/Output)

Operation Operation

Operation Operation Get owning service

for each operation

1

2

3

4

5

input and output services

6

Figure 4.3: Structural service matching algorithm

the web service. The structural matching algorithm does not work if the mapping is not provided by the user. Establishing this mapping is the task of creating an information architecture1_.

The structural matching algorithm for discovering software service types works as fol- lows: First, it extracts all business objects (i. e. either technical terms, clusters, entity types or classes) modelled as input and output of the function (see step 1 in figure4.3). After this first step, there are two sets, one containing all business objects required as input and the other one containing all business objects required as output. For each of those two sets, the algorithm navigates through the data mapping to identify all message types. Implementing this navigation is not trivial, because the ARIS modelling language allows arbitrary abstraction levels between business object and message type including cyclic dependencies. For example, the business object customer used in a business process is further decomposed into an address. This address can be represented using different message types. The algorithm has to identify all message types mapped to the business object. This is illustrated between step 1 and 2 in figure4.3. After this step, there are two sets of message types, one containing message types required as input and one contain- ing message types required as output. In step 3, the algorithm checks to which operation parameters those message types belong and if the parameters have the same direction as the message types (i. e. input or output). Extracting this information is possible, because the complete WSDL content is available in the ARIS software tools and mapped to UML 1_{Other terms used for such an initiative are shared business vocabulary, business taxonomy or data archi-}

models. If the message type is the type of a parameter with the correct direction, the al- gorithm extracts the belonging operation as shown in step 4. Afterwards, the web service owning the operation is extracted in step 5. At the end, there are two sets of web services: one set supporting all input business objects and the other set containing all web services supporting the output business objects. In the final step 6, both result sets are intersected. The final result set of the structural matching algorithm contains only those web services, which are part of both preliminary result sets and are therefore able to support all input as well as all output business objects. The ARIS modelling language requires that each web service is mapped to exactly one software service type. Therefore, in a final step (not shown in the figure), the software service types implemented by the discovered web services are extracted.

The algorithm does not check that a web service has at least one operation able to support all business objects in the parameter list. While automating business processes, this is considered to be no problem, because during transformation of a business process into an executable process model (e. g. BPEL), a function can be split up into several technical steps. Also, adding another operation to a web service able to handle all business objects in one request is often possible if the web service is owned by the company.

It can be seen that the structural matching algorithm is quite complex in case software service types must be discovered. The complexity is reduced while discovering service types. Service types also use business objects in their description. Therefore, no mapping between different abstraction levels is needed. In addition, service types do not have operations with input and output parameters.

The biggest disadvantage of the structural matching algorithm is the effort required for mapping business objects to technical data structures. Often, users of the ARIS modelling method already invested in creating a comprehensive information architecture consisting of the most important business objects. However, mapping those business objects to technical data structures requires effort. Each customer must decide if this investment can be justified. As an alternative, a more lightweight algorithm is provided, requiring less effort. The algorithm is described in the following section.