the problem with an in-memory system like HANA is that it gives you an excuse to run poor software, since after all, even the crappiest software will run faster in-memory. But if you think that running a partition-intolerant relational database in-memory will make it any more Cloud friendly, then you’re missing the point of the Cloud.

Read the entire post at http://www.devx.com/blog/why-i-just-dont-get-sap-hana.html.

When ZapThink last wrote about Business Process Management (BPM) in the Cloud in March 2012, we challenged both vendors and BPM customers to rethink their approach to BPM software, eschewing a heavyweight middleware approach for the lightweight, hypermedia-oriented approach that Representational State Transfer (REST) encourages. And while we did generate some short-lived buzz, most of the response – or lack thereof – was little more than a resounding silence.

True, work on Cloud-friendly, REST-based BPM continues in certain dusty corners of academia, most notably in the research of Cesare Pautasso, a professor at the University of Lugano in Switzerland. But in spite of his notable contributions to Thomas Erl’s SOA with REST book, the enterprise software and Cloud marketplaces have largely either ignored or misunderstood his research as well as ZapThink’s on this topic.

While it’s amusing to theorize a vast vendor conspiracy, positing middleware dinosaurs actively working to distract their customer base from lighter weight, Cloud-friendly approaches, the reality is likely to be far more mundane. People just don’t get it. Or to be precise, our audience doesn’t get how all the pieces—BPM, REST, Cloud, and even a bit of SOA—fit together. To help resolve this confusion, let’s resort to an age-old technique: let’s draw some pictures.

Framing the Cloud-Friendly BPM Problem

Let’s start this discussion with an illustration of an admittedly simplistic business process involving one person and some back-end system, as shown in Figure 1 below.

Figure 1: Simple Two-Tier Process

Note that in the figure above, the user might tackle a few tasks, and then the server takes over, executing a few tasks on its own. While the server is busy doing its thing, the user might query the server as to the current status of the process.

So far so good, but we don’t want our server to serve only one user at a time. After all, the whole point of the client/server pattern is that it is many to one. As a result, we need to introduce the notion of a process instance. For the sake of simplicity let’s assume that we don’t have more than one person participating in a particular instance at the same time. But we might have multiple people each running their own instance of a process, for example, completing a purchase on a Web site, as shown in Figure 2 below.

Figure 2: Two Tier Process with Instance

In the figure above, the BPM engine running on the server spawns a process instance to deal with the interactions with the user. If multiple users initiate the same process, the server can instantiate as many process instances as necessary, and the engine keeps track of where every user is in their instance—in other words, the instance state.

How to keep track of all this state information in a scalable, robust manner is at the core of numerous distributed computing challenges. Today’s BPM engines generally run on Enterprise Service Buses (ESBs), which maintain state by spawning threads—short-lived, specialized object instances that run  in the execution environment of the ESB. But while threads are short-lived, process instances might take days or weeks to complete, and furthermore, threads are specific to the execution environment, making cross-ESB processes difficult to implement. For these reasons, we call state management the Achilles Heel of traditional, heavyweight (Web Services-based) SOA.

If such ESB-centric issues weren’t bad enough, the Cloud introduces a new wrinkle. Because we want to run our server in the Cloud, we don’t want to use it to maintain any state information, because we expect virtual machine (VM) instances to fail. In the Cloud, we provide automated recovery from failure rather than avoiding failure. However, if we store all the state information in the underlying persistence tier (not shown), then we limit our scalability, since every time anyone clicks a link, we must update a database somewhere.

What we need is a better way of dealing with state information that both allows our BPM engines to be Cloud friendly, and also frees us from the limitations of our ESBs. Or perhaps we must reinvent our ESBs to work in the Cloud. However you slice the problem, Hypermedia-Oriented Architecture (HOA) has the answer.

HOA to the Rescue

As ZapThink has discussed before, many people misconstrue REST as an API style that features a uniform interface, where in reality it’s a style of software architecture for building hypermedia systems. Why is the latter definition a better one? Because Roy Fielding, its creator, says so. That being said, work continues on the architectural context of REST, perhaps extending Fielding’s original thinking, as well as beyond the API style that most techies think of when they think about REST. We call this extension of the REST architectural style Hypermedia-Oriented Architecture, or HOA.

The central principle of HOA is the HATEOAS REST constraint: hypermedia is the engine of application state. In essence, HOA separates two different types of state information: application state and resource state. Application state corresponds to the user’s place in the runtime workflow consisting of hyperlinked representations, while resource state remains on the server, keeping track of persisted state information and state information that multiple users share.

On the one hand, HATEOAS requires hypermedia to manage all state information specific to individual clients, and on the other hand, delegates all other state information to the server. REST also specifies a set of verbs for querying an changing state information: GET for querying resource state without changing it,  and three verbs that change the resource state: POST for initializing a resource, PUT for updating a resource, and DELETE for deleting a resource (assuming we’re using HTTP as our transport protocol).

Note, therefore, that all verbs other than GET change the resource state, while all verbs, including GET, change the application state. Furthermore, all state information appears in the messages between client and server: the requests from client to resource, and the representations from resource to client. By extension, HATEOAS requires us to only use POST, PUT, or DELETE when—and only when—we must update resource state.

