You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Luciano Resende <lu...@gmail.com> on 2008/04/24 17:37:29 UTC
What's next for SCA & BPEL Integration
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.
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: What's next for SCA & BPEL Integration
Posted by Matthieu Riou <ma...@offthelip.org>.
On Thu, Apr 24, 2008 at 8:37 AM, Luciano Resende <lu...@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.
>
I was thinking about the deployment model as well. Right now you still need
a deploy.xml descriptor to tell ODE how to bind a partnerLink to a concrete
port. In an SCA context I'm thinking this should be handled by the
container.
Matthieu
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>
Re: What's next for SCA & BPEL Integration
Posted by Matthieu Riou <ma...@offthelip.org>.
On Thu, Apr 24, 2008 at 8:37 AM, Luciano Resende <lu...@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.
>
I was thinking about the deployment model as well. Right now you still need
a deploy.xml descriptor to tell ODE how to bind a partnerLink to a concrete
port. In an SCA context I'm thinking this should be handled by the
container.
Matthieu
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>
Re: What's next for SCA & BPEL Integration
Posted by Mike Edwards <mi...@gmail.com>.
Luciano Resende 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.
>
Luciano,
WS_BPEL Process introspection is top of my list. Having to write
componentType side files is a miserable business, particularly when all
the information you need is sitting there in the BPEL Process XML. The
Spring implementation is a good model - the Spring application context
is ripped through to produce the componentType and so side file is ever
needed.
A good BPEL sample is called for. One based on some order process seems
good to me. It should also involve the BPEL process making asynchronous
calls to back end services, which means stretching the support on
references to include callbacks.
We should consider integrating with the tutorial after building a good
standalone BPEL sample.
Yours, Mike.
Re: What's next for SCA & BPEL Integration
Posted by Mike Edwards <mi...@gmail.com>.
Luciano Resende 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.
>
Luciano,
WS_BPEL Process introspection is top of my list. Having to write
componentType side files is a miserable business, particularly when all
the information you need is sitting there in the BPEL Process XML. The
Spring implementation is a good model - the Spring application context
is ripped through to produce the componentType and so side file is ever
needed.
A good BPEL sample is called for. One based on some order process seems
good to me. It should also involve the BPEL process making asynchronous
calls to back end services, which means stretching the support on
references to include callbacks.
We should consider integrating with the tutorial after building a good
standalone BPEL sample.
Yours, Mike.
Re: What's next for SCA & BPEL Integration
Posted by Matthieu Riou <ma...@offthelip.org>.
On Thu, Apr 24, 2008 at 8:37 AM, Luciano Resende <lu...@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.
>
I was thinking about the deployment model as well. Right now you still need
a deploy.xml descriptor to tell ODE how to bind a partnerLink to a concrete
port. In an SCA context I'm thinking this should be handled by the
container.
Matthieu
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>
Re: What's next for SCA & BPEL Integration
Posted by Jean-Jacques Dubray <jd...@gmail.com>.
Luciano:
congrats on this milestone. You might also want to consider the other way
around, from an SCA component type, generate the skeleton BPEL
(send/receive/invokes, partner links...).
I am looking forward to build some samples with it !
JJ-
On Thu, Apr 24, 2008 at 8:37 AM, Luciano Resende <lu...@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.
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>
--
Jean-Jacques Dubray
425-445-4467
Re: What's next for SCA & BPEL Integration
Posted by Matthieu Riou <ma...@offthelip.org>.
On Thu, Apr 24, 2008 at 8:37 AM, Luciano Resende <lu...@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.
>
I was thinking about the deployment model as well. Right now you still need
a deploy.xml descriptor to tell ODE how to bind a partnerLink to a concrete
port. In an SCA context I'm thinking this should be handled by the
container.
Matthieu
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>
Re: What's next for SCA & BPEL Integration - component type update
done
Posted by Mike Edwards <mi...@gmail.com>.
Luciano Resende wrote:
> Cool Mike, this is very good improvement for the bpel impl...
>
> BTW, could you please check if you have committed one of the new model
> classes : BPELPartnerLinkTypeExt
>
> On Wed, May 7, 2008 at 2:19 PM, Mike Edwards
> <mi...@gmail.com> wrote:
Luciano,
The class BPELPartnerLinkExt is a new part of the interface-wsdl-xml module, which was committed
under 654287, separately from the changes to the implementation-bpel package.
BPELPartnerLinkExt is a class which handles the <partnerLinkType.../> elements which turn up as
extensions in WSDL documents, separate from the BPEL process documents.
I wrote a BPELExtensionHandler class to deal with reading & writing these elements as part of WSDL
documents and I have added this extension handler to the WSDLDocumentProcessor class, which does the
handling of WSDL files. I thought it was better to keep this stuff in the WSDL processing code -
there may be other extensions which we may well need to handle in WSDL files and I suspect it is
best to keep all the extensions in one place so that it is plain for everyone to see the full extent
of our WSDL handling.
I hope it all works - it could for sure do with some more testcases, especially error cases like
missing links between particular partnerLinks and the portTypes which define their interfaces.
Yours, Mike.
Re: What's next for SCA & BPEL Integration - component type update done
Posted by Luciano Resende <lu...@gmail.com>.
Cool Mike, this is very good improvement for the bpel impl...
BTW, could you please check if you have committed one of the new model
classes : BPELPartnerLinkTypeExt
On Wed, May 7, 2008 at 2:19 PM, Mike Edwards
<mi...@gmail.com> wrote:
> Jean-Sebastien Delfino wrote:
>>
>> Are you guys still making changes to the BPEL code?
>>
>> I'd like to be able to work with BPEL components in the domain without
>> having to boot the whole runtime. I'd like to do it sometime later this week
>> but for that to work I'll need to split implementation-bpel in two modules
>> (model and runtime) like we've already done for other implementation types.
>>
>> Is now a good time to do that split or is it going to conflict with the
>> changes you've been working on? Any chance you guys can commit your changes
>> to avoid complex merging? or should I make the split on the side in sandbox
>> to give you more time to work on this and then we merge later?
>>
>> Thanks
>
> Jean-Sebastien,
>
> OK, the component type introspection updates are done and committed under
> 654282.
>
> You're free to go do the split.
>
>
> Yours, Mike.
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: What's next for SCA & BPEL Integration - component type update
done
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Mike Edwards wrote:
> Jean-Sebastien Delfino wrote:
>> Are you guys still making changes to the BPEL code?
>>
>> I'd like to be able to work with BPEL components in the domain without
>> having to boot the whole runtime. I'd like to do it sometime later
>> this week but for that to work I'll need to split implementation-bpel
>> in two modules (model and runtime) like we've already done for other
>> implementation types.
>>
>> Is now a good time to do that split or is it going to conflict with
>> the changes you've been working on? Any chance you guys can commit
>> your changes to avoid complex merging? or should I make the split on
>> the side in sandbox to give you more time to work on this and then we
>> merge later?
>>
>> Thanks
>
> Jean-Sebastien,
>
> OK, the component type introspection updates are done and committed
> under 654282.
>
> You're free to go do the split.
>
>
> Yours, Mike.
Great, Thanks! I'll go and do it soon.
--
Jean-Sebastien
Re: What's next for SCA & BPEL Integration - component type update
done
Posted by Mike Edwards <mi...@gmail.com>.
Jean-Sebastien Delfino wrote:
> Are you guys still making changes to the BPEL code?
>
> I'd like to be able to work with BPEL components in the domain without
> having to boot the whole runtime. I'd like to do it sometime later this
> week but for that to work I'll need to split implementation-bpel in two
> modules (model and runtime) like we've already done for other
> implementation types.
>
> Is now a good time to do that split or is it going to conflict with the
> changes you've been working on? Any chance you guys can commit your
> changes to avoid complex merging? or should I make the split on the side
> in sandbox to give you more time to work on this and then we merge later?
>
> Thanks
Jean-Sebastien,
OK, the component type introspection updates are done and committed under 654282.
You're free to go do the split.
Yours, Mike.
Re: What's next for SCA & BPEL Integration
Posted by Mike Edwards <mi...@gmail.com>.
Jean-Sebastien Delfino wrote:
>
> Are you guys still making changes to the BPEL code?
>
> I'd like to be able to work with BPEL components in the domain without
> having to boot the whole runtime. I'd like to do it sometime later this
> week but for that to work I'll need to split implementation-bpel in two
> modules (model and runtime) like we've already done for other
> implementation types.
>
> Is now a good time to do that split or is it going to conflict with the
> changes you've been working on? Any chance you guys can commit your
> changes to avoid complex merging? or should I make the split on the side
> in sandbox to give you more time to work on this and then we merge later?
>
> Thanks
Jean-Sebastien,
Yes, I am changing the BPEL code to introspect the BPEL process to create the componentType.
It has taken longer than I hoped but I am nearly there now and I hope to commit the changes later
today. Please don't start the split work before I do that or you'll trash my work.
Yours, Mike.
Re: What's next for SCA & BPEL Integration
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Mike Edwards wrote:
> Ashwini Kumar Jeksani wrote:
>> Hi,
>>
>> Does Tuscany support SCA Extentions to WS-BPEL? If it doesn't then I
>> guess we could look into that one as well.
>>
>> Thanks & Regards
>> Ashwini Kumar Jeksani
>>
> Ashwini,
>
> Which extensions are thinking about?
>
> Currently I am working on code that scans the BPEL process and creates
> the SCA component type. I am handling the extra @service and @reference
> parameters, but there are other ones to do with multi-refs and with
> properties that I have not looked at. It is taking time because of the
> referenced WSDL files, which need careful scanning to find the
> partnerLinkType definitions and the associated PortType definitions.
>
> One BIG thing that you could do to help here is to start building some
> testcase BPEL + WSDL files that express these capabilities, that we can
> use to test out the code as we add the function.
>
>
> Yours, Mike.
Are you guys still making changes to the BPEL code?
I'd like to be able to work with BPEL components in the domain without
having to boot the whole runtime. I'd like to do it sometime later this
week but for that to work I'll need to split implementation-bpel in two
modules (model and runtime) like we've already done for other
implementation types.
Is now a good time to do that split or is it going to conflict with the
changes you've been working on? Any chance you guys can commit your
changes to avoid complex merging? or should I make the split on the side
in sandbox to give you more time to work on this and then we merge later?
Thanks
--
Jean-Sebastien
Re: What's next for SCA & BPEL Integration
Posted by Luciano Resende <lu...@gmail.com>.
This is great, various good ideas and various volunteers...
I'll raise JIRAs to better track progress with these items.
On Thu, May 1, 2008 at 11:22 AM, Jean-Sebastien Delfino
<js...@apache.org> wrote:
> Mike Edwards wrote:
>>
>> Ashwini Kumar Jeksani wrote:
>>>
>>> Hi,
>>>
>>> Does Tuscany support SCA Extentions to WS-BPEL? If it doesn't then I
>>> guess we could look into that one as well.
>>>
>>> Thanks & Regards
>>> Ashwini Kumar Jeksani
>>>
>> Ashwini,
>>
>> Which extensions are thinking about?
>>
>> Currently I am working on code that scans the BPEL process and creates the
>> SCA component type. I am handling the extra @service and @reference
>> parameters, but there are other ones to do with multi-refs and with
>> properties that I have not looked at. It is taking time because of the
>> referenced WSDL files, which need careful scanning to find the
>> partnerLinkType definitions and the associated PortType definitions.
>>
>> One BIG thing that you could do to help here is to start building some
>> testcase BPEL + WSDL files that express these capabilities, that we can use
>> to test out the code as we add the function.
>>
>>
>> Yours, Mike.
>
> Another thing is to split the implementation-bpel in at least two modules:
> - implementation-bpel - model, SCDL XML and componentType support
> - implementation-bpel-ode - integration with the BPEL runtime
>
> or three modules:
> - implementation-bpel - model
> - implementation-bpel-xml - SCDL XML support
> - implementation-bpel-ode - integration with the BPEL runtime
>
> This will allow SCA development, deployment, and management tools for
> example to use the BPEL implementation model to create, describe, deploy,
> wire BPEL components without dragging a dependency on the whole runtime.
>
> We've been through that with other extensions, you can find examples of this
> type of split in implementation-java-*, binding-ws-*, binding-atom-*,
> binding-sca-* etc.
>
> I can help with that work if you need help or have questions.
> --
> Jean-Sebastien
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: What's next for SCA & BPEL Integration
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Mike Edwards wrote:
> Ashwini Kumar Jeksani wrote:
>> Hi,
>>
>> Does Tuscany support SCA Extentions to WS-BPEL? If it doesn't then I
>> guess we could look into that one as well.
>>
>> Thanks & Regards
>> Ashwini Kumar Jeksani
>>
> Ashwini,
>
> Which extensions are thinking about?
>
> Currently I am working on code that scans the BPEL process and creates
> the SCA component type. I am handling the extra @service and @reference
> parameters, but there are other ones to do with multi-refs and with
> properties that I have not looked at. It is taking time because of the
> referenced WSDL files, which need careful scanning to find the
> partnerLinkType definitions and the associated PortType definitions.
>
> One BIG thing that you could do to help here is to start building some
> testcase BPEL + WSDL files that express these capabilities, that we can
> use to test out the code as we add the function.
>
>
> Yours, Mike.
Another thing is to split the implementation-bpel in at least two modules:
- implementation-bpel - model, SCDL XML and componentType support
- implementation-bpel-ode - integration with the BPEL runtime
or three modules:
- implementation-bpel - model
- implementation-bpel-xml - SCDL XML support
- implementation-bpel-ode - integration with the BPEL runtime
This will allow SCA development, deployment, and management tools for
example to use the BPEL implementation model to create, describe,
deploy, wire BPEL components without dragging a dependency on the whole
runtime.
We've been through that with other extensions, you can find examples of
this type of split in implementation-java-*, binding-ws-*,
binding-atom-*, binding-sca-* etc.
I can help with that work if you need help or have questions.
--
Jean-Sebastien
RE: What's next for SCA & BPEL Integration
Posted by Ashwini Kumar Jeksani <As...@infosys.com>.
Ok mike. I will try to create the test cases for testing the generation of component types from the bpel processes.
Could you tell me if there is any standard format/template that you use in Tuscany for writing test cases.
Thanks & Regards
Ashwini Kumar Jeksani
-----Original Message-----
From: Mike Edwards [mailto:mike.edwards.inglenook@gmail.com]
Sent: Monday, April 28, 2008 8:41 PM
To: tuscany-dev@ws.apache.org
Subject: Re: What's next for SCA & BPEL Integration
Ashwini Kumar Jeksani wrote:
> Hi,
>
> Does Tuscany support SCA Extentions to WS-BPEL? If it doesn't then I guess we could look into that one as well.
>
> Thanks & Regards
> Ashwini Kumar Jeksani
>
Ashwini,
Which extensions are thinking about?
Currently I am working on code that scans the BPEL process and creates
the SCA component type. I am handling the extra @service and @reference
parameters, but there are other ones to do with multi-refs and with
properties that I have not looked at. It is taking time because of the
referenced WSDL files, which need careful scanning to find the
partnerLinkType definitions and the associated PortType definitions.
One BIG thing that you could do to help here is to start building some
testcase BPEL + WSDL files that express these capabilities, that we can
use to test out the code as we add the function.
Yours, Mike.
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
Re: What's next for SCA & BPEL Integration
Posted by Mike Edwards <mi...@gmail.com>.
Ashwini Kumar Jeksani wrote:
> Hi,
>
> Does Tuscany support SCA Extentions to WS-BPEL? If it doesn't then I guess we could look into that one as well.
>
> Thanks & Regards
> Ashwini Kumar Jeksani
>
Ashwini,
Which extensions are thinking about?
Currently I am working on code that scans the BPEL process and creates
the SCA component type. I am handling the extra @service and @reference
parameters, but there are other ones to do with multi-refs and with
properties that I have not looked at. It is taking time because of the
referenced WSDL files, which need careful scanning to find the
partnerLinkType definitions and the associated PortType definitions.
One BIG thing that you could do to help here is to start building some
testcase BPEL + WSDL files that express these capabilities, that we can
use to test out the code as we add the function.
Yours, Mike.
RE: What's next for SCA & BPEL Integration
Posted by Ashwini Kumar Jeksani <As...@infosys.com>.
Hi,
Does Tuscany support SCA Extentions to WS-BPEL? If it doesn't then I guess we could look into that one as well.
Thanks & Regards
Ashwini Kumar Jeksani
-----Original Message-----
From: Luciano Resende [mailto:luckbr1975@gmail.com]
Sent: Thursday, April 24, 2008 11:11 PM
To: tuscany-dev@ws.apache.org; antelder@apache.org
Cc: tuscany-user@ws.apache.org; dev@ode.apache.org; user@ode.apache.org
Subject: Re: What's next for SCA & BPEL Integration
On Thu, Apr 24, 2008 at 8:53 AM, ant elder <an...@gmail.com> wrote:
> On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <lu...@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.
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
Re: What's next for SCA & BPEL Integration
Posted by ant elder <an...@gmail.com>.
On Fri, Apr 25, 2008 at 11:44 AM, Mike Edwards <
mike.edwards.inglenook@gmail.com> wrote:
> ant elder wrote:
>
>>
>>> These are all the additional dependencies brought in with the Tuscany
>> implementation.bpel extension, are any of them obviously not necessary?
>>
>> activeio-2.0-r118.jar
>> axion-1.0-M3-dev.jar
>> backport-util-concurrent-3.0.jar
>> common-2.2.3.jar
>> commons-codec-1.3.jar
>> commons-collections-3.1.jar
>> commons-jexl-1.1.jar
>> commons-lang-2.1.jar
>> commons-logging-1.0.4.jar
>> commons-primitives-1.0.jar
>> derby-10.3.1.4.jar
>> dom4j-1.6.1.jar
>> ecore-2.2.3.jar
>> ecore-change-2.2.3.jar
>> ecore-xmi-2.2.3.jar
>> geronimo-common-1.2-beta.jar
>> geronimo-connector-1.2-beta.jar
>> geronimo-core-1.2-beta.jar
>> geronimo-deployment-1.2-beta.jar
>> geronimo-ejb_3.0_spec-1.0.jar
>> geronimo-interceptor-1.2-beta.jar
>> geronimo-j2ee-1.2-beta.jar
>> geronimo-j2ee-connector_1.5_spec-1.1.jar
>> geronimo-j2ee-jacc_1.0_spec-1.1.jar
>> geronimo-j2ee-management_1.0_spec-1.1.jar
>> geronimo-jpa_3.0_spec-1.0.jar
>> geronimo-jta_1.0.1B_spec-1.0.jar
>> geronimo-kernel-1.2-beta.jar
>> geronimo-management-1.2-beta.jar
>> geronimo-naming-1.2-beta.jar
>> geronimo-security-1.2-beta.jar
>> geronimo-spec-j2ee-connector-1.5-rc4.jar
>> geronimo-spec-jta-1.0.1B-rc4.jar
>> geronimo-system-1.2-beta.jar
>> geronimo-transaction-1.2-beta.jar
>> geronimo-util-1.2-beta.jar
>> howl-1.0.1-1.jar
>> icu4j-2.6.1.jar
>> javacc-3.2.jar
>> jaxen-1.1.1.jar
>> jdom-1.0.jar
>> log4j-1.2.13.jar
>> ode-bpel-api-1.1.jar
>> ode-bpel-compiler-1.1.jar
>> ode-bpel-dao-1.1.jar
>> ode-bpel-epr-1.1.jar
>> ode-bpel-obj-1.1.jar
>> ode-bpel-runtime-1.1.jar
>> ode-bpel-schemas-1.1.jar
>> ode-bpel-store-1.1.jar
>> ode-dao-jpa-1.1.jar
>> ode-jacob-1.1.jar
>> ode-jacob-ap-1.1.jar
>> ode-scheduler-simple-1.1.jar
>> ode-utils-1.1.jar
>> openjpa-all-0.9.7-incubating.jar
>> openjpa-persistence-0.9.7-incubating.jar
>> org.apache.felix.bundlerepository-1.0.0.jar
>> org.apache.felix.framework-1.0.1.jar
>> org.apache.felix.main-1.0.1.jar
>> org.apache.felix.shell-1.0.0.jar
>> org.apache.felix.shell.tui-1.0.0.jar
>> regexp-1.3.jar
>> saxon-8.7.jar
>> saxon-dom-8.7.jar
>> saxon-xpath-8.7.jar
>> serp-1.12.0.jar
>> tranql-connector-1.1.jar
>> tuscany-databinding-sdo-2.0-incubating-SNAPSHOT.jar
>> tuscany-implementation-bpel-2.0-incubating-SNAPSHOT.jar
>> xalan-2.7.0.jar
>> xbean-naming-2.7.jar
>> xercesImpl-2.8.1.jar
>> xml-apis-1.3.02.jar
>> xml-resolver-1.1.jar
>> xmlbeans-2.3.0.jar
>> xmlParserAPIs-2.6.2.jar
>> XmlSchema-1.3.2.jar
>> xom-1.0.jar
>> xsd-2.2.3.jar
>>
>> ...ant
>>
>> I suggest that we get the functionality of <implementation.bpel.../>
> working first before we start to worry about the amount of clobber that it
> involves. It is barely working at the moment.
>
>
Fair enough, I've not tried using it yet so didn't realize it was still so
rough.
...ant
Re: What's next for SCA & BPEL Integration
Posted by Mike Edwards <mi...@gmail.com>.
ant elder wrote:
>>
> These are all the additional dependencies brought in with the Tuscany
> implementation.bpel extension, are any of them obviously not necessary?
>
> activeio-2.0-r118.jar
> axion-1.0-M3-dev.jar
> backport-util-concurrent-3.0.jar
> common-2.2.3.jar
> commons-codec-1.3.jar
> commons-collections-3.1.jar
> commons-jexl-1.1.jar
> commons-lang-2.1.jar
> commons-logging-1.0.4.jar
> commons-primitives-1.0.jar
> derby-10.3.1.4.jar
> dom4j-1.6.1.jar
> ecore-2.2.3.jar
> ecore-change-2.2.3.jar
> ecore-xmi-2.2.3.jar
> geronimo-common-1.2-beta.jar
> geronimo-connector-1.2-beta.jar
> geronimo-core-1.2-beta.jar
> geronimo-deployment-1.2-beta.jar
> geronimo-ejb_3.0_spec-1.0.jar
> geronimo-interceptor-1.2-beta.jar
> geronimo-j2ee-1.2-beta.jar
> geronimo-j2ee-connector_1.5_spec-1.1.jar
> geronimo-j2ee-jacc_1.0_spec-1.1.jar
> geronimo-j2ee-management_1.0_spec-1.1.jar
> geronimo-jpa_3.0_spec-1.0.jar
> geronimo-jta_1.0.1B_spec-1.0.jar
> geronimo-kernel-1.2-beta.jar
> geronimo-management-1.2-beta.jar
> geronimo-naming-1.2-beta.jar
> geronimo-security-1.2-beta.jar
> geronimo-spec-j2ee-connector-1.5-rc4.jar
> geronimo-spec-jta-1.0.1B-rc4.jar
> geronimo-system-1.2-beta.jar
> geronimo-transaction-1.2-beta.jar
> geronimo-util-1.2-beta.jar
> howl-1.0.1-1.jar
> icu4j-2.6.1.jar
> javacc-3.2.jar
> jaxen-1.1.1.jar
> jdom-1.0.jar
> log4j-1.2.13.jar
> ode-bpel-api-1.1.jar
> ode-bpel-compiler-1.1.jar
> ode-bpel-dao-1.1.jar
> ode-bpel-epr-1.1.jar
> ode-bpel-obj-1.1.jar
> ode-bpel-runtime-1.1.jar
> ode-bpel-schemas-1.1.jar
> ode-bpel-store-1.1.jar
> ode-dao-jpa-1.1.jar
> ode-jacob-1.1.jar
> ode-jacob-ap-1.1.jar
> ode-scheduler-simple-1.1.jar
> ode-utils-1.1.jar
> openjpa-all-0.9.7-incubating.jar
> openjpa-persistence-0.9.7-incubating.jar
> org.apache.felix.bundlerepository-1.0.0.jar
> org.apache.felix.framework-1.0.1.jar
> org.apache.felix.main-1.0.1.jar
> org.apache.felix.shell-1.0.0.jar
> org.apache.felix.shell.tui-1.0.0.jar
> regexp-1.3.jar
> saxon-8.7.jar
> saxon-dom-8.7.jar
> saxon-xpath-8.7.jar
> serp-1.12.0.jar
> tranql-connector-1.1.jar
> tuscany-databinding-sdo-2.0-incubating-SNAPSHOT.jar
> tuscany-implementation-bpel-2.0-incubating-SNAPSHOT.jar
> xalan-2.7.0.jar
> xbean-naming-2.7.jar
> xercesImpl-2.8.1.jar
> xml-apis-1.3.02.jar
> xml-resolver-1.1.jar
> xmlbeans-2.3.0.jar
> xmlParserAPIs-2.6.2.jar
> XmlSchema-1.3.2.jar
> xom-1.0.jar
> xsd-2.2.3.jar
>
> ...ant
>
I suggest that we get the functionality of <implementation.bpel.../>
working first before we start to worry about the amount of clobber that
it involves. It is barely working at the moment.
I admit that the amount of code is alarming, but we shall have to work
with other groups to find out what could be removed without harm. That
is a longer-term task.
Yours, Mike.
Re: What's next for SCA & BPEL Integration
Posted by ant elder <an...@apache.org>.
On Thu, Apr 24, 2008 at 7:59 PM, Matthieu Riou <ma...@offthelip.org>
wrote:
> On Thu, Apr 24, 2008 at 10:41 AM, Luciano Resende <lu...@gmail.com>
> wrote:
>
> > On Thu, Apr 24, 2008 at 8:53 AM, ant elder <an...@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.
>
>
These are all the additional dependencies brought in with the Tuscany
implementation.bpel extension, are any of them obviously not necessary?
activeio-2.0-r118.jar
axion-1.0-M3-dev.jar
backport-util-concurrent-3.0.jar
common-2.2.3.jar
commons-codec-1.3.jar
commons-collections-3.1.jar
commons-jexl-1.1.jar
commons-lang-2.1.jar
commons-logging-1.0.4.jar
commons-primitives-1.0.jar
derby-10.3.1.4.jar
dom4j-1.6.1.jar
ecore-2.2.3.jar
ecore-change-2.2.3.jar
ecore-xmi-2.2.3.jar
geronimo-common-1.2-beta.jar
geronimo-connector-1.2-beta.jar
geronimo-core-1.2-beta.jar
geronimo-deployment-1.2-beta.jar
geronimo-ejb_3.0_spec-1.0.jar
geronimo-interceptor-1.2-beta.jar
geronimo-j2ee-1.2-beta.jar
geronimo-j2ee-connector_1.5_spec-1.1.jar
geronimo-j2ee-jacc_1.0_spec-1.1.jar
geronimo-j2ee-management_1.0_spec-1.1.jar
geronimo-jpa_3.0_spec-1.0.jar
geronimo-jta_1.0.1B_spec-1.0.jar
geronimo-kernel-1.2-beta.jar
geronimo-management-1.2-beta.jar
geronimo-naming-1.2-beta.jar
geronimo-security-1.2-beta.jar
geronimo-spec-j2ee-connector-1.5-rc4.jar
geronimo-spec-jta-1.0.1B-rc4.jar
geronimo-system-1.2-beta.jar
geronimo-transaction-1.2-beta.jar
geronimo-util-1.2-beta.jar
howl-1.0.1-1.jar
icu4j-2.6.1.jar
javacc-3.2.jar
jaxen-1.1.1.jar
jdom-1.0.jar
log4j-1.2.13.jar
ode-bpel-api-1.1.jar
ode-bpel-compiler-1.1.jar
ode-bpel-dao-1.1.jar
ode-bpel-epr-1.1.jar
ode-bpel-obj-1.1.jar
ode-bpel-runtime-1.1.jar
ode-bpel-schemas-1.1.jar
ode-bpel-store-1.1.jar
ode-dao-jpa-1.1.jar
ode-jacob-1.1.jar
ode-jacob-ap-1.1.jar
ode-scheduler-simple-1.1.jar
ode-utils-1.1.jar
openjpa-all-0.9.7-incubating.jar
openjpa-persistence-0.9.7-incubating.jar
org.apache.felix.bundlerepository-1.0.0.jar
org.apache.felix.framework-1.0.1.jar
org.apache.felix.main-1.0.1.jar
org.apache.felix.shell-1.0.0.jar
org.apache.felix.shell.tui-1.0.0.jar
regexp-1.3.jar
saxon-8.7.jar
saxon-dom-8.7.jar
saxon-xpath-8.7.jar
serp-1.12.0.jar
tranql-connector-1.1.jar
tuscany-databinding-sdo-2.0-incubating-SNAPSHOT.jar
tuscany-implementation-bpel-2.0-incubating-SNAPSHOT.jar
xalan-2.7.0.jar
xbean-naming-2.7.jar
xercesImpl-2.8.1.jar
xml-apis-1.3.02.jar
xml-resolver-1.1.jar
xmlbeans-2.3.0.jar
xmlParserAPIs-2.6.2.jar
XmlSchema-1.3.2.jar
xom-1.0.jar
xsd-2.2.3.jar
...ant
Re: What's next for SCA & BPEL Integration
Posted by ant elder <an...@apache.org>.
On Thu, Apr 24, 2008 at 7:59 PM, Matthieu Riou <ma...@offthelip.org>
wrote:
> On Thu, Apr 24, 2008 at 10:41 AM, Luciano Resende <lu...@gmail.com>
> wrote:
>
> > On Thu, Apr 24, 2008 at 8:53 AM, ant elder <an...@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.
>
>
These are all the additional dependencies brought in with the Tuscany
implementation.bpel extension, are any of them obviously not necessary?
activeio-2.0-r118.jar
axion-1.0-M3-dev.jar
backport-util-concurrent-3.0.jar
common-2.2.3.jar
commons-codec-1.3.jar
commons-collections-3.1.jar
commons-jexl-1.1.jar
commons-lang-2.1.jar
commons-logging-1.0.4.jar
commons-primitives-1.0.jar
derby-10.3.1.4.jar
dom4j-1.6.1.jar
ecore-2.2.3.jar
ecore-change-2.2.3.jar
ecore-xmi-2.2.3.jar
geronimo-common-1.2-beta.jar
geronimo-connector-1.2-beta.jar
geronimo-core-1.2-beta.jar
geronimo-deployment-1.2-beta.jar
geronimo-ejb_3.0_spec-1.0.jar
geronimo-interceptor-1.2-beta.jar
geronimo-j2ee-1.2-beta.jar
geronimo-j2ee-connector_1.5_spec-1.1.jar
geronimo-j2ee-jacc_1.0_spec-1.1.jar
geronimo-j2ee-management_1.0_spec-1.1.jar
geronimo-jpa_3.0_spec-1.0.jar
geronimo-jta_1.0.1B_spec-1.0.jar
geronimo-kernel-1.2-beta.jar
geronimo-management-1.2-beta.jar
geronimo-naming-1.2-beta.jar
geronimo-security-1.2-beta.jar
geronimo-spec-j2ee-connector-1.5-rc4.jar
geronimo-spec-jta-1.0.1B-rc4.jar
geronimo-system-1.2-beta.jar
geronimo-transaction-1.2-beta.jar
geronimo-util-1.2-beta.jar
howl-1.0.1-1.jar
icu4j-2.6.1.jar
javacc-3.2.jar
jaxen-1.1.1.jar
jdom-1.0.jar
log4j-1.2.13.jar
ode-bpel-api-1.1.jar
ode-bpel-compiler-1.1.jar
ode-bpel-dao-1.1.jar
ode-bpel-epr-1.1.jar
ode-bpel-obj-1.1.jar
ode-bpel-runtime-1.1.jar
ode-bpel-schemas-1.1.jar
ode-bpel-store-1.1.jar
ode-dao-jpa-1.1.jar
ode-jacob-1.1.jar
ode-jacob-ap-1.1.jar
ode-scheduler-simple-1.1.jar
ode-utils-1.1.jar
openjpa-all-0.9.7-incubating.jar
openjpa-persistence-0.9.7-incubating.jar
org.apache.felix.bundlerepository-1.0.0.jar
org.apache.felix.framework-1.0.1.jar
org.apache.felix.main-1.0.1.jar
org.apache.felix.shell-1.0.0.jar
org.apache.felix.shell.tui-1.0.0.jar
regexp-1.3.jar
saxon-8.7.jar
saxon-dom-8.7.jar
saxon-xpath-8.7.jar
serp-1.12.0.jar
tranql-connector-1.1.jar
tuscany-databinding-sdo-2.0-incubating-SNAPSHOT.jar
tuscany-implementation-bpel-2.0-incubating-SNAPSHOT.jar
xalan-2.7.0.jar
xbean-naming-2.7.jar
xercesImpl-2.8.1.jar
xml-apis-1.3.02.jar
xml-resolver-1.1.jar
xmlbeans-2.3.0.jar
xmlParserAPIs-2.6.2.jar
XmlSchema-1.3.2.jar
xom-1.0.jar
xsd-2.2.3.jar
...ant
Re: What's next for SCA & BPEL Integration
Posted by Matthieu Riou <ma...@offthelip.org>.
On Thu, Apr 24, 2008 at 10:41 AM, Luciano Resende <lu...@gmail.com>
wrote:
> On Thu, Apr 24, 2008 at 8:53 AM, ant elder <an...@gmail.com> wrote:
> > On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <lu...@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/
>
Re: What's next for SCA & BPEL Integration
Posted by Matthieu Riou <ma...@offthelip.org>.
On Thu, Apr 24, 2008 at 10:41 AM, Luciano Resende <lu...@gmail.com>
wrote:
> On Thu, Apr 24, 2008 at 8:53 AM, ant elder <an...@gmail.com> wrote:
> > On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <lu...@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/
>
RE: What's next for SCA & BPEL Integration
Posted by Ashwini Kumar Jeksani <As...@infosys.com>.
Hi,
Does Tuscany support SCA Extentions to WS-BPEL? If it doesn't then I guess we could look into that one as well.
Thanks & Regards
Ashwini Kumar Jeksani
-----Original Message-----
From: Luciano Resende [mailto:luckbr1975@gmail.com]
Sent: Thursday, April 24, 2008 11:11 PM
To: tuscany-dev@ws.apache.org; antelder@apache.org
Cc: tuscany-user@ws.apache.org; dev@ode.apache.org; user@ode.apache.org
Subject: Re: What's next for SCA & BPEL Integration
On Thu, Apr 24, 2008 at 8:53 AM, ant elder <an...@gmail.com> wrote:
> On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <lu...@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.
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
Re: What's next for SCA & BPEL Integration
Posted by Matthieu Riou <ma...@offthelip.org>.
On Thu, Apr 24, 2008 at 10:41 AM, Luciano Resende <lu...@gmail.com>
wrote:
> On Thu, Apr 24, 2008 at 8:53 AM, ant elder <an...@gmail.com> wrote:
> > On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <lu...@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/
>
RE: What's next for SCA & BPEL Integration
Posted by Ashwini Kumar Jeksani <As...@infosys.com>.
Hi,
Does Tuscany support SCA Extentions to WS-BPEL? If it doesn't then I guess we could look into that one as well.
Thanks & Regards
Ashwini Kumar Jeksani
-----Original Message-----
From: Luciano Resende [mailto:luckbr1975@gmail.com]
Sent: Thursday, April 24, 2008 11:11 PM
To: tuscany-dev@ws.apache.org; antelder@apache.org
Cc: tuscany-user@ws.apache.org; dev@ode.apache.org; user@ode.apache.org
Subject: Re: What's next for SCA & BPEL Integration
On Thu, Apr 24, 2008 at 8:53 AM, ant elder <an...@gmail.com> wrote:
> On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <lu...@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.
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
Re: What's next for SCA & BPEL Integration
Posted by Matthieu Riou <ma...@offthelip.org>.
On Thu, Apr 24, 2008 at 10:41 AM, Luciano Resende <lu...@gmail.com>
wrote:
> On Thu, Apr 24, 2008 at 8:53 AM, ant elder <an...@gmail.com> wrote:
> > On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <lu...@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/
>
RE: What's next for SCA & BPEL Integration
Posted by Ashwini Kumar Jeksani <As...@infosys.com>.
Hi,
Does Tuscany support SCA Extentions to WS-BPEL? If it doesn't then I guess we could look into that one as well.
Thanks & Regards
Ashwini Kumar Jeksani
-----Original Message-----
From: Luciano Resende [mailto:luckbr1975@gmail.com]
Sent: Thursday, April 24, 2008 11:11 PM
To: tuscany-dev@ws.apache.org; antelder@apache.org
Cc: tuscany-user@ws.apache.org; dev@ode.apache.org; user@ode.apache.org
Subject: Re: What's next for SCA & BPEL Integration
On Thu, Apr 24, 2008 at 8:53 AM, ant elder <an...@gmail.com> wrote:
> On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <lu...@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.
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
Re: What's next for SCA & BPEL Integration
Posted by Luciano Resende <lu...@gmail.com>.
On Thu, Apr 24, 2008 at 8:53 AM, ant elder <an...@gmail.com> wrote:
> On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <lu...@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.
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: What's next for SCA & BPEL Integration
Posted by Luciano Resende <lu...@gmail.com>.
On Thu, Apr 24, 2008 at 8:53 AM, ant elder <an...@gmail.com> wrote:
> On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <lu...@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.
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: What's next for SCA & BPEL Integration
Posted by Luciano Resende <lu...@gmail.com>.
On Thu, Apr 24, 2008 at 8:53 AM, ant elder <an...@gmail.com> wrote:
> On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <lu...@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.
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: What's next for SCA & BPEL Integration
Posted by Luciano Resende <lu...@gmail.com>.
On Thu, Apr 24, 2008 at 8:53 AM, ant elder <an...@gmail.com> wrote:
> On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <lu...@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.
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: What's next for SCA & BPEL Integration
Posted by ant elder <an...@gmail.com>.
On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <lu...@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
Re: What's next for SCA & BPEL Integration
Posted by ant elder <an...@gmail.com>.
On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <lu...@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
Re: What's next for SCA & BPEL Integration
Posted by Mike Edwards <mi...@gmail.com>.
Luciano Resende 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.
>
Luciano,
WS_BPEL Process introspection is top of my list. Having to write
componentType side files is a miserable business, particularly when all
the information you need is sitting there in the BPEL Process XML. The
Spring implementation is a good model - the Spring application context
is ripped through to produce the componentType and so side file is ever
needed.
A good BPEL sample is called for. One based on some order process seems
good to me. It should also involve the BPEL process making asynchronous
calls to back end services, which means stretching the support on
references to include callbacks.
We should consider integrating with the tutorial after building a good
standalone BPEL sample.
Yours, Mike.
Re: What's next for SCA & BPEL Integration
Posted by ant elder <an...@gmail.com>.
On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <lu...@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
Re: What's next for SCA & BPEL Integration
Posted by Mike Edwards <mi...@gmail.com>.
Luciano Resende 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.
>
Luciano,
WS_BPEL Process introspection is top of my list. Having to write
componentType side files is a miserable business, particularly when all
the information you need is sitting there in the BPEL Process XML. The
Spring implementation is a good model - the Spring application context
is ripped through to produce the componentType and so side file is ever
needed.
A good BPEL sample is called for. One based on some order process seems
good to me. It should also involve the BPEL process making asynchronous
calls to back end services, which means stretching the support on
references to include callbacks.
We should consider integrating with the tutorial after building a good
standalone BPEL sample.
Yours, Mike.
Re: What's next for SCA & BPEL Integration
Posted by ant elder <an...@gmail.com>.
On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <lu...@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