Application Platform Strategies Blog

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.

A Contrarian Perspective on WS-* vs REST

Blogger: Anne Thomas Manes

Most blog posts you see regarding WS-* vs REST tend to trash SOAP and espouse the virtues of REST. This post by Ganesh Prasad takes a contrarian perspective, defending the elegance of what Ganesh calls the "SOAP-messaging-using-Smart-Endpoints" style. Ganesh entitles his post, "Paying the RESTafarians Back in Their Own Coin," although he really doesn't trash REST in his post. He simply espouses the virtues of the SOAP-messaging-using-Smart-Endpoints" model.

The post starts off as very educational -- the first part describes the virtues of the Internet and its reliance on a dumb network that only knows how to deliver packets (which it does remarkably well) and smart endpoints.

His argument gets less convincing, though, when he attempts to correlate the Internet's elegant model with that of WS-*. He implies that the WS-* model doesn't require intelligent middleware to be responsible for routing SOAP messages -- it only requires "endpointware". But then he goes on to talk about intermediaries and proxies, which in truth are intelligent mediation processors. I believe his point, though, is that you don't need a big fat ESB in the middle to direct traffic. ESBs should do most of their mediation processing at the endpoint -- think of an ESB as a service platform rather than a mediation system-- it is the endpoint.

All-in-all, I like the post, and I agree with his assertion that ESBs should operate at the endpoint rather than in the middle (at least most of the time). And I agree that there is a great deal of elegance in the SOAP-messaging-using-Smart-Endpoints model. (I don't think it's quite as simply elegant as REST, nonetheless, it is elegant.)

Read his thesis with a grain of salt. His argument has quite a few holes in it, as pointed out in Stu Charlton's comment (the 11th comment by "Stu").

New RESTful Open Source Registry/Repository from WSO2

Blogger: Anne Thomas Manes

Open source SOA infrastructure vendor, WSO2, released a 0.1 version of a new open source RESTful SOA registry and repository. Paul Fremantle, WSO2's VP of Technical Sales, described the impetus and rational of this registry in a recent blog post.

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

The basic idea behind a REST registry and repository is a good one. It's simple, lightweight, easily accessible, and searchable. The major concern I have is that runtime systems typically need a bit more structure to enable information exchange among heterogeneous SOA infrastructure components. At the very least, we need a standard (but extensible) data model that specifies what type of information can be obtained from the registry, what the format of each type is, and the required or optional relationships that exist among registry entities. Without a standard data model, this registry will be just another vendor-specific proprietary registry.

The OASIS UDDI-spec technical committee has been talking about closing its doors, so no additional standardization effort is likely come from that quarter. If anyone is going to develop a RESTful registry/repository standard, it will be a brand new effort, and that's likely to take 5+ years to produce a standard.

The Difference between SOA and ROA

Blogger: Anne Thomas Manes

In the continuing debate over REST vs WS-* and SOA, Mike Champion recently posted the following text to the OASIS xml-dev discussion list, and I thought it deserved a little more airtime:

SOA has no constraints on operators,  but in practice operators are late bound via service definitions and operands are fairly stongly typed by schemas/data contracts. 

 

ROA tightly constrains operators, but has no constraints on operands (i.e. "resource representations" other than MIME types I suppose).

There is beauty in both views of life. What we need in my opinion is a deeper and more empirical understanding of which set of architecural constraints and non-constraints is most associated with the various, somewhat conflicting values of "scalability, evolvability, visibility, simplicity, etc."  Likewise, what are the real bottlenecks that create problems in real world implementations of the abstract designs?  I'm not at all sure there are simple and obvious results here. For example, a lot of WS-* projects founder because of the HTTP-level performance and quality of service issues compared to proprietary message services, and because of XML parsing performance bottlenecks compared to that of the previous generation of more tightly coupled data exchange mechanisms.  A failed "SOA" project isn't necessarily an opportunity for REST, it's often a victory for the old proprietary stuff that shouldn't give comfort to either side in the SOA/ROA debate. Likewise, a REST project that founders due to performance or security concerns is not necessarily an opportunity for a SOA vendor, especially if the designers don't want to install a bunch of stuff (beyond the browser) on each potential client.

      

Roy Fielding on REST

Blogger: Anne Thomas Manes

There's no one better to explain REST than the man that defined it. Roy Fielding gave a presentation recently at JAZOON 07, and the folks from BEJUG were kind enough to post a recording of the session on Parleys.com.

Roy described REST from a fairly technical perspective, and unfortunately he was a bit rushed in his presentation. (He learned at the last minute that the session was much shorter than he expected.)

I particularly like the way he summarizes the REST constraints. Plagiarizing his slide:

Uniform Interface:

• Resources are identified by only one resource identifier mechanism
• Access methods (actions) mean the same for all resources (universal semantics)
• Manipulation of resources occurs through the exchange of representations
• Actions and representations are exchanged in self-describing messages

Hypertext as the engine of state:

• Each response contains a partial representation of server-side state
• Some representations contain directions on how to transition to the next state
• Each steady-state (page) embodies the current application state

I'm not quite so fond of the way he compares REST to SOA. First of all, it really isn't appropriate to compare REST and SOA. SOA is an architectural style that should be used for high-level system design, while REST is an architectural style that should be used for system implementation. (I discussed this last June in the blog entry SOA and REST operate at different levels of architecture.) And second, Roy is equating SOA with web services. Although a lot of folks use web services to implement services, that's simply an implementation decision. Any type of middleware can be used to implement services. (I discussed this topic in September in the blog entry When Technology Matters in SOA.)

Stefan Tilkov also posted an excellent discussion about the different architectural levels of REST and SOA, FAQ Entry: What's this REST vs SOA Debate About?

So when watching Roy's presentation, replace the term "SOA" with "WS-*", and the discussion will make a lot more sense.