CentraSite 10.5 | CentraSite User’s Guide | Runtime Governance | Virtual Service Asset Management | Managing Virtual Service Assets through CentraSite Control | Virtual SOAP Service Management | Configuring Virtual Services | Configuring Load Balancing Routing
 
Configuring Load Balancing Routing
If your Entry Protocol is HTTP or HTTPS, you can choose to use the Load Balancing routing protocol. (Alternatively, you can choose Straight Through, Content-Based, or Context-Based routing.)
If you have a Web service that is hosted at two or more endpoints, you can use the Load Balancing option to distribute requests among the endpoints.
Requests are distributed across multiple endpoints. The requests are intelligently routed based on the Round-Robin execution strategy. The load for a service is balanced by directing requests to two or more services in a pool, until the optimum level is achieved. The application routes requests to services in the pool sequentially, starting from the first to the last service without considering the individual performance of the services. After the requests have been forwarded to all the services in the pool, the first service is chosen for the next loop of forwarding.
Load-balanced endpoints also have automatic Failover capability. If a load-balanced endpoint is unavailable (for example, if a connection is refused), then that endpoint is marked as Down for the number of seconds you specify in the Suspend the Failed Endpoint field (during which the endpoint will not be used for sending the request), and the next configured endpoint is tried. If all the configured load-balanced endpoints are down, then a SOAP fault is sent back to the client. After the suspension period expires, each endpoint marked will be available again to send the request.
*To configure Load Balancing routing
1. In CentraSite Control, go to Asset Catalog > Browse.
2. In the displayed list of asset types, select Virtual Service.
3. In the Assets pane, right-click the Virtual Service you want to configure, and click Details.
The Virtual Service Details page is displayed.
4. In the Processing Steps tab, click Routing Protocols.
5. In the Routing Protocols tab, provide the required information for each of the displayed fields, and click Save:
Field
Description
HTTP or JMS
Select HTTP.
Routing Type
Select Load Balancing.
Route To
The URLs of two or more Native Services in a pool to which the requests will be routed. The application routes the requests to services in the pool sequentially, starting from the first to the last service without considering the individual performance of the services. After the requests have been forwarded to all the services in the pool, the first service is chosen for the next loop of forwarding.
To specify the first service, click Endpoint and select the URL of the Web service to route the request to. To specify additional services, use the plus button next to the field to add rows.
Alternatively, Mediator offers Local Optimization capability if the Native Service and the Virtual Service (in Mediator) are located on the same machine. With local optimization, service invocation happens in-memory and not through a network hop. In the Default To field, specify the Native Service in either of the following forms:
local://<service_full_path>
OR
local://<server>:<port>/ws/<service_full_path>
For example:
local://MediatorTestServices:NewMediatorTestServices_Port
which points to the endpoint service NewMediatorTestServices_Port which is present under the folder MediatorTestServices in Integration Server. This works for HTTP endpoints only, for all types of Routing Protocols.
Configure Endpoint Properties (icon)
The Configure Endpoint Properties icon displays a dialog box that enables you to configure a single set of properties that will be shared by all the endpoints. In the dialog box, specify the following fields:
*SOAP Optimization Method: Optional. Mediator can accept the following optimization methods to optimize the payloads of SOAP requests:
*MTOM: Indicates that Mediator expects to receive a request with a Message Transmission Optimization Mechanism (MTOM) attachment, and will forward the attachment to the Native Service.
*SwA: Indicates that Mediator expects to receive a “SOAP with Attachment” (SwA) request, and will forward the attachment to the Native Service.
*None (the default).
1. Bridging between SwA and MTOM is not supported. If a consumer sends an SwA request, Mediator can only forward SwA to the native provider. The same is true for MTOM, and applies to responses received from the native provider. That is, an SwA or MTOM response received by Mediator from a native provider will be forwarded to the caller using the same format it received.
2. When sending SOAP requests that do not contain a MTOM or SWA attachment to a Virtual Service for a native provider endpoint that returns an MTOM or SWA response, the request Accept header must be set to multipart/related (or the Virtual Service's Request Processing Step should include an Virtual Service that sets the BUILDER_TYPE context variable to multipart/related). This is necessary so Mediator knows how to parse the response properly.
*WSS Header Customization: Indicates whether Mediator should pass the WS-Security headers of the incoming requests to the Native Service.
*Pass all security headers: Passes the security header, even if it is processed by Mediator (that is, even if Mediator processes the header according to the Virtual Service's security run-time policy).
Note:
If the Virtual Service does not contain a security run-time policy, and the mustUnderstand attribute of the security header is 0 or false, then Mediator will always forward the security header to the Native Service.
*Remove processed security header from request before routing: Removes the security header if it is processed by Mediator (that is, if Mediator processes the header according to the Virtual Service's security run-time policy). Note that Mediator will not remove the security header if both of the following conditions are true: 1) Mediator did not process the security header, and 2) the mustUnderstand attribute of the security header is 0 or false).
*HTTP Connection Timeout: The time interval (in seconds) after which a connection attempt will timeout. If a value is not specified (or if the value 0 is specified), Mediator uses the value of the global property pg.endpoint.connectionTimeout located in the file Integration Server_directory\packages\WmMediator\config\resources\pg-config.properties. The default of that property is 30 seconds.
*Read Timeout: The time interval (in seconds) after which a socket read attempt will timeout.
The precedence of the Read Timeout configuration is as follows:
1. If a value is specified for the Read Timeout field in the routing endpoint alias, Mediator will use the value specified in the Runtime Alias > Endpoint Alias > Endpoint Properties > Read Timeout field. The read timeout value defined at an alias level takes precedence over the timeout values defined at an API level and the global configuration.
2. If a value 0 is specified (or if the value is not specified) for the Read Timeout field in the routing endpoint alias, then Mediator will use the value specified in the Read Timeout field of this step. The read timeout value defined at an API level takes precedence over the global configuration.
3. If a value 0 is specified (or if the value is not specified) for the Read Timeout field in this step (at an API level), then Mediator will use the value of the global property pg.endpoint.readTimeout located in the file Integration Server_directory\packages\WmMediator\config\resources\pg-config.properties (in the Mediator Administration console, go to > Settings > Extended Settings > pg.endpoint.readTimeout property.).
Note:
If a value for the Read Timeout configuration is not specified in any of the above configuration parameters, then Mediator will use the default 30 seconds.
*SSL Options: To enable SSL client authentication for the endpoint, you must specify values for both the Client Certificate Alias field and the IS Keystore Alias field. If you specify a value for only one of these fields, a deployment error will occur.
Note:
SSL client authentication is optional; you may leave both fields blank.
*Client Certificate Alias: The client's private key to be used for performing SSL client authentication. If you specify a client certificate alias, you must also include in the Virtual Service's policy the Require SSL action and select that action's Client Certificate Required option. The Client Certificate Required option specifies whether client certificates are required for the purposes of: 1) Verifying the signature of signed SOAP requests or decrypting encrypted SOAP requests, and 2) Signing SOAP responses or encrypting SOAP responses.
*IS Keystore Alias: The keystore alias of the instance of Integration Server on which Mediator is running. This value (along with the value of Client Certificate Alias) will be used for performing SSL client authentication.
Suspend the Failed Endpoint
A numeric timeout value (in seconds).
Default: 30. When this timeout value expires, the system routes the execution of the Virtual Service to the next consecutive Web service endpoint specified in the Route To field.
HTTP Authentication
Authentication Scheme: Specify the mode of authentication: Basic Authentication (default), NTLM, OAuth2 or None.
Basic Authentication. Select one of the following options:
*Use credentials from incoming request: (default): Authenticates requests based on the credentials specified in the HTTP header. Mediator passes the Authorization header present in the original client request to the Native Service.
*Use specified credentials: Authenticates requests according to the values you specify in the User, Password and Domain fields.
NTLM. Note that if Mediator is used to access a Native Service protected by NTLM (which is typically hosted in IIS), then the Native Service in IIS should be configured to use NTLM as the authentication scheme. If the authentication scheme is configured as Windows, then NTLM should be in its list. The Negotiate handshake will be supported in the near future. This note applies to all three of the following options for NTLM:
*Use credentials from incoming request: Default. Mediator uses the user credentials passed in the request header for an NTLM handshake with the server.
*Use specified credentials: Mediator uses the values you specify in the User, Password and Domain fields for an NTLM handshake with the server.
*Transparent: If the property watt.pg.disableNtlmAuthHandler is set to false (the default), then Mediator will behave in pass by mode, allowing an NTLM handshake to occur between the client and server. If the property watt.pg.disableNtlmAuthHandler is set to true, then Mediator performs the Kerberos Windows authentication (and not NTLM Windows authentication). This property is located in Integration Server_directory\instances\instance_name\config\server.cnf. Note: If the client is a WCF application, then the client should be configured with clientCredentialType set to NTLM.
OAuth2. Click one of the following options:
*Use credentials from incoming request: Default. This is known as pass through mode, in which the consumer includes an OAuth2 access token (a Bearer type token) in the request. Mediator then passes the access token unchanged to the native OAuth server.
*Use specified token: In this mode, the consumer does not include an OAuth2 access token in the request. Instead, the provider generates an OAuth2 access token for each consumer, and Mediator stores the access tokens in Passman. When consumers send requests, Mediator obtains the OAuth2 access tokens from Passman and uses them to access the Native Services. Specify an OAuth access token to be deployed by Mediator. If you select this option, the consumer need not pass the OAuth token during service invocation. Click Show Token to view the OAuth access token. Users who do not have the permissions to create and manage Virtual Services will not see this button.
Specify an OAuth access token to be deployed by Mediator by clicking Show Token and selecting an OAuth access token. Users who do not have the permissions to create and manage Virtual Services will not see this button.
Note:
Here are some general guidelines:
*You must set the Integration Server property watt.server.auth.skipForMediator to true and then restart Integration Server for the change to take effect. This property is located in the server configuration file (server.cnf), which is located in the Integration Server_directory\config directory. For details, see the webMethods Integration Server Administrator's Guide.
*The run-time actions “Require HTTP Basic Authentication” and “Identify Consumer” (with the value HTTP Authentication Token as the identifier) will not be enforced when using the authentication scheme OAuth2.
None. Select the following option:
*Invoke Service Anonymously: Does not authenticate requests.
HTTP Headers
The HTTP headers that you want to use to authenticate the requests.
*Use Existing: Use the HTTP headers that are contained in the requests.
*Customize: Use the HTTP headers that you specify in the Name and Value columns below. If you need to specify multiple headers, use the plus button to add rows.