Article Preview
TopIntroduction
At the hour of fusions, reorganizations of companies, Information Systems (IS) must have the capacity to take into account these economic constraints. What results is a need for flexibility, adaptability, opening and even for interoperability between remote and/or heterogeneous IS, i.e. based on different technical bases. Interoperability supposes that the applications are able to be located, to be identified, to expose the functionalities (services) which they offer, and finally, to exchange data. The Web services arise today as the most suitable solution in order to connect remote IS, eventually heterogeneous ones.
Indeed, Service Oriented Architectures Services (SOA), initially based on the components and their capacity to communicate through their interfaces, quickly showed their limits in terms of weak coupling (necessary to meet the needs for flexibility and adaptability) and of interoperability. The Web services bring these properties to the SOA which were precisely lacking with the component based architectures. The Web services lie on standards for the information exchange as well as on protocols for their transport.
Web services are “self contained, self-describing modular applications that can be published, located, and invoked across the Web” (Tidwell, 2000). They are based on a set of independent open platform standards to reach a high level of acceptance. Web services framework is divided into three areas - communication protocol, service description, and service discovery - and specifications are being developed for each one: the “Simple Object Access Protocol” (SOAP) (Gudgin, 2000), which enables communication among Web Services, the “Universal Description, Discovery and Integration” (UDDI) (Bellwood, 2002), which is a registry of Web Services descriptions and the “Web Services Description Language” (WSDL) (Christensen, 2001), which provides a formal, computer-readable description of Web services. The latter describes such software components by an interface listing the collection of operations that are network accessible through standard XML messaging. This description contains all information that an application needs to invoke such as the message structure, the response structure and some binding information like the transport protocol, the port address, etc.
However, simple operation invocation is not sufficient for some kind of composite services. They also require a long-running interaction derived by an explicit process model. This kind of services may often be encountered in two cases. First, when a Web service is developed as an agent, it is composed of a set of accessible operations and a process model which schedules the invocation to a correct use of the service. Secondly, facing to the capability limits of Web services, composite services may be obtained by aggregating existing Web services in order to create more sophisticated services (and this in a recursive way).
In order to deal with the behavioural aspects of complex services, some industrial and academic specifications languages have been introduced. Among them, Business Process Execution Language for Web Services (BPEL4WS or more succinctly BPEL) has been proposed by leading actors of industry (BEA, IBM, and Microsoft) and has quickly become a standard (Alves, 2007). BPEL supports two different types of business processes (Juric, 2005). (i) Executable processes specify the exact details of business processes. They can be executed by an orchestration engine. (ii) Abstract business protocols specify the public message exchange between the client and the service. They do not include the internal details of process flows but are required in order, for the client, to correctly interact with the service.