What do terms like AIA, EBO, EBS, etc. mean?

Oracle has it's 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).

EBO customizations

Sometimes the EBO does not contain the elements for the information you have as part of this business object. For this case Oracle offers customization xsd's for each EBO and generic customization xsd's for common components to extend the EBO with needed elements and dataypes.

When you are going to extend an EBO, first try to find an existing common component to use for your attributes. Example when extending the EBO with street and housenumber, use the address datatype from common components. Sometimes the datatype of the used element is not known in the custom xsd, for this you have to add an import as well, for example if a common component is needed in CustomCommonComponents.xsd:
<xsd:import namespace="http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V2" schemaLocation="../../../Common/V2/CommonComponents.xsd"/>

Also determine whether the information is new/updated or a reference to information already known by the systems. Example when sending a new or updated address information use AddressDatatype, when sending a reference to a known address then use AddressReference as referenceType.

If the addition is a just one element then choose the datatype from one of the Infrastructure datatypes (\EnterpriseObjects\Infrastructure\V1\DataTypes.xsd). Example when an element is needed to indicate whether something is fragile, add a fragileIndicator of datatype IndicatorType from this DataTypes list.

In order to maintain backwards compatibility always make customizations optional (minOccurs='0') to avoid validation errors in current messages. Check similar EBOs for consistency.

Besides the good practice to document the customizations in the custom xsd itself (as a comment in the header), it is very useful to have a spreadsheet with all the customizations documented. For example with the following columns: Filename of EBO, Type extended, Name of element added, User added and Date added. To keep track of removals the following two columns can be added as well: User removed and Date removed, just be careful when removing customizations as they can be used by other projects already.

AIA configuration properties

AIA brings us a very nice solution for maintaining variables in one global AIAConfigurationProperties.xml file (kind of ini-file) which are used at runtime. This is the perfect place for e.g. the systemID (application system id) which is used in the code to identify the application for DVM and XRef translations. Also is this systemID used to populate the EBMHeader Sender segment with information from the BSR (Business Service Repository) when the EBM is created in the BPEL RequesterABCSImpl component.

