Web services composition is one of the most prominent activities in service oriented software development. Composition means to build a composite web service with component web services [1]. The specification of the composition is done by modeling a low level business process and by defining the interactions among the web services involved in the process.
The construction of the system for modeling web services composition required to establish correspondences between the elements (services and interactions) that participate in the composition process, using BPEL4WS (BPEL) as intermediary. Since UML activity diagrams do not mean to model business processes, neither services composition. Figure 2 shows the collaboration among the interface that models the activity diagrams, the web service which implements the parser that evaluates the construction of the diagrams, the BPEL language and the execution engine. Figure 2 presents the service composition system.
The system architecture was realized in such a way that variants of the activity diagrams and their parsers are easily added. Among other elements of the service interface is a service locator that localizes web services in a UDDI. The search of the web services is not done directly on UDDI, but in a customized directory based on domain descriptions. Validation of the activity diagram by the service that contains the parser based on a visual grammar is done when a relationship is established among two elements.
Figure 3 shows the general use case diagram of the system. In figure 3, a software developer may use the system for three independent operations, to search and select web services, to model web services composition using activity diagrams and to generate BPEL from activity diagrams.
When a developer wants to build an activity diagram for services composition, a configuration of the web services roles and the variables involved in the composition is established, supported by a use case that performs the analysis of the WSDL files of the web services, and by a use case that supports the BPEL code generation mapping structures as shown in table 1.
BPEL elements
The set of elements from BPEL that need to be defined in order to execute a composition process must contain at least control structures capturing modeling decisions, partner links (web services) participating in the process, and the data needed for the process. The interface of the system for modeling activity diagrams supports the definition of the basic BPEL constructs for web services composition which are sequence, conditional and iterative structures. Table 1 shows how activity diagrams modeling control structures are mapped into the basic constructs of the BPEL language. It is an important description since it shows how the system resolves a composition process represented by an activity diagram.
The example shows sequence and conditional structures. After the model for composition is defined, partner links and variables are configured via interface. Partner links define partners (services) relationships using SOAP messages and Port types employed during the interactions of the partners in both directions. Figure 4 shows an interface that contains the icons to model activity diagrams and at the same time it allows a user to define activities with tags such as “assign”, “invoke”, “receive”, “reply” which are some of the basic constructs from BPEL. They allow the communication among the Web services.
A semantic study is currently underway in order to map other elements from BPEL such as fault and compensation handlers to some constructs of the activity diagrams. One possible solution is to adapt stereotype elements. Some important proposals about stereotypes have already been described by [2, 3, and 4]. The work in [2] is the only one that clearly describes the mapping among activity diagrams, stereotypes and BPEL labels. Figure 5 shows an example of creation of partner links and an example of the definition of the role each partner link plays. The role may be either provider or consumer requester.
Variables represent data used during a composition process. Figure 6 shows how to create a variable of a data type. Figure 7 shows how to select a variable or part of it from a variable tree of a process, so it may be employed in an “assign” activity. It also allows defining XPath expressions.
Once a composition model like the one in figure 4 is built, the system generates BPEL code to be input to an engine which performs the composition and returns the result to the client that modeled the activity diagram. For the purpose of testing, the execution engine from ORACLE (Oracle BPEL PM 10.1.2) free download version was employed.
