Re: Build failure in helloworld-bpel sample

[Matthieu Riou]

I guess that would be me as the fix I did outlined another issue (as
described in the thread Luciano pointed at). So you guys expect to always
have all the tests passing on trunk all the time?

Cheers,
Matthieu

On Thu, Jun 5, 2008 at 12:57 PM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

> Folks,
>
> Someone has updated the code in SVN since this afternoon - so I am
> investigating.
>
>
> Yours,  Mike.
>
>
> Mike Edwards wrote:
>
>> Simon,
>>
>> I did an SVN update and build of Tuscany earlier this afternoon and I did
>> not see this failure.
>>
>> The code currently checked in to the Tuscany SVN was fixed up to avoid the
>> error listed by Luciano and certainly seems to work for me.
>>
>> Is anyone else seeing the same problem that Simon is getting?
>>
>>
>> Yours,  Mike.
>>
>> Simon Nash wrote:
>>
>>> I did a recent svn update and rebuild and I'm seeing the following test
>>> error from the helloworld-bpel sample.  Are other people seeing this?
>>> Any ideas?
>>>
>>>  Simon
>>>
>>> Running helloworld.BPELHelloWorldTestCase
>>> Completed calling new Process deployment code...
>>> Invoking bpel component : {http://tuscany.apache.org
>>> }helloPartnerLink#hello
>>> Creating invocation message:
>>>  >> args.: 
>>> http://tuscany.apache.org/implementation/bpel/example/helloworld.w
>>> sdl">Hello
>>>  >> message..:
>>> http://tuscany.apache.org/implementation/bpel/e
>>> xample/helloworld.wsdl">Hello
>>>
>>>  >>>Invocation status:RESPONSE
>>>  >>>Response:
>>> 
>>> http://tuscany.apache.org/implementation/bpel/e
>>> xample/helloworld.wsdl">Hello
>>> World>> ge>
>>>  >>>Response:
>>> 
>>> http://tuscany.apache.org/implementation/bpel/e
>>> xample/helloworld.wsdl">Hello
>>> World>> ge>
>>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.512 sec
>>> <<< FA
>>> ILURE!
>>> testInvoke(helloworld.BPELHelloWorldTestCase)  Time elapsed: 9.494 sec
>>>  <<< ERRO
>>> R!
>>> junit.framework.ComparisonFailure: expected: but was:<>
>>>at junit.framework.Assert.assertEquals(Assert.java:81)
>>>at junit.framework.Assert.assertEquals(Assert.java:87)
>>>at
>>> helloworld.BPELHelloWorldTestCase.testInvoke(BPELHelloWorldTestCase.j
>>> ava:57)
>>>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
>>> java:39)
>>>at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
>>> sorImpl.java:25)
>>>at java.lang.reflect.Method.invoke(Method.java:585)
>>>at junit.framework.TestCase.runTest(TestCase.java:154)
>>>at junit.framework.TestCase.runBare(TestCase.java:127)
>>>at junit.framework.TestResult$1.protect(TestResult.java:106)
>>>at junit.framework.TestResult.runProtected(TestResult.java:124)
>>>at junit.framework.TestResult.run(TestResult.java:109)
>>>at junit.framework.TestCase.run(TestCase.java:118)
>>>at junit.framework.TestSuite.runTest(TestSuite.java:208)
>>>at junit.framework.TestSuite.run(TestSuite.java:203)
>>>at
>>> org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.
>>> java:35)
>>>at
>>> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.
>>> java:62)
>>>at
>>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes
>>> tSet(AbstractDirectoryTestSuite.java:138)
>>>at
>>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab
>>> stractDirectoryTestSuite.java:125)
>>>at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
>>>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
>>> java:39)
>>>at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
>>> sorImpl.java:25)
>>>at java.lang.reflect.Method.invoke(Method.java:585)
>>>at
>>> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su
>>> refireBooter.java:308)
>>>at
>>> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j
>>> ava:879)
>>>
>>>
>>> Results :
>>>
>>> Tests in error:
>>>  testInvoke(helloworld.BPELHelloWorldTestCase)
>>>
>>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
>>>
>>>
>>>
>>
>>
>

Re: [Fwd: Re: SCA BPEL - Problems with ODE - Help requested]

[Matthieu Riou]

On Thu, Jun 5, 2008 at 12:38 PM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

> Matthieu,
>
> First - many thanks for your hard work on this.
>
> I take no pleasure in saying this, but I am glad that the DB problem was
> ODE's problem rather than Tuscany's - it looks like you are far more
> experienced in handling that area of code!
>
> Regarding that remaining error, which is generated by Tuscany.  I am
> assuming that this is the same error that I examined previously when using
> the TuscanyProcessConfImpl rather than the ODE ProcessConfImpl - namely that
> the returned data structure from ODE is simply different - and I believe it
> is in error - as the top level element is of a different type: - quoting
> from my previous email, in the case of using the TuscanyProcessConfImpl:
>

Actually I think it's a different problem even if the symptom looks
identical (as I mentioned, I fixed the process). First, it always break in
the same way, whether the process is transient or not (which is reassuring).
Second, the message looks good to me this time:

>>>Response:

http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl";>Hello
World

The namespaces of the  and the  elements seem correct. Don't
you think?

Cheers,
Matthieu



>
>
> "When we switch to using the Tuscany ProcessConfImpl - with its "transient"
> setting, when we invoke the same process, we get back a different type of
> object - an "ElementImpl" named "TestPart".  This contains an ElementNSImpl
> object named "hello" containing a TextImpl child holding "Hello World". This
> structural layout is clearly different to the previous case - and is wrong -
> it isn't what is expected."
>
> To explain futher, the direct cause of that exception you list is the fact
> that the top level element returned - the ElementImpl - does NOT have a
> namespace declared (I believe that it should be an ElementNSImpl) - and it
> is the lack of the NS that is at the root of the "null" exception that
> Tuscany returns.  I note that this is NOT the same data structure that is
> returned by ODE when the ODE ProcessConfImpl is used - that data structure
> IS headed by a DeferredElementNSImpl (the deferred aspect isn't important,
> but the "NS" aspect very much is important).
>
> I could not determine why there was this difference in the data structure
> returned.  I'll have another check using your fixed version of the code -
> but it would be useful if you could give me a clue about where in the ODE
> code this data element is being generated - it is very hard to trace.
>
>
>
> Yours,  Mike.
>
> PS - I assume that I need to take a latest build from the ODE SVN to get
> your fixes for the DB problem?
>
>
> Matthieu Riou wrote:
>
>> Okay, this took a while because it was actually far trickier than I
>> expected. Here were the two problems (the first being the serious one):
>>
>>  * When OpenJPA first connects to the DB it initializes its sequence table
>> and does it using a different connection. It's fine when it's done in
>> isolation (like at startup) but with Derby, when a transaction that
>> creates
>> stuff gets executed, it causes a lock timeout because the two connections
>> are competing to set a value. To fix this I've set a little parameters
>> (all
>> that time for a single line fix...) that forces the initialization when we
>> start the engine.
>>
>>  * The HelloWorld process assignment was actually setting a variable that
>> wasn't structured properly when checking the message schema. I updated the
>> assignment.
>>
>> So now we get the proper message in and out. I still have one last
>> problem,
>> when the message gets back to Tuscany I get:
>>
>> org.apache.tuscany.sca.databinding.TransformationException:
>> java.lang.IllegalArgumentException: local part cannot be "null" when
>> creating a QName
>>at
>>
>> org.apache.tuscany.sca.core.databinding.transformers.Output2OutputTransformer.transform(Output2OutputTransformer.java:215)
>>at
>>
>> org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:79)
>>at
>>
>> org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:186)
>>at
>>
>> org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:169)
>>at
>>
>> org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvok

Re: [Fwd: Re: SCA BPEL - Problems with ODE - Help requested]

[Matthieu Riou]

Okay, this took a while because it was actually far trickier than I
expected. Here were the two problems (the first being the serious one):

 * When OpenJPA first connects to the DB it initializes its sequence table
and does it using a different connection. It's fine when it's done in
isolation (like at startup) but with Derby, when a transaction that creates
stuff gets executed, it causes a lock timeout because the two connections
are competing to set a value. To fix this I've set a little parameters (all
that time for a single line fix...) that forces the initialization when we
start the engine.

 * The HelloWorld process assignment was actually setting a variable that
wasn't structured properly when checking the message schema. I updated the
assignment.

So now we get the proper message in and out. I still have one last problem,
when the message gets back to Tuscany I get:

org.apache.tuscany.sca.databinding.TransformationException:
java.lang.IllegalArgumentException: local part cannot be "null" when
creating a QName
at
org.apache.tuscany.sca.core.databinding.transformers.Output2OutputTransformer.transform(Output2OutputTransformer.java:215)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:79)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:186)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:169)
at
org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:103)
at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy5.hello(Unknown Source)
at
helloworld.BPELHelloWorldTestCase.testInvoke(BPELHelloWorldTestCase.java:56)

The message looks fine to me, any idea what this could be? I've committed my
fixes so you should be able to reproduce it.

Cheers,
Matthieu

On Fri, May 30, 2008 at 11:39 PM, Matthieu Riou <[EMAIL PROTECTED]>
wrote:

> I've started looking at the DbError issue and reproduced it. Digging deeper
> it seems it's caused by a lock timeout in Derby on the
> OPENJPA_SEQUENCE_TABLE when ODE tries to create a record for the new
> deployed process. Here is an excerpt from the logs:
>
> DEBUG - GeronimoLog.debug(66) | Creating process DAO for {
> http://tuscany.apache.org/implementation/bpel/example/helloworld}HelloWorld-1<http://tuscany.apache.org/implementation/bpel/example/helloworld%7DHelloWorld-1>(guid=hqejbhcnphr3beiwcxrx88)
> DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
> DEBUG - GeronimoLog.debug(66) | prepareStmt: SELECT t0.ID, t0.GUID,
> t0.PROCESS_ID, t0.PROCESS_TYPE, t0.VERSION FROM ODE_PROCESS t0 WHERE
> (t0.PROCESS_ID = ?)
> DEBUG - GeronimoLog.debug(66) | bound (1,{
> http://tuscany.apache.org/implementation/bpel/example/helloworld}HelloWorld-1<http://tuscany.apache.org/implementation/bpel/example/helloworld%7DHelloWorld-1>
> )
> DEBUG - GeronimoLog.debug(66) | close
> DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
> DEBUG - GeronimoLog.debug(66) | prepareStmt: SELECT SEQUENCE_VALUE FROM
> OPENJPA_SEQUENCE_TABLE WHERE ID = ? FOR UPDATE WITH RR
> DEBUG - GeronimoLog.debug(66) | bound (1,0)
> DEBUG - GeronimoLog.debug(66) | close
> DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
> DEBUG - GeronimoLog.debug(66) | prepareStmt: INSERT INTO
> OPENJPA_SEQUENCE_TABLE (ID, SEQUENCE_VALUE) VALUES (?, ?)
> DEBUG - GeronimoLog.debug(66) | bound (2,1) (1,0)
> DEBUG - GeronimoLog.debug(66) | close
> DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
> DEBUG - GeronimoLog.debug(66) | prepareStmt: SELECT SEQUENCE_VALUE FROM
> OPENJPA_SEQUENCE_TABLE WHERE ID = ? FOR UPDATE WITH RR
> DEBUG - GeronimoLog.debug(66) | bound (1,0)
> WARN - GeronimoLog.warn(96) | connectionErrorOccurred called with null
> java.sql.SQLException: A lock could not be obtained within the time
> requested
>
> Right now I really have no clue why this is happening, there's no reason
> why a lock would get stuck on the OpenJPA sequence table. I have to dig
> deeper but it's getting late, I'll try to find more time during the week-end
> or Monday.
>
> Cheers,
> Matthieu
>
>
> On Fri, May 30, 2008 at 1:42 PM, Mike Edwards <
> [EMAIL PROTECTED]> wrote:
>
>>
>>
>>  Original Message 
>> Subject: Re: SCA BPEL - Problems with ODE - Help requested
>> Date: Fri, 30 May 2008 17:51:12 +0100
>> Fro

Re: [Fwd: Re: SCA BPEL - Problems with ODE - Help requested]

[Matthieu Riou]

I've started looking at the DbError issue and reproduced it. Digging deeper
it seems it's caused by a lock timeout in Derby on the
OPENJPA_SEQUENCE_TABLE when ODE tries to create a record for the new
deployed process. Here is an excerpt from the logs:

DEBUG - GeronimoLog.debug(66) | Creating process DAO for {
http://tuscany.apache.org/implementation/bpel/example/helloworld}HelloWorld-1(guid=hqejbhcnphr3beiwcxrx88)
DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
DEBUG - GeronimoLog.debug(66) | prepareStmt: SELECT t0.ID, t0.GUID,
t0.PROCESS_ID, t0.PROCESS_TYPE, t0.VERSION FROM ODE_PROCESS t0 WHERE
(t0.PROCESS_ID = ?)
DEBUG - GeronimoLog.debug(66) | bound (1,{
http://tuscany.apache.org/implementation/bpel/example/helloworld}HelloWorld-1
)
DEBUG - GeronimoLog.debug(66) | close
DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
DEBUG - GeronimoLog.debug(66) | prepareStmt: SELECT SEQUENCE_VALUE FROM
OPENJPA_SEQUENCE_TABLE WHERE ID = ? FOR UPDATE WITH RR
DEBUG - GeronimoLog.debug(66) | bound (1,0)
DEBUG - GeronimoLog.debug(66) | close
DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
DEBUG - GeronimoLog.debug(66) | prepareStmt: INSERT INTO
OPENJPA_SEQUENCE_TABLE (ID, SEQUENCE_VALUE) VALUES (?, ?)
DEBUG - GeronimoLog.debug(66) | bound (2,1) (1,0)
DEBUG - GeronimoLog.debug(66) | close
DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
DEBUG - GeronimoLog.debug(66) | prepareStmt: SELECT SEQUENCE_VALUE FROM
OPENJPA_SEQUENCE_TABLE WHERE ID = ? FOR UPDATE WITH RR
DEBUG - GeronimoLog.debug(66) | bound (1,0)
WARN - GeronimoLog.warn(96) | connectionErrorOccurred called with null
java.sql.SQLException: A lock could not be obtained within the time
requested

Right now I really have no clue why this is happening, there's no reason why
a lock would get stuck on the OpenJPA sequence table. I have to dig deeper
but it's getting late, I'll try to find more time during the week-end or
Monday.

Cheers,
Matthieu

On Fri, May 30, 2008 at 1:42 PM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

>
>
>  Original Message 
> Subject: Re: SCA BPEL - Problems with ODE - Help requested
> Date: Fri, 30 May 2008 17:51:12 +0100
> From: Mike Edwards <[EMAIL PROTECTED]>
> To: tuscany-dev@ws.apache.org
> References: <[EMAIL PROTECTED]> <
> [EMAIL PROTECTED]>
>
> Matthieu Riou wrote:
>
>> On Thu, May 29, 2008 at 11:41 AM, Mike Edwards <
>> [EMAIL PROTECTED]> wrote:
>>
>>  Folks,
>>>
>>> I've run into problems with the SCA BPEL implementation and the way it
>>> interacts with the ODE engine - and I need help from some ODE experts,
>>> please.
>>>
>>> OK, the SCA code is using the ODE engine in an embedded mode - and the
>>> Tuscany code is trying to supply all the information and interfaces for
>>> each
>>> BPEL process to the ODE Engine - and in particular it aims to bypass the
>>> ODE
>>> database store so far as the BPEL process and its configuration are
>>> concerned.
>>>
>>> So - Tuscany now has its own version of the ProcessConfImpl (I sent a
>>> version of this out in a previous email).  One thing I discovered is that
>>> it
>>> is necessary for the Tuscany ProcessConfImpl to return "true" to the
>>> isTransient() method. Otherwise, the ODE engine seems to try to find
>>> information about the process in the database with nasty consequences
>>> (failed transactions).
>>>
>>>
>> Normally that shouldn't be a problem. Transient tells ODE to execute the
>> process in memory but that only applies to short living processes, for
>> most
>> scenarios you'll want to have persistent executions. So we should try to
>> see
>> why these transactions fail.
>>
>>
>>  HOWEVER, this has a side effect that is both curious and problematic.
>>>
>>> Using the ODE ProcessConfImpl (and by implication the database store for
>>> the process itself), for a trivial "Hello World" BPEL process, when the
>>> "hello" operation is invoked on the BPEL process, the ODE engine returns
>>> the
>>> result message as a "DeferredElementNSImpl" class with the name
>>> "TestPart" -
>>> which on inspection contains a child element "message" containing the
>>> expected "Hello World" string.
>>> (I attach the relevant part of the WSDL at the bottom)
>>>
>>>
>>> When we switch to using the Tuscany ProcessConfImpl - with its
>>> "transient"
>>> setting, when we invoke the same process, we get back a different type of
>>> object - an "ElementImpl" named "

Re: SCA BPEL - Problems with ODE - Help requested

[Matthieu Riou]

On Thu, May 29, 2008 at 11:41 AM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

> Folks,
>
> I've run into problems with the SCA BPEL implementation and the way it
> interacts with the ODE engine - and I need help from some ODE experts,
> please.
>
> OK, the SCA code is using the ODE engine in an embedded mode - and the
> Tuscany code is trying to supply all the information and interfaces for each
> BPEL process to the ODE Engine - and in particular it aims to bypass the ODE
> database store so far as the BPEL process and its configuration are
> concerned.
>
> So - Tuscany now has its own version of the ProcessConfImpl (I sent a
> version of this out in a previous email).  One thing I discovered is that it
> is necessary for the Tuscany ProcessConfImpl to return "true" to the
> isTransient() method. Otherwise, the ODE engine seems to try to find
> information about the process in the database with nasty consequences
> (failed transactions).
>

Normally that shouldn't be a problem. Transient tells ODE to execute the
process in memory but that only applies to short living processes, for most
scenarios you'll want to have persistent executions. So we should try to see
why these transactions fail.


>
> HOWEVER, this has a side effect that is both curious and problematic.
>
> Using the ODE ProcessConfImpl (and by implication the database store for
> the process itself), for a trivial "Hello World" BPEL process, when the
> "hello" operation is invoked on the BPEL process, the ODE engine returns the
> result message as a "DeferredElementNSImpl" class with the name "TestPart" -
> which on inspection contains a child element "message" containing the
> expected "Hello World" string.
> (I attach the relevant part of the WSDL at the bottom)
>
>
> When we switch to using the Tuscany ProcessConfImpl - with its "transient"
> setting, when we invoke the same process, we get back a different type of
> object - an "ElementImpl" named "TestPart".  This contains an ElementNSImpl
> object named "hello" containing a TextImpl child holding "Hello World". This
> structural layout is clearly different to the previous case - and is wrong -
> it isn't what is expected.
>
> Can anyone explain the difference in the two cases?  Any assistance
> gratefully received.
>

I don't see what could create this difference. The deferred element vs.
normal element is nothing to worry about, it's just that the structure has
already been traversed in one case because of the storage different, but the
content itself should be identical. Usually the switch from transient to
persistent doesn't bring that kind of differences but there's nothing I can
think of off the top of my head that could create this behavior. The
structural difference kind of reminds the difference between rpc and
document style part wrappers but that shouldn't show here.

So I'd like to reproduce this and see what's going wrong. Is all your code
committed? Which test case are you using?

Thanks,
Matthieu


>
> Is it perhaps due to differences in the compilation of the process?  Or is
> the process treated in some very different way when it is transient?
>
>
>
> Yours,  Mike Edwards.
> -
> Relevant WSDL sections:
>
>
>   targetNamespace="
> http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl";
>   xmlns="http://www.w3.org/2001/XMLSchema";>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>   
>   
>   
>   
> ---
> Relevant BPEL section:
>
> targetNamespace="
> http://tuscany.apache.org/implementation/bpel/example/helloworld";
>xmlns:bpws="http://schemas.xmlsoap.org/ws/2004/03/business-process/";
>xmlns="http://schemas.xmlsoap.org/ws/2004/03/business-process/";
>xmlns:tns="
> http://tuscany.apache.org/implementation/bpel/example/helloworld";
>xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>xmlns:test="
> http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl";
>queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath2.0"
>expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath2.0">
>
>  http://schemas.xmlsoap.org/wsdl/";
> namespace="
> http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl"/>
>
>   
>   partnerLinkType="test:HelloPartnerLinkType" myRole="me" />
>   
>
>   
> 
> 
>   
>
>   
> name="start"
>  partnerLink="helloPartnerLink"
>  portType="test:HelloPortType"
>  operation="hello"
>  variable="myVar"
>  createInstance="yes"/>
>
>  
>  
>  
>  
>  
>  
>  concat($tmpVar,' World')
>  
>  
>  
> partnerLink="hello

Re: BPEL Implementation: Latest changes mean no need for deploy.xml !!

[Matthieu Riou]

Actually the process runtime also needs a transaction when you deploy a
process. It persists some data structures needed to optimize message routing
and correlation extraction (basically which receives we can route to).

Cheers,
Matthieu

On Tue, May 27, 2008 at 4:08 PM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> The transaction is needed by the ProcessStore in order to persist the
> process information.
> I will research and see if there are any workarounds.
>
> On Tue, May 27, 2008 at 2:21 PM, Mike Edwards
> <[EMAIL PROTECTED]> wrote:
> > Luciano Resende wrote:
> >>
> >> Very good news Mike !!! I hope to start working on the db issues as
> >> soon as I get some free cycles.
> >>
> >
> > Luciano,
> >
> > There is something that you might be able to help me with right away.
> >
> > I am running into intermittent problems with transactions in the
> > registration of a BPEL process with the ODE server. The transaction
> causing
> > the problem seems to be the one in the BPELImplementationProvider start()
> > method.
> >
> > What is this transaction for?
> >
> > try {
> >txMgr.begin();
> >odeServer.registerTuscanyRuntimeComponent(implementation.getProcess(),
> > component);
> >
> >odeServer.deploy(new ODEDeployment(deploymentDir), implementation );
> >txMgr.commit();
> > } catch (Exception e) {
> >e.printStackTrace();
> >txMgr.rollback();
> > }
> >
> >
> > Will it cause a problem if I remove this transaction?  To me it does not
> > seem to provide any value when the Process is being supplied by Tuscany.
>  I
> > can't see any requirement for it in the ODE documentation.
> >
> >
> > Yours,  Mike.
> >
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende 
> http://lresende.blogspot.com/
>

Re: ODE integration and level of Geronimo-connector? was: Levels of Geronimo dependencies

[Matthieu Riou]

On Tue, May 27, 2008 at 10:35 AM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

> Mike Edwards wrote:
>
>> Jean-Sebastien Delfino wrote:
>>
>>> Jean-Sebastien Delfino wrote:
>>>
 The following files:
 sca/modules/core/pom.xml
 sca/modules/binding-jms/pom.xml
 sca/modules/policy-transaction/pom.xml
 sca/modules/binding-ejb/pom.xml
 sca/modules/implementation-bpel-ode/pom.xml
 sca/modules/host-webapp/pom.xml
 sca/modules/implementation-openjpa/pom.xml

 seem to require different levels of various geronimo JARs.

 How about making them agree on a single level: Geronimo 2.1?

>>>
>>> I've tried to change the references to Geronimo 2.1.1 and the
>>> corresponding spec JARs and got a successful build, so if there's no
>>> objection I'll commit that change in the next few days.
>>>
>>>  +1 from me to get to a single level of Geronimo.
>>
>> I have no opinion as to which level of Geronimo is best.
>>
>>
>> Yours,  Mike.
>>
>
> I spoke too fast, Geronimo JARs version 2.1.1 breaks
> implementation-bpel-ode with:
>
> testProcessInvocation(org.apache.tuscany.sca.implementation.bpel.EmbeddedODEServerTestCase)
>  Time elapsed: 0.113 sec  <<< ERROR!
> java.lang.NoSuchMethodError:
> org.apache.geronimo.connector.outbound.GenericConnectionManager.(Lorg/apache/geronimo/connector/outbound/connectionmanagerconfig/TransactionSupport;Lorg/apache/geronimo/connector/outbound/connectionmanagerconfig/PoolingSupport;ZLorg/apache/geronimo/connector/outbound/connectiontracking/ConnectionTracker;Ljavax/transaction/TransactionManager;Ljava/lang/String;Ljava/lang/ClassLoader;)V
>at
> org.apache.ode.il.dbutil.Database.initInternalDb(Database.java:187)
>at
> org.apache.ode.il.dbutil.Database.initEmbeddedDb(Database.java:225)
>at
> org.apache.ode.il.dbutil.Database.initDataSource(Database.java:144)
>at org.apache.ode.il.dbutil.Database.start(Database.java:96)
>at
> org.apache.tuscany.sca.implementation.bpel.ode.EmbeddedODEServer.initPersistence(EmbeddedODEServer.java:132)
>at
> org.apache.tuscany.sca.implementation.bpel.ode.EmbeddedODEServer.init(EmbeddedODEServer.java:99)
>at
> org.apache.tuscany.sca.implementation.bpel.EmbeddedODEServerTestCase.setUp(EmbeddedODEServerTestCase.java:58)
>at junit.framework.TestCase.runBare(TestCase.java:125)
>at junit.framework.TestResult$1.protect(TestResult.java:106)
>at junit.framework.TestResult.runProtected(TestResult.java:124)
>at junit.framework.TestResult.run(TestResult.java:109)
>at junit.framework.TestCase.run(TestCase.java:118)
>at junit.framework.TestSuite.runTest(TestSuite.java:208)
>at junit.framework.TestSuite.run(TestSuite.java:203)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>at java.lang.reflect.Method.invoke(Method.java:597)
>at
> org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
>at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
>at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
>at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>at java.lang.reflect.Method.invoke(Method.java:597)
>at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
>at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
>
>
> Results :
>
> Tests in error:
>
>
> testProcessInvocation(org.apache.tuscany.sca.implementation.bpel.EmbeddedODEServerTestCase)
>
>
> It works with geronimo-connector version 1.2-beta (from Dec 2006), but
> other versions of geronimo-connector give me that error.
>
> Is there a way to get ODE 1.1 or 1.1.1 working with a more recent level of
> geronimo-connector?
>

Depends which version of geronimo-transaction you want to use :) At the
moment we're using 2.0.1 for geronimo kernel, transaction and connector and
it works pretty well.

Cheers,
Matthieu


>
> --
> Jean-Sebastien
>

Re: Eliminating the need for deploy.xml - Tuscany SCA / ODE integration

[Matthieu Riou]

On Fri, May 23, 2008 at 9:03 AM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

> Matthieu Riou wrote:
>
>> What mike says. I should just add that picking the right process version
>> depending on what's already executing is handled by the runtime. The only
>> thing that it will need is to know what is the definition for all the
>> process versions that are still around (haven't been undeployed). You just
>> need to keep these artifacts around and feed them to the engine (by
>> calling
>> register) as long as they're needed.
>>
>> If you want, I can code the method that compiles the BPEL file if you give
>> me a signature that gets the file as parameter (I don't know how you would
>> look it up in the filesystem).
>>
>> Cheers,
>> Matthieu
>>
>>
>>
>>> Yours optimistically,
>>>
>>> Mike.
>>>
>>>  Matthieu,
>
> I'd appreciate it if you could pass your eyes over my implementation of a
> ProcessConf, inline below.
>
> There are a few questions that I have:
>
> 1) ProcessConfImpl from the ODE code has more public methods than are
> present in the ProcessConf interface.  What are they used for - and by which
> code?
>

Those are only used by the store implementation or by a test case for one of
them. You don't need to worry about those as you won't have a store
implementation.


>
> 2) What is getDefinitionforService(...) supposed to return?  The problem is
> over the interpretation of the name "Service" - what kind of service is
> this?  A service from the WSDL?  A service as listed in the deploy.xml file?
>  And what definition are we talking about - the definition of the Service in
> the WSDL file, or the definition of the portType at which the service
> points?
>

It returns the WSDL object model associated with a given WSDL service
qualified name. When something gets deployed, we scan all the WSDL documents
and associate them with the services they define. This method is basically
used by the engine to get the definition of the services that you defined in
the deploy.xml. It can then pass this definition on to the integration layer
when it wants a service to get activated.


>
> 3) What are Properties as returned by getProperties()?
>

We have a set of custom name/value properties that can be defined in the
deploy.xml that people can use to attribute some custom values to their
process definitions. This is mostly used in the management API so that a
graphical tool listing all process definitions could for example filter them
by department. Those are somewhat different to what SCA properties for BPEL
are, so I'm not sure what would be the best way to declare this in Tuscany.
Perhaps some additional property elements in the componentType definition?
In any case, it's not crucial for now.


>
> I'd appreciate any assistance you can give
>

Looking through your code, it looks pretty good. We'll need better error
reporting on the compilation but I've seen you already have a todo tag here
so nothing to add. We'll also probably need versioning soon, it's a pretty
common in BPEL when you incrementally deploy new processes but for a first
implementation, we can definitely live with it.

Looks pretty nice overall, thanks a lot for your work!

Matthieu


>
> Yours,  Mike.
>
>
> /*
>  * Licensed to the Apache Software Foundation (ASF) under one
>  * or more contributor license agreements.  See the NOTICE file
>  * distributed with this work for additional information
>  * regarding copyright ownership.  The ASF licenses this file
>  * to you under the Apache License, Version 2.0 (the
>  * "License"); you may not use this file except in compliance
>  * with the License.  You may obtain a copy of the License at
>  *
>  *   http://www.apache.org/licenses/LICENSE-2.0
>  *
>  * Unless required by applicable law or agreed to in writing,
>  * software distributed under the License is distributed on an
>  * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
>  * KIND, either express or implied.  See the License for the
>  * specific language governing permissions and limitations
>  * under the License.
>  */
> package org.apache.tuscany.sca.implementation.bpel.ode;
>
> import java.io.File;
> import java.io.InputStream;
> import java.io.FileInputStream;
> import java.io.IOException;
> import java.net.URI;
> import java.net.URL;
> import java.util.Date;
> import java.util.List;
> import java.util.Collection;
> import java.util.Map;
> import java.util.HashMap;
> import java.util.Arrays;
>
> import javax.wsdl.Definition;
> import javax.wsdl.PortType

Re: TLP migration

[Matthieu Riou]

On Thu, May 22, 2008 at 3:55 AM, ant elder <[EMAIL PROTECTED]> wrote:

> Now that we have graduated we have some work to do to migrate to a TLP, the
> Incubator has information about this if anyone is interested in helping
> out,
> for example a good start is
> http://incubator.apache.org/guides/graduation.html#transfer
>

Don't hesitate to let me know if you need a help, I can give you a hand.

Matthieu


>
> We can also look at doing an official ASF press release, a couple of
> examples are the Synapse ones at [1] and [2]. We probably want to wait till
> we have the website migrated to the TLP before sending that out but I'll
> setup a wiki page for a press release that we can work on in the mean time.
>
>   ...ant
>
> [1] http://apache.markmail.org/message/7caukr2i3uwg6w2c
> [2] http://apache.markmail.org/message/xit3tee7iqpfztx6
>

Graduation

[Matthieu Riou]

"Special order 7B, Establish the Apache Tuscany Project, was approved by
Unanimous Vote of the directors present."

Congratulations guys!

Matthieu

Re: Eliminating the need for deploy.xml - Tuscany SCA / ODE integration

[Matthieu Riou]

On Tue, May 20, 2008 at 2:12 PM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

> Luciano Resende wrote:
>
>> So, in the case where we replace the ODE Process Store module with one
>> implemented by Tuscany, is this new module going to be responsible for
>> handling all the versioning and matching a running process instance
>> with the right BPEL process version ?
>>
>> Also, can the modules that handle deploy.xml and process store be
>> implemented separately (e.g Tuscany would handle deploy.xml but still
>> use ode process store module) ?
>>
>> Thanks
>> Luciano
>>
> Luciano,
>
> My reading of Matthieu's note is that what is necessary is simply that
> Tuscany must implement a ProcessConf class, rather than the whole process
> store.  That can be prepared entirely from information which Tuscany has to
> hand, although as Matthieu points out, there are complex details within the
> ProcessConf implementation that will require us to re-use some ODE modules
> that compile the BPEL process file, but he says that doing that will not be
> too hard ;-)
>
> With Tuscany, the Process Store is not needed since Tuscany has the Domain
> configuration to drive things.
>

What mike says. I should just add that picking the right process version
depending on what's already executing is handled by the runtime. The only
thing that it will need is to know what is the definition for all the
process versions that are still around (haven't been undeployed). You just
need to keep these artifacts around and feed them to the engine (by calling
register) as long as they're needed.

If you want, I can code the method that compiles the BPEL file if you give
me a signature that gets the file as parameter (I don't know how you would
look it up in the filesystem).

Cheers,
Matthieu


>
>
> Yours optimistically,
>
> Mike.
>

Re: Eliminating the need for deploy.xml - Tuscany SCA / ODE integration

[Matthieu Riou]

On Mon, May 19, 2008 at 9:11 AM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

> Folks,
>
> I am interested in getting rid of the need to have a physical deploy.xml
> file in the directory with a BPEL process file.
>
> Can I supply the same information to the ODE runtime through some other
> means, such as method parameters or some in-memory mechanism?
>

The short answer is: yes, you can. The long answer is... a bit longer :)


