How to ensure the completion of BAParticipant at client side

[xiaoqj]

using WS-BA,

code@client side
{
userBusinessActivity.begin();

call service A

call service B

userBusinessActivity.close();
}

if I want to call service A;B sequentially, how can i ensure service A is completed to initiate an invocation to service B after that point?

Considering there are two different styles of service implementation,

Service implementation in Style 1
 ----> rpc request
 check the validation of the request
 self registration to the BusinessActivityManager
 complete the job
 BusinessActivityManager.completed()
 <---- rpc response

Service implementation in Style 2
 ------> rpc request
 check the validation of the request
 self registration to the BusinessActivityManager
 schedule a background worker thread to complete the job and return instantly
 <------ rpc response

 BusinessActivityManager.completed() will be called by worker thread later at some unpredictable point

It seems if service A,B are both implemented in style 1, I can assure myself that service A, B is completed if return from rpc call. But what happens with services implemented in style 2. How can i check the status of the invoked service.

[marklittle]

How you accomplish this is application specific. If you want to allow asynchronicity within your application then you need to implement a policy whereby the business activity cannot complete until all outstanding work has been done. This is similar to Checked Transaction semantics in traditional transaction processing systems.

[xiaoqj]

It's said that WS-Cord and WS-Tx is a mapping of BPEL into transaction processing.

Why not introduce more primitives like Fork/Join implemented by coordinator to ease the use of WS-TX?

[marklittle]

Who says this? WS-TX is not a mapping of BPEL. That doesn't make sense.

[xiaoqj]

The link http://www.choreology.com/standards/standards_btm_spectrum.htm argues that the original defining use case of WS-BA is BPEL LRT.

And several ingredients of BPEL can be witnessed in WS-BA, like

1. programmable exception handler
2. automatic installation of compensator in scope(registration of participant to sub-coordinator)

If coordinator cannot sense the relative order between participants which is expressed in BPEL by sequence and parallel, how can it determine in what order to call corresponding compensation operation.

[marklittle]

So WS-BA was put in specifically for WS-BPEL requirements but that's not the same as saying WS-TX is a mapping OF WS-BPEL. WS-BA is in fact based on a much older transaction model called Sagas.

Ultimately how you deal with transactions and ordering in your application is application specific. If you have an integration of WS-BPEL and WS-TX (or WS-CAF for that matter), then you will typically not see explicit transaction demarcations at all and the workflow tools and runtime infrastructure will help you.

[xiaoqj]

I've deployed XTS one-night demo in JBoss 4.0.3 which utilize ws4ee. But only after we fix the bug of init-param in file web.xml contained in xts-demo.war, can the demo run smoothly.


My question is that both ws4ee and jax-ws 2.0 support asynchronous rpc client, which may be suitable to implement a checked transaction semantics at application level. Is there any sample demonstration showing how to do this. Thank you.

[kconner]

The only init-params specified in the web.xml are generated by the build process. You need to check your jboss.properties file and do a clean build to correct this.

The demo included in the download is the only one we distribute at present, demonstrating both AT and BA transactions.

As far as checked transaction semantics are concerned, this is only supported when using implicit context propagation in an OTS environment, i.e. using the JTS transaction manager.

A similar outcome can be achieved in WS-AT by registering a volatile 2pc participant with the transaction and blocking the prepare call until the asynchronous work is completed.

If you are using WS-BA then the semantics are driven by your application.

Kev

[marklittle]

Checked transactions are not mentioned explicitly in WS-AT: they are assumed to be an implementation choice. Good implemenations will support them. We will support them.