All the aia functions are described and explained in the AIA Development Guide [ref: Oracle® Application Integration Architecture - Foundation Pack 2.5: Integration Developer's Guide Release 2.5 Part No. E16465-01 December 2009].

Creation of the EBM Header in the transformation xsl file:
<xsl:variable name="serviceName" select="'{http://xmlns.oracle.com/ABCSImpl/[Application]/Core/[ABCSName]/V1}[ABCSName]'"/>
<xsl:variable name="systemID" select="aia:getServiceProperty($serviceName,'Default.SystemID',true())"/>
<xsl:variable name="senderNodeVariable" select="aia:getEBMHeaderSenderSystemNode($systemID,'')"/>
<xsl:variable name="messageIdVariable" select="orcl:generate-guid()"/>

<corecom:EBMHeader>
<corecom:EBMID>
 <xsl:value-of select="$messageIdVariable"/>
</corecom:EBMID>
<corecom:EBMName>
 <xsl:text disable-output-escaping="no">{http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/Object/V1}SyncObjectListEBM</xsl:text>
</corecom:EBMName>
<corecom:EBOName>
 <xsl:text disable-output-escaping="no">{http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/Object/V1}ObjectEBO</xsl:text>
</corecom:EBOName>
<corecom:CreationDateTime>
 <xsl:value-of select="xp20:current-dateTime()"/>
</corecom:CreationDateTime>
<corecom:VerbCode>
 <xsl:text disable-output-escaping="no">Sync</xsl:text>
</corecom:VerbCode>
<corecom:Sender>
 <corecom:ID>
  <xsl:value-of select="$senderNodeVariable/ID"/>
 </corecom:ID>
 <corecom:Description>
  <xsl:value-of select="$senderNodeVariable/Description"/>
 </corecom:Description>
 <corecom:IPAddress>
  <xsl:value-of select="$senderNodeVariable/IPAddress"/>
 </corecom:IPAddress>
 <corecom:Application>
  <corecom:ID>
   <xsl:value-of select="$senderNodeVariable/Application/ID"/>
  </corecom:ID>
  <corecom:Version>
   <xsl:value-of select="$senderNodeVariable/Application/Version"/>
  </corecom:Version>
 </corecom:Application>
 <corecom:ContactName>
  <xsl:value-of select="$senderNodeVariable/ContactName"/>
 </corecom:ContactName>
 <corecom:ContactEmail>
  <xsl:value-of select="$senderNodeVariable/ContactEmail"/>
 </corecom:ContactEmail>
 <corecom:ContactPhoneNumber>
  <xsl:value-of select="$senderNodeVariable/ContactPhone"/>
 </corecom:ContactPhoneNumber>
</corecom:Sender>

The configuration properties can also be used to retrieve the service-endpoints, pretty convenient when you'll have to deploy the code to other environments with different endpoints. When the CAVS framework is not used in your organization you can remove the whole CAVS endpoint javacode in the BPEL sourcecode which was generated by the ABCS Service Constructor. Set a webservice endpoint as follows:
<variable name="EndpointReference" element="wsa:EndpointReference"/>

<assign name="SetServiceEndpoint">
  <copy>
    <from>
      <wsa:EndpointReference xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing">
        <wsa:Address/>
      </wsa:EndpointReference>
    </from>
    <to variable="EndpointReference"/>
  </copy>
  <copy>
    <from expression="aia:getServiceProperty('{http://xmlns.oracle.com/ABCSImpl/[Application]/Core/[ABCSName]/V1}[ABCSName]','Routing.[PartnerLinkName].EndpointURI',true())"/>
    <to variable="EndpointReference" query="/wsa:EndpointReference/wsa:Address"/>
  </copy>
  <copy>
    <from variable="EndpointReference"/>
    <to partnerLink="[PartnerLinkName]"/>
  </copy>
</assign>

Besides populating the BSR with the application information to populate the EBM Sender elements, by logging into the /AIA site, go to Setup and then tab System, the key field here is System Code = systemID. The properties mentioned above have to be configured in the AIA file before lookup:
$AIA_HOME/config/AIAConfigurationProperties.xml, just above the </AIAConfiguration> tag:
<!-- [ABCSName] -->
<ServiceConfiguration serviceName="{http://xmlns.oracle.com/ABCSImpl/[Application]/Core/[ABCSName]/V1}[ABCSName]">
 <Property name="Default.SystemID">APPLICATION_01</Property>
 <Property name="Routing.[PartnerLinkName].EndpointURI">http://[HTTP_HOST]:[HTTP_PORT]/webserviceaddress</Property>
</ServiceConfiguration>
In the transformation source code (xsl) only the serviceName has to be specified, not the systemID (APPLICATION_01). This systemID gets retrieved from the AIAConfigurationProperties xml file. After editing this file don't forget to reload the AIA Configuration properties: log in the /AIA site, go to setup, go to configuration and after scrolling down you'll find the Reload button.

It's worth to mention that this AIA Configuration Properties file contains environment-specific properties, like partnerlink endpoints. Use the same procedure here as you have for managing connection pools and other physical endpoints/jdbc urls/id's per application per environment.

EBMTracking stamp both in BPEL as ESB

According to AIA [ref: Oracle® Application Integration Architecture - Foundation Pack 2.5: Integration Developer's Guide Release 2.5 Part No. E16465-01 December 2009] the messages get Tracking Information added within both the BPEL and ESB components. Below you find some updated code to get this EBMTracking segment populated (the Sample EBM here is of type SyncObjectEBM):

The transformation within the BPEL Component RequesterABCSImpl (xsl) which creates the EBM:

<xsl:variable name="ServiceName" select="'{http://xmlns.oracle.com/ABCSImpl/[SenderApplication]/Core/[ABCSName]/V1}[ABCSName]'"/>

<corecom:EBMTracking>
 <corecom:SequenceNumber>
  <xsl:value-of select="position()"/>
 </corecom:SequenceNumber>
 <corecom:ExecutionUnitID/>
 <corecom:ExecutionUnitName>
  <xsl:value-of select="$ServiceName"/>
 </corecom:ExecutionUnitName>
 <corecom:ImplementationCode>
  <xsl:text disable-output-escaping="no">BPEL</xsl:text>
 </corecom:ImplementationCode>
 <corecom:ActivityDateTime>
  <xsl:value-of select="xp20:current-dateTime()"/>
 </corecom:ActivityDateTime>
</corecom:EBMTracking>

After the transformation the ExecutionUnitID gets populated in the BPEL code with the following assign:

<assign name="Assign_InstanceID">
 <copy>
  <from expression="ora:getInstanceId()"/>
  <to variable="SyncObjectEBSReqMsg" part="SyncObjectEBM" query="/objectebs:SyncObjectEBM/corecom:EBMHeader/corecom:EBMTracking/corecom:ExecutionUnitID"/>
 </copy>
</assign>

The following transformation has to be created inside the ESB Component, the population of the ExecutionUnitID is described in the Best Practices Guide [ref: Oracle® SOA Suite Best Practices Guide 10g Release 3 (10.1.3.3.0) E10971-01 December 2007].
Tip: first let JDeveloper create the transformation and map one field to get all the namespaces populated, afterwards copy/paste the following code:

<xsl:template match="/">
 <ebo:SyncObjectListEBM>
  <corecom:EBMHeader>
   <xsl:copy-of select="ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:EBMID"/>
   <xsl:copy-of select="ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:EBMName"/>
   <xsl:copy-of select="ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:EBOName"/>
   <xsl:copy-of select="ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:CreationDateTime"/>
   <xsl:copy-of select="ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:VerbCode"/>
   <xsl:copy-of select="ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:MessageProcessingInstruction"/>
   <xsl:copy-of select="ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:Sender"/>
   <xsl:copy-of select="ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:Target"/>
   <xsl:copy-of select="ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:BusinessScope"/>
   <xsl:for-each select="ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:EBMTracking">
    <xsl:copy-of select="."/>
   </xsl:for-each>

<corecom:EBMTracking>
 <corecom:SequenceNumber>
  <xsl:value-of select="position() + 1"/>
 </corecom:SequenceNumber>
 <corecom:ExecutionUnitID>
  <xsl:value-of select="ehdr:getInstanceID()"/>
 </corecom:ExecutionUnitID>
 <corecom:ExecutionUnitName>
  <xsl:text disable-output-escaping="no">{http://xmlns.oracle.com/EnterpriseServices/Core/Object/V1}ObjectEBS</xsl:text>
 </corecom:ExecutionUnitName>
 <corecom:ImplementationCode>
  <xsl:text disable-output-escaping="no">ESB</xsl:text>
 </corecom:ImplementationCode>
 <corecom:ActivityDateTime>
  <xsl:value-of select="xp20:current-dateTime()"/>
 </corecom:ActivityDateTime>
</corecom:EBMTracking>

  </corecom:EBMHeader>
  <xsl:for-each select="ebo:SyncObjectListEBM/ebo:DataArea">
   <xsl:copy-of select="."/>
  </xsl:for-each>
 </ebo:SyncObjectListEBM>
</xsl:template>

Last thing: add the following property to your esb component:
name:    enableAccessBusinessEvent
value:   true

Routing rules

Basically routing rules are build upon the following three parts: sender, receiver and messagetype.

With AIA comes a library of EBOs (Enterprise Business Objects - canonical model), EBMs (Enterprise Business Messages - EBO + envelope per action/verb) and EBSs (Enterprise Business Service - routing service per EBO, one operation for each EBM).
As the EBS contains already one operation per EBM for an EBO we can see AIA takes already care of the messagetype. The routing rule in the EBS consists of filter, mapping and target. This leaves us with no place for the sender as part of the routing rule as defined by AIA.

Therefor we want to include the sender as follows, two scenarios are described here.

First scenario: direct integration from ApplicationX to ApplicationY, apply the filter on sender and empty target to exclude calls from the EBF (the only component allowed to stamp the target).
{/ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:Sender/corecom:ID = 'ApplicationX_01' and not(/ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:Target/corecom:ID/text())};

Second scenario: direct integration with an EBF (Enterprise Business Flow) involved for data enrichment in ApplicationZ, apply the filter on sender and the target, the target is stamped by the EBF (the only component allowed to stamp the target).
Data enrichment - send to ApplicationZ_01:
{/ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:Sender/corecom:ID = 'ApplicationX_01' and /ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:Target/corecom:ID = 'ApplicationZ_01'};
Receiver - send to ApplicationY_01:
{/ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:Sender/corecom:ID = 'ApplicationX_01' and /ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:Target/corecom:ID = 'ApplicationY_01'};

The advantage is a clear overview and easier to extend/maintain the rules, the advantage increases over time.

Queue character limit

The AIA comes with howto advices and best practices, following AIA results in uniform developed interfaces which are easy to monitor and maintain. For example the naming convention for queues, the following naming convention applies to the Queue name [ref: Oracle® Application Integration Architecture - Foundation Pack 2.5: Integration Developer's Guide Release 2.5 Part No. E16465-01 December 2009]:

AIA_<App><ABO>ProvJMSQueueV[Version Number]
This convention forgets the verb and list, so we extend this naming convention to (optional=<>, variable=[])
AIA_<[App]><[verb]><[ABO|EBO]><List><Prov>JMSQueue<V[version number]>
Explanation: App is not applicable when the queue is between an EBS and before EBF (within the AIA domain), verb is from the list create|update|delete|query|sync etc., an ABO might be used before an ABCSRequester, EBO after an EBS, use a List when an ListEBM is used, use Prov for queues between an EBS and before an ABCSProvider, version number is optional for first version as V1 is the default when no version is mentioned.

The above conventions applied to a queue between the Create ObjectListEBS and ApplicationX ABCS Provider results in the following name:
According tot AIA: AIA_ApplicationXObjectProvJMSQueue Length=34
Extended convention: AIA_ApplicationXCreateObjectListProvJMSQueue Length=44

As the Oracle Database for the JMS store has a limit of 24 characters on the queue name (as well on the queue tablespace name), the convention has to be adjusted in order to not to exceed the 24 character limit while still being descriptive:

If length>24 then Shorten Queue to Q
If length>24 then shorten verb to Cre, Upd, Sy, Del, Qry
If length>24 then shorten List to L
If length>24 then shorten <ABO/EBO> to max 6
If length>24 then shorten <App> to max 6
If length>24 then shorten <ABO/EBO> to max 4
If length>24 then shorten <App> to max 4

Try to remain descriptive here, so the example we shorten as follows:

AIA_ApplicationXCreateObjectListProvJMSQueue (44)
AIA_ApplicationXCreateObjectListProvJMSQ (40)
AIA_ApplicationXCreObjectListProvJMSQ (37)
AIA_ApplicationXCreObjectLProvJMSQ (34)
AIA_AppliXCreObjectLProvJMSQ (28)
AIA_AppliXCreObjtLProvJMSQ (26)
AIA_AppXCreObjtLProvJMSQ (24)

For the queue tablespace simply replace the Q(ueue) with T(ablespace).

Tips to start SOA Suite developments

In order to have all the interfaces in Oracle SOA Suite developed in an uniform way there is a need for coding standards and naming conventions. Oracle delivers the Application Integration Architecture, which includes a canonical model, a test-framework, coding standards, naming conventions and more.

Some tips when starting with Oracle SOA Suite:

• Stick to one version or patch-level for all environments. Only if a new version or MLR (patch-bundle) is needed, for example to fix a showstopper, start a project to upgrade/patch all your environments.
• Developers must have read the AIA Development Guide [ref: Oracle® Application Integration Architecture - Foundation Pack 2.5: Integration Developer's Guide Release 2.5 Part No. E16465-01 December 2009] or taken an AIA course. As for some the AIA Development Guide is not an easy and fast read, a good practice is to create a summary for those developers :) Add to this summary company-specific coding standards and naming conventions.
• Implement the components in either BPEL or ESB technology based on their purpose. All ABCSs in BPEL, all EBFs in BPEL, all EBSs in ESB, all non-soap communication with applications use ESB adapters.
• Use the AIA Service Generator for the BPEL components (ABCSs). This takes care of code for AIA ErrorHandling, CAVS test framework and sets instance title etc.
• Automate the deployments using scripts or e.g. the osbs - Oracle Soa Build Server by Marc Kelderman [ref: http://orasoa.blogspot.com/2009/04/new-oracle-soa-build-server-osbs.html]
• Set xml validation to strict on the development and test environments (except while executing stress-tests).
• Define ownership for all the EBO customizations, DVMs, XRefs, AIA ConfigurationProperties and system-wide parameters.
• When DVM or XRef technology is used for other purposes then intended, prefix the name with for example Z_.
• Define ownership of all the applications within the SOA Suite, especially naming (name per application or per module within, name the middleware communicating with or the application behind), ApplicationObjectLibrary and connection details.
• Define appropriate Service Groups in the ESB System AIASystem, for example one service group per application.
• Transformations from ABM --> EBM should be comprehensive mapping of all available attributes (All ABM Attributes supported in EBM should be mapped). Instance identifying information needs to be populated with as much information as possible in every Identification/IdentificationType element. EBM header needs to be populated fully.
• Use the EBM verbs/EBS operations with care and as intended. For example master data from the System of Record uses the sync, messages to the SoR use create/update.
• The same for EBM List messages, bundling messages lowers the number of instances, but if one message fails all the objects within this message are blocked.

Hope this helps you...