Dynamically Reconfiguring Services in SOA Applications: A Pattern ...

Dynamically Reconfiguring Services in SOA Applications: A Pattern-Based Approach Vallidevi Krishnamurthy, SSN College of Engineering, Anna University, Chennai, India Chitra Babu, SSN College of Engineering, Anna University, Chennai, India

Service Oriented Architecture (SOA) facilitates developing applications that are inherently dynamic in nature since the service binding happens at runtime by matching the functional as well as Quality of Service (QoS) requirements of the user. The running application can be dynamically reconfigured by monitoring the application for possible violations in the agreed QoS requirements. This paper proposes suitable patterns to facilitate such dynamic reconfiguration in any service-oriented application to achieve dynamic switching between different versions of the same application without manual intervention. A proposed pattern named the MULTIPLE LEVEL BRIDGE pattern is also discussed in this paper which helps structure service interface and implementations for reuse across different application versions. This pattern based approach has been tested by applying it to a sample SOA based e-Shopping application. Categories and Subject Descriptors: H.5.2 [Information Systems]

Additional Key Words and Phrases: Service Oriented Architecture, Dynamic Reconguration, Pattern Based Approach

1.

INTRODUCTION

Service-oriented applications are inherently dynamic in nature since the service binding happens at runtime by matching the functional as well as Quality of Service (QoS) requirements of the user. The service oriented applications can be monitored to pro-actively detect the possible violations in the agreed QoS requirements which helps in dynamically reconfiguring the application. The monitoring[Keller and Ludwig 2003] can be done either by the client himself or by a third party service. Assume that you are the service provider for a complete service-oriented application which has many versions(see [Andrikopoulos et al. 2012] for an explanation on versions) such as basic, intermediate and advanced. Further, the service provider should be capable of providing new versions for the same application, whenever there is a need for an advanced version. In this context, you want to provide a dynamically reconfigurable application to the consumers where the dynamic reconfiguration takes place basically in two different ways. —The first is to provide service substitution by another service at runtime that has the same service interface and implementation. This level of reconfiguration happens when a particular service which is currently active is not meeting its QoS requirements or when a particular active service becomes unavailable. —The second dimension is to switch among several versions of the same application. The need for this level of reconfiguration arises whenever the predefined rules for reconfiguration are satisfied. This paper introduces a pattern language for the dynamic reconfiguration of services which is comprised of existing patterns from [Jain and Schmidt 1997], [Erl 2009] and [Zdun et al. 2004]. In addition, the paper also deals with the reuse of services in different versions of an SOA application which is achieved through a proposed pattern

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission. A preliminary version of this paper was presented in a writers‘ workshop at the 17th European Conference on Pattern Languages of Programs (EuroPLoP). EuroPLoP‘12, July 11-15, Irsee, Germany. Copyright 2012 is held by the author(s). ACM 978-1-4503-2943-9

named the MULTIPLE LEVEL BRIDGE pattern. This pattern based approach has been tested by applying it to a sample SOA based e-Shopping application. The proposed pattern is intended to aid the SOA application developers. When studied and applied in the evolution of SOA application development, the proposed pattern description helps in reusing the services in a well defined and structured manner. The remainder of the paper is structured as follows: A motivating example is explained in Section 2. In Section 3 the pattern language for the dynamic reconfiguration is described. A thumbnail is also given for the existing patterns in the pattern language in Appendix A. In Section 4, the proposed pattern is explained. The motivating example is revisited in Section 5. Section 6 explains the implementation of the proposed pattern description and also the role of the pattern language to achieve dynamic reconfiguration. In Section 7, the related work is discussed and Section 8 summarizes and concludes. 2.

MOTIVATING EXAMPLE: E-SHOPPING APPLICATION

Consider a service provider providing an entire SOA based e-Shopping application as a service. This application has two versions(refer Fig. 1). The first version V1 .I1 provides a multimedia view of the application. There is second implementation for this version V1 which is a view without any animation and it is named as version V1 .I2 . There is a second version, V2 .I1 which is inherited from the second implementation of V1 . This second version has the features of the version V1 .I2 with some additional features, such as notifying the administrator with an alarm when the product availability goes below a certain pre-defined threshold. This second version will be useful to the service consumers who would like to pro-actively refill their stocks so that they will not lose potential customers because of the lack of availability of their products. This feature is useful to the service consumers during special offer period. In addition, this version has an added feature of selecting an alternative payment gateway which has the capability of handling heavy loads which will be suitable during the special offer period.

