Java Web Services and BPEL

I'm struggling a little attempting to consume this web service (it is homework related but not actual homework). This BPEL process seems to provide asynchronous callbacks, I'm just not sure exactly how it is to be used. The wsimport generated the classes below:

> AttributedQName.java
> AttributedURI.java
> EndpointReferenceType.java
> N6368808CreditFlow.java
> N6368808CreditFlowCallback.java
> N6368808CreditFlowCallbackService.java
> N6368808CreditFlowProcessRequest.java
> N6368808CreditFlowProcessResponse.java
> N6368808CreditFlow_Service.java
> ObjectFactory.java
> ReferencePropertiesType.java
> Relationship.java ServiceNameType.java
> package-info.java

The N6368808CreditFlow.java is the interface with the initiate method which is I assume the credit method as it is the only method available, it takes a request as a parameter. Whereas the N6368808CreditFlowCallback.java contains an onResult method which takes a Response as a parameter.

How does one consume this service? I've been able to c开发者_如何学Goall the method but not get a response sent back (not sure how to get a response as the onResult method doesn't do anything and the initiate method returns void (not even a callback or response)).

Here is my code so far:

    N6368808CreditFlow_Service service1 = new N6368808CreditFlow_Service();
    N6368808CreditFlow port = service1.getN6368808CreditFlowPort();
    N6368808CreditFlowProcessRequest rqt = new N6368808CreditFlowProcessRequest();
    rqt.setSsn("123456789");
    port.initiate(rqt);
    System.out.println("Done");

Which according to the BPEL console works and it is given "123456789", my question is how do you get the response?

Here is a snippet from the BPEL source:

<sequence name="main">

<!--

 Receive input from requestor. (Note: This maps to operation defined in n6368808_CreditFlow.wsdl) 

-->

<receive name="receiveInput" partnerLink="client" portType="client:n6368808_CreditFlow" operation="initiate" variable="inputVariable" createInstance="yes"/>

<!--


          Asynchronous callback to the requester. (Note: the callback location and correlation id is transparently handled using WS-addressing.)


-->

- <scope name="getCreditRating">

- <sequence name="Sequence_1">

- <assign name="assign_SSN">

- <copy>

<from variable="inputVariable" part="payload" query="/client:n6368808_CreditFlowProcessRequest/client:ssn"/>

<to variable="invoke_CRS_process_InputVariable" part="payload" query="/ns1:ssn"/>

</copy>

</assign>

<invoke name="invoke_CRS" partnerLink="CreditRatingService" portType="ns1:CreditRatingService" operation="process" inputVariable="invoke_CRS_process_InputVariable" outputVariable="invoke_CRS_process_OutputVariable"/>

- <assign name="return_SSN">

- <copy>

<from variable="invoke_CRS_process_OutputVariable" part="payload" query="/ns1:rating"/>

<to variable="outputVariable" part="payload" query="/client:n6368808_CreditFlowProcessResponse/client:creditRating"/>

</copy>

</assign>

</sequence>

</scope>

<invoke name="callbackClient" partnerLink="client" portType="client:n6368808_CreditFlowCallback" operation="onResult" inputVariable="outputVariable"/>

</sequence>

</process>

---

Your BPEL process is indeed asynchronous, the process instance is started when a message is consumed by the receive activity, the response is sent via an invoke activity. In order to receive the response, your Java client needs to open a Web service endpoint which implements the client:n6368808_CreditFlowCallback port type. How the BPEL engine determines the callback's endpoint address is engine specific. Theoretically, the partner link's partner role gets initialized with the received message (i.e. the message needs to communicate the callback EPR). However it depends if and how your BPEL engine implements the initialization of partner roles.

Usually I recommend using the asynchronous process modeling paradigm, as it always supports for long-running processes. If you however use an asynchronous transport protocol (like JMS) or are absolutely sure that the called Web services is running short (i.e. it is unlikely that the whole processing takes longer than an HTTP connection timeout), you may consider modeling the process synchronous, by replacing the invoke with a reply (to the same partnerlink, porttype and operation as the receive). If in doubt, stick to the async model.