AOP for Dynamic Configuration and Management of Web Services

Transcription

1 International Journal of Web Services Research, 1(3), 25-41, July-Sept AOP for Dynamic Configuration and Management of Web Services Bart Verheecke, María Agustina Cibrán, Wim Vanderperren, Davy Suvée, and Viviane Jonckers Vrije Universiteit, Brussels ABSTRACT We observe that current approaches for the integration of Web services hard-wire the service references into client applications, affecting adaptability and reusability. Moreover, support for client-side management is hardly provided. To enable the development of more flexible and robust applications we propose the Web Services Management Layer (WSML). In this article we identify the requirements for the WSML to realize dynamic integration, client-side service management, and support for service criteria to govern the selection, integration and composition of Web services. We show how dynamic AOP, and in particular the dynamic aspectoriented language JAsCo, is ideally suited to implement the core functionality of the WSML. Keywords: aspect-oriented programming; dynamic configuration; hot-swapping; Web services; Web services management. INTRODUCTION Web services are modular applications that are described, published, localized and invoked over a network. In the relatively short time that Web services have been around, an impressive range of supporting tools has been developed that enable the creation and deployment of Web services and the development of service oriented applications. Large platforms such as Java ONE and Microsoft Visual Studio.NET provide the key technologies, built around W3C standards such as Simple Object Access Protocol (SOAP), Web Service Description Language (WSDL) and Universal Description, Discovery and Integration (UDDI), and allow publishing, looking up and consuming services in a straightforward manner. However, the approaches typically used to integrate services in client applications are very static and do not allow any dynamic adaptations of the services references. As stated by Malhotra (2001), this leads to unmanageable applications that cannot adapt to changes in the business environment (e.g., a service that is abandoned or changed, a new service that becomes available on the market, etc.). A second obstacle is that by generating hard-wired proxy classes at client

2 26 International Journal of Web Services Research, 1(3), 25-41, July-Sept 2004 side, the services are treated as regular software components. As such, the specific requirements of Web services are completely ignored. They are organizationally fragmentized, can be asynchronous and latent, can become unavailable due to unpredictable network conditions and thus require more overall management (Szyperski, 2001). To deal with these issues, code has to be written manually and repeated for each integrated service. As a result, management code results are duplicated and scattered all over the application, becoming an obstacle for future maintenance. A third limitation encountered is that services can only be selected based on the functionality they offer. The Web service documentation provided in WSDLformat does not support the explicit specification of non-functional requirements such as constraints based on Quality-of- Service and management concerns, classes of service, access rights, pricing information, SLAs (Service Level Agreements) and other contracts between Web services. Explicitly specifying these nonfunctional requirements at the service side in a precise and unambiguous way allows the composition and integration of services to occur in a more intelligent and customized manner. This way, applications are able to specify criteria to be considered at service selection time to integrate those services that best fit the application requirements. To overcome these limitations, we present the Web Services Management Layer (WSML), which is placed in between the application and the world of Web services. This intermediate layer allows dynamic selection and integration of services into an application, client-side service management, and support for service criteria based on non-functional properties that govern the selection, integration and composition. This article focuses on identifying the requirements for a technological platform to realize the WSML. We show how dynamic Aspect-Oriented Programming (AOP) (AOSD; ACM, 2001) is ideally suited to build the core functionality of this management layer. To deal with the dynamic nature of the service environment we use the dynamic aspect-oriented programming language JAsCo (Suvée et al., 2003; Vanderperren et al., 2003). In the next section we identify the requirements for the WSML and analyze how state-ofthe-art approaches fail in achieving them. In the rest of the article we explain the basic architecture of our solution and the objectives achieved, and we describe the need for AOP and why JAsCo is ideal to implement the core functionality of the WSML. Finally, we present related and future work and conclusions. REQUIREMENTS FOR WSML Web services constitute a promising middleware technology. However, we believe there are some important management issues that still need to be addressed. Today, the technology only provides standardized connection mechanisms. This might not be sufficient to drive its worldwide adoption. We identify the following challenges to be taken into account:

