Data integration is about transferring or sharing the information between business systems and partners. In this approach, only the data will be shared between systems and partners in the form of binary files, text files, documents, and objects. It does not include sharing business functions and processes. Shared folders, file transfers, FTP transfers, SQL loader, and ETL are the most common data integration mechanisms used by many enterprises. These approaches have some limitations such as data integrity, duplicate transfer, network failure, and delivery guarantee.

Most of the business application products and custom solutions provide API-based interfaces for certain business functions or logic, which can be executed by external systems. A functional integration has a more flexible approach when compared to the data integration approach. In addition, functional integration encapsulates the business functions and ensures that only certain functions are executed by external systems. It also has a few limitations such as tight integration, increased dependency, and so on.

Presentation integration is about screen scraping and data capturing from the application console and screens. This approach has many limitations and constraints that force a limited success. In addition, it has challenges in maintaining data integrity and security.

Process integration means collaborating various business functions and partner programs to meet a long-running business process based on data integration and business functional integration approaches. Process integration provides clear separation of the business functions and integration interfaces.

As we know, B2B integration is about collaboration between two different enterprises, partners, or vendors through a domain-specific and standard-based integration approach. Such collaboration includes data, business functions, and process integrations. XML-based standards such as EDI, HL7, and RosettaNet are widely-known B2B integration standards.

This approach is also known as one-to-one integration. Point-to-point is basically a decentralized networking approach to directly link two computers or systems. From the integration point of view, it is more about integrating two different systems or interfaces through a common transportation mechanism. A point-to-point integration architecture creates higher dependency between application systems and interfaces as it basically enforces a tight integration model.

This approach initially shows a lower up-front investment, but when more links are created between each application, the complexity of the integration increases. Once the complexity increases, it becomes difficult to customize or enhance the interface. This approach also requires updating each integrated application if any one of the systems require changes in the interface data model. This approach is depicted in the following diagram:

Basically, a centralized database repository will be shared across all applications and systems for information distribution. The central database system will act as an integration point. The database schema accepts all applications' input and also provides access to other systems which require that information. This approach increases the complexity in the database systems and a schema should be more generic. This approach also loads more complexity at the application's side as publishing or fetching the data from the repository has to handle all validation and elimination logic. Therefore, this approach increases the maintenance overhead. This approach is depicted in the following diagram:

Remote Procedure Call (RPC) is a protocol-based integration approach where one application or system calls the service or the function hosted by another remote application over the network. Basically, RPC uses a client-server model for communication. In addition, RPC works as a request-reply approach, so the requesting systems have to wait for the response from the provider system. Even though the entire communication happens over the TCP/IP network, applications don't need to implement the underlying networking procedures and protocols.

As the end-to-end communication happens over TCP/IP, it is considered an expensive solution. In addition, this approach will affect the performance as compared to other approaches. Java RMI and CORBA are well known technologies that work based on the RPC model, which is a subset of the TCP/IP protocol. Another disadvantage of this approach is that both systems that interact with each other should interpret the language-dependent objects sent over the network.

Message oriented middleware is an infrastructure-based integration approach where distributed systems and applications share data/information as messages over the network. This is the most popular and efficient integration architecture adopted by many enterprises. Comparing to the preceding approaches, the message oriented integration approach facilitates loose coupling, less dependency, and high reliability.

The MOM architecture is, basically, built around the Message Queue (MQ) and JMS using a messaging broker. A message broker is a server mechanism that persists messages and tracks message deliveries. Typically, a message oriented integration approach follows a publish/subscribe pattern. Most of the messaging brokers are based on Java Messaging Service (JMS) standards. IBM WebSphere MQ and TIBCO EMS are based on JMS standards. AMQP (Advanced Message Queue Protocol) is another messaging standard which is being followed by brokers, such as Apache Qpid and Rabbit MQ.

The MOM integration approach is widely adopted in the bulk or large volume of data transfer between multiple systems. As the nature of this architecture supports data exchange between various systems, it also has some limitations. The MOM approach does not support the synchronous request/response message exchange pattern. Moreover, the MOM approach does not enforce any open standardization; so many product vendors have their own implementation approach and standards.

Web services are open standard-based integration mechanisms which help to establish loosely-coupled integration communication between application systems. Web service provides an interface that can be consumed through an XML-based messaging model over various protocols. There are two types of web service implementations which are SOAP-based web services and REST architecture-based services. As web services are loosely-coupled interfaces, they are being used for the enterprise application integration by exposing legacy application functions. A web service-based integration is basically a point-to-point integration model. However, due to its open standards approach, it is easier to implement and reuse so that it is being adopted widely for the past few years. Web service interfaces are the fundamental for building SOA and BPM solutions.

The web service integration approach is based on the following open standards:

