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.
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.
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.
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. |