ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matthieu.r...@gmail.com>
Subject Re: Re: Re: Re: Re: Re: Asynchronous service invocation question
Date Fri, 02 Mar 2007 05:16:07 GMT
Actually with BPEL correlation (the first option mentioned by Alex), there's
theoretically no work to do from the web service implementer standpoint. The
work is done on the process side.

On 3/1/07, Jiang Liu <S3075163@student.rmit.edu.au> wrote:
>
> Thanks Alex, it really a lot more clear.
> It seems like eventhough "callback" is defined as "myRole" in service
> orchestration scenario, the logic still has to be concerned/implemented at
> consumer service side. Really hope this could be done automatically without
> any extra works.
>
>
> -----Original Message-----
> From: "Alex Boisvert" <boisvert@intalio.com>
> To: ode-dev@incubator.apache.org
> Date: Thu, 1 Mar 2007 20:48:05 -0800
> Subject: Re: Re: Re: Re: Re: Asynchronous service invocation question
>
> Hi Jiang,
>
> In your example, you would also generate stubs from the callback portType.
> That way, in your implementation of the "call" portType you can call back
> the process.
>
> class ExternalServiceSkeleton {
>    void simpleMethodFromCallPT(String input) {
>       // ..
>       // implement your service logic here
>       // ..
>
>       Callback cb = new Callback( url );
>       parameters = ...;
>       cb.methodfromCallback( parameters );
>    }
>   //...
> }
>
> You can also do the callback later (outside of your skeleton) using a
> different thread, etc.
>
> To achieve correlation with the original call, you several options, in
> order
> of increasing complexity:
> 1) use BPEL correlations  (e.g. pass around token in message body)
> 2) pass "session" SOAP headers element (from the stateful exchange
> protocol)
> 3) pass full EPR in SOAP header (again from stateful exchnage protocol)
>
> #1 is the most standard and achievable using any SOAP stack.  It has the
> benefit of being "business-friendly" as well, so when you look at the
> message you know exactly which process it corresponds to.
>
> cheers,
> alex
>
>
>
> On 2/28/07, Jiang Liu <S3075163@student.rmit.edu.au> wrote:
> > Hi Alex,
> > Thanks for your reply. For example, I have a external service WSDL:
> >
> > <definition ...>
> >    <schema ...>
> >    ...
> >    <portType name="call" ...>
> >       ...
> >    <portType name="callback">
> >       ...
> >    <binding>
> >       ...
> >    <service>
> >       <port name="callEPR" ...>
> >       <port name="callbackEPR" ...>
> >
> >    <partnerLink name="servicePL>
> >       <role name="call_PL" ...>
> >       <role name="callback_PL" ...>
> >    ...
> > </definition>
> >
> > A simple BPEL consume this service:
> >
> > <process ...>
> >    <partnerLinkTypes>
> >          ...
> >          <partnerLinkType>
> >             <myRole ="callback_PL" ...>
> >             <partnerRole="call_PL" ...>
> >    </partnerLinkTypes>
> >    ...
> >    <invoke partnerLinkType="call_PL" ...>
> >       ...
> >    <receive partnerLinkType="callback_PL" ...>
> >       ...
> >    ...
> > </process>
> >
> > Sorry the grammar is not strictly followed. :)
> >
> > Suppose that i implement the external service by using Axis2, when using
> > WSDL2Java to generate service skeleton, what i have to do is filling in
> the
> > "call" portType's business logic, for example:
> >
> > class ExternalServiceSkeleton {
> >    //...
> >    void simpleMethodFromCallPT(String input) {
> >       //just say input is a String
> >       //here do some work, e.g. database functions
> >       /*
> >         *now the work is done. should i implement callback?
> >         *if its not and BPEL is "receving" at the other side, how
> >         *could the callback be performed?
> >       */
> >    }
> >   //...
> > }
> >
> > You see the problem is at external service's skeleton, since its not
> > required to implement "callback" portType, then how the BPEL can receive
> > callback message?
> >
> > WS-Addressing covers reply-to address which helps for stateful EPR, but
> I
> > am not quite sure about the internal stateful connection mechanisms
> between
> > BPEL and partner services.
> >
> > Thanks so much for giving me so many advices :)
> >
> >
> >
> > ------------------------------
> > Jiang Liu
> > Student Number: 3075163
> > CS/Yallara Name: ljiang
> > RMIT, Melbourne
> >
>
>
> ------------------------------
> Jiang Liu
> Student Number: 3075163
> CS/Yallara Name: ljiang
> RMIT, Melbourne
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message