ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wayne Keenan" <wayne.kee...@gmail.com>
Subject Re: Logging from BPEL script
Date Wed, 07 May 2008 09:02:31 GMT

On Wed, May 7, 2008 at 9:51 AM, Nowakowski, Mateusz <
Mateusz.Nowakowski@sabre-holdings.com> wrote:

> >> Thank you
> >>
> >> I've also think about this workaround... but we didn't decide to do
> that
> >> way, because it is too complicated and resource consuming... logging
> >should
> >> be as fast as possible...
> >> I think that log activity should be present in the standard, but the
> >> behavior should depend on the implementation.
> >
> >
> >Have you considered using the events that Ode generates?
> Yes, we are using ODE event listeners, but these are not perfect. We'd
> like for example to log current state of all variables. The EventContext
> is deprecated, but potentially gives possibility to do that. It is
> deprecated, because it is not working for only in memory processes
> (there was a discussion some time ago about it)
> >> BPEL/ODE is annoying me slowly... It is very difficult to do very
> easy
> >> things and we need to discover very ugly workarounds to make things
> work
> >
> >
> >I would be interested in hearing more about these.  What are your top
> >itches?
> - BPEL is not completely programming language. It doesn't contain
> something like procedure or function instruction. It is also impossible
> to share code between processes. Only copy-paste methodology works.


Although I'm new to BPEL and ODE, that statement regarding sharing code is
completely correct, as there are
Abstract Process, so although not reuse by composition, does promote reuse
by inheritance.

As far a procedural/function calling goes, an 'invoke' to a BPEL process
hosted/advertised by the same
ODE instance as the caller would be a likely candidate for in-[Java|BPEL]VM
optimisation, not that such a thing
exists at the moment.  Although is the declarative overhead of the partner
link make it worth implementing some kind of <invoke-local-operation>


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