ESB's rated by analysts

After my post last year [ref: SOA Suite rated by analysts] where I looked into the evaluation of the Oracle SOA Suite by Gartner and Forrester it's time to take a new look on their saying about ESB's (Enterprise Service Bus).
For this I took a look at some newer reports from Forrester and Gartner:

• The Forrester Wave: Enterprise Service Bus, Q2 2011
  April 25, 2011 by Ken Vollmer
• Magic Quadrant for Application Infrastructure for Systematic Application Integration Projects
  June 20, 2012 by Jess Thompson, Yefim Natis, Massimo Pezzini, Daniel Sholler, Ross Altman and Kimihiko Iijima

As shown in the graphs the leaders are clearly IBM, Oracle, Software AG and Tibco.
Software AG - worked with webMethods for many years, good product.
Oracle - worked the last couple of years with SOA Suite, the 11g and 12c are build upon weblogic application server, hence the good score.
IBM - will be working with IBM in the near futurs, the multiple ESB offerings from IBM makes me wonder.

Forrester: [Click to enlarge]

Gartner: [Click to enlarge]

Now let's see what is said about IBM's multiple ESB offering:
Forrester - IBM offers three ESB's: WebSphere Enterprise Service Bus (WESB), WebSphere Enterprise Service Bus Registry Edition (WESBRE) and WebSphere Message Broker (WMB). Funny in the Forrester wave is that the actual ESB from IBM, the WebSphere ESB, scored somewhat lower than the other two.
Gartner - Some caution for IBM as despite plans to rationalize and simplify the product portfolio (e.g., in ESB), the fine-grained differences, functional overlaps and product integration challenges — for example, among WMB, WESB, WebSphere Cast Iron and the WebSphere DataPower integration appliances — make it difficult for potential users to determine the best fit for their requirements.
IBM - the faqs on the IBM website mention three different ESB's: IBM WebSphere ESB, IBM WebSphere Message Broker and IBM WebSphere DataPower Integration Appliance XI50.

Here a selection from IBM [ref: faq] on when to use which ESB:

When to Use WebSphere ESB?

• You use WebSphere Application Server and/or your team has skills with WAS Administration and Java coding
• You are focused on standards based interactions using XML, SOAP, and WS
• Reliability and extensive transactional support are key requirements

When to Use WebSphere Message Broker?

• You are currently using WebSphere Message Broker but not as an ESB
• You are using Industry formats such as SWIFT, EDI, HL7
• You are implementing a wide range of messaging and integration patterns
• You have very complex transformation needs
• Reliability and extensive transactional support are key requirements
• To achieve very high-performance with horizontal and vertical scaling

When To Use WebSphere DataPower?

• Ease of use is a pre-dominant consideration
• You are transforming between XML-and-XML or XML-and-any other format
• Your interaction patterns are relatively simple
• You are using XML-based or WS-Security extensively
• You require use of advanced Web services standards
• You need to minimize message latency when adding an ESB layer
• Your ESB must be in production very quickly

What if you require an ESB from IBM for standards based integration, with complex integration needs, high performance, advanced web service standards and want to move to production quickly?

FOTY0001 and logfiles roulation

A certain person named, or used the alias of, Vivek wrote a few years ago some interesting articles on his blog [ref: OracleD] about Oracle SOA Suite 10g. He experienced many flaws in Oracle OC4J Application Server and recommended the OTN discussion: Oracle BPEL + Oc4j + Jdeveloper = brain damage. Clearly he was not so happy with the features in the 10g version of Oracle SOA Suite...

He referred also to the so-called FOTY0001 errors, these often occur during XRef calls and XSL Transformations. More information about this FOTY0001 can be found in the OPMN log files. For example, a typical error is the following:
subLanguageExecutionFault - XPathExecutionError
  XPath expression failed to execute.
  Error while processing xpath expression, the expression is "ora:processXSLT('myTransformation.xsl',bpws:getVariableData('myInputMessage'))", the reason is FOTY0001: type error.
  Please verify the xpath query.
This error occurs e.g., when in JDeveloper the transform activity is opened and closed immediately. There was no time for the messagePart to be loaded, so it will be missing in the code leading to this FOTY0001 error on runtime. The proper syntax in the code is ora:processXSLT('myTransformation.xsl',bpws:getVariableData('myInputMessage','myMessagePart'))
To prevent this either click cancel in JDeveloper or wait for the message parts to load completely.