>
> For the SCA integration, the SCA runtime has all the information contained
> in the deploy.xml file, but in another form.  It would be great to relieve
> the developers from the need to create this file.
>

Let me explain a bit how that works. The ODE runtime doesn't know anything
about the file system, descriptors or even BPEL files. It just knows that
something is supposed to call it, passing an interface implementation
(ProcessConf [1]) that provides everything it needs (and a bit more
actually). It's so dumb that it doesn't even know which processes it should
know about, so every time the server is restarted, it expects to be called
again with the same process definition information.

Parrallely in ODE we have a process store that handles all the nitty gritty
details of knowing where is what in which version and remembering it. The
process store doesn't know about the runtime and the runtime doesn't know
about the store. The advantage is that, in theory, you could pick different
clustering models (one store / multiple servers, multiple stores / multiple
servers) depending on how you want things to be arranged. The other
advantage is that you can get rid of the store altogether if you have all
the necessary information.

When a new process is deployed (or undeployed, or retired, or ...), the
store just produces an event. Same thing when the whole server is restarted,
the store produces several events for each process the runtime should know
about. These events are just relayed by the Integration Layer that binds the
store and the runtime and implements external communication (all the
interfaces Luciano has implemented).

Getting back to Tuscany, what I'm thinking is that we should remove the
store (and its events) from the equation. Tuscany would just let the runtime
know when when a process is available by calling
BpelServer.register(ProcessConf), providing its own implementation of
ProcessConf. The current Tuscany integration layer already has a reference
to the BpelServer, so that's easy. The caveat is that in this case, Tuscany
will also need to compile the .bpel file to provide the CBP (Compiled
Business Process) but that's fairly painless (see
DeploymentUnitDir.compile(File) [2]).

The net advantage of this for Tuscany will be a much better integration and
much more control over the process lifecycle. So let me know what you think
and I can help with your ProcessConf implementation.

Cheers,
Matthieu

[1]
http://svn.apache.org/repos/asf/ode/trunk/bpel-api/src/main/java/org/apache/ode/bpel/iapi/ProcessConf.java
[2]
http://svn.apache.org/repos/asf/ode/trunk/bpel-store/src/main/java/org/apache/ode/store/DeploymentUnitDir.java


>
> Yours,  Mike Edwards
> Apache Tuscany team.
>

Re: [VOTE] Graduate Apache Tuscany as a Top Level Project (take two)

[Matthieu Riou]

On Sat, May 10, 2008 at 12:17 AM, ant elder <[EMAIL PROTECTED]> wrote:

> Restarting the graduation vote with the updated proposal words, please
> vote
> on the proposal below to graduate Tuscany to a TLP.
>

+1

Matthieu


>
> +1 from me.
>
>   ...ant
>
>  X. Establish the Apache Tuscany Project
>
> WHEREAS, the Board of Directors deems it to be in the best
> interests of the Foundation and consistent with the Foundation's
> purpose to establish a Project Management Committee charged with
> the creation and maintenance of open-source software for
> distribution at no charge to the public, that simplifies the
> development, deployment and management of distributed applications
> built as compositions of service components. These components
> may be implemented with a range of technologies and connected
> using a variety of communication protocols. This software will
> implement relevant open standards including, but not limited to,
> the Service Component Architecture standard defined by the OASIS
> OpenCSA member section, and related technologies.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache Tuscany Project",
> be and hereby is established pursuant to Bylaws of the
> Foundation; and be it further
>
> RESOLVED, that the Apache Tuscany Project be and hereby is
> responsible for the creation and maintenance of software
> related to Apache Tuscany;
> and be it further
>
> RESOLVED, that the office of "Vice President, Apache Tuscany" be
> and hereby is created, the person holding such office to
> serve at the direction of the Board of Directors as the chair
> of the Apache Tuscany Project, and to have primary responsibility
> for management of the projects within the scope of
> responsibility of the Apache Tuscany Project; and be it further
>
> RESOLVED, that the persons listed immediately below be and
> hereby are appointed to serve as the initial members of the
> Apache Tuscany Project:
>
>* Adriano Crestani 
>* ant elder 
>* Brady Johnson 
>* Frank Budinsky 
>* Ignacio Silva-Lepe 
>* Jean-Sebastien Delfino 
>* kelvin goodson 
>* Luciano Resende 
>* Mark Combellack 
>* Matthieu Riou 
>* Mike Edwards 
>* Paul Fremantle 
>* Pete Robbins 
>* Raymond Feng 
>* Simon Laws 
>* Simon Nash 
>* Venkata Krishnan 
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder
> be appointed to the office of Vice President, Apache Tuscany, to
> serve in accordance with and subject to the direction of the
> Board of Directors and the Bylaws of the Foundation until
> death, resignation, retirement, removal or disqualification,
> or until a successor is appointed; and be it further
>
> RESOLVED, that the Apache Tuscany Project be and hereby
> is tasked with the migration and rationalization of the Apache
> Incubator Tuscany podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator Tuscany podling encumbered upon the Apache Incubator
> Project are hereafter discharged.
>

Re: SCA & BPEL - ODE Database dependency

[Matthieu Riou]

I think Alex didn't mean it's there already, just pointed out a way to add
this :)

We already have something similar in bpel-store [1]. You can configure
OpenJPA to create the schema for you if it can't find it. So what you would
do is basically:

1. Create a derby instance.
2. Point OpenJPA to it with the right option (just add it as a property in
[2]).
3. Instantiate the store asking it to create its schema as well.
4. There's no 4.

Given that Tuscany already has its own IL, you have all the freedom to do
this when assembling the pieces. The only missing one is the property in 2.

Cheers,
Matthieu

[1]
http://svn.apache.org/repos/asf/ode/trunk/bpel-store/src/main/java/org/apache/ode/store/jpa/DbConfStoreConnectionFactory.java
[2]
http://svn.apache.org/repos/asf/ode/trunk/dao-jpa/src/main/java/org/apache/ode/dao/jpa/BPELDAOConnectionFactoryImpl.java

On Tue, May 13, 2008 at 12:04 PM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> Good to know we already have the code to create a new Derby dabase
> instance with a fresh Ode Schema. I guess I have missed this when
> creating the Tuscany Embedded Ode Server. Could you please point me to
> where this is available ?
>
> On Tue, May 13, 2008 at 11:56 AM, Alex Boisvert <[EMAIL PROTECTED]>
> wrote:
> > Perhaps by defining a new database mode "SAMPLE" (we already have
> EMBEDDED,
> > INTERNAL, EXTERNAL), that creates a new Derby database instance with a
> fresh
> > Ode schema everytime the server is started?
> >
> > alex
> >
> >
> > On Tue, May 13, 2008 at 11:50 AM, Luciano Resende <[EMAIL PROTECTED]>
> > wrote:
> >
> >> In Apache Tuscany, we have a embedded ODE Server that has a dependency
> >> on the ODE database (ode-dao-jpa-ojpa-derby-1.1.zip) that get's unzip
> >> by the build process when the app is run. I see two issues with this
> >> approach : The build infrastructure to unzip the db needs to be copied
> >> on every sample app and when running from an IDE, this code might not
> >> have been executed, and will require the application developer to go
> >> outside of the ide, to run some build command to create the db and
> >> make it available on the classpath.
> >>
> >>  I was wondering if there is some kind of script that could be used to
> >> generate the db structure and any initial content. If so, I was
> >> thinking to integrate this script into the Embedded ODE Server
> >> initialization code, and create the proper db dependencies if not
> >> found.
> >>
> >> Thoughts ?
> >>
> >> --
> >> Luciano Resende
> >> Apache Tuscany Committer
> >> http://people.apache.org/~lresende<
> http://people.apache.org/%7Elresende>
> >> http://lresende.blogspot.com/
> >>
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende 
> http://lresende.blogspot.com/
>

Re: What's next for SCA & BPEL Integration

[Matthieu Riou]

On Thu, Apr 24, 2008 at 8:37 AM, Luciano Resende <[EMAIL PROTECTED]>
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://lresende.blogspot.com/
>

Re: What's next for SCA & BPEL Integration

[Matthieu Riou]

On Thu, Apr 24, 2008 at 10:41 AM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> On Thu, Apr 24, 2008 at 8:53 AM, ant elder <[EMAIL PROTECTED]> wrote:
> > On Thu, Apr 24, 2008 at 4:37 PM, Luciano Resende <[EMAIL PROTECTED]>
> >  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://lresende.blogspot.com/
>

Re: Graduation next steps

[Matthieu Riou]

I'm happy to see this discussion going and I think most of the points listed
make a lot of sense.

A small detail to add to the list that I think could have some importance:
your -dev list is flooded by Jira issues. Newcomers interested in Tuscany's
development are very likely to get overwhelmed by all the noise. I'd
redirect that to -commits.

Cheers,
Matthieu

On Feb 1, 2008 2:47 AM, Simon Laws <[EMAIL PROTECTED]> wrote:

> On Jan 31, 2008 1:41 PM, ant elder <[EMAIL PROTECTED]> wrote:
>
> > I'd like to get some discussion going on what we want to do for
> graduating
> > to an Apache TLP.
> >
> > The attempt back in November raised issues about diversity and since
> then
> > it
> > feels like we've just been waiting around hoping diversity would
> improve.
> > We
> > were unlikely then and we are almost there, would it help to have a
> target
> > to aim for so we can be a bit more proactive? How about trying again at
> > the
> > April or May board meeting which would give us a two or three full
> months
> > from now? Having a few months would give us some time to work on turning
> > some of the contributors we already have into committers and to get
> other
> > committers added to the PPMC, but a few months is also near enough to
> keep
> > us focused. If we're seen to be working on this it may also encourage
> some
> > of the contributors we have to be more active and so easier to make
> > committers.
> >
> > There's a lot i think the project could do to encourage others to
> > participate, here's a few things I can think of -
> >
> > We have a lot of downloads and real users, we need to try to get more of
> > these people engaged and contributing, things that may help are:
> >
> > - better documentation, whats there is a bit sparse and our website has
> > started to fall behind and there's quite a few extensions with no or out
> > dated documentation
> > - more publicity about what each new Tuscany release can do, we have
> lots
> > of
> > new stuff in 1.1 but the only place we say that is in the release notes.
> > The
> > Tuscany blog is a little neglected these days
> > - post to user list as each bit of new function is completed to try to
> > engage users and to show them their comments can make a real difference
> to
> > what gets in the next release
> > - more timely action on JIRAs, we're getting quite a back log, if we're
> > quick to look at JIRAs it might encourage users to help debug and
> provide
> > patches
> >
> > Once a user does start contributing I think there are things we could do
> > better on the the dev list to make it easier and to encourage
> > participation:
> >
> > - just generally improve the ML traffic which is at an all time low, if
> we
> > the active developers don't discuss much then new contributors likely
> wont
> > either
> > - one reason ML traffic could be down is that discussion is going on
> > off-list instead, is there? Is it really necessary? Lets make a real
> > effort
> > to keep all discussion on the dev list.
> > - more timely replies in discussions. if someone replies to a thread
> often
> > it ends up with people waiting for a follow-up reply, if that follow-up
> > takes ages to come the discussion can stall and people loose interest
> and
> > move on to something else.
> > - we may need to provide more active help to contributors when they make
> > suggestions, not just ask if they'd implement it but at least provide
> lots
> > of detail about how they could do it or even step up and help code even
> if
> > we may not think its the most useful thing
> >
> > What do others think, would any of those things help? Any other
> > suggestions
> > that could help improve our diversity? Does aiming for the April board
> > meet
> > sound ok or too soon or too far?
> >
> >   ...ant
>
>
> I think all of the things you suggest are excellent ideas and that we
> should
> do better in all of these areas regardless of our aspirations to graduate
> from the incubator. I wouldn't like to think we put effort in now and then
> sit back as soon as we do graduate.
>
> I'm in two minds about whether having a target for graduation is
> appropriate. I would like to suggest that we give ourselves a target for
> improving our diversity by addressing all of the good points you make and
> undertake to report/discuss our progress with the IPMC at some interval
> (monthly) to see if a new graduation proposal is appropriate. However I'll
> have to take you advice as to whether posting to general@, reporting what
> progress we have made and soliciting feedback will provide a response or
> whether we actually have to start a [VOTE] to get peoples attention.
>
> Motivated by your points some specific thoughts that come to mind...
>
>
> JIRA Handling
>
> The JIRA backlog is a real problem and I, for one, have been very poor at
> addressing this. We want to be in a position where incoming JIRA are
> classified, assigned and turned round as quickly as possible. So two
> problems to solve.
>
> 1.

Re: [VOTE] Please approve Tuscany SCA Java 1.1-incubating release (RC3a)

[Matthieu Riou]

Looks good to me, thanks for correcting the problems mentioned by Sebastian.

+1

Matthieu

On Jan 28, 2008 9:31 AM, Simon Laws <[EMAIL PROTECTED]> wrote:

>  Hi,
>
> The previous VOTE thread here for SCA Java 1.1-incubating identified some
> issues.
>
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg16483.html
>
> A new release candidate (RC3a) has been created addressing the issues as
> discussed in the previous thread. I'm starting this IPMC VOTE thread in
> parallel with the project vote thread as the material content of the
> release
> hasn't changed significantly and I don't want to delay before getting IPMC
> eyeballs on it.
>
> The ongoing thread in the Tuscany community can be found here
>
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27401.html
>
> The release includes a set of bug-fixes and new function such as the
> implementation of binding.jms. You can see a list of changes at:
>
>
> http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.1-RC3a/distribution/src/main/release/CHANGES
>
> The signed binary and source distributions, the RAT reports, and the Maven
> staging repository are listed at the following links.
>
> SVN Tag:
> http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.1-RC3a/
>
> Stage maven repo:
> http://people.apache.org/~slaws/tuscany/1.1-RC3a/maven/
> 
>
> RAT report:
> http://people.apache.org/~slaws/tuscany/1.1-RC3a/rat-1.1-RC3a.txt
> 
>
> Binary and source distros (zip/gz/asc/md5) :
> http://people.apache.org/~slaws/tuscany/1.1-RC3a/
> 
>
> Please review and approve the release. This vote will remain open for at
> least 72 hours.
>
> Thank you for your attention,
>
> Simon
>

Re: [VOTE] Graduate Tuscany as a top level project

[Matthieu Riou]

On 10/9/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> Looks like we've closed all the discussions around this so we can now vote
> on it. We've an Incubator discussion thread on our graduation but I don't
> see why we can't let that run in parallel, so ...
>
> Please vote on graduating Tuscany as a top level project and the proposal
> below.


+1

Re: Graduation Checklist, was: Graduation

[Matthieu Riou]

On 10/2/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> [snip]
> Simon Laws wrote:
> > How about we put a check list up on the wiki so
> > we all get a view of what's going on and what needs to be done by when.
> I've
> > started one here by copying the checklist from the graduation guide (
> >
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Graduation+Checklist
> )
> > but we need to work out what we need to do specifically for Tuscany and,
> of
> > course by, when.
> >
> > Simon
> >
>
> I looked at the Tuscany Graduation Checklist Wiki page and it looks like
> we're making good progress. I have a few comments.
>
> Bullet #1 points to http://incubator.apache.org/projects/tuscany.html, 2
> new committers are missing on that page.
> Brady Johnson
> Simon Nash
>
> Bullet #3 - Are there three or more independent committers? says "The
> project committers are drawn from 6 independent organizations." Status
> says "Needs Checking".
> I count 8 independent organizations, more than the requirement of 3. Can
> we mark it "Done" or clarify what else needs checking?
>
> Bullet #9 - Ensure that mentors and IPMC have no remaining issues.
> Let's start with our mentors, could our mentors please list any
> remaining issues?


I personally have no remaining issues. My main concerns were related to the
specs IP and diversity and both have either been addressed or are currently
being addressed. You should send an e-mail to [EMAIL PROTECTED] mentioning that
you're on the track to graduation and ask if other IPMCers have pending
issues. I'd expect a few questions but probably nothing you can't answer
properly.

Cheers,
Matthieu

