ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: Fault exchange between bpel processes
Date Fri, 24 Oct 2008 16:05:35 GMT
On Fri, Oct 24, 2008 at 8:06 AM, Matthieu Riou <matthieu@offthelip.org> wrote:
> On Fri, Oct 24, 2008 at 7:07 AM, Dalys Sebastian
> <sebastian_dalys@yahoo.com>wrote:
>
>> Hi Matthieu, Karthick,
>>
>> Thanks for your replies. I replaced the throw activity in each of the bpels
>> with a reply activity and I find the fault getting exchanged properly. Thus
>> my current problem is resolved.
>>
>
> Cool :)
>
>
>>
>> Commenting on throw vs reply, currently if I invoke a bpel service in Ode,
>> a soapfault is thrown back to the client, irrespective of whether a throw or
>> reply activity is implemented inside the bpel for throwing the fault. I
>> naturally expected the behavior to be the same whether I call the bpel
>> service from a soap client or from another bpel service.
>>
>
> Elaborating a bit:
>
>   - I wrote "bubble back to the client" a little too quickly. What really
>   happens is that a fault never caught bubbles all the way up to the process.
>   Then pending invocations are "closed" by throwing a fault but it's not the
>   original fault that the process received. Unless you catch it yourself and
>   reply with it as you've done.
>   - Unless I misunderstood your point, the behavior can't be the same, you
>   have a process in the middle. So the behavior is the one dictated by your
>   process. What could be different is the default, instead of throwing a new
>   fault to the caller, we could use the one that failed the process instead.
>   The original intent I think was to prevent leaking information to the client
>   that would be private to the process and the service it invokes. Say for
>   example that the fault includes in its message a login that failed, you
>   typically don't want that login information to get back to the caller.

Always throw a new fault to the caller.

If you want to communicate a specific fault to the client, you can do
so by replying with a fault, and you have control over what that fault
would be.

If you don't care much, you can be lazy and just let the process
return some fault which doesn't say much to the client, other than
their request has faulted.

Assaf