3 International Journal of Web Services Research, 1(3), 25-41, July-Sept Composition of Web services: The real strength of Web services lies in the concept of combining and orchestrating them in order to deliver added-value services. However, this leads to the question of how to dynamically (i.e., at runtime) integrate a service in the consuming application. How can the required service be found and plugged in? How can one deal with different services delivering similar functionality? How can compositions of services be made that were not anticipated at design time of the application? 2. Multi-Partner Processes: Consuming Web services means that processes of several business partners situated on different locations are being integrated with each other. This gives raise to significant management issues (e.g., organizational fragmentation of the application) and technical consequences (e.g., much longer processing times, security issues, AAA, etc.). 3. Dependencies: An application that integrates with external services becomes dependent on them. Failure of the services has a negative impact on the execution of the application. 4. Flexibility: Since the context of Web services is an ever-changing business environment, the application must be flexible enough to deal with changes in the functionality, displacement or use of Web services. The current approaches of how Web services are integrated in applications do not, or only partially, address these issues. In the Wrapper approach, each Web service is wrapped and treated as an internal software component (see Figure 1). Stateof-the-art tools like BEA WebLogic and MS Visual Studio.NET adopt this mechanism. The software developer enters a Web reference to the service into the tool. Then, the WSDL document of the service is automatically looked up, analyzed and code for a proxy class is generated. Programmers can invoke Web methods on this class just like on a regular class and do not have to take into account that they are actually dealing with remote procedure calls (RPCs). Clearly, the issues mentioned above are not addressed: (1) services are selected and integrated in a static manner at implementation time, (2) code that deals with managing multi-partner processes has to be written manually, needs to be duplicated for each service and as a result becomes scattered in different modules of the application code, (3) the application has to deal with the potential unavailability of services by manually including code that again makes results tangled and scattered, and (4) changes in the environment can only be dealt with by stopping and rewriting the application code. A more dynamic solution is provided when a tmodel (Microsoft, 2002) is used instead of a concrete service. In this approach, a service can be invoked to deliver the required functionality if it implements the overall system s tmodel specification. However, this approach only solves some of the identified issues: (1) only services that exactly implement the tmodel can be dynamically integrated, while services with other interfaces and service compositions delivering the same functionality cannot be straightforwardly included, and (2) management code still

4 28 International Journal of Web Services Research, 1(3), 25-41, July-Sept 2004 Figure 1: Wrapper Approach to Integrate Services needs to be written manually and remains scattered over the application code. Problem (3) is only partially addressed, as the dependency on a certain service is weakened because dynamic switching to other similar services can be achieved in a straightforward manner; however, this is only tackled to some degree since that code still needs to be written manually. Finally, (4) is addressed, as services that match a tmodel can be registered at runtime in a UDDI-register (Uddi.org, 2001) and can as such be included in the application without having to make any changes. As the above approaches do not satisfy all requirements, we propose an abstraction layer, called Web Services Management Layer (WSML), which is placed between the application and the world of Web services. Its basic architecture and objectives are introduced in the next section. DESIGN OF WSML The WSML allows decoupling Web services from the core application. It realizes the concept of just-in-time integration of services: multiple services or compositions of services can be used to provide the same functionality. The advantages of this approach are: The application becomes more flexible as it can continuously adapt to the changing business environment and communicate with new services that were not known or available at deployment time. Extracting all Web service related code from the core application facilitates future maintenance of the code. By weakening the link between the application and the service, hot swapping functionality can be installed. When a service becomes unreachable due to network conditions or service-related problems, this mechanism enables switching to other services. The hot-swapping mechanism can take into account specific application requirements. This way, selection policies specifying criteria based on non-functional requirements of services can be considered as part of the WSML and customized for each application, making the selection of services more advanced. Figure 2 shows the WSML as a layer between the application and the Web services. On the left-hand side the core application resides, requesting service functionality when needed. The WSML is responsible for intercepting these requests and choosing the most appropriate service or composition. The Selection Module realizes this by considering different service properties. To this end, collabo-

