Virtual Service Asset Management
A Virtual Service runs on runtime gateway, for example webMethods Mediator, and acts as the consumer-facing proxy for a service that runs elsewhere on the network. You can create a Virtual Service asset for the SOAP, REST, and OData Web services. A Virtual Service provides a layer of abstraction between the service consumer and the service provider, and promotes loose coupling by providing location, protocol, and format independence between the consuming application and the provider service.
For example, Virtual Services enable you to:
Move native services to other physical addresses or switch providers without affecting existing consumer applications.
Bridge differences (for example, transport differences, message structure differences) between the capabilities of a consuming application and the requirements of a native service.
Block portions of a service interface from certain consuming applications (that is, expose selected portions of the native service to certain consumers).
Provide access to different versions of a service through a single endpoint.
You use CentraSite to define Virtual Services and to deploy them on specified Mediators. After you deploy a Virtual Service, you use CentraSite as a dashboard from which to view performance metrics and other run-time data relating to the usage of a Virtual Service.
Services You Should Virtualize
Although it is possible to virtualize any native service that is registered in CentraSite, you will generally virtualize only certain types of services. The use of virtual services creates an additional hop in the execution path and also consumes resources from an execution perspective. It is generally not practical (or beneficial) to virtualize every native service in your environment. With respect to virtualization, you want to strike a balance between the need to provide an SOA infrastructure that is flexible and extensible with the need to maintain a manageable infrastructure that is not overly complex.
Broadly speaking, there are three types of services you should consider virtualizing:
Business services (which you virtualize at the point of consumption)
Shared services
Services that are provided and consumed in different domains of control (for example, cloud computing)
Virtualizing Business Services at the Point of Consumption
As shown in the following diagram, one approach to virtualization is to think of your services in terms of business services and technical services and to virtualize those services that are business services:
# | Description |
1 | Business processes are end-user applications that perform high-level tasks within your enterprise (for example, fulfilling an order or generating a quote). Business processes provide business functionality by orchestrating operations provided by different business services (depicted in layer 3). |
2 | Virtual services run in the layer between the business processes and business services. Each virtual service functions as a proxy for a particular business service. |
3 | Business services are coarse-grain services that perform business-related tasks, such as performing a credit check, setting up a new customer account or checking the status of an order. Business services generally perform their work by invoking the operations of many different technical services (depicted in layer 4). Because business services represent the point of consumption by end-user applications and processes, they are good candidates for virtualization. Additionally, there are generally far fewer business services than technical services (typically, 10% to 15% of services in an SOA environment are business services). |
4 | Technical services are fine-grained services that perform low-level tasks and utility functions such as updating the employee database, retrieving a customer record or executing a query against the order database. Often, a technical service provides access to the functionality of a specific back-end system such as a CRM system, an order-entry system or a financial system. Note: | There are cases when you might want to virtualize a technical service. However, these situations are rare. Generally speaking, you should avoid virtualizing technical services unless they are used by consumers in multiple functional domains. |
|
Virtualizing Shared Services
A shared service is a service that is used by multiple functional domains within an enterprise. For example, consumers in the CRM area, the Sales and Marketing area and the Risk Management area might each need access to customer data. Instead of giving these systems direct access to the data service for the customer database, you virtualize the service and give these consumers access to the virtual service (or virtual services). Virtualizing the service gives you greater control over the interface that is exposed to these consumers, enables you to accommodate differences among the consumers by applying different run-time policies and/or processing steps to them and also gives you the flexibility to make modifications to the native service without impacting existing consumers.
Virtualizing Services that are in Different Domains of Control (for example, Cloud Computing)
Any service that is provided by an entity outside of the enterprise or is consumed by an entity outside of the organization should be virtualized. For example, if you have an outside service that provides sales forecasts for your industry, virtualizing this service would enable you to:
Monitor the performance and availability of the service, including compliance with service-level agreements (SLAs).
Shield consumers from changes in service providers.
Track dependencies between the external service and the applications within the enterprise that consume the service.
Resolve protocol and format inconsistencies between the outside service and the consuming applications within your enterprise.
Similarly, you should virtualize any service that your organization offers to applications that execute outside the enterprise (for example, an inventory control service that you extend to suppliers and/or distributors).
The Basic Elements of a Virtual Service
A virtual service is a Web service that runs on webMethods Mediator. You use CentraSite to create, edit, publish, and manage virtual services. Virtual services have the following major elements:
Basic service metadata and WSDL. When you create a virtual service, the metadata from the native service is copied to the virtual service. The WSDL from a native SOAP-based Web service is also copied to the virtual service. After the virtual service is generated, you can edit its metadata and/or the WSDL as necessary.
Note: | When the metadata of a native service is modified, for example, using an updated WSDL, the changes are not propagated to its derived virtual services. To have the same metadata changes in one or more of its derived virtual services, you must attach the updated WSDL to each of its required virtual services. |
A set of processing steps. Every virtual service includes a set of processing steps that you configure before deploying the virtual service. The processing steps specify how the virtual service will handle the requests it receives from consuming applications. Processing steps are discussed in more detail later in this.
One or more targets. The
Deployment profile for a virtual service in
CentraSite Control specifies the targets (
webMethods Mediators) on which the virtual service is deployed.
Run-time policies associated with the virtual service. The
Policies profile for a virtual service identifies the run-time policies that apply to the virtual service. These run-time policies are the ones that
CentraSite will include when it deploys the virtual service to the
Mediators specified on the
Deployment profile.
Performance and Event profiles. The
Performance and
Events profiles enable you to examine the run-time data associated with a virtual service. You use these profiles to view performance metrics for a specified time period and to view events that have been logged for the virtual service (for example, SLA violations, service failures, logged request/response messages and so forth).
Processing Steps of a Virtual Service in CentraSite Control
The processing steps associated with a virtual service determine how the virtual service handles the requests it receives from consumer applications. All virtual services have four processing steps:
Entry Protocol step
Request Processing step
Routing step
Response Processing step
You configure these steps to specify how Mediator is to act upon the requests it receives for this virtual service.
Entry Protocol Step
The Entry Protocol step specifies the protocol (JMS, HTTP, or HTTPS) in which the virtual service accepts requests. This step allows you to bridge protocols between the consuming application and the native service. For example, let's say that you have a native service that is exposed over JMS and a consuming application that submits SOAP requests over HTTP. In this situation, you can configure the virtual service's Entry Protocol step to accept HTTP requests and configure its Routing Step to route the request to the native service using JMS.
Besides using the Entry Protocol step to resolve protocol differences between the consumer and the native service, you might use this step to intentionally expose a virtual service over a particular protocol. For example, if you have a native service that is exposed over HTTP, you might expose the virtual service over JMS simply to gain the asynchronous-messaging and guaranteed-delivery benefits that one gains by using JMS as the message transport.
Request Processing Step
The Request Processing step specifies how the request message is to be transformed or pre-processed before it is submitted to the native service. You can configure this step to perform message transformations using a specified XSLT file or by calling the webMethods IS service (that is, a webMethods Integration Server service running on the same Integration Server as webMethods Mediator).
You can use this processing step to accommodate differences between the message content that a consuming application is capable of submitting and the message content that a native service expects. For example, if the consuming application submits an order record using a slightly different structure than the structure expected by the native service, you can use the Request Processing step to transform the record submitted by the consuming application to the structure required by the native service.
Routing Step
The Routing step specifies the endpoint to which requests are to be routed and the protocol (HTTP or JMS) by which they are to be submitted to the native service.
If the native service is exposed over JMS, you use the routing step to specify the queue to which the Mediator is to submit the request and the destination to which the native service is to return the response.
If the native service is exposed over HTTP or HTTPS, you can configure this step to route all requests to a specified endpoint (straight through routing), route requests to different endpoints based on the content of the request (content-based routing), route requests to different endpoints based on factors such as the time of day or the requestor's IP address (context-based routing) or distribute requests across multiple endpoints (load-balancing routing).
Note: | When you configure the Routing step, you can either manually type the endpoint of the native service or you can select the endpoint from a list of known endpoints in the registry. As a best practice, you should always select the endpoint rather than typing it manually. The act of selecting an endpoint establishes a relationship between the virtual service and the native service that is hosted at the selected endpoint. This relationship is rendered when you examine the virtual service or the native service using the Impact Analysis feature. |
Using the Routing Step to Direct Requests across Multiple Endpoints
If you have a native service that is hosted at two or more endpoints, you can use the load balancing option in the Routing Step to distribute requests among the endpoints or you can use the content-based or context-based options to route different types of messages to different endpoints.
Using the content-based routing option, you can route messages to different endpoints based on specific values that appear in the request message. You might use this capability, for example, to determine which operation the consuming application has requested and route requests for complex operations to an endpoint on a fast machine.
Using the context-based routing option, you can route messages based on criteria such as the time of day and/or the identity of the consuming application. For example, you might use this capability to route requests from certain high-priority consumers to endpoints on a fast machine.
Note: | With either option, you must provide a default endpoint to which the virtual service can route requests that do not satisfy any of the specified criteria. |
Response Processing Step
The Response Processing step is similar to the Request Processing step. This step specifies how the response message from the native service is to be transformed or processed before it is returned to the consuming application. Like the Request Processing step, you can configure the Response Processing step to perform message transformations using a specified XSLT file or by calling the webMethods IS service. You can also use this step to return a customized error message to the consuming application when a SOAP fault occurs. (CentraSite provides a set of context variables that you can use to incorporate specific details about the transaction into the error message. You might use these variables to include information such as the time and date of the error, the consumer identifier, and/or the requester user ID.)
Configuring CentraSite for Virtual Services
Before you can create and deploy Virtual Services on your instance of CentraSite, there are two important configuration steps that you must perform.
You must define a gateway object for each instance of
webMethods Mediator that
CentraSite uses.
You must define a lifecycle model for services and virtual services.
Defining Gateways
Before you can deploy virtual services, you must define gateways to represent the Mediators that are attached to your instance of CentraSite. For example, if you will be deploying virtual services to two different Mediators, you must create two gateway objects, one for each Mediator instance.
Note: | CentraSite will not enable the Deploy button on the Deployment profile for a virtual service until at least one gateway has been defined on your instance of CentraSite. |
Understanding the Lifecycle for Services and Virtual Services
A virtual service is a specialized form of a Service asset type. Because virtual services are actually service objects, a lifecycle model that applies to services applies to virtual services as well. Yet a virtual service and a native service have distinctly different lifecycles. To accommodate this difference, you must create a lifecycle model that defines two separate lifecycle paths.
The following diagram shows a simple lifecycle model that supports both types of services. Note that this lifecycle has a path for native services and a path for virtual services. Policies are used to switch native services and virtual services to the appropriate path.
Note: | To distinguish virtual services from native services (that is, regular SOAP-based Web services, REST services or OData services), CentraSite adds the CentraSite VirtualTypes: Virtual services classifier to a virtual service. This classifier enables you to create design/change-time policies that target virtual services specifically. |
In the following example, the Proposed state is the lifecycle model's initial state. When a native service is created, it enters the Proposed state and from there, it follows the lifecycle path for native services. After a native service is tested and it is ready to be promoted for production, a virtual service is generated for it. The virtual service initially enters the Proposed state when it is created. However, a design/change-time policy immediately switches the virtual service to the lifecycle path for virtual services.
Simple Lifecycle of a Virtual Service on the Creation CentraSite
# | Description |
1 | The Proposed state is the initial state for this lifecycle model. When a native service is created, it enters the Proposed state and follows the lifecycle path for native services. |
2 | A virtual service is generated from the native service when the service is ready to go to production. Generally, this step is performed after the native service has been tested and is considered ready for production or after it has been promoted to the production environment. |
3 | The virtual service enters the lifecycle in the Proposed state, but a policy immediately switches it to the VS_New state, which is the beginning of the lifecycle path for virtual services. This lifecycle path includes states that enable or disable the deployment of the virtual service. Note: | To prevent users from manually switching a native service to the lifecycle path for a virtual service, you can apply a policy to the VS_New state to verify that only service assets classified as CentraSite VirtualTypes: Virtual services enter this path. |
|
Creating the Lifecycle Model for Services and Virtual Services
To create a lifecycle model that supports both native services and virtual services, you must perform the general steps described below.
1. Create a lifecycle model for the Service asset type and in this model define the sequence of states and transitions that make up the lifecycle path for a native service.
2. In the same lifecycle model (and following the sequence of states that you defined in the previous step), define the sequence of states and transitions that make up the lifecycle for a virtual service.
Note: | The lifecycle path for a virtual service must include at least one state that represents the point where the virtual service has been completely configured and is ready to be deployed. Before creating the lifecycle path for a virtual service, ensure that your lifecycle path includes the appropriate deployment-related states and policies. |
3. Define a transition from the initial state of the lifecycle model to the first state in the lifecycle path for virtual services. This will be the only transition that should connect the two lifecycle paths. In the following example, this is accomplished by allowing a transition from the Proposed state, which is the initial state for the entire model, to the VS_New state, which is the first state in the lifecycle path for a virtual service.
4. Apply a policy to the lifecycle model's initial state (PostStateChange) that switches the state of a virtual service to the first state in the lifecycle path for virtual services. Use the Classification filter to scope the policy so that it executes only for virtual services.
In the preceding example, Simple Lifecycle of a Virtual Service on the Creation CentraSite, this policy executes on the PostStateChange for the Proposed state and switches virtual services to the VS_New state.
5. Optionally, create a policy that executes on the VS_New state (PreStateChange) and verifies that the service includes the CentraSite VirtualTypes: Virtual services classifier. Doing this will prevent someone from inadvertently switching a native service to the virtual service lifecycle path.
Defining a Lifecycle Path that Enables Deployment of a Virtual Service
The virtual service's Deployment profile contains the controls that you use to deploy, undeploy and redeploy the virtual service. When the Deployment profile is disabled, you cannot perform these operations on the virtual service.
By default, the Deployment profile is disabled when you create a virtual service. This is to prevent anyone from deploying the virtual service until after its processing steps have been properly configured. To enable the Deployment profile, you must switch the virtual service to a state that triggers the execution of a policy that enables the Deployment profile.
When you define the lifecycle path for a virtual service, you must determine during which states the Deployment profile will be enabled and during which states it will be disabled. Then, you must create policies to enable or disable the Deployment profile as appropriate when the virtual service enters these states.
For example, if you wanted the Deployment profile to behave as shown in the lifecycle path below, you would apply a policy that enables the Deployment profile when the virtual service switches to the VS_Virtualized, VS_Certified or VS_Promoted state, and you would apply a policy to disable the Deployment profile when the virtual service switches to the VS_Revising or VS_New state.
Virtual Service Lifecycle Path with Deployment Status
Creating a Policy that Enables the Deployment Profile
To enable the Deployment profile for a virtual service, create a policy that contains the following action and apply this policy (on a PostStateChange) to all states during which you want the controls on the Deployment profile to be enabled.
Change Deployment Status (enable)
If you want to prevent users from modifying the processing steps for a virtual service after the Deployment profile is enabled, include the Processing Step Status action in the policy to disable the Processing Step profile as shown below.
Processing Step Status (disable)
Change Deployment Status (enable)
Creating a Policy that Disables the Deployment Profile
To disable the Deployment profile, create a policy that contains the following action and apply this policy (on a PostStateChange) to all states during which you want the controls on the Deployment profile to be disabled.
Change Deployment Status (disable)
If your lifecycle includes policies that automatically disable the Processing Step profile when the Deployment profile is enabled, this policy should include the Processing Step Status action to re-enable the Processing Step profile as shown below.
Change Deployment Status (disable)
Processing Step Status (enable)
Creating Virtual Services
To create a virtual service in CentraSite, you must select the native service for which you want to create the virtual service and run the Virtualize command. During the virtualization process, CentraSite copies the metadata (including the WSDL) from the native service to the virtual service. In other words, the virtual service is basically cloned from the native service.
Because the virtual service is cloned from the native service, it has its own copy of the service metadata. If you make a change to the metadata in the native service after you generate the virtual service, you will need to explicitly update the virtual service if you want that change reflected in the virtual service, too.
Note: | If the native service includes file attributes that refer to documents in the supporting document library, the virtual service will reference the same documents. CentraSite does not create separate copies of the supporting documents for the virtual service. The virtual service simply refers to the same supporting documents as the native service. |
When Should You Create a Virtual Service?
Generally speaking, you do not want to generate the virtual service unless the following conditions are satisfied:
The interface for the native service is completely implemented and that interface is reflected in the WSDL that is registered for the service in
CentraSite.
An instance of the native service is deployed and running at a known point in network.
The metadata for the native service is valid and up-to-date. If the metadata for the native service has not been completely specified or is out-of-date, you should update it before you generate the virtual service so that you do not carry inaccurate/incomplete data into the virtual service.
Important: | Take care when assigning names to your virtual services. The name given to a virtual service when it is created, cannot be changed afterwards. |
Who Should Create a Virtual Service?
If a user has View permission on a native service and Create Assets permission within their own organization, he or she can create a virtual service. However, the user will not be permitted to configure the processing steps for the virtual service unless he or she also has the Manage Runtime Policies permission for their organization. Only users with Manage Runtime Policies permission can configure these steps.
Consider identifying a small group of users who will be responsible for configuring the processing steps for a virtual service. Give this group a role that includes the Manage Run-time Policies permission. Because these users might configure virtual services that other users have created, they will also need Modify permission on the virtual services. To ensure that these users can edit the virtual services that they need to configure, consider creating a design/change-time policy that automatically gives this group Modify permission on a virtual service when it is created.
Virtual Service Ownership
One issue to consider when creating virtual services is the issue of ownership. When you create a virtual service, CentraSite automatically adds the virtual service to your organization (even if the native service itself belongs to another organization). You cannot explicitly specify the organization to which you want the virtual service added.
The issue of ownership is important with respect to virtual services, because it determines which run-time policies are applied to the virtual service when it is deployed. If the native service belongs to another organization, the existing run-time policies for your organization might or might not be appropriate for it.
When you define the general process that your site will follow to create and deploy virtual services (that is, when you determine who will create a virtual service, who will configure a virtual service, and who will deploy a virtual service), keep in mind that CentraSite always adds a virtual service to the organization of the user who creates it. Make sure that whatever process you adopt for creating virtual services places a virtual service in the appropriate organization.
Deploying a Virtual Service
There are several ways you can deploy a virtual service to a Mediator instance. All methods except the first one allow you to deploy multiple virtual services in a single step.
From the virtual service's detail page.
From the
Operations > Deployment page.
Running a script file from a command line.
Running a batch file.
To deploy a virtual service, the following conditions must be satisfied:
Ensure that you have the Mediator Publisher Role or the publish permission on the gateway. Only users with this permission can deploy a virtual service.
CentraSite will not enable the deployment controls for any other users.
Ensure that the run-time policies for the Virtual Service are active. This is indicated in the
Policies profile on the Virtual Service's detail page. If a policy is inactive, you must activate it.
Ensure that the Virtual Service has a design-time policy that includes the Change Deployment Status action and it is set to Yes. This action specifies whether the service is eligible for deployment.
Ensure that the Virtual Service has at least one gateway associated with it, and the gateway must already have been created.
Ensure that the gateway's specified deployment URL is active and the user credentials of
Integration Server are valid. To check this, go to the gateway details page and click the
Check Connection button. If the connection is not active and valid, activate the deployment endpoint and modify the user credentials as required.
Ensure that the Virtual Service is in a deployable lifecycle state. If you are not certain in which lifecycle states a Virtual Service is eligible for deployment, consult your
CentraSite administrator.
If these conditions are not satisfied, all or part of the deployment user interface controls will be disabled when you view the virtual service.
Note: | Only users that are completely familiar with your site's mediation environment should be given permission to deploy virtual services. Generally, this would include a small number of administrators who have operational responsibility for the Mediators on which virtual services are deployed. |
The Deployment Process
The deployment process is carried out by a sequence of interactions that occur between CentraSite and the Mediator:
1. CentraSite pushes the Virtual Service that is ready for deployment to the webMethods Mediator gateway.
2. Instantly, the Mediator deploys the Virtual Service that was received from CentraSite (along with its effective run-time policy), and notifies CentraSite when the deployment process is complete.
Undeploying a Virtual Service
After you deploy a virtual service to a Mediator, the virtual service remains deployed and active on that Mediator until you manually undeploy. You can deploy a virtual service using the same deployment mechanisms mentioned above.
Redeploying a Virtual Service
A virtual service that is already deployed on a Mediator can be manually redeployed. You can redeploy a virtual service using the same deployment mechanisms mentioned above. If you make changes to a virtual service's processing steps, for example, you must manually redeploy the virtual service to put those changes into effect.
You cannot make changes to a run-time policy while it is active. To make changes to a policy after it has been switched to the active state you must do one of the following:
Switch the policy to the Suspended state (to deactivate it), update the policy and then switch it back to the Productive state (to reactivate it).
Create a new version of the policy, make your changes to the new version of the policy and then switch the new version to the Productive state. Switching the new version of the policy to the Productive state will automatically retire (and deactivate) the old version.
If you need to update a run-time policy that is already deployed with virtual services that are in production, always use the second method described above (that is, create a new version of the policy). If you use the first method, which requires you to suspend the existing policy, your production services will be running without the policy while you are making your revisions to it.
Revising a Virtual Service
Web services are bound to change and evolve over time. The loose coupling principles of service-oriented architecture (SOA) imply that service providers can release a new version of a shared service without waiting for consumers to adapt, and that service consumers should test and certify on a new shared service version before switching. Consequently, you might need to have multiple versions of a shared service running concurrently and simultaneously accessible by different service consumers. Some service consumers might need to continue using an old version of a service until migration of the consumer code occurs. Therefore, Web services versioning is an important subject that should be considered carefully in all enterprise SOA approaches.
Current standards for Web services have no explicit support for versioning. However, there are two alternatives for handling access to multiple versions of Web services:
Require the consumer applications to change their code to specify which versions to access.
This option is rarely implemented due to its prohibitively complex and time-consuming nature.
Use a mediation layer (for example,
Mediator) to decouple the consumer from the provider, and thus allow the mediation layer to route requests to the desired version of a given service.
Mediator provides versioning solutions that you can implement, called versioning patterns. To implement versioning patterns, you configure virtual services in CentraSite so that consumers can access the desired version of a given service. You can use the versioning patterns to handle access to both Minor and Major versions of services.
Mediator cannot run multiple versions of the same virtual service simultaneously. Mediator only retains the last deployed version of a virtual service. However, suppose you have multiple versions of a native Web service. By using a versioning pattern, a single virtual service can provide access to the various native service versions based on an intelligent routing scheme that routes requests from a particular consumer to the correct native service version. A second option would be to provide multiple virtual services that correspond to multiple native service versions. For example, suppose you have two versions of the native service GetOrder. You have the following options in Mediator:
Provide a single virtual service that intelligently routes each consumer to the appropriate GetOrder version (either version 1 or version 2).
Provide one virtual service that routes consumers to version 1, and one virtual service that routes consumers to version 2.
Minor Versions vs. Major Versions
Minor and Major versions of Web services are described as follows:
Minor version: A Minor version is a version that is compatible with all consumers of the existing virtual service. That is, the changes in a Minor version do not break the existing applications that use the service. Examples of changes for a Minor version include:
Bug fixes
Performance improvements
The addition of a supporting document
The addition of operations (as long as it does not break the existing applications)
A change in the Description attribute
Major version: A Major version is a version that is
incompatible with consumers of the existing virtual service. That is, the changes in a Major version “break” the existing applications that use the service. Examples of a Major version include:
Modifications to the namespace assignments
Modifications to message descriptions
Modifications to interface definitions and/or operation signatures in the service WSDL
Changes to the implementation of the service that do not explicitly affect the WSDL, but nevertheless affect the way in which an existing consumer application interacts with the service
For example, a service that returns an expanded set of result codes or generates a different form of customer ID might break an existing consumer application even if the interface defined in the service WSDL did not change.
Note: | Be aware that sometimes versioning one asset will necessitate the versioning of another. For example, if an XML schema changes and that schema is imported by a Web service, you will need to generate a new version of the XML schema and a new version of the Web service that references it. |
The Layer of Indirection Pattern
This pattern allows multiple Minor versions of a native service to coexist in the registry without requiring consumers to change the code in their consumer applications, and helps to ensure a graceful migration to the new Minor version.
To implement this pattern, you configure a single virtual service to route each request to the version that is appropriate for each consumer (or group of consumers). That is, you configure the virtual service's Routing step to use either the content-based routing option or the context-based routing option.
Content-based routing option: Using the content-based routing option, you can route request messages to different endpoints based on specific values that appear in the request message. For example, if a new Minor version contains an additional operation, you can write a rule that routes all requests that reference the newly-added operation to the new Minor version.
Context-based routing option: Using the context-based routing option, you can route request messages to different endpoints based on the identity of the consuming application. For example, if you want to allow only certain consumers to access a new Minor version, you write a rule that routes only their requests to the new Minor version.
The Adapter Pattern
This pattern allows multiple Major versions of a native service to coexist in the registry without requiring consumers to change the code in their consumer applications, and helps to ensure a graceful migration to the new Major version.
This is called the adapter pattern because Mediator will act as an adapter, adapting the client requests before they are submitted to the native services.
Unlike the Layer of Indirection pattern, which has one virtual service that can access each Minor version of the native service, this pattern has a separate virtual service for each Major version of the native service.
To implement this pattern, you configure the virtual service's Request Processing step so that it transforms the endpoint specified in a request to the endpoint of the desired version. The Request Processing step specifies how the request message is to be transformed before it is submitted to the native service. You can configure this step to perform message transformations using a specified XSLT file or by passing the message to a webMethods IS service (that is, an Integration Server service running on the same Integration Server as webMethods Mediator).
Combination of the Layer of Indirection Pattern and the Adapter Patterns
This pattern has one virtual service that can access:
Multiple Major versions of a native service (that is, utilizing the Adapter pattern).
Thus you configure the virtual service's Request Processing step so that it transforms the endpoint specified in a request to the endpoint of the desired version.
Thus you configure the virtual service with either the content-based routing option or the context-based routing option in order to route requests to the Minor version that is appropriate for each consumer (or group of consumers).
