ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tammo van Lessen <tvanles...@gmail.com>
Subject Re: TCK for BPEL?
Date Fri, 23 Oct 2009 16:17:40 GMT
Hi Kurt,

as part of this years GSOC, we had an integration project that combined
ODE with BPELunit. The results are not yet integrated back into ODE, but
BPELunit [1] provides an engine independent way to run test cases
against BPEL engines and takes care of deployment, mocking of partner
services, regressions etc. Chamith (the GSOC student) also created some
BPELunit-based test cases based on some ODE tests. I think this
framework would have the potential to create some kind of TCK for BPEL
(although i'm not sure about political impacts such a kit could create ;).

I'll let you know once I have more details about the status of this work.

Best,
  Tammo

[1] http://bpelunit.net/

Kurt T Stam wrote:
> Hi guys,
> 
> I know there is no TCK for BPEL, but on the Riftsaw project we now have the
> CXF and JBossWS stacks integrated, using the JAX-WS interface. It's been
> pretty interesting to see the amount of touch points exceed far beyond the
> axis2 module... So we'd love to run some kind of test suite with BPEL
> examples to make sure we didn't forget one, or two..
> 
> Apart from the (3?) examples is there anything you guys use to test
> regression?
> 
> Thx,
> 
> --Kurt
> 
> On Thu, Sep 24, 2009 at 11:09 AM, matthieu.riou <matthieu.riou@gmail.com>wrote:
> 
>> On Wed, Sep 23, 2009 at 8:52 PM, Kurt T Stam <kurt.stam@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 <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