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.
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.
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.
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.
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.