Oracle Application Integration Architecture (AIA) Foundation Pack 11gR1: Essentials

By Hariharan V Ganesarethinam
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Overview of Oracle AIA

About this book

Every Enterprise should have a learning curve in building better integration solutions from inaccuracy. Since Integration becomes the backbone of every corporate IT system, it is important to build the integration solution based on industry proven best practices. Oracle being a leader in enterprise solutions brings industry best practices and open standards as Oracle AIA framework. Oracle AIA Foundation Packs provide an open standard data model, templates and methodologies to build integrations and processes for enterprise applications. This book will guide you through the Oracle AIA fundamentals and development practices.

Oracle Application Integration Architecture (AIA) Foundation Pack 11gR1 focuses on the fundamentals of integration, the AIA approach to integration and various integration components in AIA. This book is developer- friendly as the structure of the book explains each component right from architecture to development.

This book covers Oracle AIA and its approach for better collaboration with integration teams. It covers all the components of the Oracle AIA Foundation Pack.

This book begins with AIA fundamentals, architecture, and components from Enterprise Business Objects (EBO), Enterprise Business Message (EBM), Enterprise Business Services (EBS), Application Business Connector Service (ABCS), and Enterprise Business Flow (EBF). However, this is not enough to build enterprise solution, so this book also covers AIA security, version management, design patterns, error handling, and centralized repository. In turn, this book doesn't leave out testing; it covers Composite Asset Validation System (CAVS). Finally, the last chapter ends with case studies that express real-time scenarios.

Publication date:
February 2012
Publisher
Packt
Pages
274
ISBN
9781849684804

 

Chapter 1. Overview of Oracle AIA

Application integration becomes the most common project in every enterprise and corporate. Integration is an important core component in IT systems. Oracle Application Integration Architecture (AIA) is a framework based on a Service Oriented Architecture approach that provides proven methodologies and best practices for integrating application systems. However, before we jump into AIA, let's understand the need for an application integration and various integration methodologies.

Small and large enterprises invest in building various business systems and applications to facilitate business functions and growth. However, due to various technology advancements, most of the applications and business systems developed over a period are in different ages and capabilities. Many enterprises are quite successful with their business applications, but not very successful in collaborating the data and business functions. In earlier days, data collaboration between applications systems was through manual entry that lead to a lack of data integrity and human errors. In order to avoid the data integrity issue and human errors, most of the investments were made towards integrating business systems. Therefore, integration becomes one of the mandatory agendas in every quarter. Why is such an investment going towards that? It is because of the organization's growth, acquisition, partner relationships, lack of standards, and technology barriers.

In this chapter, we will revisit some of the fundamentals of integration and Oracle AIA components. As part of that, the following topics will be covered:

  • Various types of integration

  • Integration architectures

  • AIA and its flavors

  • The Oracle AIA framework approach

  • Components of AIA

  • The Oracle AIA Reference Architecture

  • The role of Oracle Fusion Middleware

Various types of integration

There are various types of integrations which are followed by enterprises and industries. Integrations can be classified based on the need, scope, and architectural approaches.

Data integration

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.

Functional integration

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 (UI) integration

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.

Business process integration

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.

Business to business integration

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.

 

Various types of integration


There are various types of integrations which are followed by enterprises and industries. Integrations can be classified based on the need, scope, and architectural approaches.

Data integration

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.

Functional integration

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 (UI) integration

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.

Business process integration

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.

Business to business integration

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.

 

Integration architectures


There are various integration mechanisms or architectural approaches followed by industries to achieve integration needs.

Point-to-point

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:

Shared data repository

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)

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 (MOM)

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 service integration

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:

  • XML: It is a text-based meta language that helps to define a uniform messaging model

  • XML schema: It is an XML-based metadata definition based on W3C standards

  • SOAP: A messaging protocol for exchanging structured information

  • WSDL (Web Service Description Language): It is a descriptive artifact which elaborates service operations, input message structure, output message structure, data binding, and service endpoint URI

  • REST (Representational State Transfer): It is a style of architecture for service-based integration

  • WADL (Web Application Description Language): It is similar to WSDL, but WADL elaborates the RESTful service interfaces and operations in the form of XML

Note

SOAP and REST Web Services are two different styles of service implementation. The SOAP Web Service is basically a standards-based interface whereas REST is an architecture style of interface which provides access to the enterprise resources. The REST-based Web Service architecture best fits for CRUD (GET, PUT, POST, and DELETE) operations only. SOAP-based Web Services are basically meant for implementing complex business functions, which could be consumed by known or third party systems. The SOAP Web Service enforces policy and contract agreements.

Service-oriented Architecture

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.

Note

Notes:

There is a wrong perception that web services are SOA. Web services basically help to build loosely-coupled interfaces. Even if an enterprise has more than 100 web services, it does not mean that the enterprise has an SOA infrastructure. Service Oriented Architecture means basically, decomposing enterprise business processes and functions as services, and building business processes by orchestrating the services. This can be achieved by using various frameworks and technologies. However, web service is the most commonly adopted approach to implement such architectures. The SOA approach also requires governance and monitoring methodologies to identify the improvement opportunities. Therefore, web services are just integration interfaces and do not mean SOA.

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.

 

What is Oracle AIA?


The Oracle Application Integration Architecture is a complete standards-based integration and processing framework promoted by Oracle Corporation based on the Oracle Fusion Middleware platform. The AIA framework is designed and built based on the various collections of SOA best practices, principles, and standards. Therefore, an AIA approach provides an SOA-based integration framework, reference architecture, implementation methodologies, and best practices for integrating various business applications. This approach helps to build the application integration and enterprise business processes as more generic and align those processes to meet business requirements. The AIA integration approach also helps to build a Plug-and-Play integration solution which lowers IT costs, is faster to build, aligns quickly, and reduces the maintenance overhead. It also addresses the SOA design pain points, such as service decomposition, granularity and standard adoption.

AIA facilitates enterprises to use the existing application assets to build composite business processes and integration solutions. Oracle has a variety of application products which require an integration solution to seamlessly collaborate with each other. Oracle has understood the importance of integrating its application products, so Oracle provides best practices and reference solutions to build such integrations.

Oracle has two flavors of AIA products for its customers. Based on the customer's need and scope, a customer can choose from the following flavors:

  • Oracle AIA Foundation Pack

  • Oracle AIA Process Integration Pack

 

What is Oracle AIA Process Integration Pack?


Oracle AIA Process Integration Packs (PIPs) is a prebuilt integration package across Oracle's application solutions such as Siebel CRM, PeopleSoft, Oracle E-Business Suite, Agile PLM, Portal, and SAP. As PIP is a prebuilt package, it facilitates Oracle customers to rapidly deploy it to meet immediate application integration processes for Oracle applications. PIP packs are available not only for Oracle application's integration, but also for various domain-specific processes, such as driver-management for transportation, communication and revenue management for accounting, and so on.

Assume that we have to integrate an Order-to-Cash process flow between the Siebel CRM and Oracle EBS application, and the prebuilt PIP package is already available with Oracle. In a traditional SOA integration approach, we need to validate the application interfaces, messaging schema model, domain-specific standards to make decisions on the interface architecture, standards for messaging structure, data transformation, service interface description, discovery, and many more. All these tasks require enormous effort in analysis, design, development, and testing phases. Oracle AIA PIP implementation eliminates most of these efforts and helps to quickly adopt the AIA approaches. All we have to do is purchase the package, align the data models, and deploy in various environments as per the guidelines. At the time of writing, there are more than 25 prebuilt integrations and business process solutions available and they continue to grow. All these processes and integration solutions are built based on the Oracle AIA Foundation Pack framework. Customers who already have made a lot of investment in Oracle products and want to adopt SOA quickly can benefit from PIPs the most.

The scope of this book is to explore the Oracle AIA Foundation Pack 11gR1 and it does not cover Oracle AIA Process Integration Pack in depth. Let's discuss a little more about Oracle AIA PIP before getting into the AIA Foundation Pack.

 

Oracle AIA Foundation Pack concepts


Oracle AIA Foundation Pack is an SOA-based integration framework that includes building blocks of various components. The AIA building block components help to build complex end-to-end integration solutions based on a schema, an abstract or concrete WSDL, and a BPEL or Bus Component and Composite. The Oracle AIA Foundation Pack introduces a standard-based approach to integrate enterprise application systems as process-oriented composite application architecture. A composite application includes building an application solution with a combination of multiple service components, business functions, infrastructure services, business objects, rules, and business processes. Oracle Fusion Middleware helps to build such composite applications, and it can also be used to build the components of composite applications. As Oracle AIA components are running on Oracle SOA Suite, the composite approach could be easily adopted in Oracle AIA.

For better understanding, let's start from a simple point-to-point integration approach. In a point-to-point integration approach, the message/request object should be submitted by the requesting application to the provider application. The communication between the requester and provider could be through a file transfer, an HTTP request/response, a SOAP protocol, or a direct API call. In that case, there is no intermediate compound or layer involved in this approach. It is the requesting application's responsibility to build the message in the format that is accepted by the provider. In addition, the requesting application should transform the response message received from the provider into its own format. Therefore, the requesting and providing applications should communicate directly, as depicted in the following diagram:

The SOA best practices dictates that there should be an easily extensible canonical model between the two services, so that additional services can be accommodated with minimal changes later. Service virtualization should be used, so that the requesting services and the providing services are de-coupled, and orchestration is done with extensibility points. Therefore, to eliminate the tighter integration, we need to build a common canonical and standard interface middle component to handle all messages. This common intermediate component should handle messages in the standard data format, layout, and business process flows as services. In addition, this component should be deployed in common platforms, so that all applications could consume these services. The common platform should be hosted in a service-oriented infrastructure. As it is a common platform for applications to meet the standard, there should be a transformation component which should transfer the messages that are received from the application to the common standard layout. The transformers are used to map between application-specific messages and a canonical data model. Therefore, communication will navigate through standard layout-based services. There should be a transformer component at the provider application side which should reformat the message from middleware standard format into the provider format. This approach removes the transformation and message formatting responsibilities from the requesting and providing applications.

In addition, the common standard-based middleware can be utilized by other applications which requires message routing and transformation services from the provider. This procedure is depicted in the following diagram:

The preceding diagram represents the role of Oracle Fusion Middleware in AIA. The Oracle Fusion Middleware is used as a platform where AIA components are deployed. In the enterprise infrastructure environment, there is a high possibility of having more integration components and business services for all applications. Such environments require a centralized single service reference registry and repository for all schema and WSDL, where the requesting application identifies and chooses appropriate services for specific integration requirements. If there is no similar service available, then enforce to develop new service components and publish those to the service registry for reference.

In addition, such a service integration approach requires an effective error handling mechanism, service and message level security, and integration testing framework to facilitate the integration development. The combination of all these components makes the entire integration a highly mature service-oriented integration platform. This is all about the Oracle Application Integration Architecture framework and approach.

The following are the features of the Oracle AIA Foundation Pack:

  • Helps to build a standard-based integration architecture between enterprise applications

  • Highly robust integration framework for building service-oriented integration architecture

  • Supports a high volume of transactions for enterprise mission-critical applications and infrastructure

  • Ability to encapsulate the functionalities provided by Oracle applications and other enterprise application systems

  • Supports business process decomposition, analysis, service design, service construction, process definition, and deployment/upgrade plans

  • Supports monitoring integration services and process flows at runtime

  • Supports design and runtime artifact governance

 

Components of AIA Foundation Pack


So far, we have seen the Oracle integration approach and various components (in general) involved in building a service-oriented integration. In essence, the AIA Foundation Pack is a set of artifacts that are used to create, govern, and maintain the SOA-based integration. Now we have to explore the various components of the Oracle AIA Foundation Pack.

The Oracle AIA Foundation Pack includes several components to meet various standards and best practices to build the enterprise-level application integration architecture. The following is a list of components that AIA includes, and will be explored in this book:

  • Enterprise Business Objects (EBO)

  • Enterprise Business Messages (EBM)

  • Application Business Connector Services (ABCS)

  • Enterprise Business Services (EBS)

  • Enterprise Business Flow (EBF)

  • Enterprise Repository (ER)

  • Composite Application Validation System (CAVS)

As this book covers all preceding components in the following chapters, we will have a brief overview of each component in this chapter.

Enterprise Business Objects (EBO)

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.

Enterprise Business Messages (EBM)

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.

Note

In the messaging architecture, a message includes a header and body. The header helps to carry message-specific metadata information between applications. This header information is used for security, client application ID, and environment-specific information. In the enterprise-service architecture, the header plays a crucial role to keep track of the message information for monitoring and auditing purposes.

Enterprise Business Services (EBS)

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.

Note

In an SOA approach, web services can be implemented at different levels or layers. This is called service granularities. There are two levels of granularity which are typically practiced. They are Fine-grained and Coarse-grained web services. Implementing web services at a lower level are Fine-grained web services, such as update the customer address. Coarse-grained web services are at higher/generic level, such as account service.

Enterprise Business Flow (EBF)

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.

Application Business Connector Services (ABCS)

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.

Oracle Enterprise Repository (OER)

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.

Note

If you are using Oracle AIA 2.4 or 2.5 and would like to migrate to Oracle AIA 11g Release 1, you must migrate all your AIA service components from the BSR version to OER. Oracle provides a separate migration guide for its customers.

Composite Application Validation System (CAVS)

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.

 

Oracle AIA Reference Architecture


