Application Platform Strategies Blog

Excellent example of a RESTful Coffee Service

Blogger: Anne Thomas Manes

Let's raise a mug of fresh brew to Jim Webber, Savas Parastatidis, and Ian Robinson for an excellent example of RESTful application design. See their article on InfoQ.

Does Microsoft get REST?

Blogger: Anne Thomas Manes

I tuned into Burley Kawasaki's analyst briefing on .NET 4.0 and Project "Dublin" on Wednesday from the airport in Amsterdam (returning home from the SOA Symposium conference). I didn't get a chance to watch the Live Meeting presentation because I was standing in a security line, but for the most part I was able to pay attention to the discussion. I hope to get a more in depth F2F presentation next Wednesday, so stay tuned for more information.

I'm anxious to get my hands on the new WCF REST Starter Kit, which will be distributed at the PDC later this month. But I was a little concerned by a couple of comments Burley made regarding REST and this new toolkit. He indicated that developers would be able to create services and expose them either through WS-* or REST without any need to change the application design. He also indicated that developers would typically select WS-* for more "robust" application requirements and REST for more lightweight (i.e., less robust) application requirements.

These comments make me seriously question whether Microsoft really understands REST. It sounds to me that WCF 4.0 will adopt the same "RPC-based POX over HTTP" model used by many Java-based toolkits that supposedly support REST. They basically take an object's methods and map them directly to URLs with query strings, and you wind up with URLs that look something like:

http://www.example.com/setValue?value=1234

I know that folks like Don Box really get REST, so I was really hoping that Microsoft would design a great RESTful toolkit that helps developers design applications that really exploit hypermedia as the engine of state and develop a good resource model that could then be mapped to their method-oriented object models. But based on this quick introduction, I'm preparing for disappointment.

See my previous blog entry on the Tao of REST for more background on what makes an application RESTful.

The Lessons Learned from "Forensic Architecture"

Blogger: Anne Thomas Manes

Duane Nickull posted an interesting treatise regarding the lessons he's learned from four SOA-related architectural efforts he's participated in during the past 9 years, including ebXML, W3C Web Service Architecture, UN/CEFACT eBusiness Architecture, and OASIS Reference Model for SOA. He refers to the experience as "forensic architecture", which he describes thus:

"Forensic Architecture! What is it? I use this term to refer to the process of describing the architecture of something after it has been built. It is a largely frustrating, cumbersome process yet I seem to have made a career out of it."

I'll point out that Roy Fielding's dissertation on REST is an example of "forensic architecture" based on this definition. Dr Fielding wrote the dissertation after the Web had been implemented, and REST describes the architecture of the Web. And it's an excellent and very successful architectural document. But I will also point out that Roy had the advantage of writing his dissertation by himself rather than as part of a committee. At the end of Duane's post he plugs his new book on Web 2.0 Patterns, which is yet another attempt at forensic architecture -- this time exploring the various patterns that exemplify Web 2.0.

I think Duane's treatise provides excellent insight into the challenges of working in a formal standardization committee with many representatives from many organizations with vested interests in developing standards that correlate with their existing products. It's extremely rare to find standardization efforts that develop greenfield architectures from scratch. In fact, I can't think of one formal standardization effort that developed a greenfield architecture. But that's the nature of standards bodies. They only get involved after an architecture or technology has demonstrated sufficient value to warrant standardization.

I,too, was involved in the ebXML and W3C Web Services Architecture (WSA) efforts.

Regarding ebXML, Duane neglects to mention that the folks organizing the ebXML effort had been involved in earlier eBusiness architecture efforts, such as UN/EDIFact, so they had some preconceived notions of eBusiness architcture, which provided the foundation for defining and creating the six ebXML architectural committees. But Duane is spot on when he says that these preconceived architectural assumptions were not documented before the effort began. And time-to-market superceded all other architectural requirements.

Regarding W3C WSA: I recall the heated discussion that consumed the first three months of the effort -- we tried to define SOA. Eventually we decided to punt. I have yet to see a one-line description of SOA that everyone can agree to. A number of folks that I respect greatly (including Duane) always point to the definition specified in the OASIS Reference Model for SOA, which says, "Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains." This definition has value because it calls out some important features of SOA:

• Services implement capabilities
• Services may be distributed
• Service interactions often cross ownership domains

Unforunately, this definition misses the fundamental feature of SOA, i.e., SOA design principles, such as separation of concern, loose coupling, and service orientation. I also come away from the OASIS definition thinking almost exclusively about business functionality, and it doesn't inspire me to think about applying SOA principles to infrastructure functionality or data.

Burton Group's one-line definition of SOA is:

"SOA is a set of design principles that makes systems more flexible, reusable, and interoperable."

