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 < [EMAIL PROTECTED]> 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 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
