Planning your bus-enabled web services installation

Consider how your environment will be configured to support service integration bus-enabled web services. Determine which of the bus-enabled web services roles you want each server to perform.

Figure 1. A service integration environment
In this figure, a client request is received by an endpoint listener, then passed through an inbound port to an inbound service. The outbound service passes a request through an outbound port to an external service.
These figures show the main component types and flows for bus-enabled web services. Of all these component types, only three interact directly with the world outside the bus:
  • The endpoint listeners.
  • The outbound ports (which act as service invokers).
  • The service destinations (which provide mediation points).
By configuring these component types for a given server, you enable that server to perform one or more of the following associated bus-enabled web services roles:
  • Endpoint. Incoming requests to use an internally-hosted service (an inbound service) are received at an endpoint, then passed to an inbound port and sent on to the service destination. Responses follow the same path in reverse.
  • Service invoker. When you create an outbound service (a mapping to an externally-hosted target service) you configure an outbound port for each port defined in the target service WSDL. The service is invoked by passing messages between the outbound service and the target service through the most convenient available port.
  • Mediation point A mediation is deployed to a server, then configured for a specific service destination. The mediation acts on messages that pass through the mediation point (service destination). The action taken by a mediation depends upon the specific instructions you give in the mediation handler. For example, you can use a mediation to change the contents of a message, or to choose a particular forward route for a message.