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 "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
Matthieu,
Thanks for responding - let me try and pick my way through it for you:
1) All the code is committed and in the current Tuscany SVN.
2) The runtime code that is relevant is all in the implementation-bpel-ode
module
3) There are 3 sets of test/samples you can use to try things out:
a) In Samples - helloworld-bpel and helloworld-bpel-ws
b) In Itest - there are 4 Itests under BPEL - helloworld
- helloworld-reference
- helloworld-ws
- ping-pong
I tend to use the 2 samples. The second one uses web services and catches the problems with the
data format returned by the BPEL process, for example. (You get an exception in the databinding code
when it tries to transform it)
Now, I've fixed up the code in implementation-bpel-ode so that it works - so the problems are all
masked. But some simple commenting and uncommenting of lines of code can reproduce all the problems.
The 2 main classes to deal with are:
- EmbeddedODEServer
- TuscanyProcessConfImpl
Currently, EmbeddedODEServer is set up to use the ODE Store and Persisted BPEL Processes - the trick
I've done is that the code itself WRITES the deploy.xml file on the fly - so that the programmer
does not need to write it. This is handled by the BPELODEDeployFile class.
To change things, all you need to do is to go to the deploy(....) method in EmbeddedOdeServer. You
will find 2 blocks of code inside a try{} block - one for using the ODE Store, the other for using
the Tuscany stuff without the store. Simply comment out one an uncomment the other to flip between
them.
Only one other thing needs changing to work through all the problems - and that is the response to
the isTransient() method of the TuscanyProcessConfImpl - currently it's set to "true" - simply flip
it to return "false" to see the other behaviour.
One significant thing I discovered is that there is a "memory effect" in the database. IF the
database has been used ONCE by the ODE Store code then if the code is run afterwards in "non Store"
mode, it works ok, with no transaction errors. The transaction errors only occur with a "virgin"
database that has never been used by the Store code. If that ain't confusing, nothing is...
Note - running the Samples and Itests above using mvn usually cleans out the DB - I've been able to
preserve the DB when running from Eclipse.
When getting the transaction problem, my tracing showed that is happening in:
BpelProcess$HydrationLatch.doHydrate() line 755
"DbError"
"Unable to Commit"
Yours, Mike.
