Meet The Web, Part 2 (with transaction)

In the previous article "Meet The Web, RESTfully ", we introduced a conceptual model for a RESTful messaging service. In this article, we extended the interface and service to make a group of messaging operations in a transaction possible.

In the RESTful messaging service , the URLs to identify the message services are as follows.

http://www.effectivemessaging.com/jms/production/queue/destination_name
http://www.effectivemessaging.com/jms/consumption/queue/destination_name

Each HTTP protocol interaction (request-response) for the above service is essentially equivalent to a complete transaction. A client application examines the HTTP response code to verify if a message production or consumption request is successful.

At most one message can be in doubt (message in question) when a system failure occurred. In other word, when the application is unable to verify the HTTP response code from the response message, the status of the request is unknown.

This behavior is somewhat similar to a JMS application with a non-transacted (AUTO-ACKNOWLEDGE) JMS session. At most one message's status could be in question (unknown) when a system or network failure occurred.

In order to group a series of operations in a transaction, we define a set of "transacted protocols" to "link" these operations in a transaction.

The "transacted protocols" make it possible to commit or rollback a set of operations performed on the RESTful message service.

A conceptual implementation is described in the second section of this article.


1. Transacted protocols for the message service web interface.

The protocols includes setting the boundaries for a transaction (transaction demarcation). An unique TransactionID is created by the message service when a new transaction is created (START). Each operation in the transaction is then tagged with the TransactionID.

Applications may COMMIT a transaction after setting the END boundary. Applications may ROLLBACK a transaction if the transaction state is after START and before COMMIT.

1.0 Start a new transaction.

An application sends a HTTP request message to start a new transaction. If the request is accepted, a new TransactionID is set in the HTTP response message body and returned to the application.

URL:
http://www.effectivemessaging.com/transactions

Example request message:

----------------------------------------
POST /transactions HTTP/1.1
(other headers omitted)

TXCOMMAND=START
------------------------------------

The HTTP response message body contains a transaction ID generated by the message service.

Example response message:

--------------------------------------
HTTP/1.1 200 OK
(other headers omitted)

TransactionID=12345(UUID)
------------------------------------------

1.1 Produce and consume messages in a transaction.

The associated transaction ID is set in the HTTP header for the HTTP request message.

URL to send a message in the current transaction:
http://www.effectivemessaging.com/jms/production/queue/destination_name

Example request message:

-------------------------------------------------------------------------
POST /jms/production/queue/myQueue HTTP/1.1
Content-Type: text/plain;charset=UTF-8
User-Agent: Java/1.6.0_07
Host: localhost:8888
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 10
TransactionID: 12345 (uuid)

HelloWorld
--------------------------------------------------------------------------

Example response message:

--------------------------------------------------------------------------
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/plain;charset=UTF-8
Content-Length: 0
Date: Mon, 02 Feb 2009 21:59:58 GMT
TransactionID: 12345 (uuid)
---------------------------------------------------------------------------

URL to receive a message in the current transaction:
http://www.effectivemessaging.com/jms/consumption/queue/destination_name

Example consumption request message:

---------------------------------------------------------------------------
POST /jms/consumption/queue/myQueue/ HTTP/1.1
Content-Type: text/plain;charset=UTF-8
User-Agent: Java/1.6.0_07
Host: localhost:8888
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 0
TransactionID: 12345 (uuid)
---------------------------------------------------------------------------

Example consumption response message:

-----------------------------------------------------
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/plain;charset=UTF-8
Content-Length: 11
Date: Mon, 02 Feb 2009 23:04:05 GMT
TransactionID: 12345 (uuid)

HelloWorld
-----------------------------------------------------

1.2 End a transaction.

http://www.effectivemessaging.com/trasnactions/12345(uuid)

Example request message:

-----------------------------------------------------
POST /transactions/12345(uuid) HTTP/1.1
(other headers omitted)
TransactionID: 12345 (uuid)

TXCOMMAND=END
-----------------------------------------

Example response message:

----------------------------------------------
HTTP/1.1 200 OK
(other headers omitted)
TransactionID: 12345 (uuid)
----------------------------------------------

1.3 Commit a transaction.

http://www.effectivemessaging.com/trasnactions/12345(uuid)

Example request message:

-----------------------------------------------
POST /transactions/12345(uuid) HTTP/1.1
(other headers omitted)
TransactionID: 12345 (uuid)

TXCOMMAND=COMMIT
------------------------------------------------

Example response message:

-----------------------------------------------
HTTP/1.1 200 OK
(other headers omitted)
TransactionID: 12345 (uuid)
-----------------------------------------------

1.4 Rollback a transaction.

http://www.effectivemessaging.com/trasnactions/12345(uuid)

Example request message:

-------------------------------------------------
POST /transactions/12345(uuid) HTTP/1.1
(other headers omitted)
TransactionID: 12345 (uuid)

TXCOMMAND=ROLLBACK
-------------------------------------------------

Example response message:

-------------------------------------------------
HTTP/1.1 200 OK
(other headers omitted)
TransactionID: 12345 (uuid)
-------------------------------------------


2. Conceptual transacted message service implementation.

The transacted protocols can be easily implemented (validated) if the RESTful messaging service is backed by a (JMS) service.

Upon received a transaction START request, the message service implementation can create a transaction object and an associated (JMS) transacted session. The transaction object contains the TransactionID as its look-up key and has a reference to the (JMS) transacted session.

The TransactionID is set in the HTTP START response message body and returned to the application.

For each sub-sequential transacted send/receive request (tagged with TransactionID), the message service delegate the request to the (JMS) transacted session associated with the transacted object. The transacted session is used to send and rereive transacted messages on behalf of the request.

The END protocol is defined here to make the interface uniform and extensible in the future (such as two-phase commit protocol support). It is also used to set the END transaction boundary precisely.

For a COMMIT/ROLLBACK request, the message service delegate the request to the JMS transacted session. The transaction is thus committed or rollback via Session.commit() or Session.rollback() if the request is validated.