Fig. 1. SOA - Reference Architecture - e-Shopping Application Dynamically Reconfiguring Services in SOA Applications: A Pattern-Based Approach — Page 2

The e-Shopping application is represented in the SOA Reference Architecture [Arasanjani 2005] as shown in the Fig. 1. The lower layer is the operational layer in which all the databases are represented. Above this layer, are the components or the implementation of the services, that constitutes the service component layer. Services layer comprises of the interfaces that map to the implementations provided by the service component layer. Business process layer provides the flow of the service implementation. The consumer layer captures the corresponding user interface design. There are two different cases considered in which the dynamic reconfiguration can be achieved through version switching: Case 1: The calender period corresponding to special offers specified by the service consumer is checked periodically. If the service consumer, is in need of V2 .I1 or V1 .I2 , for certain calender period alone, switching to the appropriate version happens automatically from V1 .I1 . After the specified calender period elapses, the version V1 .I1 replaces the exchanged version. Case 2: Certain service consumers may not be interested in specifying the calender period at the beginning itself. In that case, if the load reaches a critical threshold, automatic switching from the version V1 .I1 to any one of the alternate versions specified in the SLA, has to be enabled. 3.

PATTERN LANGUAGE FOR DYNAMIC RECONFIGURATION

This section explains the context in which the pattern language is used, and the pattern language itself for the dynamic reconfiguration in SOA. Finally, this section also provides an idea of how the pattern language and the proposed pattern binds with the service composition in SOA. 3.1

Context for the Pattern Language

Fig. 2. Context for the Pattern Language

The basic architecture or the context in which the pattern language can be applied is shown in Fig. 2. This architecture is different from the standard SOA as it has a monitoring agent and a reconfiguration engine in it which helps in dynamic reconfiguration. While developing any SOA application, there are many atomic services available. Those services are composed by the service composition engine. The service composition engine has the service composition logic, monitoring agent and the reconfiguration engine within it. Dynamically Reconfiguring Services in SOA Applications: A Pattern-Based Approach — Page 3

The service composition logic makes use of the service configuration to know about the nature of the various services. The services with the same configuration such as services with the same life cycle or the services which provides the same functionality can be grouped together. The services that are grouped are then composed together which forms the service composition logic. The monitoring agent monitors the service composition logic of a particular version of the SOA application which will be active with its respective contracts established between the service providers and the consumers. This monitoring agent triggers the reconfiguration engine whenever there is any need for service substitution or there is a need to switch among different versions. The reconfiguration engine which contains the component repository helps in the co-ordination of dynamic reconfiguration. A component repository is the one which contains the list of components arranged together that has the same common properties. 3.2

Pattern Language for Dynamic Reconfiguration in SOA

A thumbnail is given for the existing patterns that are discussed in the pattern language which is available in Appendix A. CONFIGURATION GROUPS[Zdun et al. 2004] pattern will group remote objects with common properties, for example objects with the same QoS properties or that belong to the same life cycle. A server application can have multiple CONFIGURATION GROUPS at the same time. Using this pattern, the developer can have different versions of the same service oriented application as the services in the same version will have the same life cycle and can be composed to form a group. The service compositions are done by the CAPABILITY COMPOSITION pattern. This CAPABILITY COMPOSITION[Erl 2009] pattern is used to solve a problem that requires logic outside of the service boundary.

Fig. 3. Pattern Language for Dynamic Reconfiguration

The QOS OBSERVER[Zdun et al. 2004] pattern is used to monitor the QoS of services for which it is registered. Once the QOS OBSERVER is triggered by the INVOKER the QOS OBSERVER starts intercepting the service and collects the QoS data. At the end of the service execution, INVOKER stops the QOS OBSERVER. Subsequently, the Dynamically Reconfiguring Services in SOA Applications: A Pattern-Based Approach — Page 4

QOS OBSERVER analyzes the collected data and decides whether to trigger any reconfiguration or not. If the QoS parameters specified in the SLA, are expected to be violated it triggers the reconfiguration engine. In order to switch between different versions of the SOA application, the reconfiguration engine can be implemented by the SERVICE CONFIGURATOR[Jain and Schmidt 1997] pattern. The reconfiguration engine interprets and executes the code specific for the reconfiguration with the concrete services available in the component repository. The pattern language for dynamic reconfiguration is given in Fig. 3. The dynamic reconfiguration in the business process layer of the SOA reference architecture can be obtained by using those patterns. As the user requirements may change at any time, there may be situations where a single service in the application needs to be substituted by some other service. In that case, an aspect oriented programming based CLASS EXCHANGE PATTERN can be used as an alternative for the SERVICE CONFIGURATOR pattern and that is also shown in Fig. 3.