In general, designing and implementing an SOA integration solution is a very complicated process. The SOA implementation requires a strong roadmap and implementation lifecycle to succeed. An iterative development methodology-based implementation lifecycle fits best for the SOA implementation. In addition, the reference architecture plays a crucial role to eliminate the design complexity and redundancy. In a real-time scenario, if we want to construct a corporate office building, we need an architectural blueprint for construction. Similarly, the SOA reference architecture acts as a blueprint for the enterprise SOA implementation. The Oracle AIA reference architecture model is almost similar to the SOA reference architecture, as seen in the following diagram:

The preceding diagram represents the AIA reference architecture based on the SOA reference architecture approach. As we have seen, the entire AIA application solution should be deployed in the fusion middleware to get service-oriented advantages. If we look at the architecture, we will find that the complete solution is separated as two layers. Basically, this increases the performance of the integration solution. In the architecture world, we should design the solution with simplified layers to increase the performance and reduce latency.

Similarly, the AIA approach requires building an integration solution by the AIA core service layer and business process flow layer. All the AIA service components should be grouped together as part of the core service layer. The AIA components such as EBO, EBM, and EBS are part of the core service layer. All these core services are consumed to build EBF and business processes. The Oracle Enterprise Repository could play the role of service repository where all AIA business services can be registered. As the AIA integration solution deployed in the fusion middleware platform, securing services, policy governance, and monitoring can be implemented using fusion components.

Now the question is to identify the processes and business services to define the reference architecture. Oracle has suggested a process reference model in which a collection of best practices is gathered from various Oracle application customers.

AIA Process Reference Model

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 role of Oracle Fusion Middleware


The Oracle Fusion Middleware is an enterprise platform that provides solutions for various enterprise needs. Fusion middleware supports a variety of standards for integration, business processes, business intelligence, web development, content management and hosting servers, enterprise governance, and so on. One of the primary integration and process implementation components in the fusion middleware includes Oracle SOA Suite and Oracle Service Bus. The Oracle SOA Suite is built based on various patterns from enterprise application integration and service-oriented architecture.

Oracle SOA Suite 11g

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:

  • Oracle Mediator

  • Oracle Technical/Application Adapters

  • Oracle BPEL Process Manager

  • Human Workflow

  • Oracle Service Bus

  • Oracle Business Rules

  • Oracle Enterprise Manager

  • Oracle Complex Event Processing

  • Oracle B2B

  • Oracle Web Service Manager

  • Oracle Business Activity Monitor

  • Oracle Metadata Repository

  • JDeveloper IDE

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.

 

Summary


In this chapter, we have seen the various application integration requirements and architecture methodologies. Oracle AIA provides a standard-based application integration framework to build highly-scalable, processes-oriented integration solutions for enterprise assets. In addition, we have seen a brief overview of AIA concepts and integration approaches using Oracle SOA Suite.

The following chapters in this book cover more details about AIA components and one real-time use case of an AIA implementation.

The next chapter will cover the primary core component of the AIA approach, Enterprise Business Object (EBO), including the following topics:

  • An overview of EBO

  • Elements of EBO

  • Exploring EBO

  • The physical structure of EBO

  • Various domain-specific EBO components

  • Extending EBO

About the Author

  • Hariharan V Ganesarethinam

    Hariharan V Ganesarethinam associated with Aspire Systems Inc, USA as Senior Architect of Enterprise Architecture Solutions. He leads enterprise architecture, integration and SOA solutions for various customers of Aspire Systems Inc. He has around 15 years of experience in the IT industry with a variety of technologies, strategy, and enterprise solution experiences. He has architected various enterprise level solutions based on SOA, BPM and EAI architectures. Prior to Aspire Systems, he was leading various integration and research projects in MGL Americas and Unisys India. Hariharan is passionate about researching and learning upcoming technologies, architecture and industry best practices. His expertise and knowledge in SOA, EAI, ESB, BPM and SOA Governance made him comfortable in providing technical and business solutions to folks across global. He has hands on experience in implementing SOA and EAI projects using Web Services, Oracle SOA Suite, Oracle AIA, iWay Service Manager and Java CAPS. He is also an Oracle certified Oracle SOA Architect Expert. Hariharan is well known in the SOA industries through his articles published on IT Toolbox (http://it.toolbox.com/blogs/soa-governance/) and Sys-Con Media (http://vghariharan.sys-con.com/). He has written many articles in the area of SOA and SOA Governance. His articles are related to various decision-making situations in the SOA implementation. He owns a group in http://www.linkedin.com called "SOA, EA and IT Governance Practitioners Forum" through which he shares and consolidates industries views on SOA and EA practices. He also presented a paper in the IBI Summit 2010 about "Service Reusability and Best Practices" (http://www.slideshare.net/shahari3/soa- ... or-iway-sm).

    Browse publications by this author
Book Title
Access this book, plus 7,500 other titles for FREE
Access now