Row #11 - A  draft resolution is available at
>
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Draft+TLP+Resolution
> After discussing the draft on the mailing list, people seem to be OK
> with this text:
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg24387.html
>
> Row #13 - Openness of specification process.
> Looks like there is consensus in this thread:
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg24282.html. I
> think we can mark this one "Done".
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Graduation

[Matthieu Riou]

On 9/27/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 9/27/07, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > On 9/27/07, Mike Edwards <[EMAIL PROTECTED]> wrote:
> > >
> > > Folks,
> > >
> > > Simon Laws wrote:
> > > > On 9/27/07, ant elder <[EMAIL PROTECTED]> wrote:
> > > >> On 9/27/07, Matthieu Riou <[EMAIL PROTECTED]> wrote:
> > > >>
> > > >> 
> > > >>
> > > >> So you have 4 more days after Sunday :) But there's no reason to
> rush
> > > out,
> > > >>> I'm just clarifying the timeline, you'll be ready when you'll be
> > ready
> > > >> and
> > > >>> you can also target Nov. 21st.
> > > >>
> > > >> The November time frame sounds good to me and gives plenty of time
> to
> > > sort
> > > >> out things and bring it up with the IPMC so we know if they've any
> > > issues
> > > >> we
> > > >> need to address before calling a vote.
> > >
> > > I think that November is allowing things to slide too much.  Are there
> > > any reasons that will DEFINITELY prevent achieving October?  Otherwise
> > > October is my vote.
> > >
> > > >>
> > > >>...ant
> > > >>
> > > > But there is nothing stopping us pushing ahead now. If we happened
> to
> > be
> > > > ready for October we should try for October.
> > >
> > > +1 from me.  Leaving a slacker schedule typically does not help.  Set
> > > the challenging schedule and focus on the big items to get us there.
> > > Go for October.
> >
> >
> > Two of things i think we should do are:
> >
> > - the PPMC doesn't yet reflect the diversity of the committers. We've
> all
> > been a bit busy with 1.0 etc and there's a few people now who we could
> > look
> > at as PPMC members, Matthieu brought this up earlier on the thread.
> Doing
> > this now may help prevent any questions about diversity.
>
>
> +1
>
> - the openness of the specs and our interaction with OSOA has been brought
> > up before by the Incubator. Most things have now moved to OASIS and that
> > should resolve those issues but stuff still happens at OSOA. We need to
> > come
> > up with an approach to dealing with that, and i think it would be good
> to
> > do
> > this now before trying to graduate.
>
>
> You refer to at least [1]. Separating some of the issues I think are
> involved.
>
> 1 - OASIS doesn't meet the "openness of participation" required set out in
> mail [1]. I believe the issue is that  while all stages of spec
> development
> are open to anyone to see you have to pay to contribute. This is not a
> Tuscany specific issue.
> 2 - Do the IPR terms chosen by the SCA TCs in OASIS make upcoming OSASIS
> specifications suitable for implementation by Tuscany when they appear? I
> guess we need to get the view from legal@ on this.


Are these public yet?

3 - Do the license associated with the OSOA v1.0 specs, that we currently
> implement, cause concern? legal@ again.
> 4 - Some V1.0 specs haven't moved to OASIS, e.g. EJB binding, so we either
> stick with OSOA V1.0, assuming that the licenses are acceptable, or remove
> the binding (I'm assuming here that this is what binding-ejb is)
> 5 - On ongoing OSOA work. Assuming that there is ongoing work and that the
> mode of operation is unchanged, maybe we wait until it reaches OASIS.
>
>...ant
> >
>
> [1]
>
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200607.mbox/[EMAIL 
> PROTECTED]
>

Re: Graduation

[Matthieu Riou]

On 9/26/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Matthieu Riou wrote:
> > Guys,
> >
> > I'm definitely +1 for both graduation and ant as the chair. For the
> tasks,
> > as ant mentioned the graduation guide [1] is definitely a good read. A
> few
> > additional details:
> >
> >  * In your resolution, one of the most important parts is the
> description.
> > Don't be too broad, you can eventually expand the scope later on if
> > necessary (simple request/ack to the board). Right now the wording is
> good
> > but a bit too "fuzzy" I think. It's also good to add a statement about
> how
> > the project can interact or play with other projects.
> >
> > * The other important parts of the resolution are the chair and the PMC
> > list. Look like you're pretty much set on that side. You can choose to
> > extend the PMC too, and add committers that aren't in the PPMC yet but
> would
> > deserve to.
> >
> >  * Make sure that your project status page is up-to-date [2]
> >
> > Once you're set, you can start a formal vote on the board resolution in
> the
> > community. Then you'll ask for the incubator vote. You'll also have to
> take
> > the board schedule into account. Usually meetings are the third
> Wednesday of
> > each month so it's too late for this month but you could be in good
> shape
> > for October (should be the 17th).
> >
> > Cheers!
> > Matthieu
> >
> > [1] http://incubator.apache.org/guides/graduation .html
> > [2] http://incubator.apache.org/projects/tuscany.html
> >
> >
>
> I just looked at the calendar at [3] and I'm not sure what people are
> planning on Sunday but according to this calendar we should start a vote
> on the resolution this Sunday to be in a good shape for the 17th :)


Yeah, the calendar shows more the expected duration of each steps but as a
timeline it's a bit confusing. The tasks can be parallelized and it's also
possible to do stuff on Thursdays and Fridays :) The hard constraints are
the following:

   * the board meeting is the 17th
   * the resolution must be submitted at least 72 hours before (the deadline
is usually Monday) which would be the 15th.
   * the IPMC must have voted the board resolution before, another 72 hours,
usually the week-ends don't count so that would be the 9th
   * finally the community vote is one more 72 hours which would get you to
the 4th.

So you have 4 more days after Sunday :) But there's no reason to rush out,
I'm just clarifying the timeline, you'll be ready when you'll be ready and
you can also target Nov. 21st.

As you said it's better if the resolution is not too fuzzy, I'll try to
> propose small changes to crisp it up a bit (just saw that Haleh just
> proposed some changes to it  too in this thread).
>
> What else can I can help with?


I think that's pretty much it. Compared to everything that comes before,
graduation is a pretty straightforward process (even if it takes time).

Matthieu

[3] http://incubator.apache.org/guides/graduation.html#process
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Graduation

[Matthieu Riou]

On 9/24/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
>
> I have reviewed and updated our STATUS file [1] and Status page (that
> should be refreshed soon) [2] with latest and missing news. Please let
> me know if I missed something :)


Looks good, it's great that you revived this thread!

Any other task from the Graduation checklist [4] that I could help ?


You could maybe start a separate thread to discuss the resolution draft? Is
everybody happy with the description? Also it's a detail but the common
practice is usually to list people Apache e-mail address (@apache.org) for
the PMC as it gives the apache id. You have a nice collection of gmail
addresses though ;)

Matthieu

[1] https://svn.apache.org/repos/asf/incubator/tuscany/STATUS
> [2] http://incubator.apache.org/projects/tuscany.html
> [3] http://incubator.apache.org/guides/graduation.html
> [4] http://incubator.apache.org/guides/graduation#checklist
>
> On 9/13/07, Matthieu Riou <[EMAIL PROTECTED]> wrote:
> > Guys,
> >
> > I'm definitely +1 for both graduation and ant as the chair. For the
> tasks,
> > as ant mentioned the graduation guide [1] is definitely a good read. A
> few
> > additional details:
> >
> >  * In your resolution, one of the most important parts is the
> description.
> > Don't be too broad, you can eventually expand the scope later on if
> > necessary (simple request/ack to the board). Right now the wording is
> good
> > but a bit too "fuzzy" I think. It's also good to add a statement about
> how
> > the project can interact or play with other projects.
> >
> > * The other important parts of the resolution are the chair and the PMC
> > list. Look like you're pretty much set on that side. You can choose to
> > extend the PMC too, and add committers that aren't in the PPMC yet but
> would
> > deserve to.
> >
> >  * Make sure that your project status page is up-to-date [2]
> >
> > Once you're set, you can start a formal vote on the board resolution in
> the
> > community. Then you'll ask for the incubator vote. You'll also have to
> take
> > the board schedule into account. Usually meetings are the third
> Wednesday of
> > each month so it's too late for this month but you could be in good
> shape
> > for October (should be the 17th).
> >
> > Cheers!
> > Matthieu
> >
> > [1] http://incubator.apache.org/guides/graduation .html
> > [2] http://incubator.apache.org/projects/tuscany.html
> >
> >
> > On 9/12/07, Mike Edwards < [EMAIL PROTECTED]> wrote:
> > >
> > > Folks,
> > >
> > > +1. +1.
> > >
> > > Can we start to identify work tasks to get us there and then start to
> > > parcel out work amongst folk on the project?
> > >
> > > Yours,  Mike.
> > >
> > >
> > > ant elder wrote:
> > > > So how about trying to graduate Tuscany from the Incubator? :-)
> > > >
> > > > We seem close though there are a few things to sort out so it will
> take
> > > a
> > > > couple of months to get ready.
> > > >
> > > > There's a draft proposal at
> > > >
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Draft+TLP+Resolution
> > > ,
> > > > we probably need to work on the description which is just taken from
> the
> > > > website home page: "open-source software related to infrastructure
> that
> > > > simplifies the development of service-based application networks and
> > > > addresses real business problems posed in SOA". We also need a bit
> more
> > > > diversity in the initial PMC members listed in the proposal which is
> all
> > > our
> > > > current PPMC members.
> > > >
> > > > I'd like to volunteer to be chair.
> > > >
> > > > There is a graduation guide at
> > > > http://incubator.apache.org/guides/graduation.html .
> > > >
> > > >..ant
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: [VOTE] Release Tuscany Java DAS beta2

[Matthieu Riou]

There are a couple of copyright notices that you should add in your NOTICE
file, mostly derby, stax and woodstox (as described in [1]). Also JSTL is
listed in your LICENSE file although I don't think it's part of the release
(at least not in the binary package). Everything else looks fine to me as
well.

Nothing critical for this release though, so here's my +1.

Matthieu

[1]
http://incubator.apache.org/guides/releasemanagement.html#best-practice-notice

On 9/21/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
>
> Please vote to release the beta2 distribution of Tuscany DAS for Java.
>
> The Release Candidate for Tuscany Java DAS beta2 is available at
>
> http://people.apache.org/~lresende/tuscany/das-beta2-rc1/
>
> Release Notes are available at
>
>
> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta2-rc1/distribution/binary/RELEASE_NOTES
>
> The maven repository artifacts are posted in a staging repository and
> is available at
>
> http://people.apache.org/~lresende/tuscany/das-beta2-rc1/maven/
>
> The release audit tool (rat) results are available at
>
> http://people.apache.org/~lresende/tuscany/das-beta2-rc1/das-beta2-rat.log
>
> The tag for the source code is at
>
>
> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta2-rc1/
>
> Seems OK to me, here is my +1
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: [VOTE] Release Tuscany Java SCA 1.0 RC3a

[Matthieu Riou]

On 9/20/07, Matthieu Riou <[EMAIL PROTECTED]> wrote:
>
> Everything looks good but it seems that a few copyright notices are
> missing in the NOTICE file. Is it generated by Maven? I could spot at least
> XmlBeans, Xalan, Xerces and Derby.


Replying to myself :) Actually I don't see a reason this should delay the
release at hand as it looks pretty good. You should just make sure that this
issue is properly addressed before the next release but I don't think this
is a real problem for now.

So here is my +1.

As that's the only problem I can find, I think you can just patch the
> release archives without the necessity of restarting the vote if you want.
>
> Cheers,
> Matthieu
>
> On 9/20/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
> >
> > +1
> > Kelvin.
> >
> > On 19/09/2007, ant elder <[EMAIL PROTECTED]> wrote:
> > > Please review and vote on the 1.0 release artifacts of Tuscany SCA for
> > Java.
> > >
> > > The SVN tag for the release is:
> > >
> > https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.0-RC3a/
> > >
> > > The artifacts are available for review at:
> > > http://people.apache.org/~antelder/tuscany/1.0-RC3a/<http://people.apache.org/%7Eantelder/tuscany/1.0-RC3a/>
> > <http://people.apache.org/%7Eantelder/tuscany/1.0-RC3a/ >
> > >
> > > This includes the signed binary and source distributions, the RAT
> > reports,
> > > and
> > > the Maven staging repository.
> > >
> > > Many thanks,
> > >
> > >...ant
> > >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

Re: [VOTE] Release Tuscany Java SCA 1.0 RC3a

[Matthieu Riou]

Everything looks good but it seems that a few copyright notices are missing
in the NOTICE file. Is it generated by Maven? I could spot at least
XmlBeans, Xalan, Xerces and Derby.

As that's the only problem I can find, I think you can just patch the
release archives without the necessity of restarting the vote if you want.

Cheers,
Matthieu

On 9/20/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
>
> +1
> Kelvin.
>
> On 19/09/2007, ant elder <[EMAIL PROTECTED]> wrote:
> > Please review and vote on the 1.0 release artifacts of Tuscany SCA for
> Java.
> >
> > The SVN tag for the release is:
> >
> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.0-RC3a/
> >
> > The artifacts are available for review at:
> > http://people.apache.org/~antelder/tuscany/1.0-RC3a/<
> http://people.apache.org/%7Eantelder/tuscany/1.0-RC3a/>
> >
> > This includes the signed binary and source distributions, the RAT
> reports,
> > and
> > the Maven staging repository.
> >
> > Many thanks,
> >
> >...ant
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: implementation-bpel dependencies

[Matthieu Riou]

On 9/15/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> The implementation-bpel brings in nearly 30Meg of new dependency jars, i'm
> guessing a lot of these aren't really necessary and we could exclude them,
> but the list is so long it will take a while to work out, could  any of
> the
> bpel/Ode experts say which they think are essential?


Looks like Maven is doing its magic. Although there seems to be quite a few
duplicates in the list.

The complete list of jars brought in by implementation-bpel is:


I'm adding a '-' in front of the dependencies that aren't needed and a 'd'
when I find a duplicate. I've left the tuscany ones but you'll probably want
to declare them as provided. Ultimately many more could be declared as
provided if they're already bundled in tuscany (like the geronimo
transaction manager and the tranql connection pool).

activation-1.1.jar
> - activeio-2.0-r118.jar
> - ant-1.6.2.jar
> - avalon-framework-4.1.3.jar
> axion-1.0-M3-dev.jar
> backport-util-concurrent-2.2.jar
> - classworlds-1.1-alpha-2.jar
> - common-2.2.3.jar
> commons-codec-1.2.jar
> commons-collections-3.1.jar
> - commons-jexl-1.1.jar
> commons-lang-2.1.jar
> commons-pool-1.3.jar
> commons-primitives-1.0.jar
> derby-10.1.3.1.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_2.1_spec-1.1.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-jms_1.1_spec-1.0.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
> - hsqldb-1.8.0.1.jar
> icu4j-2.6.1.jar
> - javacc-3.2.jar
> jaxen-1.1-beta-8.jar
> - jdom-1.0.jar
> log4j-1.2.12.jar
> - logkit-1.0.1.jar
> - mail-1.4.jar
> - maven-artifact-2.0.2.jar
> - maven-artifact-ant-2.0.4.jar
> - maven-artifact-manager-2.0.2.jar
> - maven-error-diagnostics-2.0.2.jar
> - maven-model-2.0.2.jar
> - maven-profile-2.0.2.jar
> - maven-project-2.0.2.jar
> - maven-repository-metadata-2.0.2.jar
> - maven-settings-2.0.2.jar
> - mx4j-3.0.1.jar
> d geronimo-connector-1.2-beta.jar
> d geronimo-core-1.2-beta.jar
> d geronimo-deployment-1.2-beta.jar
> d geronimo-ejb_2.1_spec-1.1.jar
> d geronimo-interceptor-1.2-beta.jar
> d geronimo-j2ee-1.2-beta.jar
> d geronimo-j2ee-connector_1.5_spec-1.1.jar
> d geronimo-j2ee-jacc_1.0_spec-1.1.jar
> d geronimo-j2ee-management_1.0_spec-1.1.jar
> d geronimo-jms_1.1_spec-1.0.1.jar
> d geronimo-jpa_3.0_spec-1.0.jar
> d geronimo-jta_1.0.1B_spec-1.0.jar
> d geronimo-kernel-1.2-beta.jar
> d geronimo-management-1.2-beta.jar
> d geronimo-naming-1.2-beta.jar
> d geronimo-security-1.2-beta.jar
> d geronimo-spec-j2ee-connector-1.5-rc4.jar
> d geronimo-spec-jta-1.0.1B-rc4.jar
> d geronimo-system-1.2-beta.jar
> d geronimo-transaction-1.2-beta.jar
> d geronimo-util-1.2-beta.jar
> d howl-1.0.1-1.jar
> d hsqldb-1.8.0.1.jar
> d icu4j-2.6.1.jar
> d javacc-3.2.jar
> d jdom-1.0.jar
> d log4j-1.2.12.jar
> d logkit-1.0.1.jar
> d mail-1.4.jar
> d maven-artifact-2.0.2.jar
> d maven-artifact-ant-2.0.4.jar
> d maven-artifact-manager-2.0.2.jar
> d maven-error-diagnostics-2.0.2.jar
> d maven-model-2.0.2.jar
> d maven-profile-2.0.2.jar
> d maven-project-2.0.2.jar
> d maven-repository-metadata-2.0.2.jar
> d maven-settings-2.0.2.jar
> d mx4j-3.0.1.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
> - ognl-2.6.9.jar
> openjpa-all-0.9.7-incubating.jar
> - openjpa-jdbc-0.9.7-incubating.jar
> - openjpa-jdbc-5-0.9.7-incubating.jar
> - openjpa-kernel-0.9.7-incubating.jar
> - openjpa-kernel-5-0.9.7-incubating.jar
> - openjpa-lib-0.9.7-incubating.jar
> - openjpa-persistence-0.9.7-incubating.jar
> - openjpa-persistence-jdbc-0.9.7-incubating.jar
> - openjpa-xmlstore-0.9.7-incubating.jar
> - plexus-container-default-1.0-alpha-9.jar
> - plexus-utils-1.1.jar
> - quartz-1.5.2.jar
> regexp-1.3.jar
> saxon-8.7.jar
> saxon-dom-8.7.jar
> saxon-xpath-8.7.jar
> serp-1.12.0.jar
> - servlet-api-2.3.jar
> - tagsoup-0.9.7.jar
> tranql-connector-1.1.jar
> tuscany-databinding-axiom-1.0-incubating.jar
> tuscany-implementation-bpel-1.0-incubating.jar
> tuscany-interface-wsdl-1.0-incubating.jar
> tuscany-interface-wsdl-xml-1.0-incubating.jar
> tuscany-sdo-api-r2.1-1.0

Re: SCA & WS-BPEL - Initial support available

[Matthieu Riou]

Super! Thanks Luciano!

Matthieu

On 9/15/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
>
> This is a quick note to let the community know that I managed to get
> initial WS-BPEL component implementation ready just in time for our
> SCA 1.0 release. As described in  [1] and [2], we can now invoke
> executables WS-BPEL process from an SCA runtime. As for a WS-BPEL
> engine, we are using Apache ODE [3][4].The current implementation.bpel
> is available in trunk at [5] and you can see a simple helloWorld BPEL
> process being invoked. I'm working on a new sample to better
> demonstrate the usage of this new component type, I'll also look into
> references as well.
>
> I'd also like to Thank all the help from the ODE community, especially
> Matthieu Riou.
>
>
> [1] http://osoa.org/display/Main/SCA+BPEL+White+Paper
> [2]
> http://osoa.org/download/attachments/35/SCA_ClientAndImplementationModelforBPEL_V100.pdf?version=1
> [3] http://ode.apache.org
> [4] http://www.infoq.com/articles/paul-brown-ode
> [5]
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-bpel/
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: SCA 1.0 RC1 artifacts available for review

[Matthieu Riou]

Did anybody try RAT [1] (the tool the IPMC usually use to check releases) on
it? Otherwise I can give it a try.

Matthieu

[1] http://code.google.com/p/arat/

On 9/14/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> The 1.0 RC1 tag has been taken and is available for checking out and
> building:
> https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.0-incubating/
>
>
> If you don't want to build it yourself the distributions are up loading
> to:
> http://people.apache.org/~antelder/tuscany/1.0-RC1/<
> http://people.apache.org/%7Eantelder/tuscany/1.0-RC1/>
>
> And the maven artifacts will be uploaded to:
> http://people.apache.org/~antelder/tuscany/1.0-RC1/maven/<
> http://people.apache.org/%7Eantelder/tuscany/1.0-RC1/maven/>
>
> The Windows distribution is up, at the current speed it will be another
> couple of hours till everything is up including all the maven artifacts.
>
> I wont call a vote on this RC as we know its not quite perfect yet, please
> review and fix any issues or raises jira's for problems you find. I'll
> create an RC2 late Monday morning GMT and call a vote on releasing that
> unless there are critical or blocker defects still open against 1.0. At
> that
> time any non critical or blocker JIRA's still open will be deferred to
> Java-SCA-Next.
>
>...ant
>

Re: Graduation

[Matthieu Riou]

Guys,

I'm definitely +1 for both graduation and ant as the chair. For the tasks,
as ant mentioned the graduation guide [1] is definitely a good read. A few
additional details:

 * In your resolution, one of the most important parts is the description.
Don't be too broad, you can eventually expand the scope later on if
necessary (simple request/ack to the board). Right now the wording is good
but a bit too "fuzzy" I think. It's also good to add a statement about how
the project can interact or play with other projects.

* The other important parts of the resolution are the chair and the PMC
list. Look like you're pretty much set on that side. You can choose to
extend the PMC too, and add committers that aren't in the PPMC yet but would
deserve to.

 * Make sure that your project status page is up-to-date [2]

Once you're set, you can start a formal vote on the board resolution in the
community. Then you'll ask for the incubator vote. You'll also have to take
the board schedule into account. Usually meetings are the third Wednesday of
each month so it's too late for this month but you could be in good shape
for October (should be the 17th).

Cheers!
Matthieu

[1] http://incubator.apache.org/guides/graduation .html
[2] http://incubator.apache.org/projects/tuscany.html


On 9/12/07, Mike Edwards < [EMAIL PROTECTED]> wrote:
>
> Folks,
>
> +1. +1.
>
> Can we start to identify work tasks to get us there and then start to
> parcel out work amongst folk on the project?
>
> Yours,  Mike.
>
>
> ant elder wrote:
> > So how about trying to graduate Tuscany from the Incubator? :-)
> >
> > We seem close though there are a few things to sort out so it will take
> a
> > couple of months to get ready.
> >
> > There's a draft proposal at
> > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Draft+TLP+Resolution
> ,
> > we probably need to work on the description which is just taken from the
> > website home page: "open-source software related to infrastructure that
> > simplifies the development of service-based application networks and
> > addresses real business problems posed in SOA". We also need a bit more
> > diversity in the initial PMC members listed in the proposal which is all
> our
> > current PPMC members.
> >
> > I'd like to volunteer to be chair.
> >
> > There is a graduation guide at
> > http://incubator.apache.org/guides/graduation.html .
> >
> >..ant
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Tuscany mentor changes

[Matthieu Riou]

On 9/11/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> An update on some changes to the Tuscany incubation mentors:
>
> - Dims has stepped down as mentor. Many many thanks for all the help and
> guidance during our incubation, its been invaluable.
>
> - Paul Fremantle and Matthieu Riou have signed up as new mentors joining
> Sam so we now have three. Thanks guys and welcome aboard.
>
>...ant


Sorry for the late reply, I was a bit swamped. Thanks a lot for the welcome
and I hope we can all work to make from Tuscany a successful graduation
soon!

Cheers,
Matthieu

Re: Fisheye view for the Apache Tuscany repository?

[Matthieu Riou]

I think there's nothing specific to do on the Apache infra side. You just
need to send an e-mail to Cenqua at [EMAIL PROTECTED] to ask them
to add your project.

Cheers,
Matthieu

On 8/3/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
>
> I was wondering if it would be possible to get Fisheye setup for
> Apache Tuscany tree?
>
>https://svn.apache.org/repos/asf/incubator/tuscany/
>
> Fisheye is a wonderful tool and the Tuscany community would benefit by
> having this tool available. Would it be possible to get this setup
> similar to other ASF projects [1].
>
>
> [1] http://fisheye6.cenqua.com/
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: BPEL implementation: WSDL and BPEL resolving

[Matthieu Riou]

Hi Raymond,

Sorry for the late reply, your e-mail passed through my filters :) The
approach described in the document sounds good to me, it's similar to what
we're doing for import resolution within an ODE deployment package. So that
should work. The only part I'm not so clear about though is when the
resolution occurs, is it when the contribution is loaded?

And thanks for the congrats!

Matthieu

On 7/31/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
>
> Hi, Matthieu.
>
> Congratulations on the ODE graduation!
>
> We have made some processes in Tuscany regarding to the artifact
> resolving.
> Please see more details at
>
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Resolving+WSDL+and+XSD+artifacts
> .
>
> I think the strategy will apply to BPEL as well. Would you please take a
> look? Hopefully, we can get the implementation.bpel working soon.
>
> Thanks,
> Raymond
>
> - Original Message -
> From: "Matthieu Riou" <[EMAIL PROTECTED]>
> To: "Luciano Resende" <[EMAIL PROTECTED]>
> Cc: 
> Sent: Thursday, July 05, 2007 5:08 PM
> Subject: Re: BPEL implementation: WSDL and BPEL resolving
>
>
> > Sure, no problem. And thanks :-)
> >
> > On 7/5/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> >>
> >> Thanks Matthieu
> >>
> >>I'm little overbooked these days, but let me see if I could try to
> >> look into the resolution thing over the weekend. Is that OK ?
> >>
> >> On 7/5/07, Matthieu Riou <[EMAIL PROTECTED]> wrote:
> >> > Hi guys,
> >> >
> >> > I've done a few additional stuff on the BPEL implementation allowing
> a
> >> BPEL
> >> > file to be compiled by ODE upon deployment. The implementation is
> >> therefore
> >> > created and initialized with most of what would be needed by the
> >> runtime.
> >> > However there's still a couple of problems with resolution and
> finding
> >> my
> >> > way inside Tuscany code isn't that easy.
> >> >
> >> > To resolve the WSDL implemented by the process I've been trying to go
> >> > through the resolution mechanism and declare the implementation I
> >> > return
> >> in
> >> > the read() method of the processor as unresolved. However the
> resolve()
> >> > method is never called afterward and this results in a
> >> NullPointerException
> >> > in Tuscany as the InterfaceContract is never set. From what I could
> >> > make
> >> out
> >> > of the code, it seems that the resolution mechanism happens for
> >> Interface
> >> > processors but not of implementations, but I could be wrong.
> >> >
> >> > I've created a patch that adds the BPEL compilation and demonstrates
> >> > the
> >> > problem using the test case. Please have a look at
> >> > BPELImplementationProcessor, you'll see how the implementation is
> >> > built.
> >> > You'll also see that the BPEL file from now is directly loaded using
> an
> >> > additional "file" attribute. Ideally that should go as well to use
> the
> >> same
> >> > type of resolving as for the WSDL (when it will work).
> >> >
> >> > Some help regarding this would be definitely welcome...
> >> >
> >> > Thanks,
> >> > Matthieu
> >> >
> >>
> >>
> >> --
> >> Luciano Resende
> >> Apache Tuscany Committer
> >> http://people.apache.org/~lresende
> >> http://lresende.blogspot.com/
> >>
> >
>
>

Re: BPEL implementation: WSDL and BPEL resolving

[Matthieu Riou]

Sure, no problem. And thanks :-)

On 7/5/07, Luciano Resende <[EMAIL PROTECTED]> wrote:


Thanks Matthieu

   I'm little overbooked these days, but let me see if I could try to
look into the resolution thing over the weekend. Is that OK ?

On 7/5/07, Matthieu Riou <[EMAIL PROTECTED]> wrote:
> Hi guys,
>
> I've done a few additional stuff on the BPEL implementation allowing a
BPEL
> file to be compiled by ODE upon deployment. The implementation is
therefore
> created and initialized with most of what would be needed by the
runtime.
> However there's still a couple of problems with resolution and finding
my
> way inside Tuscany code isn't that easy.
>
> To resolve the WSDL implemented by the process I've been trying to go
> through the resolution mechanism and declare the implementation I return
in
> the read() method of the processor as unresolved. However the resolve()
> method is never called afterward and this results in a
NullPointerException
> in Tuscany as the InterfaceContract is never set. From what I could make
out
> of the code, it seems that the resolution mechanism happens for
Interface
> processors but not of implementations, but I could be wrong.
>
> I've created a patch that adds the BPEL compilation and demonstrates the
> problem using the test case. Please have a look at
> BPELImplementationProcessor, you'll see how the implementation is built.
> You'll also see that the BPEL file from now is directly loaded using an
> additional "file" attribute. Ideally that should go as well to use the
same
> type of resolving as for the WSDL (when it will work).
>
> Some help regarding this would be definitely welcome...
>
> Thanks,
> Matthieu
>


--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

BPEL implementation: WSDL and BPEL resolving

[Matthieu Riou]

Hi guys,

I've done a few additional stuff on the BPEL implementation allowing a BPEL
file to be compiled by ODE upon deployment. The implementation is therefore
created and initialized with most of what would be needed by the runtime.
However there's still a couple of problems with resolution and finding my
way inside Tuscany code isn't that easy.

To resolve the WSDL implemented by the process I've been trying to go
through the resolution mechanism and declare the implementation I return in
the read() method of the processor as unresolved. However the resolve()
method is never called afterward and this results in a NullPointerException
in Tuscany as the InterfaceContract is never set. From what I could make out
of the code, it seems that the resolution mechanism happens for Interface
processors but not of implementations, but I could be wrong.

I've created a patch that adds the BPEL compilation and demonstrates the
problem using the test case. Please have a look at
BPELImplementationProcessor, you'll see how the implementation is built.
You'll also see that the BPEL file from now is directly loaded using an
additional "file" attribute. Ideally that should go as well to use the same
type of resolving as for the WSDL (when it will work).

Some help regarding this would be definitely welcome...

Thanks,
Matthieu

[jira] Updated: (TUSCANY-1413) WSDL and BPEL resolving

