Quoting Dobri Kitipov <[EMAIL PROTECTED]>:
> Hi Dasarath,
> I have some questions about the BankOne example provided with Kand1.
> Precisely my questions are related to the use case shown.
> My understanding is that the use case shown into the example is the
> following:
> 1) There is some business logic already developed after a given interface (
> e.g. bankone.BankOne). There is no JTA TX behavior into it.
This is incorrect. The sample shows exactly the opposite. It shows how to
connect (expose) existing jta code through web services (ws-at).
Notice that the transaction manager returned by the Bridge is a
javax.transaction.TransactionManager instance and NOT any Kandula provided
class. This is just a way to get hold of your jta TM. If this code was in an
ejb or a jsp or a Servlet you would use the mechanism defined by the J2EE
standard to get the correct TM instance. For simplicity, the current
implementation of the Bridge simply creates an instance of Geronimo TM whenever
its instanciated. However, the correct way to do this is for the Bridge also to
retrive the TM instance used by the environment. Otherwise there will be 2 TMs
which breakdown the whole logic.
If you plan to work in this area it would help to study the jsr-109. Jsr-109
specifies how to implement web services in j2ee. It does not specify how ws-at
(let alone ws-ba) should map to jta/jts. In Apache EWS we implemented jsr-109
(the project is now outdated I believe) and then considered how we can map
services such as security and transactions between ws/j2ee. Kandula project was
a result of that.
Roughly speaking, you first implement your business logic using an ejb. Then
use jsr-109 to expose this ejb as a web-service. At this point if you deploy
Kandula in your j2ee container, it would map the incoming ws-at protocol
artifacts to corresponding jta calls so that when the ejb methods are called,
they would be called with an appropriate transaction context. Given the ejb,
the j2ee container would automatically create the ws-proxy that's shown in the
BankOne sample. However, in the sample (to make it simpler) we leave out the
ejb and implement the business logic in the web service itself. In the jsr-109
senario however, *Impl class would have contained calls to an ejb or a Servlet
instead.
One of the aims of Kandula is to provide the required transaction context for
calls to ejb methods, in a transparent way when that happens through a ws-
proxy. This however, has not been document or standardized in any jsr to the
best of my knowledge but I must say it has been quite some time since I looked
at the area. Certainly this is way beyond ws-at and is orthogonal.
thanks,
--dasarath
> 2) In order to make it transactional (part of WS TX) the original business
> logic is wrapped into an implementation class (i.e.
> bankone.BankOneSoapBindingImpl) by a developer.
> 3) This Impl class adds JTA TX behavior to it. At the same time it uses the
> so called Bridge (e.g. org.apache.kandula.geronimo.Bridge) that is
> responsible to mediate b/n WS TX and the JTA TX contexts, right?
> 4) bankone.BankOneSoapBindingStub is also created by the developer? or it is
> generated somehow? if so how it was generated?
> 5) At this point we have several classes developed: BankOne, BankOneService,
> BankOneSoapBindingImpl and BankOneSoapBindingStub. All these looks to me
> very similar to the Remote Proxy Pattern.
> 6) In addition a service locator is also developed (e.g.
> bankone.BankOneServiceLocator) and used by a given client to invoke the
> business logic;
> 7) At the end all this is registered as a WS into the server-config.wsdd and
> deployed at a given server.
>
> Something like this is done and for the client of the above mentioned WS.
>
> So, in summary, we need some development in order to reuse an already
> developed business logic in order to be a part of WS TX? What if this
> business logic is already (internally) demarcated by a JTA TX? Should we
> leave it like this so the TX become a Nested JTA TX, part of the one created
> into the Impl class (e.g. BankOneSoapBindingImpl). E.g. lets look at
> bankone.BankOneDBMS. Only one method is shown for bravity:
>
> ...
> public double debit(int accountNo, double amount) {
> if (cache == null)
> throw new IllegalStateException("transaction required.");
> return cache[accountNo] -= amount;
> }
> ...
>
> Let's suppose that this debit() method do some business logic into a JTA TX.
> It becomes as Nested TX for the one demarcated into the
> test.BankOneTestSoapBindingImpl:
>
>
> private void tx2(BankOne bank) throws RemoteException {
> System.out.println("[BankOneTestSoapBindingImpl] tx2");
> tm.begin();
> bank.credit(0, 50.0);
> bank.debit(1, 50.0);
> tm.commit();
> getBalances(bank);
> }
>
> Will we have atomic behavior in this case? If there is a rollback will the
> nested TX will be rolled back too?
>
> Thank you in advance!
>
> Dobri
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
