You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by Alex Boisvert <bo...@intalio.com> on 2006/07/11 20:26:27 UTC
Roadmap: Update
Taking a look back at the roadmap we drafted back in March/April
(http://wiki.apache.org/ode/RoadMap), here's my take on our progress so far:
1) Common Implementation: I think we're getting close. I'd like to
hear what people think about moving ode/scratch/pxe-iapi to ode/trunk.
2) Remove Hibernate dependency: OpenJPA was suggested a while back. I
don't know what is the status of the project and when they expect to
produce a first release. Anybody wants to volunteer for an investigation?
3) Data abstraction layer: We have Cory's Content API proposal in the
scratch area. Maybe it's time to merge into the IAPI?
4) Deployment model: Lance recently submitted a proposal for
discussion. Pending.
5) BPEL 2.0: PXE implements BPEL 2.0. Check.
6) Stateless processes: PXE offers non-persistent processes. Check.
7) Debugging support: PXE provides line numbers for event generated
during execution. Check.
8) Process Management API: PXE's management interfaces have been kept
current, but will need updates following #4 above. Check.
9) Jacob: We have more documentation available and there's a proposal
to make the terminology more intuitive. Do we need more
examples/walkthrough's ?
10) Integration API: We have an API with minimal dependencies and two
implementations validating it. Check.
11) Synchronous transaction and asynchronous messaging: Semantics
defined in IAPI. Check.
12) Tests: Still need to merge both BPE and PXE's test harnesseses. No
progress on common benchmark framework yet.
Scorecard: 8 / 12 (assuming we score half-points for #3 and #4 until
we reach closure)
Overall, I believe we've been making steady progress on our shared
roadmap and goals. Does this match with everybody's perspective? Any
elephants in the room? My take is we're reaching a point where moving
to a common implementation (#1) would really help push the remaining
items forward by rallying everybody around this shared codebase and
stimulating tangible contributions -- whether small or large -- to be
made directly in the codebase.
alex
Re: Roadmap: Update
Posted by Alex Boisvert <bo...@intalio.com>.
Is Minerva still needed? I was under the impression that connection
pools could be provided by the deployment environment, such as the app
server or lightweight container (e.g. Spring).
alex
Matthieu Riou wrote:
> So that would mean the following modules:
>
> - Axis2 (IAPI implementation for Axis2)
> - BPEL API (mostly DAO interfaces, IAPI interfaces, events, management
> API)
> - BOM
> - Compiler
> - DD (deployment descriptors)
> - XPath 1.0 and 2.0 support.
> - Bpel-Obj (already in)
> - Bpel-Parser (already in)
> - Bpel-QL (query language for retrieving instances information, needed by
> management API).
> - Bpel runtime
> - Bpel sechdule (quartz)
> - Bpel schemas
> - DAO-*
> - Examples
> - Jacob
> - JBI
> - Minerva (connection pool)
> - Utils (already in)
>
> That will give us a working basis to start removing the dependencies we
> don't like, changing the things that don't comply to specs and so on. But
> I'd find much more comfortable to start from something that builds and
> runs.
>
Re: Roadmap: Update
Posted by Lance Waterman <la...@gmail.com>.
Sounds good to me.
On 7/13/06, Matthieu Riou <ma...@gmail.com> wrote:
>
> > I have been looking at the Jacob engine, BPEL runtime and BOM and feel
> > comfortable with the implementations. I would be fine with moving these
> > into
> > the trunk. I would like to talk more about the build and get a better
> > understanding about project dependancies.
>
>
> Actually if it's ok for everybody, I'd also move the dependencies of these
> modules, so that we can at least have something that compiles and run a
> couple of examples. Then we can start from that and start "breaking"
> things
> to comply with the specs we already have (like deployment and content API)
> and the ones we still have to write :) Otherwise nothing will compile and
> we
> won't be to run any single thing.
>
> So that would mean the following modules:
>
> - Axis2 (IAPI implementation for Axis2)
> - BPEL API (mostly DAO interfaces, IAPI interfaces, events, management
> API)
> - BOM
> - Compiler
> - DD (deployment descriptors)
> - XPath 1.0 and 2.0 support.
> - Bpel-Obj (already in)
> - Bpel-Parser (already in)
> - Bpel-QL (query language for retrieving instances information, needed by
> management API).
> - Bpel runtime
> - Bpel sechdule (quartz)
> - Bpel schemas
> - DAO-*
> - Examples
> - Jacob
> - JBI
> - Minerva (connection pool)
> - Utils (already in)
>
> That will give us a working basis to start removing the dependencies we
> don't like, changing the things that don't comply to specs and so on. But
> I'd find much more comfortable to start from something that builds and
> runs.
>
> If you like I can then write something about build (actually nothing
> special, only using Maven2) and dependencies.
>
> What do you think?
>
> Cheers,
>
> Matthieu
>
>
Re: Roadmap: Update
Posted by Matthieu Riou <ma...@gmail.com>.
> I have been looking at the Jacob engine, BPEL runtime and BOM and feel
> comfortable with the implementations. I would be fine with moving these
> into
> the trunk. I would like to talk more about the build and get a better
> understanding about project dependancies.
Actually if it's ok for everybody, I'd also move the dependencies of these
modules, so that we can at least have something that compiles and run a
couple of examples. Then we can start from that and start "breaking" things
to comply with the specs we already have (like deployment and content API)
and the ones we still have to write :) Otherwise nothing will compile and we
won't be to run any single thing.
So that would mean the following modules:
- Axis2 (IAPI implementation for Axis2)
- BPEL API (mostly DAO interfaces, IAPI interfaces, events, management API)
- BOM
- Compiler
- DD (deployment descriptors)
- XPath 1.0 and 2.0 support.
- Bpel-Obj (already in)
- Bpel-Parser (already in)
- Bpel-QL (query language for retrieving instances information, needed by
management API).
- Bpel runtime
- Bpel sechdule (quartz)
- Bpel schemas
- DAO-*
- Examples
- Jacob
- JBI
- Minerva (connection pool)
- Utils (already in)
That will give us a working basis to start removing the dependencies we
don't like, changing the things that don't comply to specs and so on. But
I'd find much more comfortable to start from something that builds and runs.
If you like I can then write something about build (actually nothing
special, only using Maven2) and dependencies.
What do you think?
Cheers,
Matthieu
Re: Roadmap: Update
Posted by Alex Boisvert <bo...@intalio.com>.
Lance Waterman wrote:
> I have been looking at the Jacob engine, BPEL runtime and BOM and feel
> comfortable with the implementations. I would be fine with moving
> these into
> the trunk. I would like to talk more about the build and get a better
> understanding about project dependancies. It seems like there is a lot in
> the pxe-iapi and I don't know what is required for the core
> implementation (
> i.e. Jacob, BOM, etc ... ) vs test ( i.e. JBI impl, SOAP impl ).
Cool! If you want to get an idea for the dependencies, take a look at
each pom.xml file in the subprojects. All dependencies are explicitly
declared in there.
For example, you'll see that "jacob" depends only on "utils". And
"bpel-runtime" depends on "bpel-api", "bpel-compiler", "bpel-obj",
"jacob", "utils", "stax", and "commons-collections". There's no
dependency on JBI, nor Axis2 for the BPEL runtime.
> 2) Remove Hibernate dependency: OpenJPA was suggested a while back. I
>> don't know what is the status of the project and when they expect to
>> produce a first release. Anybody wants to volunteer for an
>> investigation?
>
> Yes - we did agree on a persistence abstraction. I will volunteer to
> work on
> this.
Thanks for volunteering!
>> 6) Stateless processes: PXE offers non-persistent processes. Check.
>
> This is per process definition correct? I can have a stateful and
> stateless
> process running in the same engine configuration - correct?
Yes, persistence is defined on a per-process-definition basis, in the
deployment descriptor, and you can have both persistent and
non-persistent instances running on the same engine.
You can also configure whether process events are generated or persisted
on a per-process-definition basis. There's more info at
http://pxe.intalio.org/confluence/display/PXE/PXE+Execution+Events
>> 12) Tests: Still need to merge both BPE and PXE's test harnesseses. No
>> progress on common benchmark framework yet.
>
> As soon as I have a good feel for the build I will begin to merge in
> the BPE
> tests.
Ok, let us know if you need any help!
Also I forgot to mention, one thing we had discussed in the past but was
not represented on the roadmap was integration with the Quartz
scheduler. This is now implemented in the "bpel-scheduler-quartz" and
used in both integration layers.
cheers,
alex
Re: Roadmap: Update
Posted by Lance Waterman <la...@gmail.com>.
Hi Alex,
I'm out of the office for a couple of weeks but I have inlined some quick
thoughts.
On 7/11/06, Alex Boisvert < boisvert@intalio.com> wrote:
>
>
> Taking a look back at the roadmap we drafted back in March/April
> (http://wiki.apache.org/ode/RoadMap), here's my take on our progress so
> far:
>
> 1) Common Implementation: I think we're getting close. I'd like to
> hear what people think about moving ode/scratch/pxe-iapi to ode/trunk.
I have been looking at the Jacob engine, BPEL runtime and BOM and feel
comfortable with the implementations. I would be fine with moving these into
the trunk. I would like to talk more about the build and get a better
understanding about project dependancies. It seems like there is a lot in
the pxe-iapi and I don't know what is required for the core implementation (
i.e. Jacob, BOM, etc ... ) vs test ( i.e. JBI impl, SOAP impl ).
2) Remove Hibernate dependency: OpenJPA was suggested a while back. I
> don't know what is the status of the project and when they expect to
> produce a first release. Anybody wants to volunteer for an investigation?
Yes - we did agree on a persistence abstraction. I will volunteer to work on
this.
3) Data abstraction layer: We have Cory's Content API proposal in the
> scratch area. Maybe it's time to merge into the IAPI?
Agreed.
4) Deployment model: Lance recently submitted a proposal for
> discussion. Pending.
Matthieu has sent a deployment descriptor proposal that I will take a look
at.
5) BPEL 2.0: PXE implements BPEL 2.0. Check.
>
> 6) Stateless processes: PXE offers non-persistent processes. Check.
This is per process definition correct? I can have a stateful and stateless
process running in the same engine configuration - correct?
7) Debugging support: PXE provides line numbers for event generated
> during execution. Check.
>
> 8) Process Management API: PXE's management interfaces have been kept
> current, but will need updates following #4 above. Check.
>
> 9) Jacob: We have more documentation available and there's a proposal
> to make the terminology more intuitive. Do we need more
> examples/walkthrough's ?
Not in my opinion.
10) Integration API: We have an API with minimal dependencies and two
> implementations validating it. Check.
>
> 11) Synchronous transaction and asynchronous messaging: Semantics
> defined in IAPI. Check.
>
> 12) Tests: Still need to merge both BPE and PXE's test harnesseses. No
> progress on common benchmark framework yet.
As soon as I have a good feel for the build I will begin to merge in the BPE
tests.
Scorecard: 8 / 12 (assuming we score half-points for #3 and #4 until
> we reach closure)
>
> Overall, I believe we've been making steady progress on our shared
> roadmap and goals. Does this match with everybody's perspective?
Matchs with my perspective.
Any
> elephants in the room?
Not that I can see.
My take is we're reaching a point where moving
> to a common implementation (#1) would really help push the remaining
> items forward by rallying everybody around this shared codebase and
> stimulating tangible contributions -- whether small or large -- to be
> made directly in the codebase.
>
> alex
>
>