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 Tue, 13 May 2008 15:52:32 GMT
Ok, I understand the issue now.  Thanks for the explanation.

This, ahem, idiosyncrasy, is actually defined by the BPEL 2.0 spec in
section 8.4.2 (Replacement Logic of Copy Operations).  When you're copying
from one element (EII) to another element (EII), you can specify the
"keepSrcElementName" attribute to define the behavior you want.

To paraphrase the spec,

   - When the keepSrcElementName attribute is set to "no" (which is the
   default), the target element name is maintained
   - When the keepSrcElementName attribute is set to "yes", the source
   element name is used as the name of the resulting destination element.

It sounds like you'd want to set "keepSrcElementName" to "yes" in your case.

I think you put your finger on it earlier, though, the real issue here is
the lack of schema validation that makes some of these errors go by


On Tue, May 13, 2008 at 1:50 AM, Nowakowski, Mateusz <
Mateusz.Nowakowski@sabre-holdings.com> wrote:

> 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="....">
>        <AnotherSomeTag>......</AnotherSomeTag>
> </SomeElement>
> When I tied to assign something like this:
> <TotallyDifferentType xmlns="...." someAttr="...">
>        <xx>lorem ipsum</xx>
>        <yyy>some content</yyy>
> </TotallyDifferentType>
> to variable someVariable
> the result is:
> <SomeElement xmlns="...." someAttr="...">
>        <xx>lorem ipsum</xx>
>        <yyy>some content</yyy>
> </SomeElement>
> This is done silently of course.
> --
> Regards
> 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
> 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.
> e.g.
> https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid
> /7d26a4e1-0601-0010-b9a4-c815157e69af<https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/7d26a4e1-0601-0010-b9a4-c815157e69af>
> http://www.ibm.com/developerworks/library/specification/ws-bpelsubproc/
> - 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
> detail?
> - 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.
> alex

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