[Matthieu Riou (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Riou updated TUSCANY-1413:
---

Attachment: patch.txt

> WSDL and BPEL resolving
> ---
>
> Key: TUSCANY-1413
> URL: https://issues.apache.org/jira/browse/TUSCANY-1413
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA BEPL Implementation Extension
>    Reporter: Matthieu Riou
>Priority: Minor
> Attachments: patch.txt, patch.zip
>
>
> I've done a few additional stuff on the BPEL implementation allowing a BPEL 
> file to be compiled by ODE upon deployment. The implementation is therefore 
> created and initialized with most of what would be needed by the runtime. 
> However there's still a couple of problems with resolution and finding my way 
> inside Tuscany code isn't that easy.
> To resolve the WSDL implemented by the process I've been trying to go through 
> the resolution mechanism and declare the implementation I return in the 
> read() method of the processor as unresolved. However the resolve() method is 
> never called afterward and this results in a NullPointerException in Tuscany. 
> From what I could make out of the code, it seems that the resolution 
> mechanism happens for Interface processors but not of implementations, but I 
> could be wrong.
> This patch adds the BPEL compilation and demonstrates the problem using the 
> test case. Please have a look at BPELImplementationProcessor, you'll see how 
> the implementation is built. You'll also see that the BPEL file from now is 
> directly loaded using an additional "file" attribute. Ideally that should go 
> as well to use the same type of resolving as for the WSDL (when it will work).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1413) WSDL and BPEL resolving

[Matthieu Riou (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Riou updated TUSCANY-1413:
---

Attachment: patch.zip

> WSDL and BPEL resolving
> ---
>
> Key: TUSCANY-1413
> URL: https://issues.apache.org/jira/browse/TUSCANY-1413
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA BEPL Implementation Extension
>    Reporter: Matthieu Riou
>Priority: Minor
> Attachments: patch.txt, patch.zip
>
>
> I've done a few additional stuff on the BPEL implementation allowing a BPEL 
> file to be compiled by ODE upon deployment. The implementation is therefore 
> created and initialized with most of what would be needed by the runtime. 
> However there's still a couple of problems with resolution and finding my way 
> inside Tuscany code isn't that easy.
> To resolve the WSDL implemented by the process I've been trying to go through 
> the resolution mechanism and declare the implementation I return in the 
> read() method of the processor as unresolved. However the resolve() method is 
> never called afterward and this results in a NullPointerException in Tuscany. 
> From what I could make out of the code, it seems that the resolution 
> mechanism happens for Interface processors but not of implementations, but I 
> could be wrong.
> This patch adds the BPEL compilation and demonstrates the problem using the 
> test case. Please have a look at BPELImplementationProcessor, you'll see how 
> the implementation is built. You'll also see that the BPEL file from now is 
> directly loaded using an additional "file" attribute. Ideally that should go 
> as well to use the same type of resolving as for the WSDL (when it will work).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-1413) WSDL and BPEL resolving

[Matthieu Riou (JIRA)]

WSDL and BPEL resolving
---

 Key: TUSCANY-1413
 URL: https://issues.apache.org/jira/browse/TUSCANY-1413
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA BEPL Implementation Extension
Reporter: Matthieu Riou
Priority: Minor


I've done a few additional stuff on the BPEL implementation allowing a BPEL 
file to be compiled by ODE upon deployment. The implementation is therefore 
created and initialized with most of what would be needed by the runtime. 
However there's still a couple of problems with resolution and finding my way 
inside Tuscany code isn't that easy.

To resolve the WSDL implemented by the process I've been trying to go through 
the resolution mechanism and declare the implementation I return in the read() 
method of the processor as unresolved. However the resolve() method is never 
called afterward and this results in a NullPointerException in Tuscany. From 
what I could make out of the code, it seems that the resolution mechanism 
happens for Interface processors but not of implementations, but I could be 
wrong.

This patch adds the BPEL compilation and demonstrates the problem using the 
test case. Please have a look at BPELImplementationProcessor, you'll see how 
the implementation is built. You'll also see that the BPEL file from now is 
directly loaded using an additional "file" attribute. Ideally that should go as 
well to use the same type of resolving as for the WSDL (when it will work).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Resolving files, getting the component interface

[Matthieu Riou]

Hi,

Thanks for the reply, see my comments in line:

On 7/2/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


We can follow the QName resolving approach to
figure out which BPEL file to use.



Do you have some pointers and code that I can look at to see how this
resolving is done in Tuscany right now? In case I need to extend it for
BPEL.

During the processing of a SCA

contribution, we can create a BPELImplementation w/ the QName and mark it
unresolved. For each BEPL file, we can record an entry to associate an
BPEL
file with the QName of the process. After resolving the QName of a process
to a BPEL model, we can use the QName of the portType from the
partLinkType
in BEPL file to tell the WSDLs.



Right but if I'm following correctly that means that the process will only
be really loaded when the implementation is first used (say on the first
message). That means that the process is only compiled and validated at that
time which makes me a bit nervous. Basically no static validation of a
deployed process would be done before the first message and you would then
need to invoke to find out what's possibly wrong with your process. Ideally
the process should be fully loaded with the contribution.

Cheers,
Matthieu

Thanks,

Raymond

- Original Message -
From: "Matthieu Riou" <[EMAIL PROTECTED]>
To: 
Sent: Monday, July 02, 2007 9:27 AM
Subject: Resolving files, getting the component interface


> Hi guys,
>
> I'm continuing on the ODE / Tuscany integration and I have a few more
> riddles. Say that I have to following composite:
>
> http://www.osoa.org/xmlns/sca/1.0"; targetNamespace="
> http://bpel";
>xmlns:sc="http://bpel"; xmlns:c="http://bpel"; name="bpel">
>
> promote="BPELHelloWorldComponent">
>interface="
>
http://tuscany.apache.org/implementation/bpel/example/helloworld.wsd#wsdl.interface(HelloPortType)
"
> />
>
>
>
>
>
> 
>
>
> I have 2 problems here:
>
> 1. How can I retrieve the WSDL interface associated with the BPEL
> implementation? I need basic information about that WSDL to be able to
> load
> the BPEL file and register it in ODE.
> 2. How do I load the BPEL file? I could add a specific attribute for the
> file name but it's not so nice. Is there something that I can reuse
that's
> already been implemented? I think you automatically load all the WSDLs
> from
> a contribution for example and then check from the namespace when you
need
> to retrieve something. Can I plug into that resolution mechanism?
>
> I've been looking a bit at the code but a lot of the WSDL-related work
is
> done in binding components that seem to reuse common binding-specific
> code.
>
> Thanks!
> Matthieu
>

Resolving files, getting the component interface

[Matthieu Riou]

Hi guys,

I'm continuing on the ODE / Tuscany integration and I have a few more
riddles. Say that I have to following composite:

http://www.osoa.org/xmlns/sca/1.0"; targetNamespace="
http://bpel";
   xmlns:sc="http://bpel"; xmlns:c="http://bpel"; name="bpel">

   
 http://tuscany.apache.org/implementation/bpel/example/helloworld.wsd#wsdl.interface(HelloPortType)"
/>
   

   
   
   



I have 2 problems here:

1. How can I retrieve the WSDL interface associated with the BPEL
implementation? I need basic information about that WSDL to be able to load
the BPEL file and register it in ODE.
2. How do I load the BPEL file? I could add a specific attribute for the
file name but it's not so nice. Is there something that I can reuse that's
already been implemented? I think you automatically load all the WSDLs from
a contribution for example and then check from the namespace when you need
to retrieve something. Can I plug into that resolution mechanism?

I've been looking a bit at the code but a lot of the WSDL-related work is
done in binding components that seem to reuse common binding-specific code.

Thanks!
Matthieu

[jira] Updated: (TUSCANY-1394) Database import for tests, using ODE released version

[Matthieu Riou (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Riou updated TUSCANY-1394:
---

Attachment: patch.zip

Unzip in implementation-bpel.

> Database import for tests, using ODE released version
> -
>
> Key: TUSCANY-1394
> URL: https://issues.apache.org/jira/browse/TUSCANY-1394
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA BEPL Implementation Extension
>    Reporter: Matthieu Riou
> Attachments: patch.txt, patch.zip
>
>
> The attached path corrects 2 things so that the module can compile and have 
> passing tests without any tweaking:
> - The ODE derby database gets downloaded as a regular dependency and unzipped 
> in the test directory before tests are executed. 
> - Using released version of ODE instead of a local snapshot 
> (ode-1.0-incubating). If a more recent version of ODE is needed, I'll publish 
> a snapshot version.
> After this patch is applied, the module should compile and the test should 
> run without any prior tweaking (like compiling ODE and such).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1394) Database import for tests, using ODE released version

[Matthieu Riou (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Riou updated TUSCANY-1394:
---

Attachment: patch.txt

Patch to apply to implementation-bpel.

> Database import for tests, using ODE released version
> -
>
> Key: TUSCANY-1394
> URL: https://issues.apache.org/jira/browse/TUSCANY-1394
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA BEPL Implementation Extension
>    Reporter: Matthieu Riou
> Attachments: patch.txt, patch.zip
>
>
> The attached path corrects 2 things so that the module can compile and have 
> passing tests without any tweaking:
> - The ODE derby database gets downloaded as a regular dependency and unzipped 
> in the test directory before tests are executed. 
> - Using released version of ODE instead of a local snapshot 
> (ode-1.0-incubating). If a more recent version of ODE is needed, I'll publish 
> a snapshot version.
> After this patch is applied, the module should compile and the test should 
> run without any prior tweaking (like compiling ODE and such).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-1394) Database import for tests, using ODE released version

[Matthieu Riou (JIRA)]

Database import for tests, using ODE released version
-

 Key: TUSCANY-1394
 URL: https://issues.apache.org/jira/browse/TUSCANY-1394
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA BEPL Implementation Extension
Reporter: Matthieu Riou
 Attachments: patch.txt, patch.zip

The attached path corrects 2 things so that the module can compile and have 
passing tests without any tweaking:

- The ODE derby database gets downloaded as a regular dependency and unzipped 
in the test directory before tests are executed. 
- Using released version of ODE instead of a local snapshot 
(ode-1.0-incubating). If a more recent version of ODE is needed, I'll publish a 
snapshot version.

After this patch is applied, the module should compile and the test should run 
without any prior tweaking (like compiling ODE and such).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Implementation.bpel

[Matthieu Riou]

Hi,

See my answers in line:

On 6/24/07, Luciano Resende <[EMAIL PROTECTED]> wrote:


   I have committed your initial patch for Tuscany-1365, and also
provided a summary of the necessary steps to build ODE  [1] for the
ones interested on playing with the implementation at the moment.



Perfect, thanks!

  One thing I noticed is that some required databases

(ode-work/jpadb) is not being created (if not present)... is this a
configuration issue as we were discussing on [2] or something that we
need to investigate further ?



Actually that's something I indicated in the bug report. The database is
required if we want meaningful tests and for now it must be copied manually.
I'll try to make Maven2 download it and unzip it somewhere, I just have to
pay the time toll that goes with any non-trivial Maven2 task :)

I'll try to have another patch ready today or tomorrow.

Cheers,
Matthieu

[1]

http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+implementation.bpel
[2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg19068.html

--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tuscany/ODE resources questions

[Matthieu Riou]

Hi Simon,

Please see my answers in line:

On 6/22/07, Simon Laws <[EMAIL PROTECTED]> wrote:


Can I just check that I understood what you have said. I.e. that "there
will be only one ODE server instance on which processes will
be deployed". Does this mean,

1 ODE server instance per Tuscany runtime node (a tuscany Java SCA runtime
in a Java VM) - I think this is the case given what you say about module
activator
Or
1 ODE service instance per machine that handles any number of tuscany
runtime nodes.



Your first statement is the right one yes, one ODE server per Tuscany
runtime node.

I'm asking because one of the things I'm interested in is how we manage a

domain running across multiple runtime nodes.



So if I understand correctly we're talking about clustering here. As far as
ODE is concerned, I believe both deployment models should be supported: one
single ODE instance that all Tuscany nodes use (locally or remotely
depending on where the instance is physically instantiated) and one instance
per node (and in that second deployment model, ODE would need to support
clustering). From the ODE standpoint the first mode is the easiest to
support (no need to be clustering aware and handle state propagation) and
it's not quite what we're doing right now. So I guess we'd have to migrate
at some point to that mode when it's possible?

Looking to the future I have to be able to provide such data out to nodes

remotely. To allow for this each distributed runtime node starts a small SCA
assembly purely for managing meta data, I.e. it defines services with
interfaces for reading and writing specific meta data. In that way I can use
any SCA binding to send data to a node. So a binding could still allow the
data to be read from a (distributed) file system but it doesn't have to be.



Sounds good. That's actually more or less what I was thinking of  when I
mentioned the usage of files, configuration or any type of external
resource. Ideally, within Tuscany, ODE shouldn't care about where things are
physically located.

I'm not suggesting you do anything about this specifically yet but I would

like to talk about it as the implementation progresses just in case we have
to do anthing to keep ODE happy.



Yep, good idea. When the implementation matures we'll have to answer to
those questions so it's good to ask them early :)

Thanks,
Matthieu

Regards


Simon

Re: Tuscany ODE - integration

[Matthieu Riou]

Hi Sam,

I've submitted a patch yesterday to apply on the skeleton that Luciano
provided (see [1]). It's a first step to get something up and running. I'm
also discussing with the Tuscany guys how to handle the ODE configuration
(see [2]). As for process deployment, we wouldn't have a deployment
directory as in the "standard" ODE as the deployment is going to be provided
by Tuscany as a SCA assembly (which is basically going to break our process
store but one problem at a time :) ).

So please have a look at the patch and check the SCA assembly model
specification [3]. From there we can start incrementing.

Matthieu

[1] https://issues.apache.org/jira/browse/TUSCANY-1365
[2]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200706.mbox/[EMAIL 
PROTECTED]
[3
http://www.osoa.org/download/attachments/35/SCA_AssemblyModel_V100.pdf?version=1
]

On 6/22/07, sam tam <[EMAIL PROTECTED]> wrote:


Hello,

In the process on integrating Tuscany & ODE,

I have started to with implementation-bpel [skeleton available in the
trunk]

To start with,

In order to invoke a Bpel Process in ODE,
we require
1) Deployment Directory
2) Service Id
3) Operation [from wsdl / java interface ]
4) Input Args.

So my plan is to provide DeploymentDir & ServiceId in the composite file.

In order to invoke, we have an interface and client as usual. In the
client
the we invoke : bpelservice.hello(Input_Args) where hello - operation
name.

By this we can start with an initial run. In the Invoker of Bpel
Implementation we can setUp, Run, invoke bpel process get response and
finally tear down ODE runtime.


Am almost done with this work except one problem:
In this process of Invocation :
Considering CRUD sample /Bpel_Implemenation skeleton, the function
name(Operation Name eg: hello,create etc..) for the client is given in the
CRUD interface

https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/implementation-crud-extension/src/main/java/crud/CRUD.java


But this Implementation is specific for one client ,  how  to do such that
runtime automatically finds the impl of the user defined methods,
and goes on invoking it ?

Is my approach for the integartion  Tuscany / ODE acceptabe ?


Kindly provide your views..[esp. Lucaino , Matthieu , Ant and all other
members ]

Sam...

Re: Tuscany/ODE resources questions

[Matthieu Riou]

I don't know what would be the best way from the Tuscany standpoint, but
having some sort of configuration object (maybe a StAXArtifactProcessor)
mirroring part of a global Tuscany configuration and available in the module
activator would be nice. And you'll probably have people at some point who
will ask you how they can configure this or that in Jetty or Tomcat.

And yes, there will be only one ODE server instance on which processes will
be deployed. The approach I used for now is to instantiate a server wrapper
in the module activator and initialize the engine lazily in the provider,
when the first implementation is started.

Matthieu

On 6/22/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:


Is this something that we should consider permitting thro external config
files ?  And how would it work - the contribution service picks the
resource
up and makes it available to the module activators  ?

Thanks

- Venkat


On 6/22/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
>
> I'm still reviewing the patch provided by Matthieu [1], but I think he
> is taking the similar approach we have for the embedded hosts.
>
> I think that, one difference, is that we don't necessary expose or let
> the user tweak server configuration when we start an embedded jetty or
> tomcat, do we ?
>
> [1] http://issues.apache.org/jira/browse/TUSCANY-1365
>
> On 6/22/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I assume there is going to be just about 'one' ODE instance which
might
> be
> > running several processes that are implementations of different
> components
> > in a deployment.  Is the ODE server something that we should implement
> on
> > lines with the 'hosts' that we have have ?   Thoughts ?
> >
> > - Venkat
> >
> > On 6/21/07, Matthieu Riou <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi guys,
> > >
> > > I'm starting on the lifecycle part of the Tuscany/ODE integration to
> get
> > > an
> > > engine started with all its necessary resources (transaction,
> persistence,
> > > ...). I can go with in-memory mode and light configuration for now
but
> > > we'll
> > > want a fully working server sooner or later. So I have a few
> questions:
> > >
> > > 1. How can I get server-wide configuration properties to configure
the
> > > behavior of the engine? Things like the size of our thread pool, if
we
> > > should use an embedded database or try to lookup a datasource, some
> memory
> > > optimization modes we can run in, ... These would be for the whole
ODE
> > > server and not on a per-process basis.
> > >
> > > 2. How can I get the a transaction manager? I haven't been able to
> find an
> > > extension point for it. If there are none available, I can still
> create my
> > > own but it'd be probably be better to reuse the Tuscany one if it's
> there.
> > >
> > > 3. In embedded persistence mode, ODE uses a Derby database. Which
> means
> > > files located somewhere. Is there a way to lookup a given directory
> under
> > > which the database could be made available? For example when we
deploy
> ODE
> > > in a webapp for example, the database is prepackage in the webapp
and
> we
> > > find it under the context root (or alternatively a path can be
> configured,
> > > see 1)
> > >
> > > I think that's all for now but I'll certainly find more in the
coming
> days
> > > :)
> > >
> > > Thanks!
> > > Matthieu
> > >
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

[jira] Updated: (TUSCANY-1365) Bootstrap the ODE server in the BPEL implementation