Service Oriented Architecture (SOA) is a style of architecture which is based on services, open standards, and principles. The SOA approach basically decouples the enterprise system as reusable service components and orchestrates those services to meet various business processes and integration requirements. SOA is predominantly implemented by using web services, enterprise service bus, and process orchestration technologies. As mentioned in earlier sections, each older integration approach has some limitation and complexity, which prevents the adoption of such solutions at the enterprise level. In addition, these approaches tightly integrate the application on a point-to-point basis. Therefore, it takes an enormous amount of effort and cost to enhance and align integration interfaces to meet the dynamic business requirements. However, SOA principles are enforcing to build service components as loosely-coupled, transport independent, reusable, and highly collaborative. The web services-based service architecture provides a better control in building open standard services, business processes, and an integration interface that helps to quickly align when needed. SOAP, BPEL, and WSDL are common open standards which are being used to build services and business processes.

As the Oracle AIA product is based on SOA principles and standards, let's have an overview of the service-oriented architecture, tools, and technologies in more detail:

The preceding diagram expresses the typical SOA reference architecture. The SOA reference architecture is used as a blueprint that includes components of solution, guidelines, and development templates for stakeholders, business analysts, architects, and development teams. The reference architecture should outline the layers of service-oriented solution, infrastructure components, architecture layers, building blocks, design guidelines, and policies standards.

The SOA reference architecture should represent various service components involved in the enterprise infrastructure. Typically, the SOA reference architecture should have infrastructure component layers, core business services, adapter service for exposing legacy application functionalities, third party integration services, data/information access services, infrastructure services such as an e-mail services, messaging services, and so on. All such services are consumed by business processes in an orchestrated mode to meet business process requirements. Such business processes are also services which will be triggered by the user interface components or other events.

A service-oriented architecture approach facilitates the creation of most flexible and reusable service components by exposing new and existing IT assets. Basically, this approach enforces to build business functions and resources as services which should be orchestrated to achieve business processes. This also includes integrating business systems with partner services. An SOA approach can be implemented on an application level, a program level, or an enterprise level. However, building mature services and business processes at an enterprise level should boost the return on investment and robotic solution.

Even though the architecture does not enforce it, building a highly-matured enterprise level, service-oriented solution requires a variety of tools and technologies, including web services, Canonical XML, Application Servers, Messaging Services, Enterprise Service Bus (ESB), BPEL, Business Process Management (BPM), Business Rules Engine, Adapters, Complex Event Processer, Business Activity Monitors, Service Registry, and Repository and Security. The Oracle Fusion Middleware platform includes all these tools and technologies in addition to portals, data clustering, and application development frameworks.

Implementing an optimized enterprise service-oriented solution is more complex than the traditional software development approach. It also requires well-defined implementation methodologies and governance to be succeeded. Designing reference architectures is one of the critical phases in the implementation lifecycle.

An EBO is essentially a design-time view of business entities. In technical terms, it defines the schema of the message types which can be exchanged between different components of AIA. As we have seen in the last section, AIA provides a standard-based integration approach through its centralized component. If we define the standard-based object for all integration communication, it prevents tight integrations and it is easier to manage integration challenges and modifications. EBO is standard-based common business objects that are known to business data models such as sales orders, claims, medical records, customers, and so on. A business object is a highly generalized business entity and has been carefully made to be as exhaustive as possible. Therefore, it abstracts the data models at a higher level (application independent canonical model). Therefore, the integration developed based on the AIA approach provides a higher flexibility to manage lower-level changes without changing integration objects and messages. This approach also eliminates the effort required for requesting applications to accommodate the messaging changes. Therefore, EBO helps to design and develop messaging objects at once and reuse as much as possible. Each EBO will be defined in the XML schema (XSD) and refer to each other wherever applicable, minimizing redundancy and promoting reusability.

An EBM is an EBO that is used in a particular context. It is the message that is exchanged between services at runtime. While EBOs represent the XSD or the schema for a business entity, an EBM represents the concrete XML in a particular context. For example, a SalesOrder EBO used for the creation of a sales order is a Create SalesOrderEBM, a SalesOrder EBO used for deletion of a SalesOrder is a Delete SalesOrderEBM, and so on. Therefore, an EBM is one or more EBOs and a verb, or action, used in a particular context. EBSs also exchange XML-based messages between two applications as part of request/response communication. However, EBMs includes business tasks or function-specific enterprise business objects. An EBM could be a generic messaging payload or a content-specific message payload.

In addition, EBM may include one or more EBOs in the same message. As the fundamental messaging architecture does not hold any underlying transportation mechanism, EBM also supports the transport of natural messaging.

Enterprise Business Services (EBS) is a core component in the AIA-based integration approach. EBS is an independent service component based on web service interfaces which helps to execute business tasks and functions. EBS, typically, consists of an abstract WSDL and service routing component. The WSDL defines service operations, messaging patterns, and XML payloads for each operation. Enterprise business services are coarse-grained web services that accept EBM as a message payload from the requesting application, routing the message, and finally, responding back to the requester in the EBM format. EBS makes sure that the interfaces to underlying services are standardized, and helps to specify the granularity of the service. It is an independent service, but can also communicate with other EBSs.

Enterprise Business Flow is used for orchestrating flows between two or more services exposed through EBS or other EBFs. EBFs are basically business processes. Business processes are organizational processes being followed to fulfill certain business goals. Such processes are required to interact with various divisions or business group's business activities. Processes kick off by a particular business event, then a process executes various business activities in a step-by-step or orchestrated approach. EBF is nothing but a business process component for Oracle AIA. Oracle AIA supports business processes' orchestration by executing various EBS components defined in the enterprise integration environment. AIA delegates all orchestration flows into the business services and shields such flows clearly from the Application Layer. The logic behind this is that the core business logic of an integration changes rarely as compared to the application side or end applications. Therefore, changes at the application end do not necessarily necessitate changes to the Business Flow layer represented by EBFs. In AIA, all processes are also exposed as EBS interface through web services.

As we have seen earlier, one of the best approaches is to have a validation and transformation component for each service, which integrates applications through Oracle AIA. Application Business Connector Service (ABCS) helps to bridge the gap between AIA EBS and application-specific data models. ABCS is responsible for validating the input request, transforming the message, enforcing security, and handling errors. ABCS can be requester-specific or provider-specific. The requestor is defined by the consuming application and the provider is defined by the service provider application. A requestor accepts the input message in an application specific format (ABM) and sends the response using the same format. A provider accepts the input from EBS or directly from a requester in EBM (common canonical data) and sends the response through the same channel. In addition, the provider ABCS plays a crucial role in exposing application business functions as services, which cannot be directly exposed as AIA's EBO.

In the enterprise SOA infrastructure, application business components, functions, processes, and resources are decomposed as business services. Therefore, in a typical enterprise environment, there is a high possibility of having hundreds of business services. It is highly difficult to manage the lifecycle of enterprise services and processes. There is a need of repository to handle service lifecycle, version management, monitoring, and auditing. Oracle Enterprise Repository provides such an enterprise-level service governance support, which is also an integral part of Oracle AIA FP 11g. The earlier version of Oracle AIA (Oracle AIA 2.4 and 2.5) supports Business Service Repository (BSR). However, the Oracle AIA Foundation Pack 11g release 1 consolidates the BSR functionalities with OER.

So far, we have seen the various core components of the Oracle AIA Foundation Pack which help to build the AIA approach-based integration solutions. As we know how development components are important in an integration solution, similarly, validating the integration solution is very important to produce a quality product. The Oracle AIA-based integration approach may invoke various business functions of application systems. Therefore, validating such an integration invocation through a simplified testing framework provides more flexibility. Oracle AIA Composite Application Validation System is a testing simulation framework which helps to invoke EBS, ABCS, and EBF in real-time scenarios. CAVS also includes a validation framework, service simulator, error handling configuration, and test repository to store the testing definitions and other user interfaces.

The Oracle AIA Process Reference Model is a proven best practice collected from and based on previous application integrations. This approach helps to identify the business processes, business activities, and build repository to keep track of the evaluation of the processes. This model is depicted in the following diagram:

Business processes are a collection of coordinated business tasks and business functions distributed across various business systems, which are executed in order to meet the organized goals. Some of the business processes that we would have come across are Order-to-Cash and Claim processes. Business activities are a set of tasks that execute a business function such as credit payment processing, order fulfillment, and so on. Finally, a task is a small activity which does not have any dependency on other tasks and activities such as create customer, check order status, and so on. In the composite application development, we can follow the top-down drilling approach to identify the business processes and its activities, and expose those functions as business services. Once the business tasks and activities are identified, we then need to build the business process workflow to meet the process requirements.

Apart from regular processes and business components, there are other utilities services that should also be designed as per the AIA reference architectures, which include e-mail notifications, adapter services for legacy integration, validation services, data set processing, and so on. Such services are grouped together as utility services which can be used by AIA integration solutions. This approach also helps to reuse such services for future requirements.

The Oracle SOA Suite is a set of components used to build mature, service-oriented architecture at an enterprise level. It is a central component in fusion middleware. The Oracle SOA Suite provides components for enabling services for existing applications and infrastructure assets, securing the service components, orchestrating services to build business processes, and building service composite applications.

The following are the components of the Oracle SOA Suite 11g product:

The Oracle SOA Suite is the foundation technology for Oracle AIA. The Oracle SOA Suite helps to build the AIA integration application by using various components, such as mediator, Oracle service bus, Adapters, Oracle BPEL process manager, and so on. The mediator is used to build the EBS component, whereas BPEL is used to build integration ABCS, EBF components of AIA. As the AIA approach is based on service-oriented principles, the Oracle SOA Suite best fits for implementing AIA solutions.