you need a transaction  manager to handel two face commit.there are several transaction managers such as JOTM (which is an open source transaction manager).however some of application  servers contain transaction manager,such as IBM websphere,JBoss and so on.

two phase commit won't do any good unless the socket conn is transaction  aware because it needs a trans aware end point. here we are assuming the second phase is over a pure socket with a non-transaction aware listener on the other side.am I right? this is possible with either jca adaptor for sockets i.e tcp/ip, or a transaction aware wrapper around socket connection which you can write yourself. open source libs are available for both

We live in 2009 not 2000 and before that, do not downgrade your projects while there are lots of modern and enterprise techs, patterns and tools.

Business Processing techs such as BPEL and BPM engines, JBI, ESB, mule, an implementation of JCA
en....pedia.org/.../Java_EE_Connector_Architecture

This is not the time of using sockets while there are lots of Network programming architecture, language, patterns and tools.
Try EJB, WebServices, JMS ans so on.

You can find lots of distributed transaction  handling solutions there.

if this was a fresh project, you could be right but not a good suggestion for all cases. what if the target platform is a legacy terminal that does not support any enterprise capabilities? no corba, no ejb , nothing? only an up and running legacy terminal that can only listen to sockets?

even if it is not a BABY project, there are so many solutions and framework for such things, specially in Apache, Spring and JBoss Frameworks.

In my opinion, there is no place to use directly socket for network platform projects, there are lots of protocols such as RMI, SOAP, RPC and so on, in order to get rid of implementing TCP or UDP Channels which are million times are implmeneted by so many developers for a specific task.
And in B2B using modern technologies such as BPEL, Webservices, are so recommended even if one or more of Business partner links is legacy systems, and contains my grandfather techs, However there are other simple to learn techs exist. At least we can use for example an EJB Stateful Session Bean for the sake of god to handle or cache our bloody transaction  and connection, instead of Sockets :O

My suggestion is that we shouldn't be traditional blind, having an open mind and being a little bit smart and expert, makes the things easier for us.

you didn't get the point. the question was, what if the target platform for xml  file is a legacy terminal that can only be accessible through sockets?
in that case the wise decision would be to make that socket to be transaction  aware, because if the target platform is already functioning as expected the cost of adding the stuff that you listed would be much higher than making socket transaction ware

thanks to everyone for participating i this discussion.

Lets put in this I have a web service which responds to a call and send  a
message to third party application.

How do my service know that the response is consumed.

it depends on what the "third party application" is and what capabilities it has. is it the one that you are connecting over sockets? is it the only way? if you tell us more about the TP application  and how you're connecting to it we could help more.

It makes quite a difference if the third party communication can or should be asynchronous. On top of that, is there a talk back channel from the third party? JCA seems to be a necessary solution if you are opting for synchronous communication and the third party operation should be part of the web service transaction. Unfortunately I am a door knob here so I won't say more. However, if asynchronous communication is permitted and the third party component can talk back to whoever-contains-the-web-service, I do suggest you looking into using persistent state machines. Each side of this communication has a state machine which remembers in which state of talking this side is in, and each event  will move the operation one step closer unless an error happens. Each event here can be carried synchronously. This might not be the solution for you if your me-and-my-third-party logic is not slicable like the bread I still have in my kitchen.