WebSphere

Flexibility and reuse

With a service-oriented architecture (SOA) you can reuse existing resources, and integrate with external systems. This section covers the concepts of flexibility and reuse in an SOA, and how an enterprise service bus (ESB) enables these concepts.

Introduction

An SOA enables services to be consumed more effectively, so you can respond faster to business needs. By working with common interfaces, you can more rapidly integrate external systems into an existing environment.

Planning

When you are planning how to reuse services in a flexible way, consider the following factors:
  • The addresses of service endpoints can be stored in a number of different ways. You can configure endpoints when you assemble your module or, for more flexibility, you can store endpoint information in a registry or a database.
  • More than one service might be able to fulfil a service request. If you use a registry, you can get a list of services that meet certain criteria.
  • The criteria for routing messages can be simple, or complex. Messages can be routed based upon one factor, such as a customer identifier or a customer type, or upon multiple factors.
  • Different services often need different message formats. The order of fields might need to be different, or new fields might need to be added. With an ESB you can alter the format of both the message body and the message header.

Mediations

An ESB enables reuse by mediating between service requesters (consumers) and service providers. Mediation covers the following functions:
  • Content-based routing
  • Transformation
  • Validation
  • Enrichment
  • Service invocation

WebSphere ESB and WebSphere Process Server

A mediation flow encapsulates logic that is executed when a message is received by WebSphere® ESB or WebSphere Process Server. The integration developer specifies the interfaces of the service requester and service provider, so the mediation flow knows what kinds of messages it will process.

If you are using WebSphere ESB, you can implement a mediation flow in a mediation module. If you are using WebSphere Process Server, you can implement a mediation flow in a mediation module or a module. Both a mediation module and a module are types of Service Component Architecture (SCA) module, and both can be referred to as service modules. The mediation flow is created using WebSphere Integration Developer, and the resulting service module is deployed to the run time in an enterprise archive (EAR) file.

A service module can have exports that define interactions with service requesters, and imports that define interactions with service providers. Each import and each export has a binding that defines the actual connection mechanism. For example, SOAP/HTTP. When you use dynamic routing you might not need an import, except to provide a default endpoint.

You can put the business objects and interfaces that are used by imports and exports into libraries, so that they can be shared and reused. Any service module that wants to use a library is defined to have a dependency on that library.

Mediation primitives

A service module can contain one or more mediation flow components. Mediation flow components host mediation flows, which are assembled from mediation primitives. Mediation primitives are the building blocks of mediation flows and each mediation primitive lets you do different things with a message.

Loosely bound modules: databases and registries

If you store service addresses in a database or registry you can change which services get invoked by updating the contents of your database or registry; or by pointing your mediation flow at a different registry instance or database table.

Generally, if you want to change the database your mediation flow uses, the integration developer must update the mediation primitive properties and create a new EAR file, which you deploy to the runtime. Alternatively, the integration developer can promote certain mediation primitive properties (make the properties visible at run time) and the runtime administrator can then update the properties without needing to redeploy the EAR file. For example, the Database Lookup mediation primitive allows you to promote the Table name property. The Table name property contains the name of the database table, including the schema name. For example, myschema.mytable.

Storing service addresses in a registry can make a solution even more flexible and reusable, because a mediation flow can extract multiple service addresses for one type of business service. Alternatively, a registry could return one service address based upon more detailed criteria. For example, the registry might return services in a certain geographical or linguistic area.


concept Concept topic

Terms of use | Feedback


Timestamp icon Last updated: 20 June 2010 00:38:40 BST (DRAFT)


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wbpm.scenarios.esb1.620.doc/concepts/cwesb_flexibility.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
This information center is powered by Eclipse technology (http://www.eclipse.org).
iDoc on