CTS2/doc/Architecture

The architecture of CTS2 is based on three fundamental requirements.

1. CTS2 services should be easy for clients to use, no matter what technologies those clients are made of. Services should be built on widely adopted and simple protocols.
2. CTS2 services should be lucid; that is, they should reveal enough information to allow partners to navigate them without having memorized and coded to a detailed and potentially brittle interface specification. Notice that this requirement can run counter to the data-hiding principle of object oriented architecture.
3. CTS2 services should be scalable, both in terms of reducing the need for service execution through reuse (e.g., the ability to cache stable information for reuse) and the ability to add service capacity (e.g., by federating multiple implementations).

These requirements are, not coincidentally, the same requirements used in the development of the World Wide Web. They have been used to develop a set of architectural principles known as REST (Fielding, 2000), which have in turn been used to develop an architecture known as ROA, or the Resource Oriented Architecture (Richardson, 2010). As Richardson has it, “The same features that make a web site easy for a web surfer to use [can] make a web service API easy for an programmer to use” (rr xvii). CTS2 adopts ROA, holding that the requirements above are met by the features of the Resource Oriented Architecture:

• Easy (uniform interface): ROA supports ease of use with a uniform interface. Rather than supporting a proliferation of service contracts that differ from relationship to relationship, requiring complex negotiations between implementers, the methods available to ROA service calls are the core HTTP methods GET, PUT, DELETE, and POST (and, less frequently, HEAD, OPTIONS, TRACE, and CONNECT). The simplicity of HTTP supported widespread adoption of the human-facing web, co-opting and largely replacing many other internet protocols (gopher, ftp, usenet, etc.); it can do the same for the computable web.
• Lucid (addressability & connectedness): Every resource has at least one Uniform Resource Identifier, and service clients can discover these URIs by requesting related resources. Just as a search page on the web is a resource that contains links to related resources, allowing human users to navigate from a more general resource to more specific resources, a well-designed service resource will provide links to other resources of interest.
• Scalable (statelessness): By providing links to other resources, a search page provides a web user with a process path, even though the server does not know what path the user is following. This is what is meant by “Hypertext as the engine of application state” (or “HATEOAS”): because the resource, with its links, provides sufficient documentation of client state at any point in the process, the server is freed from the need to track state. ROA services are stateless, which is absolutely critical to supporting what Fielding calls the “anarchic scalability” of the web.

The trick to all this is sound design of resource boundaries. Resources should be fairly precise, as resources that are too big require more granular services than HTTP provides. And the set of available resources should include supporting resources, like lists and catalogs, to help clients navigate to the resource of interest without requiring a set of resource URI generation rules that would re-introduce the brittleness addressed by using HTTP service definitions.

In the interest of making the resource boundary definitions as clear as possible, we provide a tracing between the CTS2 information model and the model proposed by the HL7 SFM.

---

Further Reading

• Fielding, Roy, “Representational State Transfer (REST).” Chapter 5 of "Architectural Styles and the Design of Network-based Software Architectures." (unpublished PhD diss., University of California, Irvine, 2000), http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.
• Fielding, Roy, and Richard Taylor, "Principled Design of the Modern Web Architecture," ACM Transactions on Internet Technolog, 2, no. 2 (2002): 115–150, http://www.ics.uci.edu/~taylor/documents/2002-REST-TOIT.pdf (accessed October 10, 2013).
• Richardson, Leonard, and Sam Ruby, RESTful Web Services. Sebastopol, CA: O’Reilly, 2007.
• Robinson, Ian, Jim Webber, Savas Parastatidis, REST in Practice: Hypermedia and Systems Architecture. Sebastopol, CA: O’Reilly, 2010.