To view the FOTY0001 errors in detail the obvious way is to view them using Enterprise Manager. But an easier way is to view them directly by opening the logfiles on filesystem. Depending on the logging level the server logfiles can quickly become pretty huge. In the opmn configuration the roulation can be configured as follows, open $SOA_HOME/opmn/conf/opmn.xml and make the following changes:
<ias-component id="soa_group" status="enabled">
  <process-type id="oc4j_soa" module-id="OC4J" status="enabled">
    <module-data>
      <category id="start-parameters">
        <data id="java-options"
          value="-server
Add here the following parameters:
          -Dstdstream.filesize=10 - File size in MegaBytes
          -Dstdstream.filenumber=50 - Number of files
To separate the output and error messages add the following data element with oc4j-options inside the same category:
<data id="oc4j-options" value="-out $ORACLE_HOME/opmn/logs/oc4j_soa.out -err $ORACLE_HOME/opmn/logs/oc4j_soa.err"/>
To view the FOTY0001 error details simply open (in a good text-editor) the *.err file containing the timestamp of the error.

Overload leads to timeout errors

Sometimes integration scenarios can receive a bulk load from an application, especially when the source application uses batches as the trigger for sending out messages. This load can lead to the following non-retryable SOAP errors in the ESB:
Fault message:
Failed to enqueue deferred event "oracle.tip.esb.server.dispatch.QueueHandlerException:
Context lookup failed "[CONFIGURATION ERROR] Invalid Destination "Topics/ESB_JAVA_DEFERRED" :
javax.jms.InvalidDestinationException: Looking up java:comp/resource/esbRP/Topics/ESB_JAVA_DEFERRED:
javax.naming.NameNotFoundException: No resource named 'esbRP/Topics/ESB_JAVA_DEFERRED'found.
Please verify configuration of adminobject or the lookup string."
Make sure the topic is mapped to a jndi tree"

This behaviour is described in an Oracle note [ref: note ID 1173584.1] with the following solution: increase the timeout settings. Together with two other Oracle notes describing how to avoid BPEL errors due to adapters response time and what timeout settings in SOA can impact AIA [ref: note ID 1074227.1 and 885114.1] this leads to the following timeout settings:

• xa_timeout in $SOA_HOME/integration/esb/config/esb_config.ini
  Default: 60; recommended setting: 3600
• jms_receive_timeout in $SOA_HOME/integration/esb/config/esb_config.ini
  Default: 30; recommended setting: 300
• Also according to another Oracle note [ref: note ID 752385.1] you might want to set PingCount and PingInterval to 30 in $SOA_HOME/integration/esb/config/esb_config.ini
• syncMaxWaitTime in $SOA_HOME/bpel/domains/default/config/domain.xml
  Default: 45; recommended setting: 600
• transaction-timeout in $SOA_HOME/j2ee/oc4j_soa/application-deployments/orabpel/ejb_ob_engine/orion-ejb-jar.xml (change this value for all 6 occurences of transaction-timeout in this file)
  Default: up to 3000; recommended setting: 3600
• transaction-timeout in $SOA_HOME/j2ee/[container]/config/transaction-manager.xml (change this value for all containers: e.g. home, designtime and runtime [oc4j_soa])
  Default: from 300 to 3600; recommended setting: 7200
• Timeout in $SOA_HOME/Apache/Apache/conf/httpd.conf
  Default: 300; recommended setting: 300, this option specifies the amount of time Apache will wait for a GET, POST, PUT request and ACKs on transmissions. The default is 300 (seconds) however this may need to be increased.

The settings in the $ORACLE_HOME/integration/esb/config/esb_config.ini file apply to all ESB instances in the Oracle Home. One small bonus feature: if you have many BPEL processes deployed and you experience long waiting times in the ESB Console: put a lazyLoad property in the esb_config.ini file and the waiting time is gone [ref: Bug 7720420].
esb.console.services.lazyLoad.Allowed=true
It's a little confusing regarding the file orion-application.xml, different notes say different things, one note mentions the location in application-deployments which overrides esb_config.ini, another note mentions the location under applications which overrides esb_config.ini. Just to be safe and consistent check the orion-application.xml file in the following locations and if they are present and not commented out apply the values mentioned above for the xa_timeout, jms_receive_timeout, PingCount and PingInterval:
$SOA_HOME/j2ee/[ESB_RUNTIME_CONTAINER]/application-deployments/esb-rt/orion-application.xml
$SOA_HOME/j2ee/[ESB_RUNTIME_CONTAINER]/applications/esb-rt/META-INF/orion-application.xml
$SOA_HOME/j2ee/[ESB_DESIGNTIME_CONTAINER]/application-deployments/esb-dt/orion-application.xml
$SOA_HOME/j2ee/[ESB_DESIGNTIME_CONTAINER]/applications/esb-dt/META-INF/orion-application.xml

The above changes also take care of the following errors in the container logfile from $SOA_HOME/opmn/logs:
ORABPEL-05002
ORABPEL-02182
JTA transaction is not present the transaction is not in active state
Message handle error

Instead of increasing the timeout settings for the BPEL processes a more durable solution would be to throtte the inbound flow. There is an activation agent (bpel.xml) property (since 10.1.3.1), which can be used to control the speed at which the adapter posts messages to BPEL [ref: note ID 1178163.1 or Oracle® SOA Suite Best Practices Guide 10g Release 3 (10.1.3.3.0) E10971-01 December 2007]
...
    <activationAgents>
      <activationAgent partnerLink="JmsDequeuePL" ... >
          <property name="minimumDelayBetweenMessages">1000</property>
      </activationAgent>
    </activationAgents>
  </BPELProcess>
</BPELSuitcase>
This setting ensures that there at least will be 1000 milliseconds delay between two consecutive messages being posted to this BPEL process.

Actually this last best practices guide provides many valuable tips, like

• Performance tuning guidelines.
• Answers to frequently asked questions about threading.
• Answers to frequently asked questions about transactions.
• How to optimize the JVM heap. The heap size controls the amount of memory the JVM can use.
• How to relieve the dehydration store by making BPEL processes synchronous.
• Description of performance persistence parameters in bpel.xml.
• WSIF binding (localhost) and EJB binding optimization.
• The relationship among some performance settings
• The objectives and best practices for creating the BPEL cluster.
• Increasing the instanceKeyBlockSize to 100,000. Doing so decreases the frequency at which Oracle BPEL Server visits the dehydration store.

Some best practices should be considered during design and development time, like the BPEL parameters that are configured per BPEL component, whether a BPEL process should be synchronous or asynchronous and whether it should participate in a transaction or not. Other best practices are SOA Suite wide and should be part of the overall configuration, like the start-up memory settings.

Updated June 6, 2011 with LazyLoad, PingCount and PingInterval, another location of the orion-application.xml file and jms_receive_timeout to 300.

Instance wide XML manipulations

If the input file is a plain xml file without namespaces declared the following error occurs (at least when xml validation is set to 'strict'):
<invalidVariables xmlns="http://schemas.oracle.com/bpel/extension"><part name="code">
<code>9710</code></part><part name="summary">
<summary>Invalid xml document.
According to the xml schemas, the xml document is invalid. The reason is: Error::cvc-elt.1: Cannot find the declaration of element 'TestXSD'.
Please make sure that the xml document is valid against your schemas.</summary></part></invalidVariables>

Solution: create in the consumer routing service (the component after the file-reader, postfixed with _RS) the following transformation, first check if the wanted namespace is included in the namespace declarations, otherwise map one field to get all the namespaces declared. Then add the following code in the xsl:
<xsl:stylesheet version="1.0" xmlns:test="http://www.mydomain.com/TestXSD">
<xsl:template match="*">
  <xsl:element name="test:{local-name()}" namespace="http://www.mydomain.com/TestXSD">
    <xsl:apply-templates select="@*|node()"/>
  </xsl:element>
</xl:template>

This code is based on the "identity" template, which was introduced with an example in the XSLT Recommendation itself [ref: www.w3.org]:
<xsl:template match="@*|node()">
  <xsl:copy>
    <xsl:apply-templates select="@*|node()"/>
  </xsl:copy>
</xsl:template>

Some explanation here: "node()" is shorthand for child::node(). That is node() matches all nodes (element, text, comment, processing-instruction) being children of other nodes but not attributes since they are not considered children of their parent element. To find all nodes in order to copy them, we need to match both nodes being children of other nodes, node(), and attributes, @*, that is: match="@*|node()".

This template copies everything recursive from source to target, all the attributes and nodes. Copying everything in itself is no fun but becomes very useful when we add exceptions or conditions to the copying. Here two transformations that copy all the nodes and attributes if:

• They have content: RemoveEmptyNodes.xsl
  <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="@*|node()">
    <xsl:if test=". != ''">
      <xsl:copy>
        <xsl:apply-templates select="@*|node()"/>
      </xsl:copy>
    </xsl:if>
  </xsl:template>
