Programming Model and Design
Package assets within modules, mediation modules and libraries to support effective component reuse and application maintainability
Modules
A module is a container for your services and is both a project in the WebSphere Integration Developer workbench, and the unit of deployment to the WebSphere Process Server. That means that any solution that you build will be deployed to the server as one or more modules. For those who are familiar with J2EE, a module is packaged and deployed as an enterprise archive (EAR) file. One of the advantages of the Service Component Architecture is that you don't have to be concerned with the underlying packaging. A module provides services that can be used by other modules and that can be accessed by external clients used by your partners or customers. A module is a collection of components, imports and exports.
Mediation modules
Mediation modules contain mediation flow components. A single mediation module can contain only one mediation flow component.
Libraries
Often, interfaces, business objects, business object maps, events, relationships, roles, and Web service ports need to be shared so that resources in several modules can use them. The library is a project that is used to store these resources.
Unlike modules or mediation modules, library projects can share resources. In order for a module or mediation module to use the resources from a library, the library has to be added as a dependent to the module. A library cannot be deployed by itself. However, you can add a library to the module and select to deploy it with the module. Also, you can add library dependencies to a library; for example, if one library uses resources in another library, then you would need to add the library dependency.
Effective component reuse and application maintainability
Artifacts in a library are public. Artifacts in a module are private. Designers of WebSphere® Integration Developer applications should organize artifacts by taking into consideration logical function and visibility. For example, related data types that are used by various pieces of a system should be placed into a library. Other modules can then easily reuse this library. Only one copy of each artifact needs to be created and maintained using this method. Likewise, related business logic features of the application should be grouped into modules. Componentizing an application in this way will yield a more flexible, easily maintained application. Adding new features to the application will also be easier.
No comments:
Post a Comment