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 following table 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, which then run sequentially.

A service-oriented style exposes multiple operations available in a process and each of the operations must be called directly. These operations are not related and can run independently.

Choosing the Modularity

An application module is the smallest unit of resources that is named, versioned, and packaged as part of an application. You can then run it in the TIBCO BusinessWorks Container Edition 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. It can be used by other modules that are part of the same application. Shared modules export their functionality (processes, shared resources, and schema namespaces) to application modules or to other shared modules. When creating a 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 run by the runtime 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 run by the runtime unless used 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. 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, TIBCO BusinessWorks Container Edition 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 TIBCO BusinessWorks Container Edition.

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 toolings such as source folders, JRE libraries the Use Java Configuration checkbox 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.