</xsl:stylesheet>
• They have content or the node contains an attribute with content: RemoveEmptyNodesKeepAttributes.xsl
  <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="@*|node()">
    <xsl:if test=". != '' or ./@* != ''">
      <xsl:copy>
        <xsl:apply-templates select="@*|node()"/>
      </xsl:copy>
    </xsl:if>
  </xsl:template>
</xsl:stylesheet>

These templates can replace one of Oracle's best practices [ref: Oracle® Application Integration Architecture - Foundation Pack 2.5: Integration Developer's Guide Release 2.5 Part No. E16465-01 December 2009], adding the RemoveEmptyNodes transformation after the main mapping fulfills:

Transformation logic and XPath should be designed with the possibility of missing or empty elements
<xsl:if test="normalize-space(Line3/text())">
  <Line3>
    <xsl:value-of select="Line3/text()"/>
  </Line3>
</xsl:if>

The above templates can save you the time-consuming conditional mapping per element. Just don't forget if the mapping contains empty placeholders (like EBMHeader/EBMTracking/ExecutionUnitID) then fill these first with an assign before calling the RemoveEmptyNodes. Also the element EBMHeader/DataArea/[verb] is a required field. This can be solved with both templates:

• RemoveEmptyNodes.xsl: include in the template an exclusion of this element (the [verb] is Create here):
  <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:corecom="http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V2">
  <xsl:template match="@*|node()">
    <xsl:if test=". != ''">
      <xsl:copy>
        <xsl:apply-templates select="@*|node()"/>
      </xsl:copy>
    </xsl:if>
  </xsl:template>
  <xsl:template match="corecom:Create">
    <xsl:copy-of select="."/>
  </xsl:template>
</xsl:stylesheet>
• RemoveEmptyNodesKeepAttributes.xsl: fill an optional attribute of this field, although not the most elegant solution...

WSDL artifact errors while deploying

You'll already know that the Oracle JDeveloper contains a nice tool to create the base-mapping (XSL Transformation), unfortunately advanced logic within the mapping get screwed up by this JDeveloper pretty often. Therefor use an advanced text-editor with xml highlighting instead after you finish the base-mapping in JDeveloper. Or stick to the Source-view, no more Design-view.

This leads me to write about a more serious issue with JDeveloper: during development of the integrations all the developers working with ESB components need to have identical workspaces in their JDeveloper. If not, you might run into unwanted errors when deploying. This is known by Oracle and described in a note [ref: note ID 875558.1]:

Applies to: Oracle ESB - Version: 10.1.3.4 to 10.1.3.4.9. This problem can occur on any platform.
Symptoms: When an ESB project is registered using JDeveloper and then moved to a new JDEV Workspace with a different Workspace name, re-registration of the ESB project and its related artifacts (XSL Stylesheets, XML Schemas, WSDL files) might fail.
Cause: ESB artifacts designed with JDeveloper were moved to a different JDeveloper workspace with a new name.
Solution: DO NOT move ESB projects to a different JDEV workspace name. This is not supported by Oracle ESB in the current version.
Explanation: The way ESB identifies a file update in a project at runtime is by using the convention <workspacename>_<projectname>/<filename>. If the user is changing the workspace name, but keeps the project name and file name the same, it will not be possible for JDev to update the related artifacts in the slide repository because the identifier has changed - external references in form of esb:// were created. This is a known limitation.

You might also run into an error while deploying BPEL components that contain a referral to an ESB component, for example in the transformation the target is the ESB component WSDL. This url in the xsl contains the <workspace>, if in development this <workspace> differs from the actual deployed ESB component you might end up seeing the BPEL component in the BPELConsole, but not in the ESB console in BPELSystem. The advice here is: use always the same <workspace> in the JDeveloper, for example let the whole development team develop all ESB components (Projects) under Application AIASystem.

Talking about deployments, there is also a known bug in a jar-file, which is often used by automated deployments, see the note [ref: note ID 1308408.1] which describes the following error:
java.lang.Exception: Programming Error : Adapter Service <WriteData> does not have an associated WSDL artifact
at oracle.tip.esb.jdev.artifacts.model.ESBAdapterServiceArtifactContent.getDeploymentProperties(ESBAdapterServiceArtifactContent.java:159)
For example if you use osbs - Oracle Soa Build Server by Marc Kelderman [ref: http://orasoa.blogspot.com/2009/04/new-oracle-soa-build-server-osbs.html], you'll might receive the error as described in the note above. The solution here is to get from Oracle patch 11871410, extract the file ESBMetadataMigration.jar from the deployments.zip file in this patch and put this jar file in the location mentioned in the obbuild.sh script.

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...