Angelo Santagata's Blog

Whilst reading my email this morning I saw the following question get answered by a collegue in Germany.. It's a question which gets frequently asked by partners I visit so I thought I'd post the question and response here for you all to see.

With multiple clustered ESB-Runtimes (RTs) - do I need to deploy
only once or do I need to deploy once per RT (like it is for BPEL)?

You need to register your services to the ESB metadata server (aka DT server)
only once.  Each of the RTs will get notified of the metadata change via the
Control Notification mechanism (with JMS as the underlying protocol).  The RTs
will then update/refresh their in-memory cache for only those services that they
are currently hosting.  You register your services only once to the DT server,
and not multiple times to each cluster.

Do the ESB have in-memory session state (i.e. do I need to configure OC4J
session replication)?
ESB messages are completely stateless.  The global transaction rolls back if
there are errors.  In case of synchronous flows, the exception/fault is rolled
back to the client.  In case of asynchronous flows, the message is rolled back
to the Asynchronous Topic.  There is no session state replication required since
these are stateless messages, hence no configuration is

Are ESB
configuration changes be distributed across all cluster
nodes?
All metadata and config changes are propagated to RTs via
the Control Notification mechanism.  You do not have to individually propagate
them.

Of course a lot of this is documented in our documentation which is available at http://download-west.oracle.com/docs/cd/B31017_01/core.1013/b28939/toc.htm<o:p></o:p>

I had an interesting call from a partner today, they asked me if they should use our Oracle ESB product to do integration code instead of Oracle BPEL..

Why?? Well they already know Oracle BPEL and they quite simply they didnt really want to learn/install/manage another product.... i.e. ESB

Well Yes its true that if your doing "integration" code then you could use Oracle BPEL and/or Oracle ESB. Actually before we had Oracle ESB you had to use Oracle BPEL and many customers have implemented integration hubs using Oracle BPEL quite successfully, so it why do we [oracle] need an ESB product...

Well the answer is in the description, Oracle BPEL can be used for integration code but its not designed/optimised for it.. Oracle BPEL is a Business Process Execution Language and as such its optimised for managing and coding business processes, whereas an ESB is quite simply a highly efficient intergration product. Its principle objective is to join two different services together quickly, efficiently and bi-directional.

Specifically an ESB moves data via

• Connects services via different adaptors (WebServices, FTP,File,JDBC etc) and protocols (HTTP,JMS)
• Enriches and transform data using XSL & domain value mapping lookups
  
• Routes messages based on data in the message payload and/or header
  
  and finally and often overlooked feature is that an ESB
  
  
• Virtualises services, quite simply adds a facade layer to your infrastructure...

Its also worth noting that doing integration work with Oracle ESB is not only quicker to "build" but its also quicker in its execution. I've been told by some collegues in the US that an integration process in ESB product is approx twice the speed of same process in Oracle BPEL..

So to recap

Use ESB when

• You want a really low cost solution
  
• Only need connectivity, simple transformations and routing

Use BPEL+ESB when

• You need to code complex business logic
• Integration with Workflow
• Complex transforms potentially involving the database
  
• Have Long running processes which may or may not be stateful