You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by Björn Hagemeier <b....@fz-juelich.de> on 2007/12/18 14:30:02 UTC
Monitoring
Hi all,
we're using Ode to orchestrate services in the ServiceMix JBI
environment. This is working ok and we're able to send Ode events to a
monitoring component on the bus. This is done via OdeEventListener
hooked into the deployed Service Engine. In order to track groups of
events belonging to the same process, we attach a property to the
message exchange that initiates the process instance. So far so good.
Now my observation: the property attached to the message still exists
and is propagated to our monitoring component with each OdeEvent. This
works exactly until the first BPEL »invoke«, which still contains our
property. All following events don't carry the property anymore, but we
would have expected them to. Does anyone on the list have an idea what
we can do about it?
Best regards,
Björn
--
Dipl.-Inform. Björn Hagemeier
Distributed Systems and Grid Computing
Jülich Supercomputing Centre (JSC)
Phone: +49 2461 61 1584
Fax : +49 2461 61 6656
Email: B.Hagemeier@fz-juelich.de
Skype: bhagemeier
http://www.fz-juelich.de/jsc
-------------------------------------------------------------------
-------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Dr. Sebastian M. Schmidt
-------------------------------------------------------------------
-------------------------------------------------------------------
Re: Monitoring
Posted by Alex Boisvert <bo...@intalio.com>.
On Wed, Apr 2, 2008 at 7:42 AM, Björn Hagemeier <b....@fz-juelich.de>
wrote:
> I know it's been a while, but I'm looking into this issue once more.
> What exactly did you mean by "add custom message headers and explicitly
> map between them". My assumption is:
>
> custom message header == property on ODE MessageExchange ??? That's
> what we did, anyway.
> explicitly map between them: where would we do that?
What I meant is WSDL parts mapped into the header. See
http://www.intalio.org/confluence/pages/viewpage.action?pageId=1485
And using regular BPEL assignments to carry header information from one
message to another.
alex
Re: Monitoring
Posted by Björn Hagemeier <b....@fz-juelich.de>.
Hi Alex,
I know it's been a while, but I'm looking into this issue once more.
What exactly did you mean by "add custom message headers and explicitly
map between them". My assumption is:
custom message header == property on ODE MessageExchange ??? That's
what we did, anyway.
explicitly map between them: where would we do that?
Thanks,
Björn
Alex Boisvert schrieb:
> As of today, there's no facility in the integration layer to create a
> context that's longer than a single message exchange. The engine has larger
> contexts (process, scopes, partnerLinks) but these are not yet exposed in
> the IL. That's something we plan to address in the medium term (next 3-4
> months, I guess), probably by allowing named context to be associated with
> message exchanges.
>
> Right now, the only (portable) ways to carry context between message
> exchanges is to add custom message headers and explicitly map between them,
> or use BPEL correlations.
>
> alex
>
>
> On 12/18/07, Björn Hagemeier <b....@fz-juelich.de> wrote:
>> Hi all,
>>
>> we're using Ode to orchestrate services in the ServiceMix JBI
>> environment. This is working ok and we're able to send Ode events to a
>> monitoring component on the bus. This is done via OdeEventListener
>> hooked into the deployed Service Engine. In order to track groups of
>> events belonging to the same process, we attach a property to the
>> message exchange that initiates the process instance. So far so good.
>>
>> Now my observation: the property attached to the message still exists
>> and is propagated to our monitoring component with each OdeEvent. This
>> works exactly until the first BPEL »invoke«, which still contains our
>> property. All following events don't carry the property anymore, but we
>> would have expected them to. Does anyone on the list have an idea what
>> we can do about it?
>>
>> Best regards,
>>
>> Björn
>>
>
--
Dipl.-Inform. Björn Hagemeier
Juelich Supercomputing Centre
Institute for Advanced Simulation
Phone: +49 2461 61 1584
Fax : +49 2461 61 6656
Email: b.hagemeier@fz-juelich.de
Skype: bhagemeier
WWW : http://www.fz-juelich.de/jsc
JSC is the coordinator of the
John von Neumann Institute for Computing
and member of the
Gauss Centre for Supercomputing
Re: Monitoring
Posted by Alex Boisvert <bo...@intalio.com>.
As of today, there's no facility in the integration layer to create a
context that's longer than a single message exchange. The engine has larger
contexts (process, scopes, partnerLinks) but these are not yet exposed in
the IL. That's something we plan to address in the medium term (next 3-4
months, I guess), probably by allowing named context to be associated with
message exchanges.
Right now, the only (portable) ways to carry context between message
exchanges is to add custom message headers and explicitly map between them,
or use BPEL correlations.
alex
On 12/18/07, Björn Hagemeier <b....@fz-juelich.de> wrote:
>
> Hi all,
>
> we're using Ode to orchestrate services in the ServiceMix JBI
> environment. This is working ok and we're able to send Ode events to a
> monitoring component on the bus. This is done via OdeEventListener
> hooked into the deployed Service Engine. In order to track groups of
> events belonging to the same process, we attach a property to the
> message exchange that initiates the process instance. So far so good.
>
> Now my observation: the property attached to the message still exists
> and is propagated to our monitoring component with each OdeEvent. This
> works exactly until the first BPEL »invoke«, which still contains our
> property. All following events don't carry the property anymore, but we
> would have expected them to. Does anyone on the list have an idea what
> we can do about it?
>
> Best regards,
>
> Björn
>