A virtualized service is a service that runs on webMethods Mediator and acts as the consumer-facing proxy for a service that runs elsewhere on the network. You can create a virtualized service for a SOAP-based Web service, a REST service or an XML service. A virtualized 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, virtualized services enable you to:
Move native services to other physical addresses or switch providers without affecting existing consumer applications.
Bridge differences (e.g., 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 (i.e., 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 virtualized services and to deploy them on specified Mediators. After you deploy a virtualized service, you use CentraSite as a "dashboard" from which to view performance metrics and other run-time data relating to the usage of a virtualized service.
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 (e.g., cloud computing)
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 (e.g., 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/or 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: |
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.
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 (an inventory control service that you extend to suppliers and/or distributors, for example).
A virtual service is a Web service that runs on webMethods Mediator. You use CentraSite to create, edit, deploy 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.
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 section.
One or more targets. The Deployment profile for a virtual service 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 (e.g., SLA violations, service failures, logged request/response messages and so forth).
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:
The Entry Protocol step
The Request Processing step
The Routing step
The Response Processing step
You configure these steps to specify how Mediator is to act upon the requests it receives for this virtual service.
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 (described below) 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.
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 passing the message to a webMethods IS service (i.e., 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.
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.
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.
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 passing the message to a 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 requestor's user ID.)
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 target object for each instance of webMethods Mediator that CentraSite will use.
You must define a lifecycle model for services and virtual services.
Before you can deploy virtual services, you must define targets 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 target 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 target has been defined on your instance of CentraSite.
To deploy virtual services, you must define a lifecycle model for services and virtual services. You must also create policies that enable and disable the Deployment profile depending on the state of the virtual service within this lifecycle. You cannot deploy virtual services until this lifecycle model and the necessary deployment-related policies exist and have been activated.
Note:
The starter kit includes a lifecycle model for services and virtual
services that you can use as a guide. For more information about the starter
kit, see Obtaining and Installing
the Starter Kit.
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 (i.e., regular
SOAP-based Web services, REST services or XML 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 create a lifecycle model that supports both native services and virtual services, you must perform the general steps described below.
Note:
To see how the following steps have been implemented in an actual
lifecycle model, install the starter kit and refer to the lifecycle model for
services and virtual services. For more information about the starter kit, see
Obtaining and Installing the
Starter Kit.
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.
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, review the information in
Creating a Policy that Enables the
Deployment Profile to ensure that your lifecycle path includes the
appropriate deployment-related states and policies.
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 example depicted in Understanding the Lifecycle of Services and Virtual Services, 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.
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 example depicted in 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.
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.
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
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) |
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) |
Note:
To see how these policies are implemented in an actual lifecycle
model, install the starter kit and examine the policies associated with the
lifecycle model for services and virtual services. For more information about
the starter kit, see Obtaining
and Installing the Starter Kit.
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.
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.
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.
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 (i.e., 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.
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.
From the target's detail 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 "Manage RuntimeTargets" permission. 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 virtualized service are active. This is indicated in the Policies profile on the virtualized service's detail page. If a policy is inactive, you must activate it as described in the section Virtual Services in CentraSite Control > Creating Run-Time Policies .
Ensure that the virtualized 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. For more information about this action, see the section Built-In Design/Change-Time Actions Reference > Built-In Actions for Design/Change-Time Policies .
Ensure that the virtualized service has at least one target associated with it, and the target has must already have been created, as described in the section Run-Time Targets.
Ensure that the target's specified deployment URL is active and the user credentials of Integration Server are valid. To check this, go to the target's detail page and click the button. If the connection is not active and valid, activate the deployment endpoint and modify the user credentials as required.
Ensure that the virtualized service is in a "deployable" lifecycle state. If you are not certain in which lifecycle states a virtualized 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 is carried out by a sequence of interactions that occur between CentraSite and the Mediator:
CentraSite pushes the virtualized service that is ready for deployment to the webMethods Mediator target.
Instantly, the Mediator deploys the virtualized service that was received from CentraSite (along with its effective run-time policy), and notifies CentraSite when the deployment process is complete.
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.
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.
As described in Modifying a Run-Time Policy, 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).
OR
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 (i.e., 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.
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 (e.g., 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).
Or
Provide one virtual service that routes consumers to version 1, and one virtual service that routes consumers to version 2.
This section discusses the following topics:
Minor and Major versions of Web services are described as follows:
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.
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.
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.
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.
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.
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 (i.e., an Integration Server service running on the same Integration Server as webMethods Mediator).
This pattern has one virtual service that can access:
Multiple Major versions of a native service (i.e., 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..
Multiple Minor versions of a native service (i.e., utilizing the Layer of Indirection pattern).
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).
