Atomikos Forum

TCC Participant Service Interface Contract

The current version of the specification on the Atomikos Web site says that the TCC participant service must support:

PUT /part/123 HTTP/1.1
Accept: application/tcc order to perform the "confirm" operation sent from the transaction coordinator.

However, the actual PUT request that is emitted by the Transaction Coordinator to the service provider looks as follows:

PUT  /inventory/100  HTTP/1.1
Content-type: application/tcc
Accept: text/plain
<snipped other headers>

So, long story short, we have a case where the spec and the implementation do not agree :-)

My TCC-compliant participant service is based on the Spring MVC framework.  What I found, at least in the case of Spring MVC, is that it was necessary for my participant service implementation to assert that it produces "text/plain"  (in addition to consuming "application/tcc").   Unless I asserted that, the PUT from the TC was refused.  This seems to be because of a) the behavior of the Transaction Coordinator implementation, that is emitting the Accept header as shown above, and b) the strategy used by Spring MVC to find a suitable provider class....unless I assert that I can produce text/plain, the request cannot be matched with a suitable provider (controller class).

Since the only expected response to the PUT is either 204 No Content or 404 Not Found, there will not be any response body (...other than perhaps human readable error text)...and I think the actual Accept header should not matter that much. While the use of Accept: text/plain media type may be fine for the transaction coordinator interface contract, the specification should probably be updated.  In fact, the  participant service MUST consume Content-type: application/tcc, and MUST produce: text/plain.  

Alternatively, the Accept header emitted by the transaction coordinator could perhaps be more inclusive in what is acceptable, since the response body is not used as part of the TCC protocol anyway.


JohnField Send private email
Friday, March 14, 2014
I guess this conversation is best conducted on our TCC/REST early adopter mailing list...
Guy Pardon Send private email
Monday, March 31, 2014

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics