orchestrating web services


XML & Web services: orchestrating web services

  1. orchestrating web services (6 messages)


    Is there any product to orchestrate/manage web services in a simple way?

    I have a simple use case. i am building a simple order processing application which uses 4 web services.
    1. Email validation web services (synchronous)
    2. Credit card web service (asynchronous)
    3. Inventory web service (asynchronous)
    4. Shipping web service (asynchronous)

    Web service #1 is a synchronous web service. So first i call emailWS.valdate().if it is valid email then i call async web service #2 and #3. Web service #2 and #3 are invoked in parallel. after receiving response messages from async web services #2 and #3, i need to call web service #4.

    The problem i am facing is managing the response messages from those async web services that includes correlating the response message with my application data..is there any standard way to correlate response message with my request message? how do I handle failures.. Lets say what if inventory web service is down for 2 days after i sent my request. i could do some kind of ping mechanism to see whether the web service is down or not..

    I guess there are lots of issues around managing and coordinating multiple web services particularly in loosely coupled asynchronous environment.

    I believe whoever uses multiple web services within an application might face the same problem that i face.


    Threaded Messages (6)

  2. orchestrating web services[ Go to top ]


    Collaxa offers a web service orchestration that focuses on addressing the exact problem your are discribing: compose a set of synchronous and asynchronous web services into a multi-step business process.

    The solution is based on 3 parts: a flexible abstract called ScenarioBean, an Orchestration container and an orchestration container.

    ScenarioBeans are an XML/Java abstraction that allow developers to choreograph interactions with about synchronous and asynchronous web services without having to deal with a lot of the plumbing you are describing in your message.

    Here is what your example would look like:

    package com.collaxa.samples;

    public class OrderProcessingScenario extends Scenario

    public void processOrder( IOrder order )
        // invoke asynchronous web service. The orchestration
        // will detect that the invocation is asynchronous and
        // passivate the scenario until a response is received.
        // -- all soap marshalling, stack persistance,
        // -- and correlation is handled by the container.
        creditCardWS.handlePayment( order );

        inventoryWC.checkQuantity( order );

        shippingWC.sendOrder( order );

    ScenarioBeans make the complexity of calling asynchronous web services transparent to the developer.

    4 orchestration tags (<parallel>, <parallelN>, <listen> and <conversation>) combined with the full power of Java allow developers to choreograph both simple linear interactions or more sophisticated non-linear interactions.

    You can learn more about ScenarioBeans and download the Collaxa orchestration server and kick the tires from http://www.collaxa.com

    - Edwin (edwink at collaxa dot com)

  3. orchestrating web services[ Go to top ]

    Hello Edwin,

    Thanks for the reply. I looked at the website (www.collaxa.com) very cool product!.

    Awesome! It addresses most of my problem such as async web service correlation..looks like i can even do EJB, JMS calls within my Order Processing Scenario. So that i don't need to convert my EJBs into web services..thats cool.

    Looks like i just need to deal with 4 special tags to solve most of my plumbing problems. I have couple of questions related to Scenario Bean:

    1. How is the Scenario bean different from normal EJB Session bean/Entity Bean?
    2. Can i run the scenario bean inside any J2EE container?


  4. orchestrating web services[ Go to top ]


    Thank you for your positive feedback.

    Question #1: ScenarioBean versus SessionBean?

    SessionBean is used to model short-lived business transactions: when you invoke a method on a ScenarioBean, you expect it to do its magic and return within a few milliseconds.

    ScenarioBean on the other hand are used to model long-lived business processes and workflows. When you invoke a ScenarioBean, a new long-lived, multi-step transaction is initiated and its handle/key is returned. The scenariobean coordinates the business process, invoking web services, EJBs, JMS components and also users if needs. An invocation on a scenario bean might take a few minutes or a few months to complete.

    Question #2: Can I run ScenarioBeans inside any EJB container?
    ScenarioBeans come with their own container (we call that container an orchestration container). That container encapsulates all the services need to execute, manage, persist and monitor ScenarioBeans. Collaxa will be publishing a white paper on the internal of the container very shortly.

    The orchestration container in 100% interoperable with existing EJB containers allowing developers to leverage EJBs, JMS and other J2EE services.

    The orchestration container can be loaded in memory with most application servers, web servers and Java Messaging server offering a flexible way to add orchestration capabilities to existing infrastructure.

    Those this address you questions? Did you get a chance to download the Collaxa Orchestration Server and kick the tires?

    Please let me know if there is anything else we can do.


  5. Also look at IBM's WSFL (Web Services Flow Language). I am not sure if it has been implemented as yet - but I may be out of synch now.
    Also IBM has another tool on alphawirks called "Web Services PMT (Process management toolkit)" worth a look too.

  6. orchestrating web services[ Go to top ]

    A Java Scenario Beans is a programmatic abstraction which leverages the full power of Java and a few tags to program orchestration logic. Declarative dialects of XML, such as IBM's WSFL or other emerging standards, such as BPML, can be executed by special-purpose Scenario Beans. This way, the orchestration container runs WSFL Scenario Beans, BPML Scenario Beans, etc. Also, note that these XML dialects are not the first (and likely not the last) attempts at creating flow langugage standards. Scenario Beans is a flexible future-proof programmable abstraction that can support other dialects and run all of them in parallel as part of your system if you so desire.

  7. orchestrating web services[ Go to top ]

    Here's a more elaborate example of web service orchestration using Java. There's a code sample you can review in the following article describing a real-estate application: