Hi,
On Wed, May 7, 2008 at 9:51 AM, Nowakowski, Mateusz < [EMAIL PROTECTED]> 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. <snip> 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> extension. Regards Wayne