[Matthieu Riou (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Riou updated TUSCANY-1365:
---

Attachment: ode-init.zip

Zip file to unzip in implementation-bpel

> Bootstrap the ODE server in the BPEL implementation
> ---
>
> Key: TUSCANY-1365
> URL: https://issues.apache.org/jira/browse/TUSCANY-1365
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SCA BPEL Implementation Extension
>    Reporter: Matthieu Riou
> Attachments: ode-init.patch, ode-init.zip
>
>
> I'm attaching a patch and a zip (for new files) containing the necessary code 
> to bootstrap the ODE BPEL server. It actually doesn't give you much as it's 
> just initializing all resources needed by the server and then loading it, so 
> nothing is there for exchanging messages. But it's already a start.
> Testing is a bit rough as it's still very preliminary but here are the steps 
> to get the test case to run:
> 1. You'll need to build ODE locally first. I'm basing the code on ODE's trunk 
> as some tweaks or improvements here and there will probably be needed in ODE 
> as well. Later on, when the implementation is bit more stable, I'll publish 
> snapshots and eventually transition to an ODE release. In the meantime, here 
> is how to build ODE (using buildr):
> http://incubator.apache.org/ode/jacob.html
> Run the "install" task instead of "package" to have the created jars 
> published in your local directory.
> 2. The server initializes Derby, so you need to have a Derby database. For 
> now it will be looking for it in an ode-work subdirectory of the BPEL 
> implementation root directory (until we implement a better way to find it). 
> Create this directory and copy the jpadb directory found in 
> ode/dao-jpa-ojpa-derby/target/derby after ODE has been built in it. You 
> should end up with implementation-bpel/ode-work/jpadb.
> 3. Run "mvn test". Maven2 being a pain, it will download the whole world. 
> Several things aren't actually required but come with transitive 
> dependencies, we'll have to exclude things at some point but for now it 
> should work.
> If the Maven2 build fails because it couldn't download a dependency, you'll 
> need to add some remote repositories. Here are the ones we have in ODE:
> repositories.remote << "http://pxe.intalio.org/public/maven2";
> repositories.remote << 
> "http://people.apache.org/repo/m2-incubating-repository";
> repositories.remote << "http://repo1.maven.org/maven2";
> repositories.remote << "http://people.apache.org/repo/m2-snapshot-repository";
> Thanks!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TUSCANY-1365) Bootstrap the ODE server in the BPEL implementation

[Matthieu Riou (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthieu Riou updated TUSCANY-1365:
---

Attachment: ode-init.patch

Patch file to apply in implementation-bpel

> Bootstrap the ODE server in the BPEL implementation
> ---
>
> Key: TUSCANY-1365
> URL: https://issues.apache.org/jira/browse/TUSCANY-1365
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SCA BPEL Implementation Extension
>    Reporter: Matthieu Riou
> Attachments: ode-init.patch
>
>
> I'm attaching a patch and a zip (for new files) containing the necessary code 
> to bootstrap the ODE BPEL server. It actually doesn't give you much as it's 
> just initializing all resources needed by the server and then loading it, so 
> nothing is there for exchanging messages. But it's already a start.
> Testing is a bit rough as it's still very preliminary but here are the steps 
> to get the test case to run:
> 1. You'll need to build ODE locally first. I'm basing the code on ODE's trunk 
> as some tweaks or improvements here and there will probably be needed in ODE 
> as well. Later on, when the implementation is bit more stable, I'll publish 
> snapshots and eventually transition to an ODE release. In the meantime, here 
> is how to build ODE (using buildr):
> http://incubator.apache.org/ode/jacob.html
> Run the "install" task instead of "package" to have the created jars 
> published in your local directory.
> 2. The server initializes Derby, so you need to have a Derby database. For 
> now it will be looking for it in an ode-work subdirectory of the BPEL 
> implementation root directory (until we implement a better way to find it). 
> Create this directory and copy the jpadb directory found in 
> ode/dao-jpa-ojpa-derby/target/derby after ODE has been built in it. You 
> should end up with implementation-bpel/ode-work/jpadb.
> 3. Run "mvn test". Maven2 being a pain, it will download the whole world. 
> Several things aren't actually required but come with transitive 
> dependencies, we'll have to exclude things at some point but for now it 
> should work.
> If the Maven2 build fails because it couldn't download a dependency, you'll 
> need to add some remote repositories. Here are the ones we have in ODE:
> repositories.remote << "http://pxe.intalio.org/public/maven2";
> repositories.remote << 
> "http://people.apache.org/repo/m2-incubating-repository";
> repositories.remote << "http://repo1.maven.org/maven2";
> repositories.remote << "http://people.apache.org/repo/m2-snapshot-repository";
> Thanks!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-1365) Bootstrap the ODE server in the BPEL implementation

[Matthieu Riou (JIRA)]

Bootstrap the ODE server in the BPEL implementation
---

 Key: TUSCANY-1365
 URL: https://issues.apache.org/jira/browse/TUSCANY-1365
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SCA BPEL Implementation Extension
Reporter: Matthieu Riou
 Attachments: ode-init.patch

I'm attaching a patch and a zip (for new files) containing the necessary code 
to bootstrap the ODE BPEL server. It actually doesn't give you much as it's 
just initializing all resources needed by the server and then loading it, so 
nothing is there for exchanging messages. But it's already a start.

Testing is a bit rough as it's still very preliminary but here are the steps to 
get the test case to run:

1. You'll need to build ODE locally first. I'm basing the code on ODE's trunk 
as some tweaks or improvements here and there will probably be needed in ODE as 
well. Later on, when the implementation is bit more stable, I'll publish 
snapshots and eventually transition to an ODE release. In the meantime, here is 
how to build ODE (using buildr):

http://incubator.apache.org/ode/jacob.html

Run the "install" task instead of "package" to have the created jars published 
in your local directory.

2. The server initializes Derby, so you need to have a Derby database. For now 
it will be looking for it in an ode-work subdirectory of the BPEL 
implementation root directory (until we implement a better way to find it). 
Create this directory and copy the jpadb directory found in 
ode/dao-jpa-ojpa-derby/target/derby after ODE has been built in it. You should 
end up with implementation-bpel/ode-work/jpadb.

3. Run "mvn test". Maven2 being a pain, it will download the whole world. 
Several things aren't actually required but come with transitive dependencies, 
we'll have to exclude things at some point but for now it should work.

If the Maven2 build fails because it couldn't download a dependency, you'll 
need to add some remote repositories. Here are the ones we have in ODE:

repositories.remote << "http://pxe.intalio.org/public/maven2";
repositories.remote << "http://people.apache.org/repo/m2-incubating-repository";
repositories.remote << "http://repo1.maven.org/maven2";
repositories.remote << "http://people.apache.org/repo/m2-snapshot-repository";

Thanks!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Tuscany/ODE resources questions

[Matthieu Riou]

Hi guys,

I'm starting on the lifecycle part of the Tuscany/ODE integration to get an
engine started with all its necessary resources (transaction, persistence,
...). I can go with in-memory mode and light configuration for now but we'll
want a fully working server sooner or later. So I have a few questions:

1. How can I get server-wide configuration properties to configure the
behavior of the engine? Things like the size of our thread pool, if we
should use an embedded database or try to lookup a datasource, some memory
optimization modes we can run in, ... These would be for the whole ODE
server and not on a per-process basis.

2. How can I get the a transaction manager? I haven't been able to find an
extension point for it. If there are none available, I can still create my
own but it'd be probably be better to reuse the Tuscany one if it's there.

3. In embedded persistence mode, ODE uses a Derby database. Which means
files located somewhere. Is there a way to lookup a given directory under
which the database could be made available? For example when we deploy ODE
in a webapp for example, the database is prepackage in the webapp and we
find it under the context root (or alternatively a path can be configured,
see 1)

I think that's all for now but I'll certainly find more in the coming days
:)

Thanks!
Matthieu

Re: SCA & WS-BPEL

[Matthieu Riou]

Hi Sam,

I'll have a deeper look at this today or tomorrow. I'll certainly have a
look at what you've contributed so far. My understanding is that Tuscany's
SPIs have significantly changed so we may be better off starting from
scratch from the skeleton Luciano has created and import (understand
copy/paste) the code you've already done gradually (tweaking what needs to
be tweaked).

Anyway I'll create a new issue for this, trying to merge the new skeleton
and what you've done before and maybe we can start from that.

Cheers,
Matthieu

On 6/14/07, sam tam <[EMAIL PROTECTED]> wrote:


Hello,

This is regarding the integration of Apache ODE and Apache Tuscany !

I have contributed a container in Apache Tuscnay for BPEL which was an
initial startup  http://issues.apache.org/jira/browse/TUSCANY-897

I think that was during M2 release [ During the month of Dec 2006 ]

I want to contribute more for  the integration because I had been working
on
it before .

I replied to Luciano's mail regarding this in Apache ODE  ML but
accidentally I missed Tuscany ML.

So I just want to inform you guys !

Sam Tam.



On 6/9/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
>
> Hi All
>
>I'm sending this e-mail to reactivate the collaboration between
> Apache Tuscany and Apache ODE as initiated by Matthieu a while ago[1].
> It would be great if we could have an WS-BPEL component implementation
> described in [2] and [3], where we would be able to run executables
> WS-BPEL process from an SCA runtime.
>
>In order to get this started, I have put together a skeleton that
> we could use as the bases for implementation.bepel and it's available
> at [4]. I'm in the middle of simplifying it further, and I'll keep you
> guys posted of my progress.
>
>
> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg10042.html
> [2] http://osoa.org/display/Main/SCA+BPEL+White+Paper
> [3]
>
http://osoa.org/download/attachments/35/SCA_ClientAndImplementationModelforBPEL_V100.pdf?version=1
> [4]
>
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-bpel/
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>



--

[jira] Updated: (TUSCANY-897) BPEL container based on Apache Ode

