Overview | Package | Class | Tree | Deprecated | Index | Help
PREV NEXT | FRAMES NO FRAMES

This javadoc is a description of the entire Interstage BPM API.

See:
Description

Packages
com.fujitsu.iflow.common | This package contains utilities that are common to all of Interstage BPM.
com.fujitsu.iflow.common.wfapp | This package contains utilities that are common to all of the Interstage BPM applications.
com.fujitsu.iflow.ddframework.intf | The Framework Adapter (DdFramework) Interface handles user authentication and manages directory and document service objects.
com.fujitsu.iflow.diradapter.intf | This package contains Interfaces to the Interstage BPM Directory Service.
com.fujitsu.iflow.dmsadapter.intf | This package contains Interfaces to the Interstage BPM Document Management System.
com.fujitsu.iflow.model.event | This package includes interfaces and classes that listen for changes in the Interstage BPM objects to provide proactive notification to the user.
com.fujitsu.iflow.model.util | This package contains low level utility classes that are commonly used by other classes and interfaces.
com.fujitsu.iflow.model.wfadapter | This package contains interfaces that manage the Document Management System (DMS) and the Directory Service (DS).
com.fujitsu.iflow.model.workflow | This package contains interfaces that manage the information required by the workflow templates & processes.
com.fujitsu.iflow.server.intf | This package contains many interfaces to the Interstage BPM Server.

This javadoc is a description of the entire Interstage BPM API. The Interstage BPM API allows you to access and manipulate Interstage BPM, including its administration function, as well as build applications using these model layer, adapter, and graphical user interfaces.

This JavaDoc is a reference document only. It is provided as is for your use. Technical support for customizations created using this API will not be generally provided. To get a feel for how to use this API, see the Interstage BPM Developers Guide as well as the examples that ship with this version of Interstage BPM.

## The Common Utilities

Interstage BPM has a utility package called common. It is used by Interstage BPM for general administration.

## The Model

Interstage BPM has four Model packages: event, util, wfadapter and workflow. The completely qualified name for each package is com.fujitsu.iflow.model.<package name>.

## Integration Adapters

Three of the API packages in this Javadoc are used to integrate the Interstage BPM Server with its Directory Service and Document Management System. These three packages are:

- The Framework Adapter (com.fujitsu.iflow.ddframework.intf)
- The Directory Adapter (com.fujitsu.iflow.diradapter.intf)
- The DMS Adapter (com.fujitsu.iflow.dmsadapter.intf)

### The Challenge of Interoperability

Interstage BPM's Integration Adapters provide a protective shell that insulates Interstage BPM from services that vary extensively according to the operating environment. These adapters give Interstage BPM users the ability to extend Interstage BPM according to the needs of their specific platform and implementation.

Adapters behave as converters in the traditional sense of the word--they connect two things which themselves were not designed to directly connect. Interstage BPM's Integration Adapters do just that; they connect Interstage BPM's pure Java workflow engine to the other components in widely diverse environments.

Interstage BPM's system of logging in, for instance, is very sensitive to the authentication strategy used by the specific directory services that are implemented on its server host. Yet in spite of wide differences in directory service methodology, Interstage BPM Integration Adapters must encapsulate similar functionality for all platforms.

Interstage BPM can't gain access to some of the functionality built into code libraries which often provide access control because it's written in pure Java. Code libraries for different operating system environments (such as DLLs for Windows) are very different, and very dependent on the environment. As an example, if Interstage BPM operated only on a Microsoft Windows 2000 platform, we could easily take advantage of the platform-specific libraries for using the native file system and native directory services system.

Interstage BPM's Integration Adapters create an outline or framework for encapsulating repeatable functionality on different platforms. They provide a framework of functionality that allows programmers to add value by extending our adapters to fit the needs of the specific environment they will be operating in.

### How the Interstage Business Process Manager Server Uses the Integration Adapters

#### Introduction to Interstage Business Process Manager's Three Integration Adapters

Secure access control in an open Web environment requires that three things be integrated and working together: authentication , the DMS, and the directory service. For these three to be working together, they must somehow have the functionality to pass the user information and session context to the server.

