ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matth...@offthelip.org>
Subject Re: What's next for SCA & BPEL Integration
Date Thu, 24 Apr 2008 18:59:09 GMT
On Thu, Apr 24, 2008 at 10:41 AM, Luciano Resende <luckbr1975@gmail.com>
wrote:

> On Thu, Apr 24, 2008 at 8:53 AM, ant elder <ant.elder@gmail.com> wrote:
> > On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <luckbr1975@gmail.com>
> >  wrote:
> >
> >
> >  > Now that we are making more progress with the SCA & BPEL integration
> >  > and have figured out how to make References to work, let's discuss
> >  > what could be the next steps on this area. Below are couple examples
> >  > of what we could do next
> >  >
> >  > - WS-BPEL Process Introspection : Currently we are requiring SCA
> >  > componentType files, we could introspect the BPEL process file to
> >  > generate the component type information from it.
> >  >
> >  > - Integrate BEPL with the store scenario tutorial : We could add a
> >  > OrderProcessing step to the store checkout, and illustrate a more real
> >  > integration scenario.
> >  >
> >  > Other then these, we could review the
> >  > SCA_ClientAndImplementationModelFor BPEL and identify other areas that
> >  > we might need enhancements. Scenarios / Samples / Demos are always
> >  > welcome too. Or if you have other suggestions, feel free to jump to
> >  > the discussion.
> >  >
> >  > BTW: Copying the ODE list in case they want to jump and help, or in
> >  > case they have other ideas.
> >  >
> >  >
> >  Not a very exciting one but is there any clean up of the dependencies
> >  possible? Currently using the implementation.bpel extension brings in 78
> >  addition dependency jars at about 20meg, i wondered if some of those
> could
> >  get excluded?
> >
> >    ...ant
> >
>
> Part of this is because we have a Embedded ODE BPEL engine, and that
> itself brings several dependencies. But this is certainly something to
> investigate. It would be also good if ODE could be more
> flexible/dynamic with some dependencies (e.g Saxon) and only really
> require these dependencies if they are going to be in use, this would
> help our side as well.
>

Saxon is going to be hard to remove, there are very few BPEL processes that
won't need any XPath expressions to execute so I'm not sure it's one we can
save. But you're right for the embedded engine, right now we use our own
stuff for everything ODE needs to execute: connection pool, transaction
manager, jpa instance, thread pool, ... I'm guessing for many of these we
could reuse what comes with Tuscany.

Cheers,
Matthieu


>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>

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