[Matthieu Riou (JIRA)]

 [ http://issues.apache.org/jira/browse/TUSCANY-897?page=all ]

Matthieu Riou updated TUSCANY-897:
--

Attachment: BpelServerLoader.java

Simple loader than can be used to initialize Ode.

> BPEL container based on Apache Ode
> --
>
> Key: TUSCANY-897
> URL: http://issues.apache.org/jira/browse/TUSCANY-897
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SCA Common
>Affects Versions: Java-Mx
>Reporter: ant elder
> Fix For: Java-Mx
>
> Attachments: BpelServerLoader.java, container.bpel.zip
>
>
> JIRA for attaching patches to create the Tuscany BPEL container based on 
> Apache Ode.
> There's a white paper on SCA and BPEL at: 
> http://osoa.org/display/Main/Service+Component+Architecture+Specifications
> A draft specification is available at: 
> http://osoa.org/display/Main/Service+Component+Architecture+Specifications
> The Tuscany container is at: 
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/services/containers/container.bpel/

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: SCA and BPEL

[Matthieu Riou]

Hi Sam,

I've had a look at your implementation and played with a couple of things on
my side as well. I think I have a much better idea of how things can play
with each other now and how to solve your problems.

- For server instantiation, you should create a separate component for it
with @Init and @Destroy annotations. I've made a rough implementation of it
and I think you could take it and start from that. You'll just have to add
the component as a system implementation in your bpel.system.cdl. I'll
attach the java file to the same Jira issue. Then you can have this injected
in the  BpelComponentBuilder using a constructor like:

   public BpelComponentBuilder(@Autowire BpelServerLoader serverLoader) {
   _server = serverLoader.getServer();
   _store = serverLoader.getStore();
   }

That should fix the server instantiation problem.

- For the binding part you will need to go through a real remote web service
invocation. Check of the Tuscany helloworldws is structured with the
sample-helloworldws web application being deployed in Tomcat and the client
sample-helloworldwsclient calling it remotely. I think you can even reuse
the client almost as is. However the server side should change to something
like:

   
   http://ode/bpel/unit-test.wsdl#wsdl.interface(HelloPortType)"
   wsdli:wsdlLocation="http://ode/bpel/unit-test.wsdl
HelloWorld2.wsdl"/>
   http://ode/bpel/unit-test.wsdl#wsdl.endpoint(HelloService/HelloPort)"
location="HelloWorld2.wsdl" />
   HelloWorldBPELComponent
   

   
   
http://ode/bpel/unit-test.wsdlHelloService"/>
   

Again check the Tuscany sample-helloworldws service declaration, it's almost
the same except for the implementation that will be BPEL in our case instead
of java. You can even use the same type of SDO databinding So you will need
to package the BPEL container on the server side in Tomcat and that should
get loaded.

Let me know if you need more,

Matthieu

On 11/26/06, sam tam <[EMAIL PROTECTED]> wrote:


Hello Guys..

As discussed earlier about Integration of SCA(Apache Tuscany) and BPEL
(Apache Ode),

I have started with a bpel container for Apache Tuscany(SCA).

Also i have attached a small readme file .

And a test case file also.

The link for the attached source is :
http://issues.apache.org/jira/browse/TUSCANY-897?page=all

Comments:

Things to do :
- need to figure out a better way than instantiating the server for every
component
- need to bring in databinding into the invoke method to be able to
convert
java objects to xml that can be sent over ODE requests and also do the
reverse for the response.


Guys I need your feedback on this !!! Plz share your ideas . !!.

Sam..Tam...







___


On 10/29/06, sam tam <[EMAIL PROTECTED]> wrote:
>
> That would be fine with me Ant.  I am residing in India ..So to confirm
:
> Thursday 4pm BST !
>
> Sam...
>
> On 10/29/06, ant elder < [EMAIL PROTECTED]> wrote:
> >
> > Thats fine for me, how about you Sam?
> >
> >...ant
> >
> > On 10/27/06, Matthieu Riou <[EMAIL PROTECTED]> wrote:
> > >
> > > Actually most Ode committers (including myself) are in California.
> > Also
> > > we're going to be a bit busy early next week. So would 4pm BST (8am
> > PST) on
> > > Thursday work for you?
> > >
> > > On 10/27/06, ant elder <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Sure ok I guess an IRC chat would be fine to get started. I'm in
UK
> > time
> > > > zone but can be pretty flexible about scheduling it. How about
> > 9:30am BST
> > > > next Tuesday?
> > > >
> > > >..ant
> > > >
> > > > On 10/26/06, Matthieu Riou < [EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > So what about an IRC session to get started? Everybody
interested
> > > > > could come to ask questions and we would discuss in more details
> > how this
> > > > > could be done. We can both exchange our views on SCA / BPEL and
> > give as much
> > > > > information as possible to the volunteers (like Sam [1]).
> > > > >
> > > > > What do you think?
> > > > >
> > > > > Matthieu
> > > > >
> > > > > [1]
> >
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/[EMAIL 
PROTECTED]
> > > > >
> > > > >
> > > > > On 10/25/06, ant elder < [EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > &

Test compilation failure

[Matthieu Riou]

Hi,

I just wanted to let you know that I had a small compilation failure when
building Tuscany from the sources (latest trunk) with a test case that
didn't compile:

/home/dusty/Dev/Projects/tuscany/sca/tools/src/test/java/org/example/creditscore/doclit/DoclitPackage.java:[23,41]
cannot find symbol
symbol  : class ModelPackageImpl
location: package org.apache.tuscany.sdo.model.impl

And more. Look like a package has been moved. No big deal, I just skipped
the tests for that module but just wanted to let you know...

Cheers,

Matthieu

[BPEL] Transaction managers, datasources and more

[Matthieu Riou]

Hi,

I have a better and better idea on how Apache Ode could be used as a Tuscany
container. However I'm still wondering how I can get hold on some resources
in Tuscany. To run Ode's BPEL engine we need basic services like a
transaction manager, a datasource or a thread scheduler (
java.util.concurrent.ExecutorService).

How could these be provided to the BPEL container? Do you already have
something for this? Or should we assume that we're running in a managed
environment (i.e. Geronimo) and lookup these things ourselves?

Thanks,

Matthieu

Re: IRC chat on Ode/Tuscany integration: Thursday 2nd Nov 4pm GMT/8amPST (was Re: SCA and BPEL)

[Matthieu Riou]

Thanks ant!

On 11/3/06, ant elder <[EMAIL PROTECTED]> wrote:


As discussed, I've created an empty skeleton container for this at:

https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/services/containers/container.bpel/

There's a JIRA for attaching patches to at:
https://issues.apache.org/jira/browse/TUSCANY-897

Starting sending your patches!

   ...ant

Re: IRC chat on Ode/Tuscany integration: Thursday 2nd Nov 4pm GMT/8amPST (was Re: SCA and BPEL)

[Matthieu Riou]

For those who couldn't attend, here is the transcript of the chat session:

[08:00]  so shall we start on the BPEL / SCA topic a.k.a. ODE /
Tuscany ?
[08:00]  yes..ofcourse...
[08:01]  Alex is here as well, Lance tried to join us but he has
a firewall problem
[08:01]  can't connect to IRC
[08:01]  hi all
[08:01]  hi ant
[08:01]  how are you doing?
[08:02]  Hi guys!
[08:02]  doing fine...so Tuscany and Ode
[08:02]  have you all had a look at the white paper and spec on the
osoa website?
[08:02] --> lmsurprenant has joined this channel ([EMAIL PROTECTED]
/ibm/x-36f69103afa7a9f8).
[08:03]  I'd like to know if anybody here has experience
integrating "engines" into Tuscany
[08:03]  It would be good to have a model to follow
[08:03]  I've had a look at the spec, not the white paper
[08:03]  yes..i did look at the white paper ..Ant
[08:03]  and SCA C & I model
[08:04]  we have a few Tuscany containers now, which is whats reqd from
tuscany perspective, you can see the code at
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/services/containers/
[08:05]  all run under java and c++ or some only run on Java and
others on C++ ?
[08:05]  those are only the java ones
[08:06]  ok, nice
[08:06]  the C++ has extensions as well but its quite seperate
[08:06]  the code doesn't seem that big, that's nice
[08:06]  Is there  another  way to contact SCA ie by bindings ? Am i
right Ant ?
[08:07]  what kind of XML representation does Tuscany use
internally?   DOM?
[08:07]  Sam, yes, but the bpel spec talks about using an
impelementtaion type not a binding
[08:07]  oh ok Ant
[08:08] --> Amita has joined this channel ([EMAIL PROTECTED]).
[08:08]  there's a runtime databinding framework which means the
runtime will give the extension data in whatever type it requires
[08:08] <-- lmsurprenant has left this server (Read error: 131 (Connection
reset by peer)).
[08:09]  and which types are currently supported?
[08:09]  the extesnion tells the ri=untime what it requires, and maybe
contrabutes a databinding extension, and then the runtime uses that to
transform the message to whats needed
[08:09]  right now there's sdo, jaxb, cator and axiom:
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/services/databinding/
[08:10]  i thnk also as part of the runtime DOM and StaAx
[08:10]  what does Ode use internally?
[08:10]  neat!
[08:10]  mostly DOM
[08:11]  we convert Axiom as well for Axis2
[08:11]  and to/from JAXP Sources with JBI
[08:11]  right
[08:11]  I guess the format that would make sense for now would
be DOM
[08:12]  so tuscany should be able to just give the Ode extension DOMs
so it should would quite easily
[08:12]  so how many interfaces you need to implement to build a
container?
[08:15]  ok so a container includes an scdl file defining the classes
it adds to the runtime, for example:
[08:15] 
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/services/containers/container.javascript/src/main/resources/META-INF/sca/default.scdl
[08:16]  the loader as the class that handles the XML config file
[08:17]  for BPEL the spec defines the XML as:
[08:17]  *
[08:17] 
[08:17]  
[08:17] --> halehM has joined this channel (n=
[EMAIL PROTECTED]).
[08:18]  makes sense
[08:18]  so you need a class that has a type name of
implementation.bpel
[08:18]  and that will pick up the process= attribute
[08:18]  and how would deployment work? for now we use deployment
packages that contain BPEL files, WSDL and XSD files and a deployment
descriptor, so that's not only a BPEL
[08:19]  what is your deployment package? sometheing liek a jar file?
[08:19]  i think they have some war file..(ode.war) ..
[08:20]  it's either a zip or an exploded directory version of it
that you can copy under a "well-known" location
[08:20]  the war is the whole thing
[08:20]  oh ok
[08:20]  but when you deploy a "processes" directory gets created
in ode/WEB-INF
[08:21]  so dropping a directory in processes containing all the
necessary files will trigger hot deployment
[08:21]  but we also support remote deployment using a ws
interface
[08:21]  and then you send a SOAP message using a MTOM attachment
with your zip file in there
[08:21]  but that's for Axis2
[08:22]  I guess the mechanism would be different with scca
[08:22]  sca
[08:22]  that would be with Ode handling the sending and receiveing of
WS messages
[08:23]  yes, with a BPEl container i think Tuscany would need to
handle the sending/receiving
[08:23]  right but the deployment in handled by Tuscany right?
and we would be notified when a complete service bundle is deployed (could
contain bpel, ruby and javascript)
[08:23]  so as in the picture in the white paper:
http://osoa.org/display/Main/SCA+BPEL+White+Paper
[08:24]  right
[08:24]  in the simplest case the service and references would be wired
to WS bindings so the BPEL/Ode process would directly receive/send the WS
messages via tuscany
[08:24]  yep
[08:25]  one thing i wondered about, one of you samples talked about
receiveing back 

Re: Private mailing list now set up for Tuscany

[Matthieu Riou]

It's simply sending an e-mail to the infrastructure mailing-list, giving
them the mailing-list name and your Apache id and they'll add you as a
moderator.

Matthieu

On 11/2/06, ant elder <[EMAIL PROTECTED]> wrote:


On 7/28/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
>
> On Jul 27, 2006, at 9:02 AM, ant elder wrote:
>
> > Did you ever add me as a moderator for the private list, I've not
> > seen any
> > moderation requests? So you must have seen all the subscription
> > requests...could you post a list of who has subscribed? (or is
> > there some
> > other way I can find the subscriber list myself and I'll post the
> > list?)
> >
>
> I haven't figured out how to add you as a moderator - I'd ask one of
> our mentors to explain the mechanism ...


Dims, any idea how to add me as moderator to the Tuscany lists?

Thanks,

   ...ant

Re: SCA and BPEL

[Matthieu Riou]

Actually most Ode committers (including myself) are in California. Also
we're going to be a bit busy early next week. So would 4pm BST (8am PST) on
Thursday work for you?

On 10/27/06, ant elder <[EMAIL PROTECTED]> wrote:


Sure ok I guess an IRC chat would be fine to get started. I'm in UK time
zone but can be pretty flexible about scheduling it. How about 9:30am BST
next Tuesday?

   ..ant

On 10/26/06, Matthieu Riou <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> So what about an IRC session to get started? Everybody interested could
> come to ask questions and we would discuss in more details how this could be
> done. We can both exchange our views on SCA / BPEL and give as much
> information as possible to the volunteers (like Sam [1]).
>
> What do you think?
>
> Matthieu
>
> [1] 
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/[EMAIL 
PROTECTED]
>
>
> On 10/25/06, ant elder < [EMAIL PROTECTED]> wrote:
> >
> > On 10/25/06, Matthieu Riou <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi all,
> > >
> > > This e-mail is being sent to both Apache Ode and Tuscany development
> > > mailing
> > > lists.
> > >
> > > The objective is to see which possible collaboration could happen
> > > between
> > > our 2 projects and how we could integrate them. Alex, Cory and
> > > myself (we're
> > > all Ode contributors) met with Jean-Sebastien Delfino and Simon Laws
> > > (Tuscany contributors) during the ApacheCon in Austin and we've
> > > found out
> > > that integrating Ode into Tuscany could be a brilliant idea.
> > >
> > > From the Tuscany side, there's an SCA client and implementation spec
> > > for
> > > BPEL. Roughly, it defines how a BPEL process can be used as an SCA
> > > component
> > > (or at least that's my understanding of it). So I guess Ode could be
> > > a good
> > > choice for the BPEL part of that.
> > >
> > > From the Apache Ode perspective, we've defined an interface to the
> > > engine (
> > > a.k.a. the integration API or IAPI for acromyn lovers) and we would
> > > like to
> > > support several integration scenarii. Currently we have an
> > > integration layer
> > > for Axis2 to support all web services interactions, we also have one
> > > for JBI
> > > and another one for CXF has been proposed. We would love to have an
> > > implementation of these interfaces for Tuscany to be able to run Ode
> > > in an
> > > SCA environment (for the curious, the interfaces are
> > > 
here<https://svn.apache.org/repos/asf/incubator/ode/trunk/bpel-api/src/main/java/org/apache/ode/bpel/iapi/
> > > >
> > > ).
> > >
> > > I think the discussion (if discussion there is) should take place on
> > > tuscany-dev as there's less of us, Ode people, so it's easier for us
> > > to
> > > subscribe to it.
> > >
> > > So what would it take to fit into Tuscany?
> > >
> > > Thanks,
> > >
> > > Matthieu
> > >
> > >
> > Hi Matthieu, this would be really great, i'd love for Tuscany to get a
> > involved with Ode to get a BPEL component.
> >
> > For those that haven't found these already there's a white paper on
> > SCA and BPEL [1] and a specification [2].
> >
> > You can see the type of thing required to implement a container for a
> > new component type in Tuscany by looking at some of our existing ones [3]
> >
> > I agree it may be easiest for the discussions to be over here
> > initially, but i've subscribed to ode-dev as well anyway. I'd be very happy
> > to help you do this, how would you like to get started?
> >
> >...ant
> >
> > [1] http://osoa.org/display/Main/SCA+BPEL+White+Paper
> > [2] 
http://osoa.org/download/attachments/35/SCA_ClientAndImplementationModelforBPEL_v0.95.pdf?version=2
> >
> > [3] 
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/services/containers/
> >
> >
>
>

Re: SCA and BPEL - Integration

[Matthieu Riou]

Hi,

Nice volunteering indeed!

So on the Ode side, I'd go with implementing a specific integration layer
for Tuscany instead of reusing the Axis2 one. That would allow in-VM SCA /
BPEL interactions and a greater integration between the two.

Ode provides an integration API that you have to implement if you want to
plug the engine into something else. The engine uses this API to get
whatever it needs to work, like the ability to send and receive messages, to
get some representation of the services it's going to interact with, or even
threads and transactions. So you would just wire up all services Tuscany
provides into the engine when implementing these interfaces.

To see what those look like you can have a look at [1]. We currently have 3
working implementations for these interfaces: Axis2, JBI and test. The Axis2
one is wrapped around Axis2 in a WAR and works in any servlet container. The
JBI one is bundled in a Service Assembly and can be deployed in ServiceMix.
The test one works in-memory in a standalone manner. These are great
examples to look at to see how the required services are provided to the
engine and how everything is initialized. In particular you can have a look
at ODEServer [2] for Axis2 and OdeLifeCycle [3] for JBI, these are where all
the initialization and wiring up logic happens for these 2 integrations.

I'd start from the test IAPI implementation [4] [5] to see how things work
out, this will run in memory so you won't have to worry about providing a
datasource and a transaction manager to start with. Then you can bring some
pieces from the Axis2 and JBI integrations (copy / paste is your friend) and
increment from that. Implement the different communication interfaces by
using Tuscany services and you should be all set.

Now I think we could discuss about the details and how to use Tuscany
services in Ode during an IRC chat session as I proposed in the other
thread? So we can all have a better understanding of how this will work and
you'll have more information to start from.

Matthieu

[1]
https://svn.apache.org/repos/asf/incubator/ode/trunk/bpel-api/src/main/java/org/apache/ode/bpel/iapi/
[2]
https://svn.apache.org/repos/asf/incubator/ode/trunk/axis2/src/main/java/org/apache/ode/axis2/ODEServer.java
[3]
https://svn.apache.org/repos/asf/incubator/ode/trunk/jbi/src/main/java/org/apache/ode/jbi/OdeLifeCycle.java
[4]
https://svn.apache.org/repos/asf/incubator/ode/trunk/bpel-test/src/test/java/org/apache/ode/test/BPELTest.java
[5]
https://svn.apache.org/repos/asf/incubator/ode/trunk/bpel-test/src/main/java/org/apache/ode/test/

On 10/26/06, ant elder <[EMAIL PROTECTED]> wrote:


On 10/26/06, sam tam <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I am a student and I have been looking into this topic for my project
> work.
> I'd like to contribute as much in this with some help from you folks.
> For
> now here is what I have been doing as ground work.
>
> - Tried out Tuscany M1 release and also recently from the current
> development branch.
> - With Apache ODE I deployed sample process in Tomcat and have been able
> to
> call it using a SOAP message.
>
> At the present moment I am trying to figure out how to integrate ODE
into
> Tuscany.  One obvious thought I have in my mind is to use the Tuscany
> Axis2
> Binding and invoke the BPEL process as a reference.  I am going to be
> digging into the OSOA specs for this and hope to get better clarity as I
> go
> along.
>
> I'd be happy to take advice from you folks on taking this forward.
>
> Thanks.
>
> Sam.
>
>
Hi Sam,

Its great you're interested in this, it would be really good to have BPEL
support in Tuscany. In case you didn't see due to all the ASF email
problems
over the last few days, the Ode guys have also just started talking about
this: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg10042.html.

I talked about how to start a new container in this old mail:

http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/browser
.
I'd start with trying to get a simple helloworld going which for this
would
be a combination of the Tuscany helloworldws sample and the Ode
axis2-examples HelloWorld2.

Basically start by copying the existing sample and one of the Tuscany
containers, rename everything to BPEL. Remember when you do the
copy/rename
there's scdl in the META-INF/sca directory that you'll need to edit to
update with the new class names.

As there's an existing SCA spec for this you get some help with what to
do.
The spec defines what the implementation element looks like:

  

So you'll need something like a BPELImplementation and
BPELImplementationLoader for that. Use one of the existing ones and just
change the  QName constant to be "implementation.bpel" and the code to
read
in the attribute named "process". A harder part will be how Tuscany
locates
the BPEL process XML, for now its likely easiest to add a location
attribute
and have the loader just read it in, and then sort this part out properly
later oncee th

Re: SCA and BPEL

[Matthieu Riou]

Hi,

So what about an IRC session to get started? Everybody interested could come
to ask questions and we would discuss in more details how this could be
done. We can both exchange our views on SCA / BPEL and give as much
information as possible to the volunteers (like Sam [1]).

What do you think?

Matthieu

[1]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200610.mbox/[EMAIL 
PROTECTED]

On 10/25/06, ant elder <[EMAIL PROTECTED]> wrote:


On 10/25/06, Matthieu Riou <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> This e-mail is being sent to both Apache Ode and Tuscany development
> mailing
> lists.
>
> The objective is to see which possible collaboration could happen
> between
> our 2 projects and how we could integrate them. Alex, Cory and myself
> (we're
> all Ode contributors) met with Jean-Sebastien Delfino and Simon Laws
> (Tuscany contributors) during the ApacheCon in Austin and we've found
> out
> that integrating Ode into Tuscany could be a brilliant idea.
>
> From the Tuscany side, there's an SCA client and implementation spec for
> BPEL. Roughly, it defines how a BPEL process can be used as an SCA
> component
> (or at least that's my understanding of it). So I guess Ode could be a
> good
> choice for the BPEL part of that.
>
> From the Apache Ode perspective, we've defined an interface to the
> engine (
> a.k.a. the integration API or IAPI for acromyn lovers) and we would like
> to
> support several integration scenarii. Currently we have an integration
> layer
> for Axis2 to support all web services interactions, we also have one for
> JBI
> and another one for CXF has been proposed. We would love to have an
> implementation of these interfaces for Tuscany to be able to run Ode in
> an
> SCA environment (for the curious, the interfaces are
> 
here<https://svn.apache.org/repos/asf/incubator/ode/trunk/bpel-api/src/main/java/org/apache/ode/bpel/iapi/
> >
> ).
>
> I think the discussion (if discussion there is) should take place on
> tuscany-dev as there's less of us, Ode people, so it's easier for us to
> subscribe to it.
>
> So what would it take to fit into Tuscany?
>
> Thanks,
>
> Matthieu
>
>
Hi Matthieu, this would be really great, i'd love for Tuscany to get a
involved with Ode to get a BPEL component.

For those that haven't found these already there's a white paper on SCA
and BPEL [1] and a specification [2].

You can see the type of thing required to implement a container for a new
component type in Tuscany by looking at some of our existing ones [3]

I agree it may be easiest for the discussions to be over here initially,
but i've subscribed to ode-dev as well anyway. I'd be very happy to help you
do this, how would you like to get started?

   ...ant

[1] http://osoa.org/display/Main/SCA+BPEL+White+Paper
[2]
http://osoa.org/download/attachments/35/SCA_ClientAndImplementationModelforBPEL_v0.95.pdf?version=2
[3]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/services/containers/

SCA and BPEL

[Matthieu Riou]

Hi all,

This e-mail is being sent to both Apache Ode and Tuscany development mailing
lists.

The objective is to see which possible collaboration could happen between
our 2 projects and how we could integrate them. Alex, Cory and myself (we're
all Ode contributors) met with Jean-Sebastien Delfino and Simon Laws
(Tuscany contributors) during the ApacheCon in Austin and we've found out
that integrating Ode into Tuscany could be a brilliant idea.


From the Tuscany side, there's an SCA client and implementation spec for

BPEL. Roughly, it defines how a BPEL process can be used as an SCA component
(or at least that's my understanding of it). So I guess Ode could be a good
choice for the BPEL part of that.


From the Apache Ode perspective, we've defined an interface to the engine (

a.k.a. the integration API or IAPI for acromyn lovers) and we would like to
support several integration scenarii. Currently we have an integration layer
for Axis2 to support all web services interactions, we also have one for JBI
and another one for CXF has been proposed. We would love to have an
implementation of these interfaces for Tuscany to be able to run Ode in an
SCA environment (for the curious, the interfaces are
here
).

I think the discussion (if discussion there is) should take place on
tuscany-dev as there's less of us, Ode people, so it's easier for us to
subscribe to it.

So what would it take to fit into Tuscany?

Thanks,

Matthieu