Accessing services external to an application

This scenario discusses different ways to access services that are external to the application, and provides high level tasks for accessing these external services.

In an integrated business application, business services interact with each other to provide a required function. A business service performs a repeatable function or task that contributes towards achieving a business goal. But the work of locating a service and connecting to it is not related to the business function. Separating the business function from the task of managing service connections provides flexibility to a solution.

Service interaction begins when a service requester sends a request to a service provider to perform a business function. This request is sent in the form of a message, which defines the function to be performed. The service provider performs the requested function and sends the result in a message to the service requester. Typically, messages need to be processed in order to allow the services to exchange data, and to implement other low level IT functions that are independent of the business functions and data. For example, routing, protocol conversion, transformation, retry of a failed invocation, and dynamic service invocation. This processing is known as mediation.

There are two types of modules in IBM Integration Designer; modules (or business integration modules), which are primarily designed to contain business logic (such as business processes, business rules and business state machines), and mediation modules, which implement mediation flows. Although there is some overlap of function between the two types of modules, in general, we recommend that business logic be isolated in business modules and mediation logic be performed by mediation modules.

But there is not always a clear separation between business and mediation logic. In these cases, consider the amount of state, or data in variables that will need to be processed between service invocations. In general, if there is little or no state processing required, consider using a mediation flow component. If you need to store state between service invocations, or if you have data that will need to be stored in variables and processed, consider using a business process component. For example, if you are calling multiple services and recording the information that is returned from each, so that after invoking all the services, you want to do some further processing with the returned data, use a business process where you can easily assign the returned information to variables. In other words, when you have too much state you have crossed the line into business logic. The following sections help clarify this guidance.

There is no one integration scenario, and there is no technically wrong answer. The guidelines that we discuss here are good practice to enable flexibility and reuse, and are presented for your consideration. As usual, you should carefully consider the benefits and drawbacks of implementing these patterns for your business integration application. Let's consider some situations.

Accessing an SCA component

A basic example of accessing a service is when an import calls another SCA component, without requiring any data transformation. Even in this situation, you could access the external service from a mediation module, rather than accessing it directly from a business module. This would allow flexibility in the future, for changing the service endpoint or qualities of service or governance (for example, adding logging) without impacting the business components that consume the service. This architectural pattern is known as "separation of concerns".

Before you decide to implement this pattern, weigh the benefits of the pattern against the potential effects of overhead introduced by another module. If your main requirement is flexibility, and you are going to make frequent changes to the services accessed, consider using a separate module as shown here. If performance is most important, and you are willing to update and redeploy the business logic, consider using a single module.

Here are the high level tasks to achieve this example.

1. Create a mediation module. For step-by-step instructions, see Creating mediation modules .
2. In the mediation module, create an import with the appropriate binding for the external service that you want to access. For step-by-step instructions, see Creating imports. For more information on bindings, see Bindings
3. Create an export, and give it the same interface as the import. For step-by-step instructions, see Creating exports.
4. Generate an SCA binding for the export. For step-by-step instructions, see Generating SCA bindings
5. In the mediation module's assembly, wire the export to the import. Save the mediation module.
6. Create a module. For step-by-step instructions, see Creating a module for business services
7. Add an export, and a component.
8. In the Business integration view, drag the export that you created in the mediation module (in step 4) into the module assembly. An import with the same binding as the export will be created.
9. Wire the export to the component, and the component to the import.
10. Add the component's implementation. For information on implementation types, see Implementations

Later, you can add mediation logic such as logging or routing to the mediation module without affecting the business module.

Adding mediation

Sometimes it is not sufficient to simply invoke an external service. Sometimes you need to do processing first, by adding a mediation module as an intermediary between the service requester and provider.

These are some of the functions that the intermediary mediation flow would perform:

• Setting protocol headers. For more information, see Protocol conversion in the WebSphere Enterprise Service Bus information center.
• Interface or parameter transformation by using a Business Object Map or Mapping primitive.Transforming messages
• Selecting a particular service from a static list, by using a Message Filter primitive.Message filter
• Invoking multiple services to aggregate the results, by using the Fan out and Fan In primitives.Aggregating and broadcasting messages
• Dealing with service invocation failures by retrying the same service or invoking a different service, by using a Service Invoke primitive. Retrying a failed service invocation
• Dynamic routing by choosing which service to use at the run time, rather than integration time, which enables services to be more loosely coupled and businesses to react faster to change. New services can be added without touching the modules that have been deployed to the runtime environment. Dynamic routing is most powerful when used with a registry, which requires the Endpoint Lookup mediation primitive to be used.Selecting endpoints dynamically

Accessing Enterprise Information Systems

Services and artifacts on external systems can be imported into Integration Designer. A wizard discovers applications and data on an Enterprise Information System (EIS) and lets you generate services from the discovered applications and data. The generated artifacts are interfaces and business objects, which can be used by components in a module.

Using an intermediary mediation module between a module and a host system makes it more reusable. In the example below, a mediation flow is used to route to the correct host system, and to transform the data to the format required by the host system.

Here are the high level tasks for this example:

1. Use the external service wizard to connect to the host system. Using the external service wizard to access external services follows a similar pattern regardless of the adapter you are using. For information on how to use the external service wizard, see Pattern of accessing external services with adapters
2. Create a module. For step-by-step instructions, see Creating a module for business services
3. Add an export, a component, and an import with SCA binding. For more information, see Calling services
4. Add an interface to the export, and wire the export to the component.
5. Add the component's implementation. In the implementation, set a property that indicates which host service will be accessed. For information on implementation types, see Implementations
6. Create a mediation module with an export that has an SCA binding, and the same interface as the import of the module that you created in step 2.
7. Wire the export to a mediation flow component.
8. Create an import for each host system that you want to access, using the appropriate outbound adapter from the assembly editor palette.
9. Wire the mediation flow component to the imports.
10. Implement the mediation flow component. Use a Message Filter primitive to choose the import based on a property set in the business logic, and use a Mapping primitive for each adapter import. Message filter.
11. In the module, select the mediation module's export as the service to be imported into the module. For step-by-step information, see Invoking a service from another module.

Later, you can make a change such as adding an adapter, or changing an adapter to point to a different host system, with minimal impact to the business logic.