Service-oriented computing [10] aims at replacing large monolithic systems by a composition of services. By abstracting from underlying technologies and implementations, it is possible to focus on the functionality of a service and to reuse it in other compositions. Consequently, services can be designed independently from the compositions they are used in, which in turn allows for faster production cycles at lower costs. A downside of this flexibility is the possible incompatibility of independently designed services. To avoid the redesign of incompatible services, an adapter (sometimes called mediator) can resolve incompatibilities by manipulating the communication protocol between the incompatible services. State-of-the-art techniques [1,2,3,5,9,4,11,6] allow to generate adapters automatically given a set of domain-specific message transformation rules.
So far, the design of such transformation rules was out of scope of most existing adapter generation approaches, and of course transformation rules can be formulated independently of a concrete service composition. However, it is likely that the design of such rules can be accelerated if the services to be adapted is taken into account. This paper follows this idea and presents an approach to iteratively create proposals for the designer of semantic message transformation rules. These proposals are derived by diagnosing behavioral incompatibilities. The approach is complete; that is, if services can be adapted using some rule set, then this set can be constructed.
The rest of this paper is organized as follows. The next section briefly sketches the automatic generation of adapters and introduces a running example. It further discusses how transformation rule proposals can be derived from diagnosed incompatibilities. Section 3 presents the main contribution of this paper, a Webbased graphical user interface for the iterative construction of transformation rules. Finally, Sect. 4 discusses possible future extensions and concludes the paper.
We shall briefly outline the basic concepts of an adapter generation algorithm and its meaning for finding transformation rules in this section.
For adapting two services A and B several approaches agree on using message transformation rules (creating, removing, or changing messages) [1,2,3,5,9,4,11,6], which handle semantical incompatibilities.
We concentrate on the approach of Gierds et al. [6], consisting of two: They model transformation rules as an artifact called engine E. Then they try to synthesize a controller C, such that the composition of A, B, E, and C behaves according to a certain correctness criterion (e. g., deadlock freedom). The composition of E and C thus yields an adapter for A and B and ensures semantical and behavioral correctness of the two services. The engine E implements the message transformation rules and thus ensures semantically correctness. The controller C ensures correct behavior; that is, the correct order of applying rules and sending messages to the services.
Figure 2 shows a small example based on open nets [7], an extension of classical Petri nets. Interface places are positioned on the dashed border of a net. As running example, the model of a beverage vending machine is depicted on the left (cf. Fig. 2(a)). After receiving a Euro (MEuro), either the tea (MTeaButton) or the coffee button (MCoffeeButton) must be pressed. Afterward the appropriate beverage is delivered (MServedTea and MServedCoffee, resp.). On the right (2(c)), a coffee drinker provides a Euro (DEuro), then forgets to press a button, and waits for its coffee (DServedCoffee). Obviously, this service is not compatible to the vending machine. To overcome this incompatibility, the adapter in Fig. 2(b) simply transforms a DEuro message to an MEuro message and MServedCoffee to DServedCoffee, which seems obvious concerning the names. Further it creates a MCoffeeButton message. Due to structural reduction, we may identify the controller part only by the initially marked places, allowing each rule to be applied exactly once.
To synthesize such an adapter automatically, the before-mentioned three rules must be provided as input to the synthesis algorithm.
As mentioned, one of the essential parts of the adapter approach is the set of message transformation rules. Although correct in isolation (in the example, there exist compatible drinker and vending machine services, resp.), two services may only be adaptable if a certain set of rules is provided. So whenever the synthesis algorithm fails to create an adapter, this is caused by missing rules.
Previous approaches almost totally rely on Semantic Web technologies for providing rules. We will briefly sketch an idea on how to extend the set of transformation rules by behavioral diagnosis. During controller synthesis deadlocks will be reached if no deadlock free controller exists. These deadlocks provide valuable information, how an additional rule might look like. The setting does not allow to change one of the services, but we are free to add as many new rules as we like. Let m be a deadlock marking, then we can analyze which messages remain in the engine, thus are pending and could be transformed. Further we check whether one of the services could continue if we provided a certain message, so we check which messages are required. A new rule then may transform pending into required messages. Consequently, m will no longer be a deadlock marking, because we can apply the newly added transformation rule now (which behaves like a transition added to a net, which is enabled by the pending messages). This step can be repeated until we find a controller and therefore an adapter, or until we are no longer able to add meaningful transformation rules.
For our example in Fig. 2, starting with an empty set of transformation rules, our proposed algorithm will state that DEuro is pending (in Fig. 2(c) the appropriate transition is activated and thus fired), MEuro is required, and thus we may add the rule transforming MEuro to DEuro. In the next step (as shown in Fig. 3) we will see, that MTeaButton and MCoffeeButton are required. After providing a corresponding rule, we will see, that MServedCoffee is pending, and DServedCoffee is required. Finally the rule set is sufficient and we gain an adapter for our example.
In the given example the single steps are straightforward. For more complex examples, the number of deadlocks as well as the number of details for each deadlock grows significantly. Thus we need a good representation for this kind of information.
Interactive approaches highly benefit from a concise way of presenting information. A user must be able to quickly access all relevant information. Graphical solutions with means to highlight or hide information based on a user's demands clearly excel console applications in this point. Marlene as single purpose tool has already been integrated into service-technology.org/live [8], which is our platform to demonstrate the functionality of our tools and allow a user to perform more complex tasks involving several of our tools by simply using a Web browser. The previously described interactive approach has also been integrated there and can be tested at the URL http://service-technology.org/live/marlene.
In an interactive approach, we do not only need to present the input and output artifacts, but also intermediate information which shall enable the user to make a next step. In our case, we have to list all possible suggestions for adding new transformation rules without showing all details at once and thus confusing the user.
Figure 3 shows the essential part for our approach: an editing field for transformation rules and below a table with information on all deadlocks, which may help in providing additional rules. Additionally, but not depicted here, the services are visualized. We divide the table in the following columns:
type might either be deadlock or a livelock (in case we want an adapter ensuring also livelock freedom); the pending messages, which can be used in a rule on the left side; the required messages, of which at least one must be provided for resolving a deadlock in one of the services the triangle button, for showing additional information on a deadlock or livelock The additional information might state, that one of the services is already in a final state thus needing no further attention, and which rules have been applied prior to reaching a certain deadlock.
We have decided to initially show only the first line for each deadlock (the line starting with deadlock, thus hiding all additional information at first). As we can see in Fig. 3, providing all available information on a deadlock in a clear way requires a lot of space. Presenting a larger number of deadlock then would almost immediately require the user to scroll the page. This would clearly hamper deciding which deadlock to resolve, because a direct comparison of deadlocks would always depend on scrolling.
In our understanding, pending and required messages are the most important information for a certain deadlock. Thus showing only this piece of information should be sufficient in most case. By clicking the triangle at the end of a line the user gets additional information as described above.
The user is frfee to add and change the rules arbitrarily in the text field. By clicking Save Rules the page is updated and information based on the new rule set are provided. Finally, if a sufficient set of rules was added, the generated adapter is presented.
We have presented a first idea for the interactive retrieval of transformation rules in the setting of service adaptation. We have also focused on an appropriate visualization of information. First tests indicate that interaction as described here with the proposed degree of initial information offers easy access to the approach. This of course is only a first step.
First, the algorithm for finding new transformation rules has to be described in detail and we have to proof its feasibility in adapter generation (i. e., that when an adapter exists, the algorithm leads to a corresponding set of rules). Second, we have to evaluate acceptance of the Web site. Only feedback of real users playing through real-word examples will give us valuable hints on how to improve presentation of our tool.
Especially the order of different deadlocks might facilitate decision, which one to resolve -the higher the position of a deadlock, the more likely it will be considered. Here we have to find heuristics based on user behavior and its reason to prefer certain deadlocks. Also highlighting certain situations (e. g., both services are already in a final state, but superfluous messages must be removed) might help a user to pick more goal leading deadlocks.
Although not having finished the approach, yet, using a Web front-end for our prototype allows us to test our approach from the very beginning and distribute it easily, thus gaining valuable feedback from prospective users.