Tuesday, December 16, 2008

REST: Decision Services Needed More Than Ever

You can switch from classic SOA using service interfaces expressing business capabilities and domain specific messages and data types, to REST exchanging resource representations in standardized formats over the uniform interface with hypermedia expressing the next allowable state transitions of the processes operating on the resources. But how to you put those next state transitions (links) into the representation in the first place? Where is the semantics of the business events interpreted?The classic SOA domain specific service interfaces and schemas try to express semantics that can be used when composing processes, not just a common format and protocol. Yes, you get more technical loose coupling in your systems with REST, but still have to do the semantic interpretation of the business messages somewhere. The huge advantage of REST is that the semantic decisions or compositions of processes are not part of the consumers, allowing applications like mashup clients to be standardized and (re)use a wide range of shared RESTful services. The only decisions consumers make is which of the transitions to follow next.

The application state machine using hypermedia as the engine needs to have a mechanism for deducing which are the next allowable state transitions to emit as links into the resource representation. This is where I think that the classical decision services/business rule engine is a good fit even for REST. Granted, it is a bit unusual to calculate a set of possible decisions - allowable state transitions - on beforehand, kind of a dynamic state-driven workflow. But it should be no stranger than adjusting to accepting the uniform interface. In addition, nothing is stopping you from inspecting the incoming resource representation as part of the decision making for controlling the flow of your business processes.

As I’ve said before, to me REST is just another architectural approach to service-orientation, as is EDA.

2 comments:

I am not sure Subbu's explanation on client vs server composition is correct.

A service composition requires a composition engine that orchestrates the invocation of the different services.

In REST, "composition" means hand off from one server to another. I would not really consider that a "huge advantage". They are just two different things. REST's approach works better at the presentation layer and service composition works better at the process layer.

I believe the links need not be to another server, just a different URI. And these URIs must be put in there by the service provider.

The REST application model is analogous to the messaging model described by Hohpe/Woolf in "Enterprise Integration Patterns" with named topical channels, named document messages and adressing or dynamic routing slips.

The composition is done on the server-side, the client only needs to decide which channel to send the next document message on to signal the process composition of a new business event.