Fig. 4. CASCADED BRIDGE

The implementations with the same configuration are grouped together with the help of CONFIGURATION GROUPS pattern. The SERVICE FACADE pattern is used to decouple the contract generated between the service consumers and the service provider. The communication between the SERVICE FACADE, the CAPABILITY COMPOSITION and the implementation are like a CASCADED BRIDGE pattern[Sun 1998] which is explained in Fig. 4. Initially, the request from the consumer is processed through the SERVICE FACADE where it acts as a interface for the service consumers. The request is then delegated to the CAPABILITY COMPOSITION acts as the implementation for the SERVICE FACADE . Again the CAPABILITY COMPOSITION behaves as an interface for the original implementation which are grouped together by the CONFIGURATION GROUPS pattern. Thus, there are two bridges which are arranged in the form of CASCADED BRIDGE pattern. The CAPABILITY COMPOSITION plays the role of cascading the interface and the implementation part. Depending on the contract generated with the different service consumers, the provider can come up with different service facades without disturbing the original service composition and also the functionalities of the individual services. The contracts generated between the service provider and the service consumer should be physically decoupled from their implementations. This can be achieved by generating the contract which could be very different from the underlying technology. DECOUPLED CONTRACT pattern helps in generating contracts this way. The MULTIPLE LEVEL BRIDGE pattern(see Section 5) which is the proposed candidate pattern helps in the reuse of services available in the previous version. With this pattern, the developer is capable of developing an advanced version of the same service with some additional features. The proposed pattern and the pattern language are mapped to the context in Fig. 5. The patterns used in the various components of a SOA application with many versions, which can be exposed to multiple clients with different contracts are shown in this. Dynamically Reconfiguring Services in SOA Applications: A Pattern-Based Approach — Page 5

Fig. 5. Pattern Language Mapping with the Architecture

4. 4.1

MULTIPLE LEVEL BRIDGE PATTERN Context

You are the provider for the service oriented application that comprises multiple services. First you are in a position to satisfy the service consumers for whom you have agreed the SLA. Secondly, you would like to provide additional features of the services in a service oriented application when it is going to evolve. 4.2

Problem

How to design the services when the change in the service implementation would and would not have any impact on the service contract? 4.3

Forces

—Ability to extend from any level. For example, version Vn of a SOA application need not inherit all the features from version Vn−1 . It should be Dynamically Reconfiguring Services in SOA Applications: A Pattern-Based Approach — Page 6

possible to either retain or extend some of the features of the services in any of its previous versions. It should be backward compatible. —Ability to evolve from its previous version without disturbing the already existing contract. Whenever there is any major change in the implementation, then it may lead to the change in the contract. In such a case, the new contract should not affect the already existing contract which is agreed with the existing customers. 4.4

Solution

If the new version of the application replaces the existing one, then the already existing contracts may be disturbed.(Here only the new version of the application will be existing and not the older one.) Whenever there are interface changes such as addition and removal of any operation in a service and policy changes such as change in quality of service, then there will be a change in the contract[1]. If there is no major change that induces change in the contract, then the service extension can be designed in the same namespace and the same version number exists for that. Otherwise, the service extension need to be saved in a new namespace and a new version number is given for such cases. Apply a variant of the BRIDGE pattern which separates an internal service interface and service implementation. The internal service interface is to be referenced in the service compositions. Apply a hierarchy of bridge pattern which helps us to vary the interface and the implementation to any level separately.

Fig. 6. MULTIPLE LEVEL BRIDGE pattern

The structure of the MULTIPLE LEVEL BRIDGE pattern in the view of service provider is shown in the Fig. 6. This is a variant of the BRIDGE pattern in which both the interface and the implementations are being extended to multiple levels. For the same interface, many implementations can be mapped using the BRIDGE pattern. However, Dynamically Reconfiguring Services in SOA Applications: A Pattern-Based Approach — Page 7

the interfaces and the implementations can be extended to multiple levels which is not possible using the BRIDGE pattern alone. 4.5

Consequences

