What do terms like AIA, EBO, EBS, etc. mean?
Oracle has its own guide to explain all the AIA terms, the AIA Concepts and Technologies Guide [ref: Oracle® Application Integration Architecture -Foundation Pack 2.5: Concepts and Technologies Guide Release 2.5 Part No. E15762-01 October 2009]. Here a overview of the terms AIA, EBO, EBM, ABO, ABM, EBS, EBF, ABCS, BSR, CAVS, PIP, SOA, ESB and BPEL with their explanation:
AIA - Application Integration Architecture
Oracle Application Integration Architecture Foundation Pack provides Oracle's best-practice methodology and reference architecture, which are based on a profound service-oriented foundation running on Oracle's best-in-class middleware suites. Application Integration Architecture defines a common vocabulary across applications and industries. EBOs are the key elements in this context. They canonically describe standard business entities such as an order or an invoice. Based on these generic business entities, Application Integration Architecture delivers other artifacts such as EBSs, EBMs, EBFs, and ABCSs.
Basically AIA delivers you the integration framework including a canonical model.
EBO - Enterprise Business Object
You can think of EBOs as canonical, application-agnostic representations of frequently used business entities. The architecture starts with the concept of Enterprise Business Objects (EBOs). EBOs can be considered as application-independent representations of key business entities.
Basically EBOs are the objects moving between applications.
EBM - Enterprise Business Message
An EBM is the message format that is specific to the input or output of an EBS operation. Enterprise Business Service operations require specific message formats called Enterprise Business Messages (EBMs) for service requests and responses.
Basically EBMs are the envelopes containing the EBOs.
ABO/ABM - Application Business Objects/Messages
The Oracle AIA canonical model exists of the EBOs and EBMs. Outside the canonical domain are the application-specific formats, these can be objects and messages, respectively ABOs and ABMs. Every application has it's own set of ABOs and ABMs.
Basically ABOs and ABMs are application specific objects and envelopes.
EBS - Enterprise Business Service
An EBS provides the generic operations that an EBO should have. Enterprise Business Services (EBSs) are the centerpiece of the AIA Reference Architecture. They implement the required operations on EBOs in the right coarse-grained granularity that SOAs demand. For every EBO, Application Integration Architecture also ships generic service definitions to cover standard operations such as create, update, query, delete, and sync.
Basically EBSs are the routing services.
EBF - Enterprise Business Flow
An EBF orchestrates a number of EBSs to implement a complex integration flow. Sometimes, the integration scenario is not just a simple requester-provider relationship. In those cases, an Enterprise Business Flow (EBF) orchestrates any number of EBSs required to implement a specific business flow. The EBF completely controls the business logic and calls the appropriate EBS methods.
Basically EBFs are the orchestrations spanning multiple EBO's and/or applications.
ABCS - Application Business Connector Service
An ABCS implements a particular service operation in the context of a specific application. To enable applications to integrate into these generic, application-independent structures, you can implement Application Business Connector Services (ABCSs). Such an ABCS calls or is called by the appropriate EBS, depending on whether the application is in the requestor or provider role in a particular scenario. The main responsibilities of ABCSs include: conversion between the generic EBO and the application-specific format (ABO), cross-referencing of key attributes and message validation, and conversation with the specific application.
Basically ABCSs are the application-specific services per EBM.
BSR - Business Service Registry
The BSR stores and provides information about the objects, messages, and services that compose the integration scenarios in your Oracle AIA ecosystem. An integration scenario refers to the end-to-end (requester participating application-to-provider participating application) flow of a message. The BSR presents the components of your integration scenarios in a centrally managed and searchable repository, enabling it to become the system of record for your business services.
Basically BSR stores services, test-definitions and application-information.
CAVS - Composite Application Validation System
The CAVS enables you to test integration web services without the deployed participating applications in place. Using a framework that includes initiators to simulate calls to participating applications and simulators to simulate responses from participating applications, CAVS provides a system that can test integrations while also eliminating the need to set up deployments of all participating applications that are involved in the integration. The CAVS provides a test repository, an execution engine, and a user interface.
Basically CAVS is a testing framework.
PIP - Process Integration Pack
Prebuilt process integration packs (PIPs) from Oracle use the Oracle AIA to deliver composite industry processes for specific industries, using software assets from Oracle's portfolio of applications. Most of these solutions encompass orchestrated process flows, as well as prebuilt data integration scenarios that are meant to seamlessly connect the systems.
Basically PIPs are off-the-shelf integrations.
SOA - Service Oriented Architecture
Oracle AIA relies upon a SOA for integrations. SOA is an approach for defining an architecture based on the concept of a service. SOA applications are integrated at the service specification point, not at the application interface. This allows application complexities to be separated from the services interface, and diminishes the impacts of back-end interface and application changes. Service-oriented integration leverages messages to communicate between consumers and providers and uses XML schemas and transports such as SOAP to transport messages.
Basically SOA is integrating using (web) services.
ESB - Enterprise Service Bus
In integrations where it makes sense, Oracle AIA also relies on ESB. An ESB is the underlying infrastructure for delivering SOA. Oracle AIA uses Oracle Enterprise Service Bus as the foundation for services using SOA. It enables interaction through services that encapsulate business functions and supports service routing and the substitution and translation of transport protocols.
Basically ESB and BPEL are the engines driving Oracle SOA Suite. ESB is used for application adapters and routing rules (EBSs).
BPEL - Business Process Execution Language
Business Process Execution Language (BPEL), short for Web Services Business Process Execution Language (WS-BPEL) is an OASIS standard executable language for specifying actions within business processes with web services. Processes in Business Process Execution Language export and import information by using web service interfaces exclusively.
Basically BPEL and ESB are the engines of the Oracle SOA Suite. BPEL is used for transformations (ABCSs) and orchestrations (EBFs).
AIA - Application Integration Architecture
Oracle Application Integration Architecture Foundation Pack provides Oracle's best-practice methodology and reference architecture, which are based on a profound service-oriented foundation running on Oracle's best-in-class middleware suites. Application Integration Architecture defines a common vocabulary across applications and industries. EBOs are the key elements in this context. They canonically describe standard business entities such as an order or an invoice. Based on these generic business entities, Application Integration Architecture delivers other artifacts such as EBSs, EBMs, EBFs, and ABCSs.
Basically AIA delivers you the integration framework including a canonical model.
EBO - Enterprise Business Object
You can think of EBOs as canonical, application-agnostic representations of frequently used business entities. The architecture starts with the concept of Enterprise Business Objects (EBOs). EBOs can be considered as application-independent representations of key business entities.
Basically EBOs are the objects moving between applications.
EBM - Enterprise Business Message
An EBM is the message format that is specific to the input or output of an EBS operation. Enterprise Business Service operations require specific message formats called Enterprise Business Messages (EBMs) for service requests and responses.
Basically EBMs are the envelopes containing the EBOs.
ABO/ABM - Application Business Objects/Messages
The Oracle AIA canonical model exists of the EBOs and EBMs. Outside the canonical domain are the application-specific formats, these can be objects and messages, respectively ABOs and ABMs. Every application has it's own set of ABOs and ABMs.
Basically ABOs and ABMs are application specific objects and envelopes.
EBS - Enterprise Business Service
An EBS provides the generic operations that an EBO should have. Enterprise Business Services (EBSs) are the centerpiece of the AIA Reference Architecture. They implement the required operations on EBOs in the right coarse-grained granularity that SOAs demand. For every EBO, Application Integration Architecture also ships generic service definitions to cover standard operations such as create, update, query, delete, and sync.
Basically EBSs are the routing services.
EBF - Enterprise Business Flow
An EBF orchestrates a number of EBSs to implement a complex integration flow. Sometimes, the integration scenario is not just a simple requester-provider relationship. In those cases, an Enterprise Business Flow (EBF) orchestrates any number of EBSs required to implement a specific business flow. The EBF completely controls the business logic and calls the appropriate EBS methods.
Basically EBFs are the orchestrations spanning multiple EBO's and/or applications.
ABCS - Application Business Connector Service
An ABCS implements a particular service operation in the context of a specific application. To enable applications to integrate into these generic, application-independent structures, you can implement Application Business Connector Services (ABCSs). Such an ABCS calls or is called by the appropriate EBS, depending on whether the application is in the requestor or provider role in a particular scenario. The main responsibilities of ABCSs include: conversion between the generic EBO and the application-specific format (ABO), cross-referencing of key attributes and message validation, and conversation with the specific application.
Basically ABCSs are the application-specific services per EBM.
BSR - Business Service Registry
The BSR stores and provides information about the objects, messages, and services that compose the integration scenarios in your Oracle AIA ecosystem. An integration scenario refers to the end-to-end (requester participating application-to-provider participating application) flow of a message. The BSR presents the components of your integration scenarios in a centrally managed and searchable repository, enabling it to become the system of record for your business services.
Basically BSR stores services, test-definitions and application-information.
CAVS - Composite Application Validation System
The CAVS enables you to test integration web services without the deployed participating applications in place. Using a framework that includes initiators to simulate calls to participating applications and simulators to simulate responses from participating applications, CAVS provides a system that can test integrations while also eliminating the need to set up deployments of all participating applications that are involved in the integration. The CAVS provides a test repository, an execution engine, and a user interface.
Basically CAVS is a testing framework.
PIP - Process Integration Pack
Prebuilt process integration packs (PIPs) from Oracle use the Oracle AIA to deliver composite industry processes for specific industries, using software assets from Oracle's portfolio of applications. Most of these solutions encompass orchestrated process flows, as well as prebuilt data integration scenarios that are meant to seamlessly connect the systems.
Basically PIPs are off-the-shelf integrations.
SOA - Service Oriented Architecture
Oracle AIA relies upon a SOA for integrations. SOA is an approach for defining an architecture based on the concept of a service. SOA applications are integrated at the service specification point, not at the application interface. This allows application complexities to be separated from the services interface, and diminishes the impacts of back-end interface and application changes. Service-oriented integration leverages messages to communicate between consumers and providers and uses XML schemas and transports such as SOAP to transport messages.
Basically SOA is integrating using (web) services.
ESB - Enterprise Service Bus
In integrations where it makes sense, Oracle AIA also relies on ESB. An ESB is the underlying infrastructure for delivering SOA. Oracle AIA uses Oracle Enterprise Service Bus as the foundation for services using SOA. It enables interaction through services that encapsulate business functions and supports service routing and the substitution and translation of transport protocols.
Basically ESB and BPEL are the engines driving Oracle SOA Suite. ESB is used for application adapters and routing rules (EBSs).
BPEL - Business Process Execution Language
Business Process Execution Language (BPEL), short for Web Services Business Process Execution Language (WS-BPEL) is an OASIS standard executable language for specifying actions within business processes with web services. Processes in Business Process Execution Language export and import information by using web service interfaces exclusively.
Basically BPEL and ESB are the engines of the Oracle SOA Suite. BPEL is used for transformations (ABCSs) and orchestrations (EBFs).
No comments:
Post a Comment