| Backgrounder: |
Today, TIBCO’s product set reflects the two convergent trends:
SOA – providing a virtualized, loosely coupled environment in which to deliver the functional capabilities required as Services, and enabling agility and reuse in the provision of those Services
BPM – providing a process driven environment in which to assemble and orchestrate the Services into business solutions, and enabling process flexibility
SOA support can be seen as a natural evolution for TIBCO’s middleware market, with message delivery and broking providing the core of the Enterprise Service Bus (ESB). In addition, TIBCO also provide Service hosting, orchestration, assembly and management capabilities, delivering a rich SOA platform. The core technology is also well suited to the delivery of “real-time” Services, providing accessibility and visibility of information, that reflect the nature of modern business.
BPM is not separate from, or an alternative to SOA. Rather the two are just “flip sides of the same coin”. In the CBDI-SAE service oriented process we show Business Improvement and Solution Assembly as two key activity areas in the “Consume” layer. BPM would be an appropriate approach for modeling business process improvements, and with appropriate tooling an ideal mechanism for assembling Services into an automated business process solution.
This report provides a logical decomposition of the run-time infrastructure required to support SOA and BPM. This decomposition provides a technology independent model by which to understand the capabilities required.
The potential path taken by Service Requests and Responses as they move between Provider and Consumer is also illustrated in the report. Above the Provision/Host layer, each of the other layers, or the capabilities within them is optional. Not all messages for example require signing and encrypting, or transforming and routing. Ideally, such decisions are driven by policies and rules that are abstracted away from the providing or consuming applications. A decision to encrypt a message for example, or the need to transform it to support new requirements should be transparent to the applications and instead is configured within the infrastructure.
Some capabilities span several layers. Security requirements for example may mean that mediation and orchestration functions need to be able to sign messages, or handle encrypted messages. Similarly, in each layer many components of the infrastructure need to communicate with the Service Management capabilities, or host some management “plug in”.
Vendor’s products are often packaged in a less logical way, hence the decomposition also provides a mechanism against which different products might be assessed in terms of the capabilities they offer, perhaps revealing gaps or duplication in their functionality. So called Enterprise Service Bus (ESB) products are a good example in that they often offer capabilities that span several of these layers. |
Home