The benefits of using this pattern are explained below. MULTIPLE LEVEL BRIDGE pattern, exhibits the inherent characteristics of Service Oriented Architecture such as, . Decoupling interface and implementation This pattern decouples the interface and the implementation. Hence, there is no tight coupling between the interface and the implementation. At runtime, the interface and the implementation are bound which is a very much essential need for the Service Oriented Architecture. . Hiding the implementation details from the client As the abstraction and the implementation are decoupled from each other, any changes made in the implementation will be hidden from the client. . Improved Extensibility This pattern is helpful in extending the features of version Vn to version Vn+1 of any service in the SOA environment i.e., the abstraction and the implementor hierarchies can be extended independently in the same level(where there is no change in the contract) or it can be extended to subsequent levels (where there is a change in the contract). . Extension Guideline When the developers start extending for every small change, then it may lead to many versions unnecessarily. Whenever there is a change in the contract of the SOA application, then the extension to the next level can be done. Else it can be extended in the same level. This guidance to the extension is provided in the MULTIPLE LEVEL BRIDGE pattern.

Fig. 7. Class Diagram for e-Shopping application Dynamically Reconfiguring Services in SOA Applications: A Pattern-Based Approach — Page 8

4.6

Known Uses

—CORBA supports the following Interface inheritance which is also called as diamond inheritance. It does not support the implementation inheritance and the MULTIPLE LEVEL BRIDGE pattern also supports the interface inheritance to a great extend and supports implementation inheritance only when it is needed.

interface interface interface interface interface

A{ ... } B:A{ ... } C:A{ ... } D:B,C{ ... } E:A,B{ ... };

With this above CORBA inheritance code snippet, it is clear that, a part of MULTIPLE LEVEL BRIDGE pattern is supported by the applications built in CORBA which uses the interface inheritance as explained above. 4.7

Motivating Example

For the previously discussed e-Shopping application in Section 2, the class diagram is shown in Fig. 7. The AbstractInterface, AbstractImplementation classes and their subclasses together represent the MULTIPLE LEVEL BRIDGE pattern. The Customer class handles the responsibility of obtaining the personal details of the customer and registering them. The Account class, is responsible for authenticating the customers using username and password. Both the Customer and the Account details are stored in the database. There is an Administrator class with which the items in the e-Shop are managed by adding and removing the items and their details. There is a MonitorAgent class which monitors the number of people currently online. Whenever there is a need for change in interface or implementation, then the MonitorAgent triggers that corresponding change. There is a

Fig. 8. Example of Multiple Level Bridge Implementation Dynamically Reconfiguring Services in SOA Applications: A Pattern-Based Approach — Page 9

StockManager which checks for the stock availability in each and every Warehouse and refills the items if it goes below a pre-defined critical limit. The MULTIPLE LEVEL BRIDGE implementation is shown in the Fig. 8. 4.8

Application Of MULTIPLE LEVEL BRIDGE Pattern in the e-Shopping Example

The mapping of the application scenario to the proposed pattern is shown in Fig. 9. At run time, object corresponding to any one of the versions is created. Assume that version V1 and the implementation I1 of the application is composed of services, s1 , s2 , s3 , and s4 ; Version V1 and the implementation I2 of the application is composed of services s1.1 , s2.1 , s3 and s4 . s1.1 has the features of s1 with different implementation. Similarly, s2.1 has the features of s2 with different implementation. Such services of V1 .I2 are created in the same namespace of the services of V1 .I1 . This second implementation helps to maintain the agreed SLA with minor changes in the existing implementation. Assume that, version V2 .I1 is composed of services, s1.1 , s2.1 , s3 , s4 and s5 . Then at run time, if the application is suddenly switching from version V1 .I1 to version V2 .I2 , then there are 3 changes totally. —s1 is exchanged with the service s1.1 —s2 is exchanged with the service s2.1 —a new service s5 which is not available in version V1 .I1 but in version V2 .I1 is added now in that application. Thus, the services layer of the SOA reference architecture is dynamically reconfigured with this proposed pattern.

Fig. 9. Mapping MULTIPLE LEVEL BRIDGE pattern and SOA Reference Architecture Dynamically Reconfiguring Services in SOA Applications: A Pattern-Based Approach — Page 10

This pattern when used with the Q O S OBSERVER [Zdun et al. 2004], SERVICE CONFIGURATOR[Jain and Schmidt 1997] and CONFIGURATION GROUPS [Zdun et al. 2004] helps to switch between different service compositions in the business process layer or service composition layer of the SOA reference architecture . 5.

RELATED WORK

