Thanks Dasarath for the input.
I am not trying to integrate Kandula with WAS as Kandula is being done today with Geronimo. That is not my objective. The objective is: Web Service Transaction Interoperability (Kandula Implementation and WAS Implementation of Web Service Transaction) Web Service Client (build with axis generated stubs and using Kandula to attach transaction details) ----------------------------> Web Service on WAS (which does some insertion into database) Do you think this is feasible or not? The resources are defined (say datasource) within the WAS Container. Now the question would be do I need to expose these resources (XAResource) deployed within WAS using Kandula? I was having a look somewhere (http://www.ibm.com/developerworks/websphere/library/techarticles/0707_l o/0707_lo.html ) where there are MS Web Service Clients (Web Service Transactions configured) are interoperating with Web Services deployed on WAS and the transaction management is happening. That is an excellent case of web service transaction interoperability. What I am wondering is if that is possible, then why not what I am trying out, where the client would be using axis (instead of Microsoft) and the transaction configuration would be done using Kandula. Let me know if I am not clear. Regards, Anshuk Pal Chaudhuri -----Original Message----- From: Dasarath Weeratunge [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2008 10:55 PM To: Pal Chaudhuri, Anshuk (Cognizant) Cc: [email protected] Subject: RE: Issues while compiling src code Quoting Anshuk <[EMAIL PROTECTED]>: Interfacing JTA with WS-AT is completely different from looking at web services interoperability between different implementations like Kandula, WAS, MSFT etc. I'm not sure which one you are after at this point. If you want to expose some XAResource deployed inside WAS using Kandula, then you need to interface Kandula with the native JTA implementation in WAS. What Kandula does is it creates a JTA transaction whenever it sees a new coordination context and attaches it to the thread that would execute the web service. From there on, the native JTA implementation takes care of the rest. In the absence of such a native JTA implementation we have provided a toy JTA implementation that could be used but this is mainly for testing. When the WS-AT protocol attempts to terminate the activity, Kandula will use its private interface with the native JTA implementation to terminate the JTA transaction that was created earlier. Here Kandula uses the two-phase commit protocol. However, the JTA API is not sufficient to completely handle the two phase commit protocol that is used to terminate a transaction. For example, if you look at how Kandula has been interfaced with Geronimo, you would see that we have used an API exposed by the Geronimo transaction manager which is non-standard. In the case of WAS it is not possible to study their internal API s to do the same. In short, it is not possible to do what we have done with Geronimo with WAS. You could however, try the following: 1) Use a Kandula client with WAS server. 2) WAS client with Kandula server (in Geronimo server or Tomcat + Geronimo transaction manager) Thanks, -- dasarath > Thanks Dasarath for the input. > > As I mentioned earlier, I did try out the WAS-WAS and it is working fine. I > also tried out the Kandula-Kandula (as you mentioned about the banking > example)and it is also working fine. > Now w.r.t. the sceanrio which I described earlier, the first case (WAS-WAS), > the datasource is defined within the WAS container, so the application is > taking care of the rollback. > In the second case, (correct me if I am wrong), the resources are defined in > the BankOneDBMS which implements NamedXAResource so the resources are > enlisted there only and the commit and rollback are managed explicitly > (using the Transaction Manager of Geronimo) > > Now when I am trying to incorporate Kandula (at the client side) and WAS (at > the server side, where the web service is deployed), the transaction > management is not taking place as expected. > > The co-ordination context (within the soap request) that I have sent across > from WAS (when client) and Kandula (when client) seems to be different. > > In case of kandula (being client), the standalone client uses the stubs > (generated from axis wsdl2java) and a client handler does the following: > > > public void invoke(MessageContext mc) throws AxisFault { > System.out.println("handler"); > CoordinationContext ctx; > CoordinationContextType ctxType; > try { > ActivationStub stub = new ActivationStub(new EndpointReference( > "http://localhost:8081/axis/services/activationCoordinator";)); > ctx = stub.createCoordinationContext(ATCoordinator.COORDINATION_TYPE_ID); > > }catch (Exception re) { > try { > ctx = null; > } catch (Exception e) { > e.printStackTrace(); > } > } > } > > I am not sure where I am going wrong. > > Can you guide me on this. > > > Thanks. > > Regards, > Anshuk > > > Dasarath Weeratunge-3 wrote: > > > > Quoting [EMAIL PROTECTED]: > > > > Anshuk, > > > > Have you looked at the banking example? If you are going to > > use WAS on one end and Kandula on the other end I would very much > > like to see what the result is going to be. I would recommend > > that you first try WAS-WAS and Kandula-Kandula before attempting > > WAS-Kandula. > > > >> I did have a look at the documentation, but I am not exactly sure what > >> needs to be done. > > > > This is unfortunately a little too gernal to answer over a mailing list. > > Please be more specific/discrete about what you are trying to do. For > > example, > > if you say you tried this and got this error, then we can tell you why and > > what you need to do differently. > > > > Thanks, > > -- dasarath > > > > > > > > > >> Hi Hannes, > >> > >> Thanks for your input. > >> > >> I did try out using the atomic transaction that comes with the IBM WAS > >> 6.0. The web service would insert some values in a database. The web > >> service client was built using the stubs generated by the IBM SOAP > >> Engine WSDL2Java and configured in such a way so that it would send > >> atomic transaction details in the soap envelope. So, I tested a good > >> scenario and the values got inserted in the table. While testing the > >> error scenario, in the web service after the part of the which does the > >> insertion, I threw a runtime exception explicitly and when I checked the > >> tables, the values were not inserted. > >> > >> Now I intend to do a similar scenario using Apache Kandula at the client > >> side. The same web service (deployed on WAS) would be used, but the > >> client would now send the soap request using apache Kandula and the > >> necessary transaction details (within the soap header) would be sent. > >> > >> I did have a look at the documentation, but I am not exactly sure what > >> needs to be done. > >> > >> Can you help/guide me in testing the above. > >> > >> Thanking you in advance. > >> > >> Regards, > >> Anshuk Pal Chaudhuri > >> > >> -----Original Message----- > >> From: Hannes Erven [mailto:[EMAIL PROTECTED] > > > >> Sent: Sunday, June 29, 2008 4:37 AM > >> To: [email protected] > >> Cc: Pal Chaudhuri, Anshuk (Cognizant) > >> Subject: Re: Issues while compiling src code > >> > >> Hi Anshuk, > >> > >> > >> > What I am not clear is the flow how exactly the client creates the > >> > co-ordination context and so on. > >> > >> I'm not sure what you are exactly looking for and what you already know > > > >> or have read. > >> > >> As a general starting point, I suggest you have a look at the > > > >> WS-Coordination specification and also WS-AtomicTransaction or > > > >> WS-BusinessActivity, whatever transaction type you are interested in. > >> > >> In the source code, at the Kandula server it all starts at > > > >> org.apache.kandula.coordinator.CoordinationService#createCoordinationCon > >> text > > > >> , this is where the call from the client is received. From there, the > > > >> actual transaction coordinator object is created depending on the > > > >> requested type of transaction. > >> > >> > >> If you have further questions or need reading tips, please reply with > > > >> more details what you are interested in. > >> > >> > >> Best regards and thank you for your interest in Kandula, > >> > >> -hannes > >> > >> This e-mail and any files transmitted with it are for the sole use of the > >> intended recipient(s) and may contain confidential and privileged > >> information. > >> If you are not the intended recipient, please contact the sender by reply > >> e-mail and destroy all copies of the original message. > > > >> Any unauthorised review, use, disclosure, dissemination, forwarding, > >> printing > >> or copying of this email or any action taken in reliance on this e-mail > >> is > >> strictly > > > >> prohibited and may be unlawful. > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > View this message in context: > http://www.nabble.com/Issues-while-compiling-src-code-tp18028466p1837975 3.html > Sent from the Kandula mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful.