5 International Journal of Web Services Research, 1(3), 25-41, July-Sept Figure 2: General Architecture of the WSML ration with the Monitoring Module is required, as several properties of services need observation over time. Available services are looked up in a central UDDIregister or discovered using decentralized Web Services Inspection Language (WSIL) documents (Appnel, 2002). Generic functionality, necessary to provide support for multi-partner processes (e.g., to guarantee security, transactions, etc.) also resides in the layer, depending on specific application requirements. Examples of this generic management functionality are: Caching: To avoid slow response times, lost packages, congested networks, and reduce the network traffic, a caching mechanism can be considered. Instead of invoking the services each time the application requests particular service functionality, the results are retrieved from a cache. Billing: Services can specify their own billing strategies and the client application might want to control how billing is applied. Analogously, services might need to be billed as a requirement for the integration in a client application. Accounting: Many industries are required to provide tracing and logging capabilities for accounting as well as regulatory purposes. Security: Web services can use several security mechanisms (e.g., WS- Security) depending on the environment where they are deployed. Data sent over the network can be encrypted and user authentication and authorization might be required. Transaction: If the communication with a Web service is transaction based and if in the middle of a transaction the layer must switch to another service, some compensation or rollback mechanism needs to be used to restore the state of the service. In the next sections an AOP solution for the encapsulation of these concerns as part of the WSML is presented. In this context it is important to note that the WSML is reusable in different applications and is fully configurable to avoid unnecessary overhead. In the following sections we present the technical decisions made for the implementation of the WSML. AOP FOR WSML Motivation for AOP To achieve high flexibility in the selection of services, hard-wiring references to concrete services in the applications must be avoided. Using traditional software engineering methodologies it is the responsibility of the applications to decide which the most suitable service is for a given request or to explicitly request the

6 30 International Journal of Web Services Research, 1(3), 25-41, July-Sept 2004 layer to decide this. In both cases, code for either implementing or triggering the service selection is written at each point where some service functionality is required. As a consequence, selection code results are scattered in different places of the application and tangled with code that implements other concerns. Thus, we need support for encapsulating this crosscutting code and plugging it in and out in a noninvasive way. To achieve this we need to intercept the points in the execution of the application where concrete services are invoked. At those points, the WSML decides which concrete service or service composition is the most suitable. Moreover, the selection of services also involves other management issues to be considered at the moment the services are selected to be integrated in the applications. For instance, services might need to control security, accounting and billing concerns at the time their functionality is requested. This also results in crosscutting code since the application developer would need to include this management code each time a service is requested. In order to avoid tangling the application code with service related code we observe the need for Aspect-Oriented Programming (AOP). AOP argues that some concerns of a system, such as synchronization and logging, cannot be cleanly modularized using current software engineering methodologies, as they are scattered among different modules of the system. Due to this code duplication, it becomes very hard to add, edit and remove such a crosscutting concern in the system. The ultimate goal of AOP is to achieve a better separation of concerns. To this end, AOP approaches introduce a new concept to modularize crosscutting concerns, called an aspect. An aspect defines a set of join points in the target application where the normal execution is altered and describes the additional behavior that should be executed. Aspect weavers are used to weave the aspect logic into the target application. Using aspects to express the selection and management concerns as part of the WSML allows the application to remain independent of the service selection infrastructure. Moreover, we also pursue dynamism in the management of services, and therefore an AOP technology that provides support for dynamic inclusion and removal of aspects is required. To this end, an aspect-oriented implementation language called JAsCo (Suvée et al., 2003; Vanderperren et al., 2003) is used, whose features are ideal for achieving the identified requirements. JAsCo JAsCo is primarily based upon two existing AOP approaches: AspectJ (Kiczales et al., 2001) and aspectual components (Lieberherr et al., 1999). AspectJ s main advantage is the expressiveness of its language to describe the join points. However, AspectJ s aspects are not reusable, as the concrete context of an aspect is hard-coded. To overcome this problem, Lieberherr et al. introduce aspectual components. They claim that when using AOP one must be able to express each aspect separately, in terms of its own modular structure. Using this model, an aspect is described as a set of

