You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by Kurt T Stam <ku...@gmail.com> on 2009/09/02 16:26:20 UTC
1.3.x - 2.x Roadmap?
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
Re: 1.3.x - 2.x Roadmap?
Posted by Milinda Pathirage <mi...@gmail.com>.
Hi Alex,
Can you point me some JIRAs. I would like to contribute for 2.x
Thanks
Milinda
On Tue, Sep 8, 2009 at 10:57 PM, Alex Boisvert <bo...@intalio.com> 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 <mi...@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 <ku...@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
> > >
> >
>
--
Milinda Pathirage
Senior Software Engineer & Product Manager WSO2 BPS; http://wso2.org/bps
WSO2 Inc.; http://wso2.com
E-mail: milinda@wso2.com, milinda.pathirage@gmail.com
Web: http://mpathirage.com
Blog: http://blog.mpathirage.com
Re: 1.3.x - 2.x Roadmap?
Posted by "matthieu.riou" <ma...@gmail.com>.
On Wed, Sep 23, 2009 at 8:52 PM, Kurt T Stam <ku...@gmail.com> 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 <ku...@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 <mi...@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 <ku...@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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
Re: 1.3.x - 2.x Roadmap?
Posted by Kurt T Stam <ku...@gmail.com>.
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 <ku...@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 <mi...@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 <ku...@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
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>
>
>
Re: 1.3.x - 2.x Roadmap?
Posted by Matthieu Riou <ma...@gmail.com>.
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 <ku...@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 <mi...@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 <ku...@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
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
Re: 1.3.x - 2.x Roadmap?
Posted by Kurt T Stam <ku...@gmail.com>.
Thanks Alex,
1. That is very helpful. Is there any expectation as to when the first
release 2.0 release will happen?
2. I see there are 85 jira for 2.0, so that may take a bit?
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 <mi...@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 <ku...@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
>>>
>>>
>
>
Re: 1.3.x - 2.x Roadmap?
Posted by Alex Boisvert <bo...@intalio.com>.
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 <mi...@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 <ku...@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
> >
>
Re: 1.3.x - 2.x Roadmap?
Posted by Alexis Midon <mi...@intalio.com>.
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 <ku...@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
>