There are several existing research works which have addressed the evolution of services with design patterns in the context of SOA. —Kaminski[Kaminski et al. 2006] has focused on the compatibility issues that arise in dealing with different versions and has proposed a pattern named CHAIN OF ADAPTERS. On the other hand, the focus of the proposed pattern based solution is towards dynamically reconfiguring the whole application by switching between different versions. —CASCADED BRIDGE [Sun 1998] is a series of linked bridges, in which intermediate implementors perform some of the implementations and then delegate the rest to the downstream. Whereas, the proposed pattern talks about having different instances of the various versions of the same application. The creation of those instances is carried out by multilevel inheritance. This pattern is not designed in a way that, if version Vn is to be executed, then it is not downstreamed from the top. Rather, it is connected directly to the version Vn of the implementation which is designed by inheriting from version Vn−1 . —EXTENSION INTERFACE pattern [Buschmann et al. 1996] allows multiple interfaces to be exported by a component. This avoids bloating of interfaces when the developers extend or modify the functionality of the component. —For using EXTENSION OBJECTS pattern[Gamma 1997] we need to support the addition of new or unforeseen interfaces to existing classes and you don’t want to impact clients that don’t need this new interface. Extension Objects lets you keep related operations together by defining them in a separate class. Middleware based dynamic reconfiguration has also been discussed in the existing literature by many authors already. —Xiaoying Bai[Bai et al. 2007] talks about DRESR which discusses the necessity of dynamic routing during dynamic selection and composition in SOA middleware. —Geebelen[Geebelen et al. 2008] had proposed a technique for dynamic service composition in SOA middleware by using templates. Whereas we have suggested some collection of patterns for the same. —Manel Fredj[Fredj et al. 2008] has proposed the SIROCO middleware platform,enabling the runtime, semanticbased service substitution. Here, service substitution is indirectly taking place when there is a version change. —Ibrahim[Ibrahim et al. 2009] has proposed MySIM which is a spontaneous middleware that integrates services in a transparent way without disturbing users and applications of the environment. Lionel[Seinturier et al. 2012] has discussed about the reconfiguration in the middleware platform which is a component based one in the SOA. 6.

CONCLUSION

A pattern language from the existing patterns is introduced for the dynamic reconfiguration of SOA based application. This paper also proposes a new pattern namely, the MULTIPLE LEVEL BRIDGE pattern. As the known uses for this proposed pattern is missing, this pattern has been treated as a candidate pattern. With the proposed pattern, the service provider is capable of deciding how to extend the services when the change in the service implementation would and would not have any impact on the service contract. Thus, the service provider is capable of providing a flexible and dynamically extensible service-oriented application. Additionally, the service consumer obtains a whole SOA application as a service with an improved cost structure. Usually, most of the service providers providing the entire application as a service will be interested in providing all the advanced features in their application to their customers. In that case, the consumer will be paying even for what he is Dynamically Reconfiguring Services in SOA Applications: A Pattern-Based Approach — Page 11

not using. The SERVICE FACADE [Erl 2009] pattern can be used to expose the services to different clients with varying contracts. Thus the provider gains his business both by using the MULTIPLE LEVEL BRIDGE pattern and the SERVICE FACADE pattern. By using the SERVICE CONFIGURATOR pattern, the basic version alone is exposed to the service consumer. The advanced features are exposed to their consumers, only when there is a need for them. Hence, the consumers are can reap the benefit of paying for only what they are using. 7.

ACKNOWLEDGEMENT