To accomplish this, Interstage BPM uses three integration adapters:

The Framework Adapter provides the Interstage BPM server and its clients with user authentication.

The Directory Adapter controls access to the directory of users in the system.

The Document Management System Adapter (DMS Adapter) controls access to the document management services.

The adapters are the methods by which the server talks to the DMS and the directory service. The capabilities and behaviors of each adapter must fit the operating environment correctly. These three adapters may need to be verified before using them, since every environment is different. While they may work, right out of the box, they really only demonstrate what is possible.

The Framework Adapter is the parent adapter. It acts as a framework that controls access to the other two adapters. It passes the application environment to them as needed. When the user logs into Interstage BPM, Interstage BPM looks only for the Framework Adapter in the naming service tree and not for the other two adapters.

In your development work, you should preserve this relationship between the Framework Adapter and the other two.

The Framework Adapter that ships with Interstage BPM use either the Microsoft Windows 2000 User Manager or LDAP to authenticate users.

Note: The twf.ini file is the script or the outline of the system configuration. Although we ship certain integration adapters on the Interstage BPM CD, we do not include the code for Interstage BPM's script or database adapters on the CD.

#### Adapters Communicate via RMI

Interstage BPM is a multi-tiered, distributed system, that uses RMI to communicate between the different components used in this version of Interstage BPM.

These communication methods give developers the freedom to use workflow in an enterprise-wide system without changing where documents are or how the users are registered with the directory service.

Each of Interstage BPM's Integration Adapters implements an RMI interface. The directory services adapter implements the DirAdapterInterface interface, and the DMS Adapter implements the DMSAdapterInterface interface.

For every authenticated user the adapter maintains a directory session object and a DMS session object which are RMI objects that implement the DirSession and DmsSession interfaces respectively. When logout is invoked, these objects can be deactivated and resources allocated for that user can be released.

Note: It is also possible for a single RMI object to implement all three of these interfaces: DirAdapterInterface, DMSAdapterInterface and DDFrameworkInterface.

### The Basic Methods of Adapter Development

This open server API is provided so that you may develop your own adapters, which will connect the Interstage BPM workflow engine with other DMS or directory service systems than those listed. Furthermore, we are giving you the source code of all three integration adapters to get you started.

Only a moderate effort is required to build a set of custom adapters. DDFramework contains only four functions. DIRAdapter and DMSAdapter have only three each, and DirSession and DmsSession have seven each.

The Interstage BPM strategy of providing you with a server-side skeleton to plug into provides you with flexibility about which DMS and directory service you choose to use, as well as how you choose to implement these functions in your situation. Developers who wish to write their own adapters should start from the Java stubs and skeletons provided.

The Integration Adapter API contains nothing more than the description of the server-side skeleton--an abstract class. You need to implement this skeleton by extending it and by creating the correct stubs or headers to fit it. This will require some knowledge of RMI interface conventions. The software package includes the necessary RMI interface classes.

The API describes the specific objects and methods that you must account for in the adapters that you write. They are included here so that if you are writing your own adapters, you will know what methods you must implement. In other words, you must implement all of the interfaces in the API, and DDFramework only should be used to communicate between the adapters and the server.

You should not call any of these interfaces or methods during the implementation of any other solution.

Since these three adapters work closely together, any new set of adapters developed to fit new configurations must be developed in tandem. On the other hand, one or more of the three adapters that are independently developed can be mix-and-matched with the adapters that are shipped with the Interstage BPM system.

An example of a possible alternative to our framework is the option of having multiple document management systems. From the server's point of view, it is important that you give it a view of a single DMS, but if you satisfy this condition, it doesn't matter how many DMS systems you choose to integrate.

Warning: All interfaces in this chapter should only be used to communicate between the adapters and the server. They are included here so that if you are writing your own adapters, you will know what methods you must implement. (You must implement them all.)

You should not call any of these interfaces or methods during the implementation of any other solution.

Overview | Package | Class | Tree | Deprecated | Index | Help
PREV NEXT | FRAMES NO FRAMES