IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Get started with IBM Integration Designer > Create a new project > Create modules and libraries > Business integration projects

Libraries

Often, interfaces, business objects, data maps, mediation subflows, relationships, roles, and web service ports need to be shared so that resources in several modules can use them. The library is a project used to store these resources.

Unlike modules or mediation modules, library projects can share resources. There are two kinds of sharing here, sharing of artifacts for development and sharing of artifacts within the solution at run time. In order for a module or mediation module to use the resources from a library at run time, the library has to be added as a dependent to the module. You can add a library to the module and select to deploy it with the module or you can deploy it as a global library. 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. For details on dependencies, see the related concepts listed at the end of this topic.


Public and private artifacts

Artifacts in a library are public, and they can be shared at run time. Artifacts in a module are private. Designers of IBM Integration Designer applications should organize artifacts by taking into consideration logical function and visibility.

For example, related data types 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.


Business objects and interfaces for imports and exports

To use imports and exports in assembly diagrams, it is a good practice to put the business objects and interfaces used by the import and exports into a library so that they can be shared. Then, add a dependency on the library to all of the modules that use these common resources. Avoid copying the same business objects and interfaces into different modules to use them.


Mediation subflows

If you have mediation flow patterns that you use regularly, you can create reusable subflows, for those patterns, and store them in a library so that they can be shared between modules and mediation modules.


Deploying with a process application, with the module or globally

Libraries can be deployed in several ways. They can be deployed with a process application, with the dependent module or globally. You can make your choice in the dependency editor and configure the section "Sharing across runtime environments."


Library resources that are shared

If you have associated a library with a process application then Process Application will be selected in the dependency editor in the section "Sharing across runtime environments." The library will be shared within the deployed process application. If one or more modules are deployed independently from the process application then the library will be copied into each module.

If you choose to deploy the library with the module, which is the default setting when the library has not been associated with a process application, a copy of the library is made for each module when the module is deployed. After deployment, if shared resources change in the library, modules using the resources have to be updated.

For example, two modules share some resources in a library. The applications are deployed. One of the modules has to be updated, resulting in changes to some of the shared resources in the library. In this case, the second module also needs to be updated to reflect the changes in the shared resources. See "Modules and libraries dependencies" for more details.


Comparison of library types

The library types can be compared in several ways as shown in the following table.

Comparison of library types
Library type Deployment Content allowed Other libraries this type can depend on Benefits
Global Deployed as WebSphere Application Server share library Java, XSD, WSDL

  • Global
  • Java project

Pros: least runtime memory consumption

Cons: difficult to setup (a manual process), has the most restriction on its content, has no data isolation (it is visible to all applications installed on the server)

Shared by reference Deployed as a WebSphere Application Server Business Level Application XSD, WSDL, business object map, relationship and role definitions, calendar, mediation sub flow

  • Global
  • Share by reference

 
Shared by value Deployed as part of an EAR file Java.jar, XSD, WSDL, business object map, relationship and role definitions, calendar, mediation sub flow

  • Global
  • Share by reference
  • Share by value
  • Java project

Pros: no restrictions of what can be put into the library, has a simple yet robust memory model

Cons: consumes more runtime memory

Scenarios supported by share-by-reference library type:

Scenarios supported by share-by-value library type but not supported by share-by-reference library type:

Scenarios supported by share-by-value library type:

Business integration projects


Related concepts:
Modules and libraries dependencies


Related tasks:
Create libraries


Related reference:
Partitioning libraries and modules