2 Replies Latest reply: Oct 31, 2012 3:27 AM by user11243772 RSS

    OSB JCA Adapter performance issue

    user11243772
      Hi,


      We have to use OSB as an ESB at integration level which need to populate the result from local services e.g. from DB as well as from external services. Actually we need to use switch [split -join] and connector [individual proxy for individual services] features.

      As for external services, we do not have questions but to access data from local system e.g. Database, whether it will be a performance issue in OSB, in case if we are using JCA Adapter and exposing it as a service? Because some one objected that accessing JCA layer in OSB will be a performance issue.

      If some one can shed the light on it, it will be great.

      Thanks & Regards,

      V D
        • 1. Re: OSB JCA Adapter performance issue
          vladodias
          Hi,

          Have a look at the Developer Guide for OSB... Oracle JCA Adapter for Database is supported... Have a look at the limitations, there's nothing mentioning performance...
          http://docs.oracle.com/cd/E23943_01/dev.1111/e15866/jca.htm#i1110405

          Also have a look at the following blogs... One of them even suggests that jca performs better than xquery with fn-bea:execute-sql...
          http://victor-jan.blogspot.com.au/2012/06/osb-fn-beaexecute-sql-vs-jca-dbadapter.html
          http://reallifeserviceorientedarchitecture.blogspot.com.au/2011/09/oracle-service-bus-osb-and-jca-adapters.html

          If you are still in doubt open a SR with Oracle Support...

          Hope this helps...

          Cheers,
          Vlad
          • 2. Re: OSB JCA Adapter performance issue
            user11243772
            Thanks for your reply.

            The conern more is if there is finegrained call to the DB from OSB? other wise we may need to use stored procedure to make coarsegrained.
            And also to make this call to DB, some business decision need to happen which eventually will be in OSB onlly.

            Thanks,

            Vish