WebSphere® Integration Developer provides you with the tools to easily compose a business solution that integrates applications, processes, and data across multiple systems and business organizations. The building blocks of the business solution are Service Components Architecture (SCA) components wired together to form modules that can be deployed to the WebSphere Process Server. The WebSphere Integration Developer's assembly editor lets you build applications by assembling the SCA components.
To illustrate the concepts covered in this topic, we will
use a simple example of a customer enquiry; when the customer ID is supplied,
the customer's portfolio information is returned. Processing this enquiry
requires two additional services: one to access the customer's account information
and another to find out the current stock price. The following picture shows
this solution:
Components are reusable; that is, you can invoke their services from other components or from clients through stand-alone references. You can also export their services, allowing them to be called from other applications.
The components generated by WebSphere Integration Developer tools and used by the assembly editor are Service Components Architecture (SCA) components. SCA defines a technology-independent format for describing component implementations, so that assembling components to build an application do not require knowledge of the language and technology of the implementation of the component.
Customer enquiry example
Assembly editor notes:
When you are using the assembly
editor, the component appears as a rectangle on the canvas, as shown here: The canvas is the open area in the editor view where you assemble
your application.
Each component has a name and a display name. (The
display name is used by various runtime functions.) By default, the two names
are the same, although you can name them independently. The context menu for
the assembly editor canvas has a toggle setting that allows you to display
or hide the display names in the assembly diagram. Here is the component with
the display name visible:
See "Adding and wiring components" under related tasks for more information on how to create a component.
Interface map and selector are special components that do not have "business logic" implementations. Interface map contains "mapping" logic for interface operations. Selector provides "routing" logic to invoke required services.
See the "Assembly editor" under related reference for more information on component implementation types.
Customer enquiry example
In the enquiry example, the three components require implementations that perform the processing. For example, the CustomerQuery component can be a business process that retrieves the customer portfolio information and stock price.
Assembly editor notes:
When working in the assembly editor, the component's
implementation type is represented by an icon in the component. The following
image shows the CustomerQuery component which has a business process implementation
type:
If the component's implementation does not exist, the component will have an exclamation mark in the lower left corner, as shown in the above CustomerQuery component. If the implementation already exists, then there is no exclamation mark, as shown in the following image of the CustomerQuery component:
Components
that do not have an implementation type specified have the untyped icon, , as shown
in the following image of the CustomerQuery component:
See "Working with implementations" under related tasks at the end of this topic for instructions on how to change the component's implementation type and generate the implementation.
In bottom-up development, you can drag one of the implementations (for example, a human task) from the same module onto the canvas of the assembly editor and the component will be created for you. The component will show its implementation type with no exclamation mark to indicate that the implementation exists.
Also, you can set qualifiers on the component's implementation. The qualifiers provide “quality of service” support (such as transaction support, event sequencing, or security) required from the hosting container. See the related links for more information on qualifiers.
A component exposes business-level interfaces to its application business logic so that the service can be used or invoked. The interface of a component defines the operations that can be called and the data that is passed, such as input arguments, returned values, and exceptions. An import and export also have interfaces so that the published service can be invoked.
All the components have WSDL type interfaces. Only Java components support Java type interfaces in addition to WSDL type interfaces. If a component, import, or export has more than one interface, all the interfaces must be the same type. See "Adding Java objects to a module" and "Adding and wiring components" under the related topics for more information.
A component can be called synchronously or asynchronously (this call is independent of whether the implementation is synchronous or asynchronous). The interfaces on the component are defined in the synchronous form and asynchronous support is also generated for them. For an interface, you can specify a preferred interaction style as synchronous or asynchronous. The asynchronous type advertises to users of the interface that it contains at least one operation which may take a significant time to complete. As a consequence, the calling service should avoid keeping a transaction open while waiting for the operation to complete and send its response. The interaction style applies to all the operations in the interface.
You can also apply a role-based permission qualifier on an interface so that only authorized applications can invoke the service using that interface. If the operations require different levels of permission for their use, you will need to define separate interfaces to control their access. See the related links for more details on qualifiers.
Customer enquiry example
Assembly editor notes:
In the assembly editor, the
component's interfaces are represented by a single icon, , on the left side of the component. The
following image shows the CustomerQuery component which has one or more interfaces
defined:
When you drag an implementation onto the assembly editor's canvas to create a new component, the interface of the implementation is automatically added to the component. If you are doing top-down development, you can create the component first and then add the interface to it. See "Adding and wiring components" for instructions on how to add interfaces to a node.
A partner reference is required when one component uses another component; it is defined on the component that wants to use another component. The partner reference (sometimes referred to as a reference) specifies the interface that is used in the invocation of the other component. The partner reference also contains wires that specify the target components that can be used. See "Adding and wiring components" under related tasks for more information on adding partner references to nodes.
Assembling the components for the application involves creating partner references, interfaces, and the wiring of components in the module assembly. The result is an assembly diagram that represents the modeled solution.
Customer enquiry example
Assembly editor notes:
In the assembly editor, the
component's partner references are represented by small blocks on the right
side of the component. The block contains the number of wires that are allowed
in the partner reference; the numbers are either 1..1 or 0..n to
indicate one wire or 0 to n number of wires, respectively. The following image
shows the CustomerQuery component which has two partner references:
If there are many partner references for your component, you can collapse them. As shown here, CustomerQuery component's two partner references have been collapsed:
Select the partner reference on the node and right-click to invoke the Collapse References and Expand References actions to collapse and expand them, respectively.
A wire allows you to assemble components into an integrated application by identifying target services. The target of a wire must support the interface or interfaces that the source specifies.
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 stand-alone references 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 (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.
Customer enquiry example
For our customer
enquiry example, the CustomerQuery component has two partner references and
the wires point to the target components that have the referenced interfaces.
Here is part of the assembly diagram showing the three components wired together:
Assembly editor notes:
You can wire components together by hovering your mouse over the source component or partner reference to display the handle and then dragging the handle to connect to the target. Here is a component with the handle displayed for wiring:
Here is a partner reference with the handle displayed for wiring:
You can also use the editor's wire action to automatically wire components together. To learn about the wiring action, see "Adding and wiring components" and the tutorial listed at the end of this topic.
Components are assembled in the module, which is a basic unit of deployment in the WebSphere Process Server. The module assembly contains a diagram (referred to as the assembly diagram) of the integrated business application, consisting of components and the wires that connect them. You use the assembly editor to visually compose the integrated application by using elements that you drag from the palette or from the tree in the Business Integration view.
Customer enquiry example
For our customer enquiry example of creating an application
to get portfolio information for a customer, we can create a module for the
application and the wired components in the module assembly may look like
the following diagram in the assembly editor:
The implementations of components that are used in a module's assembly reside within the module. Components belonging to other modules can be used through imports, which are described later in this topic. Components in different modules can be wired together by publishing the services as exports that have their interfaces, and then dragging the exports into the required assembly diagram to create imports.
When wiring components, you can also specify quality of service qualifiers on the implementations, partner references, and interfaces of the component. For more information on qualifiers, see the related links at the end of this document.
Customer enquiry example
In
our customer query example, we have added a stand-alone references node to
provide access to the CustomerQuery service. As a result, we can create JavaServer
Pages to use the stand-alone references to access CustomerQuery. In the assembly
editor, the node for the stand-alone references has an arrow icon, . The following image shows the addition of the stand-alone references
to access the CustomerQuery service:
Assembly editor notes:
The palette in the assembly editor has an icon to let you create the stand-alone references in the module assembly. You can add partner references to the stand-alone references and wire them to target components or target imports.
An import allows you to use functions that are not a part the module that you are assembling. Imports can be from components in other modules or non-SCA components such as stateless session Enterprise JavaBeans™ (EJBs) and Web services. Available function (or business logic) implemented in remote systems (such as web services, EIS functions, EJBs, or remote SCA components) is modeled as an “imported service”. 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.
Under related concepts at the end of this topic, see "Modules and libraries dependencies" for more information on dependencies and see "Introducing a Java class or EJB into a module" for more information on how to wire components with WSDL interfaces to EJB imports that have Java interfaces
Imports are used in an application in exactly the same way as local components. This provides a uniform assembly model for all functions, regardless of their locations or implementations.
A binding describes a protocol for calling a piece of code. The binding, then, determines how the import or export interact with clients outside the module where the import and export reside. The import binding does not have to be defined at development time; it can be done at deployment time. For bindings information, see the "Generating bindings for imports and exports" topic under related tasks.
Customer enquiry example
The following image shows StockQuote as an import rather
than a component:
Assembly editor notes:
For an import that is generated from an export, Web service, or EJB, the binding type of the import will be specified for you. If you are creating the import using the palette, you will have to specify a binding type for the external service technology in order to test it.
If you are doing top-down development and have not yet generated an implementation, you can also convert a component into an import using the Convert to import action from the component's context menu.
An export is a published interface from a component or import to offer its business 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. 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. See related tasks for more information on dependencies.
Customer enquiry example
In the earlier example, we can make the CustomerQuery service available to other modules by creating an export. The following image shows the export, CustomerQueryExport, which is created from the CustomerQuery component's interface:
Assembly editor notes:
Exports that are shown under the module assembly in the Business Integration view can be used to create imports in other modules.
If an export in a module assembly does not have any binding, when deployed, SCA binding is assumed. For bindings information, see the "Generating bindings for imports and exports" topic under related tasks.
The component interfaces only support the automatic Java mapping of WSDL portTypes that follow the WS-I standard, that is, interfaces that have operations with single input and output part, and use document literal encoding.
Related information