But note that this definition doesn't call out the features expressed in the OASIS SOA RM definition. As I said, no one-line SOA definition suits everyone.

Some additional comments on Duane's perspective on a perfect architectural experience. He says:

The sequence of events in a perfect world usually involves the following steps:

1. A problem is identified.
2. The problem is documented.
3. A solution is proposed.
4. Specific requirements for the solution are documented.
5. An architecture is proposed to solve the problem.
6. An iterative process of mapping requirements to solutions takes place until all issues are resolved.
7. The final solution is built and solves the problem.

I assume that a bit of analysis occurs somewhere between steps 2 and 3, and I'd also expect quite a bit more iteration to occur in steps 3 thru 5, with quite a bit of protoyping and solution building going on during those iterations. I would also expect some gap analysis of current solutions to occur in steps 1-3 to explain why current solutions can't address the problem.

The Tao of REST

Blogger: Anne Thomas Manes

Check out this excellent discussion about the Tao of REST:

Jon Udell initiated the discussion in his post about the REST API now offered by the World Bank. Stefan Tilkov responded with a post of his own by expressing his dismay regarding the unwieldiness of the URLs used in the API (they tunnel verbs through the URL). Jon concurred with Stefan that the API could be webbier.

The responses to Jon's second post are particularly interesting. 

Miguel de Icaza's comment causes me to ruminate:

"My friend Nat was wondering about this data the other day, and since this is all static data the question is: why was this data not published merely as a Sqlite database dump?

Do we really need a REST web service to static data when we already have a good query and mining language?

Maybe the only use of this REST API is to download all the data and stick it into a SQL database ;-)"

Miguel's questions brings to mind a conversation I had recently with Peter O'Kelly regarding an emerging data model: hypermedia, which is webby and RESTful at a fundamental level. The hypermedia data model is essentially a flat data model (i.e., no predefined hierarchical or tabular structure), and it uses hyperlinks to express relationships within the data. Every data item (or collection of data items) is identified by and accessed via a URL, and any data item can express a relationship with any other data item via a hyperlink. I think this model is much more expressive than a data model that relies on primary and foreign keys to express relationships. The question of static or dynamic content doesn't really come into play from this aspect. The data model determines what means you have at your disposal to access and navigate your way through the data. Perhaps underneath the data might be managed in a SQLLite file. On the other hand it might just be an indexed file or an enterprise-class DBMS or data generated by an aplication. As Stefan said in his reply to Miguel:

Once nice aspect of good URI design and a REST approach that deserves the name would be that you couldn’t tell whether the data is kept statically, generated dynamically, or some arbitrary mixture.

Effort to define standards for RESTful registries beginning

Blogger: Anne Thomas Manes

Back in January, shortly after MuleSource and WSO2 announced their RESTful registry products (Mule Galaxy and WSO2 Registry respectively), I issued a call to arms to the vendor community to define some standards that would enable information exchange. I'm glad to report that an effort is beginning. 

Glen Daniels from WSO2  raised the issue again in his blog last week, and Dan Diephouse from MuleSource picked up the baton and offered some basic scoping requirements. Glen responded the next day with some thoughts on open repositories and APP patterns, and Paul Fremantle from WSO2 set up a Google Code Project for it.  Michael Neale from Red Hat (core team member for JBoss Rules and Drools) has joined the project, too.

WOA, ROA, SOA: When will it stop?

Blogger: Anne Thomas Manes

Yikes! The "WOA" term (Web Oriented Architecture) has popped up again. Nick Gall first introduced the term in late 2005 at a Gartner Summit. He described it as a subset of SOA that embraces the principles of REST and W3C's Architecture of the World Wide Web. No one really picked up on the term at the time. I suspect it was drowned out by the Web 2.0 hype.

But then Dion Hinchcliff wrote about it (and redefined it) in February this year. And now there's been a flurry of discussion about the term, starting with a post on ZDNet by Dana Gardner in early April hailing WOA as the savior for SOA. Dion followed up with another article on ZDNet recounting Web 2.0 success stories and implying that SOA might be more successful if it focused on WOA instead. But the pundit community has reacted poorly to yet another "xOA" acronym. Mike Meehan at SearchSOA summarized the discussion nicely and asked if WOA brings anything new to SOA. The same day Dana Gardner published a second article on ZDnet entitled "Enough with WOA". And just last week the ZapThinkers weighed in on the discussion, pointing out that SOA and WOA are different levels of abstraction, and proposing yet another term, "Web-oriented SOA". (Please, no!)

Personally, I don't see any value in the WOA term. I don't view it as significantly different from a RESTful style of building services, but Nick provided some additional reasoning behind the term in a post from August 2006, indicating that the W3C Web Architecture adds some additional constraints.

Dion's revised definition seems to miss Nick's subtle distinction between REST and WOA. Dion's definition is essentially REST, and I don't see the point of using multiple terms for the same thing. We already have way too many terms:

• Tim Bray calls it "Web Style".
• Leonard Richardson and Sam Ruby call it ROA (Resource Oriented Architecture) in their book on RESTful Web Services.

Note that ROA has an entry in Wikipedia, but WOA does not. No doubt someone will rectify the situation soon and ensure that the term "WOA" is formally defined and remains to confuse us all.

I find it amusing that Dion's Web 2.0 Success Stories article was indirectly in response to my post calling for SOA success stories. Advocates of WOA/ROA/WebStyle/etc claim that development of services using simpler technologies such as POX (plain old XML) over HTTP will facilitate SOA success. But as I've recounted before, SOA is not about technology. Using REST rather than WS-* isn't likely to improve the success rate of your SOA initiative. Our research makes it clear that the primary impediment is adoption (i.e., getting the business to buy into the initiative and sponsor development of services).

And actually, the most important thing to understand from a technical perspective is that a service should support access via multiple styles of interface. It should enable an application to interact with it using whatever means it wants:

• A method-oriented interface (e.g., SOAP)
• A message-oriented interface (e.g., JMS)
• A resource-oriented interface (e.g., HTTP)

As the ZapThinkers said, SOA and WOA specify different layers of abstraction. SOA specifies a system-level architectural style (i.e., how to implement capabilities so that they can be consumed by many applications). WOA refers to an interface-level architectural style (i.e., the means by which service capabilities are exposed to consumers). WOA (aka REST or ROA) advocates a resource-oriented interface. (Note, though, that many folks interpret WOA simply as POX over HTTP, which may actually support a method-oriented interface rather than a resource-oriented interface.)

SOA is about services at a conceptual level -- not about any particular technology, interface style, or protocol. You should be designing your services for the long-term. It's highly likely that the technologies that are all the rage this year will fade away into obscurity within the next five years. A service encapsulates a capability and makes it available to application consumers through one or more interfaces/protocols. Be careful to maintain a clear separation of concerns between the service implementation and the interfaces used to expose it. Chances are high that you will need to add additional interfaces over time.

REST is about Resources

Blogger: Anne Thomas Manes

The folks at InfoQ have been doing a nice job putting together information about REST. SOA Lead Editor Stefan Tilkov posted A Brief Introduction to REST in December, which explains REST in simple terms and provides some basic examples of the model. For those looking to delve more deeply into the REST architectural style, I recommend reading Mark Baker's article, Hypermedia in RESTful applications. As Mark says at the start of the article, "Hypermedia as the engine of application state" (HATEOAS) is arguably the most important constraint in REST.

The most recent REST article posted on InfoQ is a follow-up article by Stefan, entitled Addressing Doubts About REST. He starts off by addressing the issue I hear most often from developers who inherently resist the notion of constraining an application to a uniform interface: "REST may be usable for CRUD but not for *real* business logic". Stefan explains how GET, PUT, POST, and DELETE can be used to accomplish a variety of functions that deliver more value than just create, read, update, and delete (CRUD) of data, and he shows an example of using GET to call a calculation function. But I don't think he effectively dispels this concern. And that's because he doesn't go the next step to talk about resource models.

REST is fundamentally about resources. Every "thing" that anyone might ever want to access or manipulate is a resource. And what that means, in practical terms, is that an application's interface is defined by the resources that it exposes (i.e., its resource model). Thinking in terms of resources rather than objects and methods requires a fundamental shift in application design. This is the biggest challenge that the typical OO developer is likely to have in adopting REST. If you're working on a RESTful application, and you find that you just can't support the functions you need without tunneling an RPC through POST, then you should go back and reassess your resource model.

Joe Niski is right now working on a revision of our report on Ruby on Rails, and one of the coolest features in Rails 2.0 is its inherent support for REST via the resource_controller plug-in. It automatically generates a resource model that exposes the application's data model as RESTful resources. See the InfoQ article by Rick DeNatale for more information, Rails: Resource_controller Plugin Put Controllers on a Diet.

Rails 2.0 is a really nice framework for building RESTful web applications, but the Rails sweet spot is focused on relatively simple applications based on relatively simple data models performing basic CRUD operations. If the application requires more complex processing, Rails is not such a good option. It requires a lot of complex coding to do complex things. So this brings us back to the big issue raised by Stefan: What to do if the application needs to do more than simple CRUD?

The answer is to use an abstraction layer. Keep in mind that a RESTful application's interface is defined by its resource model. Also keep in mind that the resource model does not need to map one-to-one to methods in the application's object model. And here's where many supposed "REST" frameworks tend to fall down. Most service frameworks invariably map the application's object model directly to its resource model. This approach often leads to non-RESTful POX services that violate RESTful principles. For example, a framework might map a setter method to a GET operation:

GET http://example.com/products/setPrice?item=widget&price=10.95

This is an extreme no-no. A GET operation should never update a resource. But how is a framework supposed to know whether a particular object method is "safe"?

That's why it's a good idea to start designing a RESTful application by defining its resource model. You need to ensure that you can expose all the required capabilities of the application through resources that support the uniform interface (GET, PUT, POST, and DELETE). From there, you can map the resource methods to code that implements the required capabilities.

 

Summary of APS VantagePoint Telebriefing

Blogger: Anne Thomas Manes

If you missed the Application Platform Strategies VantagePoint telebriefing this week, you can find a nice summary of the SOA-related aspects of it in this article by Rich Seeley.

MuleSource Releases Another RESTful Open Source Registry Repository

Blogger: Anne Thomas Manes

Following closely on the heels of WSO2, MuleSource (the commercial entity behind Mule, the popular open source ESB) has released another RESTful open source registry/repository. This new product, called Galaxy, is a bit more feature complete and mature that the WSO2 repository.

Like the WSO2 repository, Galaxy treats each piece of information captured in the repository as an identified resource--i.e., a resource with a URI--which can be accessed and manipulated using the traditional HTTP verbs. The repository also supports remote access and notifications using the Atom Syndication Format (Atom) and the Atom Publishing Protocol (AtomPub).

Also like the WSO2 repository, Galaxy does not conform to the prevailing registry standard, UDDI, and therefore presents a bit of a challenge to organizations looking to use a registry to enable information exchange among heterogeneous SOA infrastructure components. Galaxy provides deep runtime integration with Mule and with the Apache CXF service platform, but connecting it with other ESBs and platforms (e.g., WebSphere, AquaLogic, Microsoft WCF) and with other management and mediation systems (e.g., XML gateways and SOA management systems) is left as an exercise for the implementor. REST makes that exercise relatively straight forward, but work is required.

At this point, three vendors provide fully RESTful repositories: MuleSource, WSO2, and HP Systinet. The IBM WSRR product also supports RESTful access to some of the entities in its repository. HP and IBM both support automatic synchronization between their repositories and a UDDI registry. The folks at MuleSource tell me that a similar synchronization feature is potentially on their roadmap, depending on customer demand.

Unfortunately, all four RESTful repositories use proprietary data models. It would be very helpful if these vendors got together to try and bang out some standards.

The difference between SOA and 3-tier

Blogger: Anne Thomas Manes

Jeff Schneider recently started a thread on the Yahoo! service-orientated-architecture discussion list asking for a comparison between SOA and 3-tier. Here's my response:

3-tier or n-tier application architecture is just that -- an *application* architecture. It's focus is on building monolithic applications that can be distributed across multiple processors to increase performance and scalability. The tiers represent different aspects of the application: presentation, business logic, and data access. But the fundamental architecture doesn't talk about services, and it has never stressed reusability -- except at the DBMS layer.

SOA and n-tier are somewhat orthogonal -- you can build the various application tiers from services. Folks that built n-tier systems with CORBA or similar service-oriented technology were more likely to use services than most others. But consider the predominant n-tier development environment in use today -- Java EE:

• presentation implemented with JSP/servlets
• business logic implemented with POJOs or EJBs
• data access logic implemented with JPA/Hibernate

I don't see much that looks like SOA in this model.

SOA operates at a significantly different level from n-tier. SOA is focused on reducing the amount of redundancy in the corporate application portfolio. I've said it before: SOA is an enterprise architectural style rather than an application architectural style. SOA doesn't focus on individual application architecture. It focuses on encapsulating discrete functionality into services.

SOA and n-tier architectures have one thing in common -- they focus on separation of concerns. But SOA takes SoC to a new level. I think of it as refactoring application systems. (similar to refactoring code,
but on an enterprise  application architectural level).

As industry experience with SOA matures, I expect we'll start to develop new application architectures that more effectively exploit a development model based on services. SCA is a start, although still
way too immature for prime time. I expect to see some synergy develop among RIA, widgets and gadgets, mashups, composite application development, and services.

I also expect that the concept of "application" is likely to go away. Why is it that we as systems users have to be constrained by the limits of this artificial boundary called an application? Why do I have to shift my focus among multiple applications? Why do I have to copy data from one application to another? Why do I have to launch this stupid browser or that stupid application to get my work done? Why isn't everything just accessible to me from my desktop (via widgets and gadgets) or from within my preferred operating context (e.g., email)? Why can't I just link to whatever I need? (think REST)

Think outside the box!

Chris Haddad talked a little about the need to abandon traditional n-tier concepts and the MVC design patterns in his blog post, MVC Matrix and the Red Pill.We'll be talking a lot more about this next generation application platform this year. Stay tuned.