Nowadays there exist hundred of modeling tools for applications development. Most of them implement the standard de-facto modeling language UML, but they do not directly support the composition of web services which is one of the predominant activities in service oriented architectures.

Using UML modeling diagrams in new processes within software development has the advantage that users are already acquainted with the notation. Additionally, they may be employed in the integration of inter-enterprise applications in order to solve dynamic requirements via web services composition. Because of this, tools that implement UML diagrams must evolve to support web services composition processes. This paper describes a system for web services composition using UML activity diagrams. The interface for modeling composition of web services is set on a software developer side as the client for a web service.

A parser based on a visual grammar that evaluates the construction of the activity diagrams was separated from the interface and it was wrapped as a web service. From the interface, developers model and execute the composition of web services. It is done by mapping composition models (activity diagrams) into basic BPEL4WS constructs which are in turn input to an execution engine.

The idea of having tools like the one described in this paper is to generate a view of a software development tool like a polymorphic entity. If one day a developer requires modeling activity diagrams he can do it. If the next day the developer requires modeling composition of web services, workflows; he can do it and son on, without having a centralized installation. Figure 1 describes the idea of having software development tools implemented as web services.

Some works [2, 3, and 4] are mainly focused on the extension of UML activity diagrams notation via stereotypes. They do not show how they implement the composition of web services. In [5], IBM describes how WebSphere and Rational Software Architect collaborate to convert process models into UML activity diagrams through an eclipse shell, from there; the web services composition is not addressed.

Two other groups of related works were identified. One group based the composition process on workflows. [6] Proposed a method for guiding a composition process using activity diagrams. [7 and 8] employed a dynamic composition strategy based on flow diagrams and produced a system to perform the composition process. In [9] the authors also developed a system for dynamic composition using workflows.

The other group looks at composition like planning by artificial intelligence. In [10], the authors presented a system that realizes composition using rules to represent services and to express preconditions and pos conditions. In [11], the author use declarative composition with state charts, the product is a system.

Also uses declarative composition with Petri nets; the main product of this work is an algebraic model. [13] Realizes composition by program synthesis, same as [2], this work delivers a composition method. The main disadvantage of composition based on artificial intelligence planning is that users must know the language employed to specify the characteristics of the composite web service; they are usually represented by rules, sentences and/or preconditions and posconditions.

The advantage of visual notations like the one used in the first group and this work is that users are usually acquainted with this type of notations particularly the ones from UML. Also this work is different from the others in that the interface is separated from the grammar that evaluates the construction of the diagrams. This is a step towards the view of software as services as some researchers have proposed [14].