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