ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nowakowski, Mateusz" <Mateusz.Nowakow...@sabre-holdings.com>
Subject RE: Logging from BPEL script
Date Tue, 13 May 2008 08:50:29 GMT
Thank you for your answer.
It gives me more lights on the problem.

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

For example I have variable defined that way:

<bpel:variable name="someVariable" element="tns:SomeElement"/>

And an example of tns:SomeElement element type looks like :

<SomeElement xmlns="....">

When I tied to assign something like this:

<TotallyDifferentType xmlns="...." someAttr="...">
	<xx>lorem ipsum</xx>
	<yyy>some content</yyy>

to variable someVariable
the result is:

<SomeElement xmlns="...." someAttr="...">
	<xx>lorem ipsum</xx>
	<yyy>some content</yyy>

This is done silently of course.

Mateusz Nowakowski
-----Original Message-----
From: Alex Boisvert [mailto:boisvert@intalio.com] 
Sent: Monday, May 12, 2008 11:58 PM
To: user@ode.apache.org
Subject: Re: Logging from BPEL script

Hi Mateusz,

I'm coming back to this thread after a busy week at
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
> to share code between processes. Only copy-paste methodology works.

Correct.  There's been a few proposals/experiments in the past but I
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
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
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
> 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
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
architecture.   We should probably support more than one at a time and
dynamically select the most appropriate one at runtime.   Second, the
handling and error reporting could be improved to provide more
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
to why messages are not processed when they don't fit the expected

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

- 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
> 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
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
handling, ...)

The main issue preventing us from migrating to and releasing the trunk
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
it from there.


View raw message