Bulk Data Processing Integration Style Choice Matrix

20-24 Developers Guide for Oracle Application Integration Architecture Foundation Pack

20.3.3 Bulk Data Processing

Bulk data processing involves a large batch of discrete records or records with very large data. The methodology is point-to-point integration specializing in the high-performance movement of data with a trade-off of reusability. Bulk data processing is about persistent data replicated across multiple applications. The integrations fall into four styles: ■ Initial data loads ■ High-volume transactions with Xref table ■ Intermittent high-volume transactions ■ High-volume transactions without Xref table For complete details about using bulk data processing with AIA, see Chapter 22, Using Oracle Data Integrator for Bulk Processing.

20.3.4 Integration Style Choice Matrix

In any AIA implementation, a variety of integration flows conforming to different integration styles will coexist. Integration flows represent processing of messages by AIA services deployed to deliver the business functionality desired. The choice of an integration style influences the design of AIA services. Conversely, decisions about the design of AIA services lead to a particular integration style. Various aspects of AIA service design are: ■ Service Granularity You can decide upon the functionality to be implemented in a service in one of the two ways: either based on the business logic needed for a business activity or business task the result of business process analysis or based on the functions exposed by a provider application. Service granularity is Coarse-Grained if the business logic conforms to the requirements of a business activity or business task result of business process analysis of AIA Reference Process Models. In this case, the service is implemented by invoking multiple low APIs of the provider application. Service granularity is Granular if the business logic conforms to the low-level functions exposed by the provider application. ■ Service Reusability Service reuse is High for different Integration Flows if its design is modular and built for the requirements of various business use cases. Conformance to the requirements of a business activity or business task the result of business process analysis of AIA Reference Process Models leads to modular design. Asynchronous Request-Delayed Response Requester ABCS EBS Provider ABCS CBP Requester ABCS EBS EBF Provider ABCS Table 20–3 Cont. AIA Artifacts for Integration Flows with Multiple Application Message Pattern No Processing Logic With Processing Logic Building AIA Integration Flows 20-25 If the service is built to meet the requirements of a particular business use case, then the logic is monolithic and reuse is Low. ■ Service Virtualization This aspect provides for separation of concerns and independence of requester applications and provider applications from changes. The choices are Yes or No. ■ Service Interoperability The capability of diverse service implementations to interoperate is dependent on their conformance to WS-I standards, a common message meta model, and a robust versioning strategy. The AIA EBS WSDLs and AIA EBOs and EBMs provide this capability as delivered. For others, special effort is needed to ensure interoperability. Table 20–4 summarizes the granularity, reusability, virtualization, and interoperability for the various integration styles.

20.4 Development Tasks for AIA Artifacts