When to use "my role" and "partner role" in BPEL?

Question

I'm a bit confused when to set/use partner role and my role.
Can anyone shed a little light,
regards, Henrik

Answer 1

Saurabh,
> I humbly disagree with your explanation of inputs
No need to be humble, you can boldy disagree. :)
You're right that I did technically use the wrong term in that sentence of my explanation. I updated the post and corrected it. However the gist of what I was saying is still true.
There are two invocation types. People use different terms but here I'll call them request-response and one-way. A request-response invocation type is used for what we typically think of as a "synchronous" process. That is, the service consumer is blocked until the service responds. It's like methodA() in Java calling methodB(). methodA() is blocked until methodB() completes. (In fact, this is exactly what it's like since all invocations on our BPEL engine ultimately go through our Java API.)
In the case of one-way, the service consumer is not blocked. This is often referred to as fire-and-forget. It simply sends its request, then it is free to continue or do whatever it wants. Moreover, nothing is returned to the client (you fired-and-forgot, remember). Typical "asynchronous" BPEL processes uses this invocation type.
So we have those two invocation types. Yet the problem before us how to have an asynchronous process return a result. You can't use request-response because the service consumer is blocked until the process finishes. You can't just use a one-way because nothing is returned to the caller. What to do?
The way the BPEL standard solved the problem is to use two one-way invocation types. The first one is to invoke the process. The second one is a one-way from the BPEL process to the service consumer to return the result. There are some glaring implications of this:
1. When the BPEL process returns it's result, things have now switched: The BPEL process becomes the service consumer, and the (original) service consumer becomes the service.
2. The service consumer has to be able to listen for one-way invocation type requests.
3. The BPEL process has to know how and where to call the service consumer back. This information is passed in the original request. As well as containing the data payload, it contains a callback address and unique identifier. This, in essence, is what the WS-Addressing standard is about.
Now the definition of a one-way invocation type in a WSDL is:
    <portType name="aaa">
        <operation name="bbb">
            <input message="tns:ccc"/>
        </operation>
    </portType>Compare that to a request-response invocation type:
    <portType name="aaa">
        <operation name="bbb">
            <input message="tns:ccc"/>
            <output message="tns:ddd"/>
        </operation>
    </portType>Let's look again out our example WSDL:
    <portType name="SelectService">
        <operation name="processRequestQuote">
            <input message="tns:RequestQuote_processRequestQuote"/>
        </operation>
    </portType>
    <portType name="SelectServiceCallback">
        <operation name="processRequestQuoteResponse">
            <input message="tns:RequestQuote_processRequestQuoteResponse"/>
        </operation>
    </portType>Here comes the good bit... Both portTypes have an <input> operation. But that's because they are both one-way invocation types, and there is no choice but use the <input> element -- that's the standard. You can't imply put <output> because there's no such thing in the standard. However we know that one of those is to actually return the result. That is, it's the output, even though it's labelled <input>.
Hopefully that's given you enough information now. Re-read my first post, above, and it should make more sense.
Incidentally, this is why you rarely see try asynchronous web services, because the caller has to also be a listener. And if you want to call a service, who wants to also have to write code to listen, to handle responses coming out of order, etc. This is one of the advantages of using an orchestration engine like Oracle BPEL Process Manager. The framework takes care of the hard work, and you can simply call an aysnchronous service and not have to worry about how to get the response back -- the engine does it for you.
Regards,
Robin.