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
Host: www.example.com
Accept: application/tcc
...in 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.
Thoughts?
Thanks,
John
PUT /part/123 HTTP/1.1
Host: www.example.com
Accept: application/tcc
...in 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.
Thoughts?
Thanks,
John
JohnField 
Friday, March 14, 2014
Friday, March 14, 2014
Other recent topics