1. Will it be possible to span Webservice atomic transaction across multiple applications that are deployed in different servers but are inside the same cell? I have WebSphere 5.1.2 and 6.1 in mind. App1 may be deployed in server 1, app2 in server 2 and app3 in server 3 in WebSphere under the same cell. Can app1, app2, app3 particilate in WS-AT (2 phase commit, rollback etc.)? 2. What if these are different applications e.g. App1 as Java app deployed in WebSphere in New York, App2 as Microst app in IIS deployed in Texas etc. Can I write a Java client using WS-AT and still make the transaction boundary span across applications written in different technologies and deployed across locations and ensure that 2 phase commit, rollback etc. happen? 3. Is WS-AT different from JTA?
A web service doesn't care about location (NY, TX etc.) or implementation (Java, .Net) or the deployment platform (IIS, WebSphere). As long as the service is available (through security etc.) and both service consumer and service provider are interoperable, things will work.
The keyword here is interoperable. In your case, if your client can start a global transaction context and if both client and service support WS-AT, it will work regardless of deployment configurations (cell etc.).
WS-AT is a web service standard for transactions. JTA is Java transaction specification and API. So, if your web service is implemented in Java/J2EE, you can use JTA to execute that web service in its local transaction. If your client is a compatible client, it can use JTA to start a global transaction.
Let's assume Client --> (service 1, service 2, service3). If you use a compatible client (servlet, BMT EJB or in a limited sense J2EE client) in WebSphere, you can obtain a reference to UserTransaction via JNDI lookup and use it to start a global transaction. Within that transaction, you can invoke service1, 2 and 3. In WebSphere web service world, this would use WS-AT behind the scene. Like I have explained in the past, you will have to configure your services and deployment time to use an incoming transaction context.