ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kurt T Stam <kurt.s...@gmail.com>
Subject Re: 1.3.x - 2.x Roadmap?
Date Thu, 24 Sep 2009 03:52:33 GMT
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.

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 <kurt.stam@gmail.com> 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 <midon@intalio.com> 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 <kurt.stam@gmail.com> 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
>>>>>
>>>>>
>>>>>
>>>>>           
>>>       
>>     
>
>   


Mime
View raw message