>
> Cheers,
> Matthieu
>
>
>
>>
>> Thanks,
>> Dalys
>>
>> --- On Thu, 10/23/08, Matthieu Riou <matthieu@offthelip.org> wrote:
>>
>> > From: Matthieu Riou <matthieu@offthelip.org>
>> > Subject: Re: Fault exchange between bpel processes
>> > To: user@ode.apache.org
>> > Date: Thursday, October 23, 2008, 10:41 PM
>> > On Thu, Oct 23, 2008 at 7:42 PM, Karthick Sankarachary <
>> > sankarachary@intalio.com> wrote:
>> >
>> > > Hi Dalys,
>> > >
>> > > Just to be clear, when you throw a fault after a
>> > <receive> activity, it
>> > > will
>> > > not magically propagate back to the invoker as a
>> > response. In fact, no
>> > > reply
>> > > will be sent for any inbound message activity that was
>> > open at the point
>> > > the
>> > > fault was thrown. If the fault is not caught, the
>> > fault throwing process
>> > > will cease to exist, and the invoker will and should
>> > eventually timeout.
>> > >
>> >
>> > Mmmh actually the behavior in that case isn't dictated
>> > by the BPEL spec. But
>> > letting the fault bubbling back to the caller and not
>> > letting it timeout is
>> > a sensible thing to do. So that's what ODE does :) I
>> > believe most other
>> > implementations behave similarly.
>> >
>> > Matthieu
>> >
>> >
>> > >
>> > > I suggest replacing the <throw> with a
>> > <reply> activity, like so:
>> > >
>> > > -        <bpws:throw
>> > faultName="fault:TestFault"
>> > > faultVariable="testFault"/>
>> > > +       <bpws:reply
>> > faultName="fault:TestFault"
>> > variable="testFault"
>> > > partnerLink="..." portType="..."
>> > .../>
>> > >
>> > > Hope it helps.
>> > >
>> > > Best Regards,
>> > > Karthick Sankarachary
>> > >
>> > >
>> > > On Thu, Oct 23, 2008 at 7:08 PM, Dalys Sebastian
>> > > <sebastian_dalys@yahoo.com>wrote:
>> > >
>> > > > Hi Karthick,
>> > > >
>> > > > Here's the complete package attached. Earlier
>> > in the day I had sent all 5
>> > > > files, but only 3 made it to the mailing list.
>> > Sorry about that. Please
>> > > let
>> > > > me know if you have any trouble receiving it.
>> > > >
>> > > > Thanks,
>> > > > Dalys
>> > > >
>> > > >
>> > > > --- On Thu, 10/23/08, Karthick Sankarachary
>> > <sankarachary@intalio.com>
>> > > > wrote:
>> > > >
>> > > > > From: Karthick Sankarachary
>> > <sankarachary@intalio.com>
>> > > > > Subject: Re: Fault exchange between bpel
>> > processes
>> > > > > To: "Alexis Midon"
>> > <midon@intalio.com>
>> > > > > Cc: user@ode.apache.org, "Karthick
>> > Sankarachary" <karthick@intalio.com
>> > > >
>> > > > > Date: Thursday, October 23, 2008, 7:31 PM
>> > > > > I just want to point out that throwing a
>> > fault in the middle
>> > > > > of a <receive>-
>> > > > > <reply> pair is not the same as
>> > replying with a fault
>> > > > > name in the response.
>> > > > > In light of that, I don't think
>> > Dalys' issue is
>> > > > > related to
>> > > > >
>> > https://issues.apache.org/jira/browse/ODE-401. Like
>> > > > > Matthieu said, it would
>> > > > > help to have the complete BPEL project.
>> > > > >
>> > > > > Best Regards,
>> > > > > Karthick Sankarachary
>> > > > >
>> > > > >
>> > > > > On Thu, Oct 23, 2008 at 5:24 PM, Alexis
>> > Midon
>> > > > > <midon@intalio.com> wrote:
>> > > > >
>> > > > > > It seems to me that your issue and the
>> > jira ODE-401
>> > > > > are very similar.
>> > > > > > and I think Karthick is baking a patch.
>> > > > > >
>> > > > > >
>> > https://issues.apache.org/jira/browse/ODE-401
>> > > > > >
>> > > > > > Alexis
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > On Thu, Oct 23, 2008 at 8:28 AM, Dalys
>> > Sebastian <
>> > > > > > sebastian_dalys@yahoo.com> wrote:
>> > > > > >
>> > > > > >> Hi Matthieu,
>> > > > > >>
>> > > > > >> Thank you for your response. To
>> > better
>> > > > > troubleshoot this problem, I went
>> > > > > >> and created test process samples
>> > that would easily
>> > > > > reproduce the problem.
>> > > > > >>
>> > > > > >> In this sample, there are 5 files:
>> > The first 2
>> > > > > files implement the
>> > > > > >> WSFaultThrower process that just
>> > throws a fault.
>> > > > > The next 2 files implement
>> > > > > >> the WSFaultInvoker process that
>> > invokes the
>> > > > > WSFaultThrower process. This
>> > > > > >> process then should catch the fault
>> > thrown by
>> > > > > WSFaultThrower and then
>> > > > > >> rethrow a new fault to the client.
>> > > > > >>
>> > > > > >> WSFaultThrower.wsdl
>> > > > > >> WSFaultThrower.bpel
>> > > > > >> WSFaultInvoker.wsdl
>> > > > > >> WSFaultInvoker.bpel
>> > > > > >> deploy.xml
>> > > > > >>
>> > > > > >> I could reproduce the problem by
>> > creating soap-ui
>> > > > > projects that could
>> > > > > >> invoke both services separately.
>> > When I invoke
>> > > > > FaultThrower service, it just
>> > > > > >> throws a standard soap fault to me.
>> > But when I
>> > > > > invoke WSFaultInvoker, it
>> > > > > >> just times out instead of throwing
>> > a fault as
>> > > > > well.
>> > > > > >>
>> > > > > >> Please let me know if I am doing
>> > something wrong.
>> > > > > >>
>> > > > > >> Thanks,
>> > > > > >> Dalys
>> > > > > >>
>> > > > > >>
>> > > > > >>
>> > > > > >> --- On Wed, 10/22/08, Matthieu Riou
>> > > > > <matthieu@offthelip.org> wrote:
>> > > > > >>
>> > > > > >> > From: Matthieu Riou
>> > > > > <matthieu@offthelip.org>
>> > > > > >> > Subject: Re: Fault exchange
>> > between bpel
>> > > > > processes
>> > > > > >> > To: user@ode.apache.org,
>> > > > > sebastian_dalys@yahoo.com
>> > > > > >> > Date: Wednesday, October 22,
>> > 2008, 10:20 AM
>> > > > > >> > On Tue, Oct 21, 2008 at 9:57
>> > PM, Dalys
>> > > > > Sebastian
>> > > > > >> >
>> > <sebastian_dalys@yahoo.com>wrote:
>> > > > > >> >
>> > > > > >> > > Hi everyone,
>> > > > > >> > >
>> > > > > >> > > I have 2 bpel processes
>> > running within
>> > > > > the same folder
>> > > > > >> > under
>> > > > > >> > > WEB-INF/processes. My
>> > first bpel calls
>> > > > > my second bpel
>> > > > > >> > via an invoke activity
>> > > > > >> > > and the second bpel
>> > throws a soap
>> > > > > standard fault. But,
>> > > > > >> > my first bpel process
>> > > > > >> > > cannot catch it.
>> > > > > >> > >
>> > > > > >> > > In my first bpel, I have
>> > set:
>> > > > > >> > > <ext:failureHandling
>> > > > > >> >
>> > > > >
>> > xmlns:ext="http://ode.apache.org/activityRecovery">
>> > > > > >> > >
>> > > > > >> >
>> > > > >
>> > <ext:faultOnFailure>true</ext:faultOnFailure>
>> > > > > >> > >
>> > </ext:failureHandling>
>> > > > > >> > >
>> > > > > >> > > I tested the operation of
>> > my second bpel
>> > > > > via soap-ui
>> > > > > >> > and I can see that it
>> > > > > >> > > correctly returns a
>> > soap-fault. The
>> > > > > soap-fault looks
>> > > > > >> > exactly like the
>> > > > > >> > > specifications and is a
>> > standard soap
>> > > > > fault.
>> > > > > >> > >
>> > > > > >> > > But, when the same
>> > operation of the
>> > > > > second bpel is
>> > > > > >> > called by my first bpel,
>> > > > > >> > > the fault cannot be
>> > caught by the first
>> > > > > bpel. I have a
>> > > > > >> > catchAll inserted in
>> > > > > >> > > the invoke activity to
>> > catch the fault.
>> > > > > Could anyone
>> > > > > >> > please help out? (I am
>> > > > > >> > > using ode 1.2)
>> > > > > >> > >
>> > > > > >> >
>> > > > > >> > Could you provide your whole
>> > deployment so I
>> > > > > can have a
>> > > > > >> > look at it and
>> > > > > >> > eventually reproduce the
>> > problem?
>> > > > > >> >
>> > > > > >> > Thanks,
>> > > > > >> > Matthieu
>> > > > > >> >
>> > > > > >> >
>> > > > > >> > >
>> > > > > >> > > Thanks,
>> > > > > >> > > Dalys
>> > > > > >> > >
>> > > > > >> > >
>> > > > > >> > >
>> > > > > >> > >
>> > > > > >> > >
>> > > > >
>> > __________________________________________________
>> > > > > >> > > Do You Yahoo!?
>> > > > > >> > > Tired of spam?  Yahoo!
>> > Mail has the best
>> > > > > spam
>> > > > > >> > protection around
>> > > > > >> > > http://mail.yahoo.com
>> > > > > >> > >
>> > > > > >>
>> > > > > >>
>> > > > > >>
>> > > > > >>
>> > > > > >
>> > > > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > >
>>
>>
>>
>>
>

Mime
View raw message