Forum Stats

  • 3,769,293 Users
  • 2,252,943 Discussions
  • 7,874,980 Comments

Discussions

Basic Query on OSB Reply action in synchronous service

Naveent_2785
Naveent_2785 Member Posts: 27 Blue Ribbon
edited Jul 28, 2020 10:57AM in SOA Suite Discusssions

Hi,

In a HTTP synchronous webservice service implemented in OSB, while using the reply action it immediately stops the flow and returns back the response and stops all the next stage/activies in the pipeline flow. Whereas if the same synchronous web service if implemented in BPEL and using the reply node to return back the response but it still process the subsequent BPEL activities/scope in the flow.

Why is it differently implemented in ESB/BPEL for the same kind of message exchange pattern(synchronous services)

BR,

Naveen.

Tagged:
Naveent_2785Martien van den Akker

Answers

  • Martien van den Akker
    Martien van den Akker Member Posts: 2,776 Bronze Crown
    edited Jul 2, 2020 8:03AM

    Hi Naveen,

    OSB and Oracle BPEL are significantly different products. OSB is definitely not BPEL, it's not statefull (like BPEL) but stateless.

    Everything is done in the same thread, synchronously. With one caveat, regarding service call-outs. So, if you do a reply in OSB it indeed gives back the control and finishes the service.

    Also exception handling is different. In OSB you need to finish your exception handling explicitly with a retry or reply, because otherwise it will transfer the control to the higher-level exception handler, where as in BPEL if you 're in a faulthandler-catch, the fault is considered 'handled', unless you explicitly implement a throw activity.

    Keep in mind that Oracle BPEL dates back to 2004, when Oracle acquired Collaxa, the original builders of BPEL PM. Since 2006 BPEL is integral part of Oracle SOASuite, the SOA Integration platform of Oracle. At the time, it was a competitor to products/vendors like Tibco and BEA Aqualogic Service bus. Oracle acquired BEA in 2008 and rebranded Aqualogic Service Bus to Oracle Service Bus. In other words the history of both products are significantly different with a very different background and architecture.

    Funny though: if you create a split-join component in Aqualogic/Oracle Service Bus, then it will create a flow object. This artefact is meant to be able to implement parallellism in Service Bus. You can't do that in the regular message flow in the proxy service (11g) or pipeline (12c). You may try and gues in what technology the Split-Join is implemented. And thus besides messageflows, the Service bus also has a ....-engine... (but only for synchronous service orchestration, no support for asynchronous patterns).

    Kind regards,
    Martien

    Naveent_2785Naveent_2785
  • Naveent_2785
    Naveent_2785 Member Posts: 27 Blue Ribbon
    edited Jul 3, 2020 4:38AM

    Hi Marteen,

    Thanks for a very detailed reply!

    Even my thoughts are on being stateless/stateful as per the product design. okay, so as you said as per the design of the OSB threading model while executing the flow.

    Yes, I think in BPEL, we have the option to create synchronous durable process using the stateful design of the product.

    Thanks for info! Will try to explore split join with some hands on

    BR,

    Naveen.

  • Martien van den Akker
    Martien van den Akker Member Posts: 2,776 Bronze Crown
    edited Jul 3, 2020 6:18AM

    HI,

    I haven't used it in 12c yet. However I found the designer of the split/join in OSB 11g, very unfriendly to say the least. Editing Assigns was a drag, especially if you wanted to introspect detail elements from down the hierarchy in a message. So, I'd recommend to use it only for orchestrating services in parallel, but do the assignments and aggregations in the pipeline/message flow. Maybe the desginer improved (since it's JDeveloper now), but otherwise keep the flow component as sparse as possible. Only do the most necessary things in there.

    Kind regards,
    Martien

    Naveent_2785
  • Naveent_2785
    Naveent_2785 Member Posts: 27 Blue Ribbon
    edited Jul 5, 2020 7:15PM

    Okay Thanks Martien!

    Martien van den Akker
  • Martien van den Akker
    Martien van den Akker Member Posts: 2,776 Bronze Crown
    edited Jul 8, 2020 6:07AM

    Hi Naveent,

    Have I answered your question? I would appreciate if you mark my answers as helpfull and/or answering your question.

    It helps others to see that this thread is answered and what helped you.

    Kind regards,
    Martien

  • Naveent_2785
    Naveent_2785 Member Posts: 27 Blue Ribbon
    edited Jul 28, 2020 10:57AM

    Hi Marteen,

    Yes got the answer, Thanks.  I have marked it as helpful.

    BR,

    Naveen.

  • User_8US5A
    User_8US5A Member Posts: 0 Green Ribbon

    Hi Martien and Naveen,

    I stumpled on your conversation here when searching for a very related question.

    When having the special case of a proxy pipeline that has no routing to connect the request and response pipelines, then OSB will revert to using the default work manager (WM) for the response pipeline, disregarding which non-default WM the proxy configured to use. This behavior is described in this article: https://blogs.oracle.com/reynolds/following-the-thread-in-osb

    Design 1: Do you know what happens if one uses the "Reply" action in the request pipeline? Will the similar behavior with revert to default WM also occur in this pipeline design?

    Design 2: What happens if Conditional branching action has a branch with no routing? Default of non-default WM?

    Design 3: What happens if just a "If Then" action is used in the route and one of the cases has no routing? Default of non-default WM?


    Best Regards

    Anders

  • Naveent_2785
    Naveent_2785 Member Posts: 27 Blue Ribbon

    Hi Anders,

    I don't have a direct answer to the question but I think the above scenarios have to be tested and verified for behaviour in WebLogic. If you login to the weblogic console/servers/osb_server/workload you can find the related work manager metrics which can help you find out what work managers are processing your application requests.

    However, please, note that details about custom work managers cannot be seen but only the stats related to configured constraints for customer work managers are getting captured. It is also observed that OSB trace logs are also not capturing any details of the WMs used while processing the requests(searched based on the execution context ID).



    BR,

    Naveen.