7 International Journal of Web Services Research, 1(3), 25-41, July-Sept abstract join points that are resolved when an aspect is combined with the base modules of a software system. This way, the aspect behavior is kept separate from the base components, even at run time. JAsCo combines the expressive power of AspectJ with the aspect independency idea of aspectual components. The main contributions of JAsCo relevant to this research are: JAsCo aspect beans are described independent of a concrete context, making them highly reusable. JAsCo has extensive support for specifying aspect combinations. JAsCo allows easy attachment and removal of aspects at run time. The JAsCo language itself stays as close as possible to the regular Java syntax and it introduces two new concepts: Aspect Beans: An aspect bean is an extended version of the standard Java bean component that is able to contain several hooks that capture the crosscutting behavior. Hooks define when the normal execution of the system needs to be intercepted in an abstract way. In addition, hooks specify the extra behavior that needs to be executed at that moment in time. Connectors: A connector is responsible for connecting an aspect bean to a concrete context. Furthermore, expressive combination strategies and precedence strategies can be defined in order to manage the collaboration of several aspect beans and components. As such, a partial solution for the notorious feature interaction problem (Pulvermüller et al., 2001) is provided. On a technical level a new, backward compatible component model is introduced that enables the run-time application and removal of connectors. This high flexibility and configurability is exactly what is needed in the context of Web services. JAsCo s connectors are ideal to achieve the dynamic behavior of the WSML and to allow the runtime integration and management of services without requiring invasive changes to the core application. The next section shows code examples of how JAsCo connectors and aspect beans are used in the WSML. For more information about JAsCo and the JAsCo component model, we refer to Suvée et al. (2003) and Vanderperren et al. (2003). IMPLEMENTATION OF WSML Architecture of WSML Figure 3 illustrates the architecture of the WSML using aspect beans, implementing the generic functionality of the layer, and dynamic JAsCo connectors specifying when these need to be deployed. The left-hand side of the figure illustrates the application requesting Web service functionality. To make it possible for an application to make requests without referencing concrete services the service type concept is introduced. The righthand side shows three semantically equivalent services that are available to answer the request. A mechanism based on redirection aspect beans in the WSML allows for the redirection of requests and enables hot swapping. Additional management aspect beans deal

8 32 International Journal of Web Services Research, 1(3), 25-41, July-Sept 2004 Figure 3: Detailed Architecture of the WSML with the concerns such as monitoring, caching and billing. Finally, selection policies, encapsulated in selection aspect beans, enable advanced service selection. In the next subsections, these new concepts are described in greater detail. Service Types One of the aims of the WSML is to eliminate hard-wiring of services. Therefore, service requests have to be formulated in an abstract way in the client application and the WSML will make the translation to a concrete service. To this end, service types are introduced. A service type can be seen as a contract specified by the application towards the services and allows hiding the syntactical differences between semantically equivalent services. Two services may offer the same functionality but differ on a number of considerations like: Web method names Synchronous/asynchronous methods Parameter types and return types Semantics of parameters and return values Method sequencing By introducing the WSML, the heterogeneity of those services can be hidden. This approach differs from the concept of tmodels (Microsoft, 2002), where the services must have identical interfaces. Our solution also supports services with different interfaces and service compositions. This is achieved by using mapping schemas that unambiguously describe how the service or service composition maps to the service type. These schemas are described by the service provider or can be specified by the application developer. The idea of using sequence diagrams for expressing this mapping is followed here. This solution is also employed in PacoSuite (Vanderperren, 2001), a component based development tool, where these diagrams are used to determine if composition patterns and components are compatible. In

9 International Journal of Web Services Research, 1(3), 25-41, July-Sept addition, they are used to automatically generate glue code to connect the components. In the same way, sequence diagrams can be used to specify the orchestration between service types and concrete service interfaces. To illustrate these ideas, an example of a travel agency application is introduced. The application offers the functionality to book holidays online, which customers can use to make reservations for both flights and hotels. To achieve this functionality, the application integrates several Web services. Suppose HotelServiceA and HotelServiceB are services that offer the same functionality for the online booking of hotels. Each hotel service returns exactly the same results. The client application has to present a list of available hotels has to be presented to the customer. To this end a HotelServiceType is defined, which specifies the following method: List listhotels (Date, Date, CityCode). At deployment or run time the following two services are available: HotelServiceA provides the method: HotelList givehotels(citycode, Date,Date) HotelServiceB provides the method: HotelList gethotels (Date,Date,CityName) Figure 4 shows how the HotelServiceType is mapped to the concrete interfaces provided by these services. In the first example, both the name and the order of the arguments of the service type differ from the ones specified in HotelServiceA. In the second example a simple service composition is needed. HotelServiceB requires city names instead of city codes, and thus a third service is required to perform the translation between city names and city codes. In the current prototype these orchestrations are specified manually, but we are automating this process by adding support for the Semantic Web through DAML-S (DAML Services Coalition, 2002), a Web service ontology approach that is to provide semantic descriptions of Web services. Figure 4: Example of Sequence Diagram for Service Type Mapping

