Mediator design pattern


I am trying to understand various design patterns when Mediator is added to an existing IS based service landscape.

  1. Is communication between Mediator and IS service always HTTP? This will contribute to overall latency of the virtual service.
  2. Consumer -> Enterprise web service -> provider. In this scenario, where to put virtual service?
    2.a Consumer -> VS -> Enterprise web service (IS) -> VS -> Provider web service.

I think above setup is required for protocol and security bridging between consumer and provider.

  1. Consumer -> VS -> Provider

Above pattern uses IS for request and response transformation. Incoming and outgoing policies can be enforced in Mediator. No need of inbound and outbound virtual services.

  1. Can the same provider service be exposed over HTTP and JMS? In this case, I am assuming 2 virtual services to be created one for HTTP and one for JMS.

  2. Can VS route to another VS? What will be mode of communication here? HTTP or some sort of native protocol?

  3. Where can I get more details in these topics?


  1. local optimization can be used if the native IS services reside on the same IS. JMS can also be used to invoke native services.
  2. What is the use case for having both a virtual service and an “Enterprise web service”? Are there other consumers of the “provider web service”?
    2.a Again, what is the use case for the “Enterprise web service”? How is it different from a virtual service? Can you call IS services from the request or response processing step to achieve whatever additional processing is being considered?
  3. Not sure what is being asked here…
  4. Yes, each VS provides a different facade for the consumer applications to use
  5. Yes, technically possible as the VS is exposed as a web service. Communication is the same as with any other virtual service.
  6. CentraSite documentation is under the “webMethods” area - Additional topics, utilities, tools can also be found in the Communities site -