The authors would like to thank sincerely, Stefan Sobernig and Uwe van Heesch for their continuous encouragement, support and tireless shepherding. REFERENCES A NDRIKOPOULOS , V., B ENBERNOU, S., AND PAPAZOGLOU, M. P. 2012. On the evolution of services. Software Engineering, IEEE Transactions on 38, 3, 609 –628. A RASANJANI , A. 2005. Towards a pattern language for service-oriented architecture and integration, part 1: Build a service eco-system. B AI , X., X IE , J., C HEN , B., AND X IAO, S. 2007. Dresr: Dynamic routing in enterprise service bus. In Proceedings of the IEEE International Conference on e-Business Engineering (ICEBE ’07). 528–531. B USCHMANN , F., M EUNIER , R., R OHNERT, H., S OMMERLAD, P., AND S TAL , M. 1996. Pattern-Oriented Software Architecture: a system of patterns. Vol. 1. John Wiley and Sons. E RL , T. 2009. SOA Design Patterns 1st Ed. Prentice Hall PTR. F REDJ, M., G EORGANTAS , N., I SSARNY, V., AND Z ARRAS , A. 2008. Dynamic service substitution in service-oriented architectures. In Proceedings of the 2008 IEEE Congress on Services - Part I (SERVICES ’08). IEEE Computer Society, 101–104. G AMMA , E. 1997. Pattern languages of program design 3. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, Chapter Extension object, 79–88. G EEBELEN , K., M ICHIELS, S., AND J OOSEN , W. 2008. Dynamic reconfiguration using template based web service composition. In Proceedings of the 3rd workshop on Middleware for service oriented computing (MW4SOC ’08). ACM, 49–54. I BRAHIM , N., L E M OUËL , F., AND F RÉNOT, S. 2009. Mysim: A spontaneaous integration middleware for pervasive environments. In Proceedings of the ACM International Conference on Pervasive Services (ICPS’2009). London, UK, 1–10. J AIN , P. AND S CHMIDT, D. C. 1997. Service configurator: a pattern for dynamic configuration of services. In Proceedings of the 3rd conference on USENIX Conference on Object-Oriented Technologies (COOTS) - Volume 3. COOTS’97. Berkeley, CA, USA, 16–16. K AMINSKI , P., M ULLER , H., AND L ITOIU, M. 2006. A design for adaptive web service evolution. In Proceedings of the international workshop on Self-adaptation and self-managing systems (SEAMS ’06). ACM, 86–92. K ELLER , A. AND L UDWIG , H. 2003. The wsla framework: Specifying and monitoring service level agreements for web services. Journal of Network and Systems Management 11, 2003. S EINTURIER , L., M ERLE , P., R OUVOY, R., R OMERO, D., S CHIAVONI , V., AND S TEFANI , J.-B. 2012. A Component-Based Middleware Platform for Reconfigurable Service-Oriented Architectures. Software: Practice and Experience 42, 5, 559–583. S UN , B. M. 1998. The cascading bridge design pattern. In Proceedings of the PLoP-98 Conference. Z DUN , U., K IRCHER , M., AND V ÖLTER , M. 2004. Remoting patterns. IEEE Internet Computing 8, 6, 60–68.

Dynamically Reconfiguring Services in SOA Applications: A Pattern-Based Approach — Page 12

A.

APPENDIX

Pattern INVOKER

[Zdun et al.

2004] CONFIGURATOR GROUPS

pattern [Zdun et al. 2004]

SERVICE CONFIGURATOR

[Jain and Schmidt 1997]

QOS

OBSERVER

[Erl

Different versions of the SOA application are available. The service provider needs to optimally market his business using these versions. The service consumer also need to be benefited by suitably using these different versions. How can a service express its capabilities independently of its implementation?

FACADE

CONTRACT

[Erl 2009]

pat-

Separate implementation dimensions into independent components so that they can be independently interchangeable, evolvable, and testable.

COMPOSI -

How to use the capability which is available out of the scope of the service?

CASCADED BRIDGE

tern [Sun 1998]

CAPABILITY TION

[Erl 2009]

As the QOS OBSERVER has suggested, you are ready with the selected version now. This version of the SOA application should replace the existing version at run-time. You have many different versions of the same SOA application. You need to follow the SLA agreement to switch among those versions.

2009]

DECOUPLED

You architect and design a SOA application where there are many versions maintained for the same.

[Zdun

et al. 2004]

SERVICE

Problem There are many services which are registered for some monitoring purpose.

Solution The INVOKER will invoke the QOS OB SERVER when a particular service which is registered for monitoring is to be executed. The atomic services (with the advanced features) of the same life cycle are available in a pool they are to be selected and configured into groups. Thus you have many versions of the same service-oriented application with the help of CONFIGURATOR GROUPS pattern. For the new version to be replaced instead of the existing version, many configurations need to be done. Those configurations can be carried out by the SERVICE CONFIGURA TOR pattern. Some monitoring agent needs to check whether the system meets the SLA. Whenever there is a need for switching, then, the QOS OBSERVER which is acting as a monitoring agent triggers the reconfiguration engine. Different service consumers can come up with different contracts for those versions of the SOA application. Thus the consumer and the provider both are benefited.

The service contract should be physically decoupled from its implementation. This can be achieved by making the contract independent of the underlying technology. Use a CASCADING BRIDGE pattern. A CAS CADING BRIDGE is a series of linked bridges, in which intermediate implementers perform some of the implementation chores and then delegate the rest to the downstream. This pattern composes the capabilities available in various services and achieves the goal of solving the larger problem.

Dynamically Reconfiguring Services in SOA Applications: A Pattern-Based Approach — Page 13