Service Virtualization

Hi,

I am new(3 days) to CA LISA, we are using v9. We have a requirement from a client as an interim solution to create a virtual service with pass through and routing capabilities. This service will only route the web service requests to already deployed web services. So, if a request hits this new router service it will inspect the request and route to already existing deployed virtual service. So my questions:

- is it advisable to do this as an interim or a long term solution? to create a router service and all client requests for different virtual service hits this service first. 

-if this can be done by editing the VSM, then please direct me to some example documentation which I can use and also which step in the VSM should be used to do this (some detailed examples would be really helpful).

Hopefully I have explained the requirement adequately.

Any help or pointers would be really appreciated.

Your assignment seems a bit unusual since it adds an intermediate layer of HTTP overhead.  

But, you might consider the following pattern as one of many designs that may work:

1) The Listener step is receiving the request from the consumer.  Add in the desired DPHs to filter out the data you need.

2) The Logic to Determine Endpoint Host and Port step, accesses the incoming request properties, evaluates them to determine the name of the endpoint (since you indicate there can be more than one endpoint).  This step also creates two DevTest properties.  One is called targetServer and the other is called targetPort.  I depicted this in the model as a step, but you could potentially implement the behavior as a Scriptable DPH in the Listen Step.  

Regardless, you will most likely need to use scripting logic (beanshell, groovy, etc.) to access and evaluate the input to determine the endpoint and set the targetServer and targetPort properties.  (Ideas RE logic and syntax not included in this post and are likely to require some knowledge of the basic SDK for accessing values in the lisa_vse_request object.) 

3) The Virtual HTTPS Live Invocation step forwards the original incoming request to the endpoint using the {{targetServer}} and {{targetPort}} properties you assign in Step 2.  You override that as shown below.  This makes the forwarding dynamic.

4) And, the Virtual HTTPS Responder step, sends the response from the Live or Virtual Endpoint back to the consumer and loops to the Listen step to await the next request.

There are some caveats that may apply to non-identified requirements:

- If the service has to support a mixture of HTTP and HTTPS Live Invocation calls, you need to two (2) Live Invocation steps (one HTTP & one HTTPS) and some branching logic to get to the correct invocation step.

- The service listen step will either be HTTP or HTTPS -- a single deployed service can not listen for both types of inbound traffic.

- Something in the request (e.g., either the URI, data in the header, or data in the incoming request body) must provide the necessary information for the service to identify the target host; otherwise, the service does not know which of the live invocation endpoints are to receive the request. 

- The service shown above is merely routing incoming requests As-Is.  It is not altering the content of the incoming request headers, body, or URL, except for host & port.

- If this is a functional VSE and the number of requests is high, you could potentially experience slower response or HTTP timeouts since the functional VSE license throttles the TPS rate on a service like this.

You might get fancy and let the service pass the request to the VSI Selection Step.  The VSI might be able to evaluate the request and have its response contain the endpoint and port.  If you did this, you would need scripting logic to marshal the response endpoint and port into the properties in your Live Invocation step.

Adviteeya,

Did Joel's recommendations help you out?

Regards,

Reid

Reid,

Yes, Joel's recommendations did help. We are using the skeleton he has recommended. The simple steps we are currently testing:

1) Parse the incoming request for an unique operation name; and

2) Use a custom created xml to get the target host and port value based on the operation name to route the incoming request to the target virtual service.

Advi