Network Deployment (Distributed operating systems), v8.0 > Applications > Web services > Bus-enabled web services
Plan your bus-enabled web services installation
Consider how the 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 or cluster to perform.
Figure 1. A service integration environment with a gateway 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 stand-alone server or cluster, you enable that server or cluster 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 or cluster, 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.
You might choose to use a cluster rather than a stand-alone application server to support a role for any of the following reasons:
- Reliability.
- Scalability.
- Performance.
For example, in a production environment you would typically use a cluster to act as an endpoint.
There is a fourth role of Configuration connection point. This role is never provided by a cluster; only a dmgr or an unfederated stand-alone server can act as a configuration connection point.
Concept topic