10 34 International Journal of Web Services Research, 1(3), 25-41, July-Sept 2004 Figure 5: Redirection Aspect Bean for Hotel Retrieval responding service type request. This way, they encapsulate the deployment details. Typically there is a different connector in charge of deploying each redirection aspect bean. Figure 6 illustrates the connector HotelServiceA_RC, which specifies the mapping between the requests of HotelServiceType and the aspect bean of Figure 5. The connector instantiates the hooks defined in the aspect bean, which results in the execution of the replacement behavior specified in those hooks, as soon as a service type request is made. The WSML is responsible for the creation and management of these redirection connectors. As JAsCo allows for the runtime deployment of aspect beans and connectors, it becomes possible to dynamically integrate new services and service compositions. By creating a new connector and redirection aspect bean at runtime the new service or service composition can be integrated in the client apclass ServiceA_RA { Stub stub; //client stub of HotelServiceA hook ListHotelsHook { ListHotelsHook(method(..args)){ execute(method); replace() { try { return stub.givehotels(args); catch (ServiceUnavailableException e) { WSML.serviceFailure ( HotelServiceA ); return proceed(); hook BookHotelHook { JAsCo Aspect Beans & Connectors for Redirection To implement the abstraction mechanism of service types in the WMSL, the aspect-oriented features of JAsCo are used. JAsCo aspect beans encapsulate the orchestration for a single service or service composition and JAsCo connectors are used to link the aspect beans with the appropriate service type. These redirection aspect beans define the logic of intercepting client application requests and replacing them with concrete Web service invocations. As such they encapsulate all communication details for a specific Web service or service composition. Figure 5 shows code for the redirection aspect bean for the hotel retrieval example. Note that the redirection aspect beans refer to application requests in a generic way. A redirection connector links the redirection aspect bean with the cor-

11 International Journal of Web Services Research, 1(3), 25-41, July-Sept Figure 6: Connector that Deploys the Redirection Aspect Bean static connector HotelServiceA_RC { HotelServiceA_RA.ListHotelsHook listhook = new HotelServiceA_RA.ListHotelsHook (List HotelServiceType.listHotels (Date,Date,String)); HotelServiceA_RA.bookHotelHook bookhook = listhook.replace(); bookhook.replace(); plication in a transparent way. The current version of the WSML supports full automatic generation of the connectors and provides tool support for the creation of the aspects. This mechanism also enables hot swapping between services. If the response time of a service is too slow or the service becomes unavailable, the selection module can hot swap to another service by simply activating its connector and deactivating the previous one. Note that if the communication with the service involves more complex transactions or if the service is state full, a transaction mechanism is required, as mentioned before. Client-Side Service Management The WSML can also deal with other management issues that need to be controlled at the application side. For instance, suppose HotelServiceA describes a strategy for billing its use and the application wants to locally control this for auditing reasons. Imagine the service specifies that each time the method to retrieve the list of hotels is invoked, an amount of five cents needs to be paid. If this functionality were implemented as part of the application, code for dealing with this billing concern would be needed at each point in the application where that service is requested. This code would crosscut the core application and should be decoupled and encapsulated in a separate module. We can achieve this by defining a new aspect bean that abstracts the logic for a pay per use billing strategy. Figure 7 shows the implementation of this billing aspect bean. Note that this aspect bean is generic and can be deployed and customized for other services that adopt this billing policy. This deployment can be specified as part of the connector shown in Figure 8. In this example, the billing is done when listhotels is invoked in the application. However, as the connector HotelServiceA_RC implements this method as a call to HotelServiceA, the billing is only done when this concrete service is used. Note that it is also possible to use a separate connector for the billing concern. The BillPerUseAspect defines a billing template that can be reused by different services. Other more complex billing aspect beans can be formulated and implemented in a similar way. Following the idea illustrated in this simple example we can envision the definition of a generic

12 36 International Journal of Web Services Research, 1(3), 25-41, July-Sept 2004 Figure 7: Billing Aspect Bean class BillPerUseAspect { hook BillHook { private int total, cost = 0; public void setcost(int acost){ cost = acost; private void pay(){ total = total + cost; BillHook(method(..args)){ execute(method); after() { pay(); library of aspect beans that can be easily instantiated and deployed. For this, connectors are automatically generated by the WSML, achieving high flexibility in the implementation of client-side service management. Service Selection & Monitoring Figure 8: Connector Extended with Billing static connector HotelServiceA_RC {...continued from figure 6 BillPerUseAspect.BillHook billhook = new BillingPerUseAspect.BillHook (List HotelServiceType.listHotels (Date, Date, String)); billperuse.setcost(5); listhotelshook.replace(); billperusehook.after(); In previous sections we discussed how service types can be mapped to concrete services and service compositions and how a selection module is responsible for regulating the activation of redirection connectors. A service will effectively deal with a given request if the selection module of the WSML selects and activates its corresponding connector. This process is driven by business requirements that can change over time. A service might be chosen today for its low price, but tomorrow a high response time might be more desirable. In the WSML selection policies representing these criteria can be specified. These policies are again implemented using aspect beans and connectors, resulting in a dynamic and flexible service selection routine. In order to control the properties of the Web services that influence the decision making, monitoring is required. A solution using aspect beans, similar to the one introduced for the management concerns can be applied to dynamically install and monitor the necessary measurement points. For instance, if the response time of the services is an important criterion, then a monitoring aspect bean can be dynamically plugged in to intercept the Web service invocations and provide information about the response time to the selection aspect beans in the selection module. Note that to be able to specify non-functional properties on Web services, an extension of WSDL is required. Approaches such as WSOL, the Web Service Offering Language (Tosic, 2003), can be used for this purpose. This is, however, outside the scope of this article and the subject of future research. RELATED WORK A lot of research is going on in the Web service context and a lot of vendors are currently working on dedicated Web

13 International Journal of Web Services Research, 1(3), 25-41, July-Sept service management platforms. However, most of these products focus on the server-side management of Web services. They allow developers to build and deploy Web services and also provide some management capabilities such as load balancing, concurrency, monitoring, error handling, and so forth. Our approach provides support for the client applications that want to integrate different third-party Web services and manage them. Some of the most relevant approaches are as follows: The Web Service Description Framework (WSDF) (Eberhart, 2002) incorporates ideas from the Semantic Web (Semantic Web Community Portal, 2002), suggesting an ontological approach for the side effect-free invocations of services. The Web Services Mediator (WSM) (Chatterjee) also identifies the need for a mediation layer to achieve dynamic integration of services. However, as far as we know there is no implementation available. The Web Services Invocation Framework (WSIF) supports a Java API for invoking Web services irrespective of how and where the services are provided. WSIF mostly focuses on making the client unaware of service migrations and change of protocols. A lot of work is being done towards standardization of various Web service protocols covering security (WS-Security), policy assertions (WS-Policy) or transaction support (WS-Transaction), business process definition languages (BPEL4WS), and so forth. All these protocols require communicating with Web services in a specific manner. Our approach can be used to hide these differences from the client application. The idea of applying AOP concepts to Web services is quite innovative and not many approaches have adopted this path. However, Arsanjani et al. (2003) have recently identified the suitability of AOSD to modularize heterogeneous concerns involved in Web services. In particular they refer to technologies like AspectJ (Kiczales et al., 2001) and the HyperJ (Ossher et al., 2001; Tarr et al., 1999). These approaches only allow static aspect weaving though, contrary to JasCo, which supports dynamic pluggability of aspects. They also identify the need for the Web services to include the definition of non-functional interfaces that permit control over performance, reliability, availability, metering and level of service. These properties can be taken into account at service selection time. CONCLUSIONS In this article we propose a new management layer called WSML to control the integration and configuration of Web services in client applications. We identified the need to use AOP as we observed that service management concerns are crosscutting. To this end we use a dynamic AOP implementation language, called JAsCo, to enable hot swapping and runtime management of services. Our approach has the advantage that applications become more robust, as the layer can dynamically deal with potential service failures and hot swap to new functionally equivalent services. Moreover, a high flexibility for the integration of services is achieved by supporting the on-the-fly pluggability of services.

14 38 International Journal of Web Services Research, 1(3), 25-41, July-Sept 2004 We are currently working on the definition of a library of reusable aspect beans that allows the application developer to dynamically instantiate and configure the required aspect beans to deal with different service management concerns. These reusable aspect beans can be seen as generic templates that can be customized and integrated on demand to accommodate service requirements. We are also working on realizing a more advanced hot-swapping mechanism that would consider service-oriented criteria. These criteria are derived from the application requirements and are based on the non-functional properties of services. They govern the selection of services specifying under which conditions the services have to be selected. Another direction of research under attention is the automatic generation of redirection aspect beans for new services and service compositions that need to be integrated in the client application. To achieve this, the orchestration between the service types and the concrete services has to be parsed and translated into code at runtime. We are working on tool support to specify this orchestration more easily and to automatically generate aspect bean code out of it. To automate this process even further, we are adopting techniques from the Semantic Web by introducing DAML-S (DAML Services Coalition, 2002) support to add semantic meaning to the service type and Web service documentations. ACKNOWLEDGMENT The research presented in this article is conducted with the support of the Flemish Government Project MOSAIC, funded by the Institute for the Innovation of Science and Technology in Flanders (IWT), or in Dutch, Instituut voor de aanmoediging van Innovatie door Wetenschap en Technologie in Vlaanderen, and is carried out in cooperation with Alcatel Bell. REFERENCES ACM. (2001, October). Aspect- Oriented Software Development. Communications of the ACM. AOSD. Aspect-Oriented Software Development. Appnel, T. (2002). An introduction to WSIL, the Web Services Inspection Language. O Reilly on Java.com, / 10/16/wsil.html Arsanjani, A., Hailpern, B., Martin, J., & Tarr, P. (2003, March). Web services promises and compromises. ACM Queue, 1(1). BPEL4WS. (2003, May). Business Process Execution Language for Web Services (BPEL4WS) v1.1. BEA Systems, IBM, Microsoft, SAP AG, Siebel Systems. Chatterjee, S. Developing real world Web services-based applications. The Java Boutique, internet.com/articles/wsapplications/ DAML Services Coalition (Ankolenkar, A., Burstein, M., Hobbs, J.R., Lassila, O., Martin, D.L., McDermott, D., McIlraith, S.A., Narayanan, S., Paolucci, M., Payne, T.R., & Sycara, K.) (2002, June). DAML-S:

15 International Journal of Web Services Research, 1(3), 25-41, July-Sept Web service description for the semantic Web. Proceedings of the First International Semantic Web Conference (ISWC), pp Eberhart, A. (2002). Towards universal Web service clients. Proceedings of Euroweb. UK. Kiczales, G., Hilsdale, E., Hugunin, J., Kersen, M., Palm, J., & Griswold, W.G. (2001). An overview of AspectJ. Proceedings of the European Conference on Object-Oriented Programming. Hungary. Lieberherr, K., Lorenz, D., & Mezini, M. (1999, March). Programming with aspectual components. Technical Report NU-CCS Malhotra, J. (2001). Challenges in developing Web services-based e-business applications. Whitepapers interkeel Inc. Microsoft. (2002). Introduction to UDDI services and tmodels. isb.oio.dk/uddi/help/1033/ intro.whatisuddi.aspx Ossher, H., & Tarr, P. (2001, October). Using multidimensional separation of concerns to (re)shape evolving software. Communications of the ACM, 44(10), Pulvermüller, E., Speck, A., Coplien, J.O., D Hondt, M., & De Meuter, W. (2001). Proceedings of the Workshop on Feature Interaction in Composed Systems at the European Conference on Object-Oriented Programming. ~pulvermu/workshops/ecoop2001/ Semantic Web Community Portal. (2002, November). semanticweb.org/ SOAP. (2003). Simple Object Access Protocol (SOAP) v1.2 Whitepaper. W3C Technical Publications. Suvée, D., & Vanderperren, W. (2003). JAsCo: An aspect-oriented approach tailored for component based software development. Proceedings of the Second International Conference on Aspect-Oriented Software Development (AOSD 2003). USA. Szyperski, C. (2001, August). Components and Web services. Beyond Objects column, Software Development, 9(8). Tarr, P., Ossher, H., Harrison, W., & Sutton, S.M. (1999). N degrees of separation: Multi-dimensional separation of concerns. Proceedings of the International Conference on Software Engineering (ICSE 1999). Tosic, V., Pagurek, B., & Patel, K. (2003, June). WSOL A language for the formal specification of classes of service for Web services. Proceedings of International Conference on Web Services (ICWS 03). Las Vegas, USA. UDDI. UDDI Executive Whitepaper. (2001, November). Executive _White_Paper.pdf Vanderperren, W. (2001). Applying aspect-oriented programming ideas in a component based context: Composition adapters. Proceedings of the NetObjectDays Germany. Vanderperren, W., Suvée D., Wydaeghe B., & Jonckers, V. (2003, April). PacoSuite & JAsCo: A visual component composition environment with advanced aspect separation features. Pro-

16 40 International Journal of Web Services Research, 1(3), 25-41, July-Sept 2004 ceedings of the Second International Conference on Fundamental Approaches for Software Engineering (FASE 2003), Warshaw, Poland. WSDL. (2003). Web Service Description Language (WSDL) v2.0 Whitepaper. W3C Technical Publications. WSIF. The Web Services Invocation Framework (WSIF). Apache. /ws.apache.org/wsif/ WSML. Web Services Management Layer. WS-Policy. Web Services Policy Framework (WS-Policy) v1.0. (2002, December). Microsoft Developer Network. webservices/ WS-Security. Web Services Security (WS-Security) v1.0. (2002, April). IBM Developer Works. www106.ibm.com/developerworks/ webservices/library/ws-secure/ WS-Transaction. Web Services Transaction (WS-Transaction) v1.0. (2002, August). IBM Developer Works. developerworks/library/ws-transpec/ Bart Verheecke obtained his master s degree in Applied Computer Science at the Vrije Universiteit Brussel (VUB) (2001). He is working as a PhD student on the Mosaic project in collaboration with Alcatel Bell, funded by the Institute for the Innovation of Science and Technology in Flanders (IWT). His research is combining aspect-oriented and service-oriented application development in a Web service context. He is involved in the development of the WSML and is also researching the role of information and communication technology (ICT) in sustainable development. María Agustina Cibrán obtained her university degree in Computer Science at the Universidad Nacional de La Plata (Argentina) (2001) and her master s degree in Object Oriented Software Engineering at the Ecole des Mines de Nantes (France) and the Vrije Universiteit Brussel (Belgium) (2002). She is currently working as a PhD student on the Mosaic project at the VUB. Her main research areas are business rules, aspect-oriented software development and its application on service-oriented application development. She is involved in the design and development of the WSML. Wim Vanderperren is a PhD student at the VUB, funded by a doctoral scholarship from the Fund for Scientific Research (FWO). He received his master s degree in Computer Science in His research is focused on combining aspect-oriented and component-based software engineering. In this context, he developed the visual component composition environment PacoSuite and the JAsCo language. Davy Suvee obtained his Master s in Applied Computer Science at the VUB (2002) and is currently working as a PhD student funded by the IWT. His main research is combining the ideas behind aspect-oriented and component-based software development. He is involved in the development of the JAsCo language and is also researching the advantages of combining aspects and components within a unified component architecture.

17 International Journal of Web Services Research, 1(3), 25-41, July-Sept Viviane Jonckers received her PhD in Computer Science from the VUB (1987). Since 1987, she has been a professor both at the Computer Science Department of the faculty of Sciences and in the Computer Science group of the Engineering Faculty. Currently, she is director of the System and Software Engineering Lab. Her research interests are knowledge based programming, the use of (semi-) formal methods in software and knowledge engineering, and more recently, component and service based software development.