ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From buddhika chamith <chamibuddh...@gmail.com>
Subject Re: bpelrun
Date Sun, 15 Mar 2009 19:23:36 GMT
Hi,

I went through the project idea for providing ODE runtime support for
BPELUnit. I think BPELUnit covers the ground of the idea that I was
suggested on the bpel-dev list earlier.  I am very enthusiatic about the
prospect of ODE integration since I have some experience with ODE with my
current project of developing a simulator for bpel processes. I am currently
going through BpelUnit and ActiveBpel testing scenarios. I will come back
with questions when I meet any.

Best Regards,
Chamith Buddika

2009/2/26 buddhika chamith <chamibuddhika@gmail.com>

> Hi,
>
> I have been suggested of working on some thing similar to this for a GSOC
> project in bpel-dev list as a plugin[1] though I even don't mind if it
> doesn't necessarily involve in Eclipse. Any ideas on this?
>
> Regards,
> Chamith Buddhika
>
> [1] http://dev.eclipse.org/mhonarc/lists/bpel-dev/msg00897.html
>
> 2009/2/26 Daniel Luebke <daniel.luebke@inf.uni-hannover.de>
>
> Hi,
>>
>> at my department we have implemented BPELUnit available under the EPL.
>> You can send messages to processes and can define mocks for services
>> that can have assertions and return messages and faults to the process.
>> These message flows are stored as test cases, which can be grouped to
>> test suites.
>> BPELUnit has (besides an Eclipse 3.2 front-end) a command line-front end
>> and an ant task. You can easily have automated unit tests with it.
>> However, there is no ODE deployer yet. Therefore, you have to deploy the
>> process(es) manually beforehand or you can add the
>> deployment/undeployment to the ant task.
>>
>> Daniel
>>
>> Ford, Mark schrieb:
>> > I would like to see the existing test harness in ODE expanded to support
>> more robust unit testing. The bpel-test project in the ode trunk is a good
>> start. The default implementation of the MessageExchangeContext interface
>> supports a simple probe service and a fault service. This concept could be
>> expanded to include assertions on the data passed to the
>> MessageExchangeContext as well as returning preconfigured responses. This
>> interface alone would give you the hook you'd need to handle invokes. I'm
>> not sure what facilities ODE has in place to control the scheduling of
>> alarms but that's another area which could offer assertions as well as
>> changing the actual value for the alarm (you might not want your bpel to
>> have the full value for the wait/onAlarm during testing). I think the
>> existing harness already supports multiple inbound messages but I'm not sure
>> about how they're delivered.
>> >
>> >
>> > On 2/25/09 11:47 AM, "Rafal Rusin" <rafal.rusin@gmail.com> wrote:
>> >
>> > Hello,
>> >
>> > what do you think of implementing a command line tool bpelrun, which
>> > could compile and run a process by sending a request from stdin and
>> > displaying response to stdout.
>> > This would speed up testing of various bpel constructs. It would be
>> > helpful in developing larger processes by copy-pasting from small
>> > examples.
>> > It could be also useful to do bpel unit testing.
>> >
>> > --
>> > Rafał Rusin
>> > www.mimuw.edu.pl/~rrusin <http://www.mimuw.edu.pl/%7Errusin>
>> >
>> >
>> >
>> >
>> > --
>> > Mark Ford
>> > MIT Lincoln Laboratory
>> > 244 Wood Street
>> > Lexington MA 02420
>> > (781) 981-1843
>> >
>> >
>>
>>
>> --
>> Dr.-Ing. Daniel Lübke
>> Leibniz Universität Hannover
>> Welfengarten 1
>> D-30167 Hannover
>> Tel. +49 511 762 19672
>> Fax  +49 511 762 19679
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message