Application Design Considerations

Applications help solve integration problems of varying complexity. This section describes some important factors to consider when designing an application.

Choosing Between Integration Styles

The table, Salient features of integration styles, provides guidelines to choose a high-level integration style for your applications.

Salient features of integration styles
Speed of Integration Data Abstraction Richness of Orchestration Primitives Typical Endpoints
Batch-oriented Non-real time Record Low Databases, files, and so on
Application-oriented Real-time Message Medium Application APIs, Adapters, and so on
Service-oriented Real-time Service, Operation High Web services and APIs
Resource-oriented Real-time Resource Medium Mobile/Web Applications and APIs

In an application-oriented integration style, each operation in a process can be invoked by a call to the process. Invoking multiple operations requires multiple calls to the process, that are then executed sequentially.

A service-oriented style exposes multiple operations available in a process and each of the operations can be called directly. These operations are not related and can be executed independently. However, you can use conversations to correlate the related messages between two or more parties.

Choosing the Modularity

An application module is the smallest unit of resources that is named, versioned, and packaged as part of an application, and then executed in the ActiveMatrix BusinessWorks runtime environment. It cannot provide capabilities to other modules.

A shared module is the smallest unit of resources that is named, versioned, and packaged as part of an application and can be used by other modules that are part of the same application. Shared modules export their functionality (process, shared resources, and schema namespaces) to application modules or to other shared modules. When creating a new module, select a shared module if the business logic needs to be shared across multiple applications. Shared modules can also be used if XML collisions exist.

Differences between Application and Shared Modules
Runtime Reusability Encapsulation XML Namespace Restrictions
Application Modules Can be executed by the run time when packaged as part of an application. Can be used by one or more applications. Processes within an application module are visible to each other. However, the processes are not visible outside of the module. Namespace can be provided by multiple documents.
Shared Modules Cannot be executed by the run time unless utilized by an application module. Can be used by one or more application modules or shared modules. Processes within a shared module are visible to each other. However, only the processes defined as public are visible outside of the shared module. Only one document can provide the namespace; that is two documents cannot have the same namespace.

All schemas and WSDL files are visible to other modules that depend on the shared module.

Choosing Implementation Technologies for the Modules

When implementing the business logic, ActiveMatrix BusinessWorks provides flexibility ranging from developing applications graphically without coding, to using existing Java classes (or libraries), to writing custom code. Application modules or shared modules typically consist of one or more business processes that define the business logic. Create an application or shared module using the GUI to leverage the rich orchestration capabilities provided by ActiveMatrix BusinessWorks.

Choose to create (or use) a Java module (or a Java OSGi bundle), if multiple calls from a process to other Java libraries are needed to compute the result. Java modules provide a high degree of customization. To use the enhanced Java development tooling such as source folders, JRE libraries, and so on, select the Use Java Configuration check box in TIBCO Business Studio for BusinessWorks when creating an application module. Alternatively, create a module that contains existing Java code or custom code.
Differences between Process Modules and Java Modules
Orchestration Capabilities Visibility Granularity Examples
Process Modules High High visibility of process flow logic, services, and bindings. Better suited for coarse-grained functionality that consists of more discrete functionality and process constructs. Account opening, mortgage loan, and so on.
Java Modules Low Low Better suited for fine-grained functionality that has a very specific function, and often requires very little or no process constructs. Query flight status, update product description, and so on.