Interposed Clients

Assume, you are running an app server in a multi tier setting. A possible design would be, to let the app server use transactions without exposing transaction demarcation to the front-end tier. In that case, there are good reasons to have an interposed transactional client in the app server, instead contacting a out-of process, possibly remote TXsvc. The business logic in the app server starts transactions by making calls to Current or to co-local (interposed) TransactionFactory. All transaction management logic will be interposed and run in the application's process address space. This eliminates expensive calls to OTS objects residing in the TXsvc - and after all, it does no more need a TXsvc.
As the picture below shows, the app server hosts the transaction management code and must have access to reliable storage in order to realize the needed logging functionality.

The picture above does not show the actual "client", that makes use of the services provided by the app server. You have to carefully design your application, and in particular the client code, with respect to failure handling: while the server logic is executed transactionally, the invocation of the service is not. Imagine, the client sends the request to appserver1, the server transaction is run successfully, but just before getting the reply back to the client, something goes wrong (the reply message could simply not make it to the client). Even if the client code sees some exceptions, this does by no means imply, that the tx1 was rolled back. Simply retrying might not be possible, in all cases. From the client's point of view, the request execution semantic is still "at most once", although there are running transactions at the backend.