With this principle in mind, we have a real problem with the process in Figure 2. Note that the server is maintaining application state, which HOA forbids. But we can’t solve this problem simply by picking up the process instance from the server and sticking it in the client and expecting it to work properly, because sometimes we really do want to update the resource state. We somehow need to separate the process instance into two (or more) pieces so that hypermedia on the client can be the engine of application state while the BPM engine remains the engine of resource state.

Figure 3 below illustrates this principle. The client sends a POST to the server, which initializes a resource. In this case, that new resource sends a hypermedia representation to a stateless intermediary which caches the representation. This hypermedia representation is essentially an abstraction of a dynamic set of hyperlinked representations, for example, one or more php scripts that can generate a set of hyperlinked Web pages. Once the intermediary has the hypermedia representation, it returns the initial representation (for instance, a Web page) to the client.

Figure 3: HOA-Based Process with Stateless Intermediary

From that point on, as long as the client is navigating the application via hypermedia, changing only the application state as the user moves from one step in the process to the next, there is no need to change the resource state—and thus, no further POSTs, PUTs, or DELETEs are allowed. The client may perform a GET, because GETs change only the application state. The intermediary may be able to handle the GET on its own (if the necessary information is resident in the cache) or can turn around and perform a GET on an underlying resource, if necessary.

Furthermore, the application state may change without any interactions with the intermediary or the server by leveraging programmatic capabilities on the client. If the client is an arbitrary piece of software then this capability is trivial. But even if the client is a browser, it’s possible to change the state of an application without fetching anything from the server. In fact, there are many was to accomplish this feat.

Sometimes, of course, a hypermedia application, which we might also call a HOA process, must update resource state, for example, when it’s time to process the user’s credit card or change the number of widgets in inventory. Then—and only then—do we perform a PUT.

The most important characteristic of the process in Figure 3 is the fact that the intermediary is entirely stateless. If for some reason the VM that is hosting the hypermedia representation that is serving the client crashes, the Cloud environment must simply spawn a replacement and reload the same hypermedia representation as before. The client won’t lose its place because the hypermedia on the client are maintaining the application state. Similarly, we can horizontally scale the middle tier however and whenever we like. Instead of one VM hosting a particular hypermedia representation, we could have two or a hundred, and it doesn’t matter which one responds to a particular GET from the client.

Combining HOA Processes and Traditional BPM

The problem with the example in Figure 3, of course, is that every client’s process is separate from every other client’s process. However, most business processes in today’s organizations involve multiple parties—either multiple people or multiple enterprise applications or some combination.

On first glance, HOA doesn’t address such complex processes, since HATEOAS only deals with application state, not resource state. Fortunately, HOA works perfectly fine in this broader context as well, because it calls for a separation of application and resource state while providing for multiple ways to update resource state. After all, POST, PUT, and DELETE all update resource state, and any user can execute these verbs for a particular resource. Figure 4 below illustrates this more complex process.

Figure 4: HOA Process with Composite RESTful Service

In the figure above, a POST from a client instructs the BPM engine to instantiate a process instance on the server as in Figure 2. The first step in this process creates a hypermedia representation for the client to interact with as in Figure 3. Meanwhile, the resource state may change via any event, including a server-generated event or the action of a different user. If a user executes a PUT on the client to the hypermedia representation on the intermediary, then that representation turns around and PUTs to the appropriate underlying resource. Or perhaps the client PUTs to an underlying resource directly. Either way, the PUT goes to a hyperlink the client obtained from a previous representation at an earlier step in the process.

We might call the process running on the server a Composite RESTful Service, because the intermediary may abstract the entire server-based process via one or more RESTful URIs. A simple example of a Composite RESTful Service is a chat window application. Multiple users share the same chat session, so clearly the chat session state is part of the resource state.

There are a few essential points to keep in mind about the illustration in Figure 4. First, the intermediary remains stateless and therefore Cloud-friendly. We must maintain resource state in the persistence tier, but since we’ve offloaded the maintenance of application state to the client, we won’t be overburdening our database. We may also interact with our Composite RESTful Service via RESTful interactions, an essential benefit that Prof. Pautasso emphasizes in his research. And finally, not only is the middle tier horizontally scalable and elastic, so is the client tier—because every user brings their own client to the process.

The ZapThink Take

With the addition of an appropriate approach to building a RESTful Service abstraction, Figure 4 also serves as an illustration of how to implement RESTful SOA, what ZapThink refers to as “next generation” SOA in our Licensed ZapThink Architect (LZA) course as well as in my new book, The Agile Architecture Revolution. We therefore have a single, simple diagram bring together the worlds of SOA, BPM, Cloud, REST, and HOA.

The secret to getting all these architectural trends to work well together centers on how we deal with state information. We must first separate application state from resource state, and then subsequently take the conceptual leap to understanding that the best way to implement our business processes is by combining HOA processes with Composite RESTful Services. Once we make this leap, however, the pieces of this complicated puzzle finally fall into place.

Image credit: Bruce Guenter