ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Boisvert" <boisv...@intalio.com>
Subject Re: Axis Namespace prefix generation
Date Wed, 21 May 2008 22:06:43 GMT
On Sun, May 18, 2008 at 3:52 AM, Ciaran <ciaranj@gmail.com> wrote:

> I'm currently evaluating the possibility of moving to ODE from ActiveBPEL,
> currently it seems that for a single thread, ActiveBPEL performs better
> end-to-end for a like-for-like BPEL flow, (ActiveBpel ~300ms, Ode ~700ms)
> but seems to scale considerably better for multiple threads,  has anyone
> else seen this behaviour, or has anecdotal information on the comparative
> performance ?

I don't have comparative data but I'd be interested in profiling your
use-case to see if there's something inherently slow in what we're doing.

> Also, one thing that concerns me, is looking at my load-tests it seems that
> ODE is generating unique namespace prefixes for *every* element in each
> response document in the workflow (and presumably the documents
> created+consumed during the running of the BPEL processes).  In my
> particular case the set of namespaces used by the BPEL workflow is static
> and known at deployment time, so I'm perplexed why every single element
> gets
> its own unique-prefix un-necccessarily, could anyone please explain this to
> me, an example response is as follows:

What?  You don't like this new feature of Axiom?? :)

It's possible this is Ode's fault since we had to implement a few
workarounds in namespace handling to avoid prefix clashes in previous
versions of Axiom/Woodstox.  I guess we could review this code to see if we
can avoid it now.   Could you file a Jira?

Also I'm interesting in writing an AJAX explorer for
> the ODE process instances, has anyone else been down this route already ?
> Many thanks :)

Milinda is just getting started on an AJAX management console for Ode.
Check out the recent ode-dev archives and I'd invite you to follow the
dicussions and get involved.


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