SCA HTTP Conditional Scenarios (vtest)

This page describes in further detail the Atom Binding scenarios in the Tuscany Web 2.0 roadmap at http://tuscany.apache.org/sca-java-roadmap.html.

A broader view of all the scenarios is located at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Scenarios.

Explanation of the use of caching in HTTP is in the HTTP spec at http://tools.ietf.org/html/rfc2616. Explanation of the use of caching in Atom is explained in the Atom spec at http://tools.ietf.org/html/rfc5023.

Understanding HTTP Conditional Actions and Caching using ETags and Last-Modified

The HTTP specification provides a set of methods for HTTP clients and servers to interact. These methods form the foundation of the World Wide Web. Tuscany implements many of these methods a binding interface to a collection. The main methods are:

  • GET - retrieves an item from a collection
  • POST - creates or adds an item to a collection
  • PUT - updates or replaces an item in a collection
  • DELETE - removes an item in a a collection

The HTTP specification (HTTP 1.1 Chapter 13 - Caching) also provides a mechanism by which these methods may be executed conditionally. To perform conditional methods, an HTTP client puts 3 items in the HTTP request header:

  • ETag - entity tag, a unique identifier to an item in a collection. Normally created and returned by the server when creating (POST) a new item.
  • LastModified - an updated field. Normally a string containing a date and time of the last modification of the item.
  • Predicate - a logical test (e.g. IfModified, IfUnmodified) to use with the ETag and LastModified to determine whether to act.

The complete list of predicates is given in the HTTP specification.

The most common use of conditional methods is to prevent two requests to the server instead of one conditional request. For example, a common scenario is to check if an item has been modified, if not changed update it with a new version, if changed do not update it. With a conditional PUT method (using the IfUnmodifed predicate and a LastModified date), this can be done in one action. Another common use is to prevent multiple GETs of an item to ensure we have a valid copy. Rather than doing a second request of a large item, one can do a conditional GET request (using an IfModified predicate and a LastModified date), and avoid the second request if our object is still valid. The server responds with either a normal response body, or status code 304 (Not Modified), or status code 412 (precondition failed).

Tuscany implements the logic to move these caching items to and from the HTTP request and response headers, and deliver them to the collection implementation. The items are delivered to a user implementation via a serializable object called CacheContext. This object contains the value of the ETag, the LastModified value, and any predicates. It is up to the implementer of a collection to provide the correct server logic to act on these predicates.

As an example, one can look to the module http-binding unit tests to understand how these conditional request work. The HTTPBindingCacheTestCase contains 36 tests of all 4 HTTP conditonal methods. Various predicates are tested with various ETags and LastModified fields. The fields are tested in both the positive and negative cases.

Here is a complete list of the tests as implemented by TUSCANY-2516 and TUSCANY-2601:

  • testGet() - tests normal GET method of collection, expects item
  • testConditionalGetIfModifiedNegative() - tests not modified GET, expects item
  • testConditionalGetIfModifiedPositive() - tests modified GET, expect code 304
  • testConditionalGetIfUnmodifiedNegative() - tests unmodifed GET, expects item
  • testConditionalGetIfUnmodifiedPositive() - tests modified GET, expects code 412
  • testConditionalGetIfMatchNegative() - tests matching GET, expects code 412
  • testConditionalGetIfMatchPositive() - tests matching GET, expects item
  • testConditionalGetIfNoneMatchNegative - tests unmatching GET, expects item
  • testConditionalGetIfNoneMatchPositive() - tests unmatching GET, expects code 412

Similarly, there are 9 tests each for DELETE, POST, and PUT, making a total of 36 test cases.

The TestBindingCacheImpl class implements a server collection which pays attention to conditional methods. Notice that this collection implements conditionaGet, conditionalPut, conditionalPost, and conditionalDelete methods as well as get, put, post, delete. Tuscany automatically routes a request with proper request header fields (ETag, LastModified, and predicates) to the proper collection method. The server collection can look at the CacheContext obect to determine whether an item or a status code should be returned.

TO DO: Provide diagram that shows the routing of requests to collection methods.

Differences Between HTTP Binding Caching and Atom Binding Caching in Tuscany

A similar sort of conditional posting is implemented in the Atom Binding. The difference is that the HTTP binding requires an implementer to provide conditional methods. The Atom binding caching uses the Abdera Atom model objects to automatically derive an ETag and a LastModified tags. In the Atom model, the Entry or Feed ID is used to make an item ETag field. The Atom Entry or Feed updated field is used to make an item LastModified field.

(lightbulb) Use the HTTP binding caching when you are not using Atom Entries and Feeds as your business objects. However, the more flexible HTTP binding caching requires you to implement special conditional methods. Use the Atom binding when you can model your business data in terms of Atom Entries and Feeds. The more constrictive Atom binding caching will derive caching tags from your data model fields.

  • No labels