Working with Modules and Libraries
There are two
important project types when doing Business Integration development in
the WebSphere Integration Developer, as shown in the following
screenshot:
A module project represents a
basic unit of deployment and is a composite of service components,
imports, and exports. Modules can contain various components (BPEL,
Mediation Flow, Java, and so on) within a module and can pass their data
by reference. There are two types of modules-modules and mediation
modules. A module (considered a superset is also referred to as a
Business Integration module) contains many component types that support a
business process. A mediation module contains one or more mediation
flow components, plus zero or more Java components that augment the
mediation flow component. A module can contain mediation flow components
also.
A module is a Business
Integration project type for developing SCA-based applications. A module
is a basic unit of deployment to the WebSphere Process Server runtime
environment, and as such, is packaged in an Enterprise Archive (EAR) file. The EAR file contains all the SCA-based artifacts packaged in a JAR file, J2EE projects, such as Web and EJB modules, dependent Java projects, and any dependent Libraries packaged as JAR
files. Also included in this project are other Business Integration
artifacts that make up the overall application. This would include BPEL
definitions, interface definitions, and XML schema definitions.
A library project is also
another type of Business Integration project. Unlike the module project,
a library project is not a deployable unit. The library project holds
artifacts that can be shared between multiple modules. Implementations,
interfaces, business objects, business object maps, roles,
relationships, and other are held within a library. It is important to
note, however, at runtime that the library is not shared. In this case,
the library is deployed individually with the module that is dependent
upon it.
Another important difference
between a module and library project is the type of artifacts that can
be contained in each project type.
Specifically, library
projects only contain interfaces, business objects and graphs, business
object maps, and relationships. Library projects do not include other
types of Business Integration resources such as SCA artifacts. A library
project is created to store artifacts that are shared between module
projects. If a module is dependent upon a particular library project,
that project must be added to the dependency list for the appropriate
module using the dependency editor.
Solution diagram
The integration solution
diagram organizes and displays how modules, mediation modules,
libraries, and other dependent projects connect. The Business
Integration view is split between projects and integration solutions, as
shown in the following screenshot:
The
integration solutions section helps users organize multiple modules,
mediation modules, libraries, and other dependent projects into one
scope. This is a development/design time concept only and the
servers/runtime still will not have any visibility into this concept.
The second and most important part of the integration solution is the
diagram. It allows you to visualize how modules, mediation modules,
libraries, and other dependent projects connect.
Assembly Diagram
The primary tool for
defining and assembling SCA artifacts is the assembly editor. This
editor will allow you to visually assemble SCA applications such as
components, exports, imports, and standalone references, and to wire
them together to build composite applications/solutions. A sample
assembly diagram would look like a figure as shown in the following
screenshot:
When using the assembly
editor, there are several development approaches. First, you can build
your SCA application using a top-down development model. In this case,
you use the assembly editor to diagram and model your application
visually before you implement the components and create any associated
component business logic. You drag and drop the preferred SCA componets
to the assembly diagram. Once the SCA components are added to the
assembly diagram, you can assign interfaces and even create new
interface definitions for each component from within the assembly
editor.
In the bottom-up development
model, you start by implementing the components individually, by
defining your business logic. The components can be implemented as a
business processes, business state machines, business rules, or human
tasks. Or you can import existing components or services exposed by end
applications by dragging them and dropping them onto the assembly
diagram. As part of this process, the appropriate interfaces and
references are automatically added to the components. You complete the
assembly by wiring the SCA elements together.
Finally, in the middle
development model, you define the elements in the assembly diagram and
their implementations in parallel. As with the top-down approach, you
create the assembly diagram in the assembly editor. But unlike the
top-down approach, you do not generate implementations from the elements
in the diagram. Instead, you select the appropriate implementation that
you created in parallel. Be aware that the parallel activities,
creating the diagram and creating their implementations, are not done in
isolation.You must know the interfaces and references for each element
in order to create its implementation, and vice versa. The point is that
you do not have to wait for one activity to finish before you begin
with the other.
Palette
On the left of the assembly
editor is a palette that allows you to add various SCA components to the
assembly diagram. The palette groups elements into drawers that can
then be expanded and collapsed. The primary drawer is labelled
components and is expanded in this screen capture. Within the expanded
view there are three groupings.
The first grouping is
for those SCA components that provide business logic, which are human
tasks, Java, business processes, business rule groups, and business
state machines.
The
second group is for those SCA artifacts that provide access to services,
specifically imports, exports, and standalone references.
The
third grouping is for components that provide supporting logic, which
are interface maps and selectors. The two collapsed drawers at the
bottom of the palette are for outbound and inbound adapters which
provide access to imports and exports associated with specific adapter
types.
Favorites allows you to
create your own grouping of the components and adapters you regularly
use, allowing you to work from that drawer without having to open the
others. The canvas area of the assembly diagram shows the various
components that make up the SCA application in the module project.
Imports and Exports
The following screenshot shows an example of Import and Export SCA components.
An import
allows you to use functions that are not a part of the module that you
are assembling. Imports are used in an application in exactly the same
way as local components. Imports have interfaces that are the same as,
or a subset of, the interfaces of the remote service that they are
associated with so that those remote services can be called. To share
the interfaces between modules, put the interfaces into a library. Then,
for both modules, add a dependency on the library to use its resources.
Imports and exports
require binding information, which specifies the means of transporting
the data from the modules. An import binding describes the specific way
an external service is bound to an import component. For an import that
is generated from an export, the binding type of the import will be
specified for you. Imports can use the following bindings, which can be
remote or local:
If you are creating the
import using the palette in the assembly editor, you will have to
specify a binding type for the external service in order to test it.
Bindings specify the means or the technology protocol used for
transporting data into or out of a module.
An export is a published
interface from a component or import that offers its service to the
outside world, for example, as a Web service. Exports have interfaces
that are the same as or a subset of the interfaces of the component or
import that they are associated with so that the published service can
be called. An export dragged from another module into an assembly
diagram will automatically create an import. Exports that are shown
under the module assembly in the Business Integration view can also be
used to create imports in other modules. Each export has an address
(which is a URL, for example: http://localhost:9080/BenefitEligibilityModuleWeb/sca/BasicValidationExport) at which it will be deployed on the server. The export can be exposed at that address.
Imports and exports
require binding information, which specifies the means of transporting
the data from the modules. When you use the Generate Export
action from the menu of a component, you need to select the binding so
that the binding is generated when the export is created.
References and wires
There are two types of wires.
The first type of wire comes from a Partner Reference (the source) that
is defined for a component or standalone reference node and goes to a
component or import (the target). In this case, the wire identifies the
component or import (target) that is accessed when the source component
uses that partner reference. By default, a partner reference only allows
one wire leading from it unless the partner reference's multiplicity
property is changed to 0...n.
The second type of wire
comes from an Export Wire (the source) and goes to a component or import
(the target). In this case, the wire identifies the (target) component
that provides the service. An export can only have one wire leading out
of it.
The following screenshot shows the two types of wires:
Dependency editor
If a module or mediation
module needs to use resources from a library or if a library needs to
use resources from another library, you have to open the module or
library with the dependency editor and add a dependency on the required
library, as shown in the following screenshot:
Business
objects and interfaces are examples of the resources that you would
want to share. Libraries must be deployed with modules that have
dependencies on them so that the resources are available during runtime.
With the dependency editor, you can add dependencies on libraries and
Java projects and also add dependencies on J2EE projects.
