On Wed, Sep 23, 2009 at 8:52 PM, Kurt T Stam <[email protected]> wrote:
> Thanks Matthieu, > > We initially based the Riftsaw project on the trunk (2.0 codebase), but we > have since moved back to 1.3, as we need a stable codebase to build on. One > of the main areas of concern for us is the ability to swap out the WS stack, > and we're trying to use JAX-WS rather > then coding against another internal API (as is done with axis2). We're > making progress but I have to say things are pretty hairy in this module. If > we pull it off we sure think this would be good to contribute back > "upstream" to the ODE project. I'm hoping you would be interested to take it > back. > > I'm sure there's interest. Thanks, Matthieu > Thank you for giving such a great overview on the history of the 2.0 > branch. We will sure take a look at jira and start putting our votes in, and > hopefully we should be able to work on some of the issues that are important > to us (providing patches). Versioning is high on our list. > > --Kurt > > > Matthieu Riou wrote: > >> I realize this thread is pretty close to dead but I thought some >> perspective >> on the trunk could help. >> >> On Wed, Sep 9, 2009 at 7:00 AM, Kurt T Stam <[email protected]> wrote: >> >> >> >>> Thanks Alex, >>> >>> 1. That is very helpful. Is there any expectation as to when the first >>> release 2.0 release will happen? >>> >>> >>> >>> >> When it's ready :) More seriously, you can make it happen. >> >> >> >> >>> 2. I see there are 85 jira for 2.0, so that may take a bit? >>> >>> >>> >>> >> 2.0 has been for a while the "future" release so there's a lot of issues >> there that actually belong to the wishlist. Some triage is required to see >> what's really necessary (like porting fixes from 1.X) and what's just >> "nice >> to have". It'd be pretty helpful if someone could do a first pass on all >> of >> those and assign them to the wishlist. >> >> I can also provide a more context regarding the current state of trunk. It >> all started as Alex described it, the need to reflect the QoS at the >> message >> exchange level. This is necessary to support transactional or reliable >> transports correctly and it allowed some optimizations for the classic >> async, non reliable case (HTTP). The most important optimization being the >> number of transactions, 1.X is pretty pessimistic and commits a lot, often >> unnecessarily when you keep in mind that HTTP is unreliable in the first >> place. In trunk there's the notion of a process-level work queue, so work >> gets done for as long as possible without committing. >> >> So that work got started and we realized it would break the serialized >> OModel backward compatibility. Which was another problem that needed >> tackling anyway. At this point we introduced runtime versioning which is >> also in the trunk (you'll notice 2 versions under runtime and compiler). >> The >> idea is that the older process definitions and their instances get loaded >> in >> the older runtime and the newer ones use the v2 runtime so everyone can >> continue business as usual. >> >> There's also been some work on RESTful support and a related message >> exchange and ODEProcess implementation. If you implement a RESTful >> integration API, you can have a full request/response interaction served >> without any WSDL or SOAP BS. An example of a RESTful integration layer >> implementation can be found in simplex >> (http://github.com/intalio/simplexunder the http and messaging >> packages). >> >> So that's a lot of good infrastructure work. To the best of my knowledge, >> everything implemented is functional. It's probably not as fine-tuned as >> the >> 1.X branch though, there's been a lot of maturation behind each 1.3.x >> release. The BART stuff runs nicely, the reliable and transactional parts >> are untested (no IL uses it) but the classic HTTP code path works well and >> the work queue is effective. My guess would be that trunk commits about >> 30% >> less often than 1.X on typical processes. Runtime versioning works too, >> we >> have test cases for it reloading older saved runtimes. Finally, the >> RESTful >> support is also well tested in SimPEL. >> >> So the 2 main things necessary before a 2.0 I think would be >> >> 1. some bug triage to see which important fixes could have been >> forgotten >> from 1.x >> 2. migration at the database level for people who will want to upgrade >> from 1.x >> 3. someone volunteering to push the release forward >> >> >> The second point mostly matters for folks who have or are supporting >> people >> with a 1.x production. >> >> Hope this helps, >> Matthieu >> >> >> >> >> >>> Some stuff we worked on: >>> ODE-225 - HowTo: JBoss & ODE - might prob just a link to the RiftSaw >>> project (https://www.jboss.org/riftsaw) >>> ODE-41 - CXF Implementation of the IAPI - In RiftSaw we're using the >>> JBossWS (spi), which allows plugging in CXF and JBossWS Native. I'm >>> guessing >>> this code will stay in RiftSaw since it will run easiest on JBoss. We've >>> tried using plain JAXWS but that turned out to be infeasible. So the spi >>> is >>> the easiest way to support multiple WS stacks. >>> >>> Thx, >>> >>> --Kurt >>> >>> >>> Alex Boisvert wrote: >>> >>> >>> >>>> The trunk has a reworked engine-to-IL contract that supports BART >>>> (blocking, >>>> async, reliable, transacted) invokes. The engine part is mostly done; >>>> the >>>> IL parts are still a work in progress. >>>> >>>> The trunk also supports extension activities and includes support for >>>> Javascript E4X assignments. >>>> >>>> Some fixes/improvements that went into 1.X branch still have to be >>>> ported >>>> to >>>> trunk. We have Jira trackers for these if you want details. >>>> >>>> alex >>>> >>>> On Tue, Sep 8, 2009 at 10:02 AM, Alexis Midon <[email protected]> >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>>> Hi Kurt, >>>>> ODE trunk has two new big features compare to 1.3: >>>>> - support for multiple bpel runtimes: ODE 2.0 supports all its >>>>> previous >>>>> runtime verisons so that running process instances are not affected by >>>>> upgrades. >>>>> - atomic transactions: >>>>> http://ode.apache.org/atomic-scopes-extension-for-bpel.html >>>>> >>>>> On the roadmap as well: >>>>> - RESTful bpel part 2 >>>>> - Tuscany integration >>>>> >>>>> anything I'm omitting guys? >>>>> >>>>> Alexis >>>>> >>>>> >>>>> On Wed, Sep 2, 2009 at 7:26 AM, Kurt T Stam <[email protected]> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Hi guys, >>>>>> >>>>>> 1. What are currently the differences between the 1.3 branch and the >>>>>> 2.0 >>>>>> branch? >>>>>> >>>>>> 2. When is the expectation there is going to be a release from the 2.0 >>>>>> branch? Any RC being planned? >>>>>> >>>>>> Thx, >>>>>> >>>>>> --Kurt >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >> >> >> > >
