Wednesday, July 29, 2009

Best practices 3 – Oracle ESB and Mediator

This is the third post in our SOA and BPM best practices series. This blog provides best practices for Oracle ESB (Oracle Fusion Middleware 10g) and its successor (when it concerns routing and transformation): the mediator component in SCA (Oracle Fusion Middleware 11g). The previous blog in this series is about Web Services best practices.

Use a bus. Maybe a bit of an open door, but there are still projects that stall, exceed budget, or fail all together since no ESB is used and “SOA-plumbing” is implemented (or tried at least) in an orchestration tool, custom logic, and so on. Use an ESB for decoupling, virtualization, abstraction, transformation (data as well as protocols), and content-based routing. Decouple this type of functionality from your orchestration and workflow.

Migrating from OFM 10g to OFM 11g.

  • If you don’t migrate to SCA and have used Oracle ESB as a stand-alone ESB then migrate to OSB. This will require reimplementation of OESB flows as OSB flows.

If you migrate to SCA:

  • For non-reusable ESB flows that perform “internal” transformation and routing functionality within the SCA runtime: create a mediator component that is not directly exposed in its containing SCA composite and add your other components that use the mediator -such as BPEL components- to that composite. Open the OESB project in JDev 11g to create an initial composite.
  • For reusable ESB flows that perform “internal” transformation and routing functionality within the SCA runtime: create a composite containing only one mediator component that is exposed using a service. Other SCA composites can reuse this “mediator” composite. Open the OESB project in JDev 11g to create an initial composite.
  • For ESB flows that interact with the “outside world”; in other words connect the SCA runtime to other runtimes and/or external parties such as suppliers and clients: migrate to OSB.

Encapsulation and exposing operations. As with Web Services in general, do not expose all routing service operations and adapter operations. This promotes encapsulation; only expose what is or will be reusable. Also see this post about improved encapsulation in OFM 11g. In 10g, you cannot “hide” an ESB flow but you can minimize the operations that are invocable by disabling the option “Invocable from an external service”. In 11g, you can hide a mediator within its composite by not directly exposing it by making sure there’s no direct service and wire to it. This is achieved by disabling the “Create Composite Service with SOAP Bindings” option when creating a mediator component.

Data enrichment. Although data enrichment typically is something you would do in an ESB -for example when implementing VETO (validate, enrich, transform, and operate)- don’t use Oracle ESB for it. Through the lack of temporary variables it is not well suited for data enrichment when data comes from different sources. You can use the $ESBREQUEST variable to ameliorate this, but still this is not a great workaround. Use BPEL PM or OSB in 10g for complex data enrichments and OSB or SCA composites containing multiple mediator and/or BPEL components to achieve complex data enrichment.

XML. Create a public_html folder in every ESB project created with JDeveloper 10g and place non-generated XML artifacts such as XSLTs and XSDs in it. Leave generated XML artifacts such as TopLink descriptors from the DB Adapter in the (default) root folder. When editing mediators in 11g XSLT will automatically be created in an xsl directory and XSDs will be placed in a xsd directory.

Deployment. Use Oracle ESB Ant scripts to deploy to test, acceptance, and production environments. Use deployment plans to configure endpoint and adapter settings per environment (DTAP). Make sure you don’t mix Ant and JDeveloper deployment since it can cause problems in your ESB runtime. For SCA composites use configuration plans.

Structuring. Use ESB Systems and Service Groups in 10g to structure ESB flows. A possibility would be to use an ESB Systems per business domain and an ESB Service Group per project. For example: ESB System “Finance” that contains ESB Service Group “FIN_ESB_Process_Invoice”.

XSLT extension functions. Custom XSLT functions can be a powerful mechanism to implement your own transformation logic but it can also break portability when moving from one environment to the other due to the required configuration and deployment steps. The creation of user-defined extension functions in OFM 11g is different from 10g. See Appendix B of the Oracle Fusion Middleware Developer’s Guide for Oracle SOA Suite.

Clustering. Clustering of Oracle ESB is not a trivial thing to do. Only cluster if needed from QoS (Quality of Service) reasons such as high availability, failover, and throughput. Mind non-concurrent adapters such as FTP and File adapters when clustering.

Versioning. Oracle ESB 10g does not support versioning natively. You can include the version number in the ESB project name and deploy it as new flow alongside older versions. In OFM 11g mediators are part of composites and therefore versionable.

Transactionality. Transactionality -including support for XA- of ESB in 10g is dependent on several factors and can therefore be somewhat complex. These factors include the mechanism (through BPEL PM, ESB, or other technology or client), binding protocol (SOAP versus WSIF) used to invoke ESB flows, use of synchronous or asynchronous routing rules, use of different ESB Systems in an ESB project, and so on. Read Oracle’s SOA Suite Best Practices Guide and this presentation on transactions, error handling and resubmit.

Oracle’s best practices guide. Read Oracle’s SOA Suite Best Practices Guide for more tips and tricks.

Next blog in this series will be about security and identity- and accessmanagement in a SOA-environment.

3 comments:

  1. Original comment by: Preetam Singh
    Original timestamp comment: 2 August 2009, 10:12

    Hi ALL,

    Thanks for proving information about custom functions, but i’ve few new questions and scenarios:

    AREA – BPEL (11g JDEV) and OSB (10.3.1)

    1. I have build a user defined function (for XSLT mapper) in 11g Jdeveloper. But as in other cases of 10g, i’m able to use it in my project but it does not execute at design time or runtime.

    Please let me know if you are aware of resolving this problem in 11g. Moreover, xpath-functions.xml do exist in 11g i think. All the steps related to runtime deployment have been taken but stillno luck!!

    2. Also, I need custom XSLT function in OSB(10.3.1). I tried a lot to build but was not able to and neither any information is available on Internet(being new product).
    Let me know if you can help me in this case too.

    Thanks
    Preetam

    ReplyDelete
  2. Original comment by: Ashish
    Original timestamp comment: 1 September 2010, 16:50

    Hi,
    It was such a concise yet thorough article..
    The use of ESB (and OSB for that matter) has always been confusing for me as there is a lot of overlap in terms its functionalities with BPEL.

    I would not ask you to elaborate the subject as you maybe busy in your assignmetns, however would be grateful if you can throw some lights on the following scenairo:

    We are using BPEL processes to implement point-to-point interfaces which follow essentially receive-validate-transform-process(invoke services)-reply pattern. All this is done in BPEL.
    Do you see a need to use ESB/OSB here. As per the gist of this article, all routing and transormation should be placed in Bus. (Correct me if I misunderstood), do I need to use ESB/OSB here?

    Thanks-
    Ashish

    ReplyDelete
  3. Original comment by: Lonneke Dikmans
    Original timestamp comment: 4 September 2010, 13:38

    Dear Ashish,

    That is an excellent question! The recently started SOA BPM Enterprise Methodology group is a good place to ask this question. We are planning a session on this subject at the Oracle Open World Unconference. The result will be posted on this group. Instructions on how to join this group can be found here: http://groups.google.com/group/soa-emg

    Before being accepted as a member we require you to please fill out this short survey at http://www.surveymonkey.com/s/TLXWD3Y to detail your current SOA and BPM interests and usage. Your details are only used by the SOA-BPM EMG to better understand its members and will not be passed on to Oracle or 3rd parties. Once you have completed the survey we will endeavour to activate your membership within two working days (but we’re volunteers and only human so please bear with us!). PLEASE complete the survey before you apply for SOA-BPM EMG membership and use the same email address in both.

    Kind regards Lonneke

    ReplyDelete