ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Boisvert" <boisv...@intalio.com>
Subject Re: Logging from BPEL script
Date Mon, 12 May 2008 21:57:49 GMT
Hi Mateusz,

I'm coming back to this thread after a busy week at CommunityOne/JavaOne,
Scala Lift-Off, and all that craziness...

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

> >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.

Correct.  There's been a few proposals/experiments in the past but I haven't
heard anything recently about these efforst.


- ServiceMix integration. A last problem with deploying ODE within SM is
> minor in my opinion. ODE slightly doesn't fit to SM. When message
> arrives to ODE from SM, it looses all normalized messages properties
> (there was a short discussion about it) - so if we have something in
> properties we need to make hardcore workaround and copies properties
> into xml payload. It breaks service schema, but it doesn't matter for
> ODE.

Generally speaking, BPEL wasn't designed to support low-level message
properties or protocol details, whether they are JBI-specific, or come from
WS-Addressing headers, etc.    This is the kind of details that's better
left hidden from the business process to make the process as reusable and
portable as possible.

This being said, there have been a few ideas thrown around to supporting
some of these in Apache Ode.   We've had some recent discussions within
Intalio and Matthieu should post some proposal about this on the mailing
list for wider discussion.

> - Schema validation. It is written in the documentation that schema
> validation is not implemented. It is not completely true. When you
> assign some data to variable, ODE checks the first tag of data. A very
> strange thing appears when you assign completely different data to
> inappropriate variable type. ODE silently "merges" input data with
> destination variable type that the result has the first tag the same as
> destination type, but payload is from input data...

Ode attempts to be very JBI compliant and follow the normalization rules
defined by the JBI spec; we didn't define our own rules.  The only message
converters we have (to complement the standard JBI one) were written to
support existing ServiceMix components that didn't follow JBI rules.

This being said, I think this is an area were much improvements can be
done.  Right now Ode supports only one message converter at a time.  This is
inconvenient if you have both standard and non-standard components in your
architecture.   We should probably support more than one at a time and
dynamically select the most appropriate one at runtime.   Second, the error
handling and error reporting could be improved to provide more visibility
into how messages are matched, mapped or converted into and out of Ode.
The current behavior is rather silent and thus doesn't provide much clue as
to why messages are not processed when they don't fit the expected format.

I'm not sure about the "merge" issue that you mention.  Can you provide more

- Last my JIRA entry ODE-263. onAlarm is not working. It generates alarm
> only after completed activity, not after specified amount of time. In
> other words it doesn't work. We want use this functionality as a timeout
> guard, but because of that we need to implement this functionality
> outside ODE.

Ok, I'll take a look.

> - Some useful extensions like external variables or adding own
> activities are not in stable ODE version. We cannot rely on trunk.
> Faster releases would be appropriate.

Actually, external variables are on the Ode 1.1 branch and will be part of
the next stable 1.2 release.

Things that are on the trunk but not in 1.1 are,
-Atomic scopes (transactions)
-BPEL extension activities (including Javascript E4X assigns)
-Improvement to the IL messaging interaction model
  (future support for reliable messaging, transactional invoke, better async
handling, ...)

The main issue preventing us from migrating to and releasing the trunk is
backward compatibility.  Maciej was working on dual support for both Ode
1.1-compiled processes and Ode-trunk compiled processes but it's taken
longer than expected and he's been less available than expected.   We're
waiting for him to clean up and commit what he's done so far so we can take
it from there.


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