How to Ensure Transactions in AIA Services

13-28 Developers Guide for Oracle Application Integration Architecture Foundation Pack ■ Does the application need the security credentials to authenticate? If yes, can you use a generic account or should you use the requesters credentials, as specified in the message? ■ How are these credentials transmitted? Are they adopting a WS-Security scheme or a custom mechanism? If a custom mechanism, is it through the header or as part of the payload? Refer to Chapter 26, Working with Security for details about how to: ■ Transform application security context into standard format in ABCS. ■ Propagate the standard security context from ABCS to ABCS through EBS and EBF. ■ Transform standard security context to application security context.

13.6 Enabling Transactions

When SOA is used to encapsulate and integrate cross-enterprise workflows, multiple services may take part in transactions spanning system boundaries. End-to-end business transactions that cross application boundaries involve multiple applications. Creating robust integration solutions requires more than simply exchanging messages. An important consideration is that the Web services participating in an end-end message flow are often asynchronous, stateless, distributed, and opaque. You must understand the mechanics of transaction management.

13.6.1 How to Ensure Transactions in AIA Services

Business requirements drive transactional requirements. Transaction considerations must start during the design phase. You cannot postpone them until construction time. You must: ■ Identify all the ABCS services and the EBFs that comprise a business activity. ■ Organize these activities into meaningful groups to have an overall unifying purpose. ■ Indicate transaction demarcation points. The grouping of activities provides the starting point for transaction demarcation so that the relevant business operations are performed in the context of a transaction. In the asynchronous fire-and-forget pattern, where no milestones are configured, the requester, EBS, and provider ABCS must participate in the same global transaction, including cross-references in Oracle XA. In an asynchronous MEP, where JMS queues are set up and the participating applications interact with the queues, the JMS consumer adapters must also participate in the global transaction, as do the requester ABCS, EBS, and provider ABCS. In such a case, when an undergoing transaction is aborted before the message is persisted at a milestone, the message is rolled back into the JMS queue. In other words, the transaction demarcation begins with the JMS consumer adapter picking up the message from the queue and ends when the message is delivered to the consumer application or when the message is persisted at a configured milestone. Completing ABCS Development 13-29 In a SOA-based integration, long-running business transactions often involve incompatible trust domains, asynchrony, and periods of inactivity, which present challenges to traditional ACID-style transaction processing. You may need to predefine the transaction boundaries based on technical or business criteria. PIP designersarchitects should divide the whole transaction into parts by setting transaction boundaries using JMS interface at logical points. Non-retryable application services must have corresponding compensatory services. ABCS invoking non-retryable application services should invoke compensatory services in case of roll-back. Application services implemented using JCA adapters can leverage session management to facilitate transaction coordination.

13.6.2 Transactions in Oracle Mediator