SOA for the Web

Authors: Kyle Brown, Gennaro Cuomo, Jason McGee

Extending the Reach of SOA with Web-Oriented Architecture

We're in an interesting time right now in development for the Web. For the first time in several years we have a new set of technologies that are letting us look at Web development in a new and different way. Rather than viewing the web as a net of entire pages, where web-based applications generate a unique page at a time, we can now take a fundamentally different view of the web. We can now view the web as a set of services that can be asynchronously invoked, merged together with other services, and rewoven into new, dynamic combinations. This approach as a whole has been coined Web 2.0, and it's a significantly different approach to the web.

The primary instigator of this new way of looking at the web is a set of technologies commonly referred to as AJAX (Asynchronous JavaScript and XML). It's a way of building web pages that, rather than mixing content and presentation together, separates the two into a basic page that contains the presentation (lists, trees, etc.) and a set of XML documents that are asynchronously fetched (using JavaScript) and used to populate the presentation based upon the actions of the user of the page.

This set of technologies has led us to have to take a step back and think about what this means for enterprise computing. Where we used to have to consider that enterprise services either ended at the corporate firewall, or at most were exposed under strict security to a limited set of corporate partners, we can now envision a time where some services extend all the way out to the browser. This is leading to a consideration of a new type of architecture, the Web-Oriented architecture, or WOA.

WOA is an emerging term that was coined by Nick Gall (and since echoed and refined by a number of others like Dion Hinchcliffe) that refers to a small set of services protocols that are optimized for browser and other end-client interactions. The way to look at this is to take the basic idea of services extended all the way out to the browser, and then consider the impact this has on the notion of an SOA.

WOA refers to delivering simple XML web services delivered over HTTP using the REST (Representational State Transfer) approach. REST is the foundation of a WOA. The next layer down is how you represent the information flowing from the service using technologies like ATOM feeds and JSON (JavaScript Object Notation). Finally, AJAX (that started the whole thing) is the way to render the information in the service to the user. However, the core idea remains that we're only considering a small set of protocols aimed at bringing information out directly to the client.

Why would we want a WOA?

There are many benefits to a WOA – it allows you to build more interactive web pages, and allows you to allow your own customers to create new web pages (or mashups) from your published services and those of others. It also opens up the notion of user-created content and allows you to contact your customers in new ways, such as blogs and wikis. But the way to view this as a whole is that it allows you to extend the reach of your Enterprise SOA to a much wider audience. With a WOA, you can reach the masses that have so far been untouched by the SOA revolution.

REST and the foundation of the WOA

A stated above, REST is the first key component in an implementation of a Web Oriented Architecture. REST is a style of architecture that is best exemplified within the HTTP protocol. REST enables the creation of web services that are simple to implement, built for re-use, and are ultra-scaleable.

Simple to Implement

Creating a RESTful web service is like forming a Sentence; you need a Noun, a Verb and an Adjective. In REST terms, Nouns are the Resources pointed to by URLs. The Verbs are the HTTP Actions on resources. The Adjectives (okay, this might be a little stretch), are the formats of data that the Resources are represented in. We like to lay this out in tables similar to the way we broke down sentences in grade school. For example, here is how we would describe a set of services related to a Photo Album application:

Some explanation

• Nouns/URIs - URLs are the most identifiable part of the web, and as such really straight forward way of organizing your services. Organizing a unique URI for each resource avoids confusion and promotes scalability.

• Verbs/Actions - You can perform exactly 4 HTTP operations on these URLs. POST, GET, PUT and DELETE. (HTTP supports a few more actions, but these are the interesting ones for now). While constraining, the simplicity is somewhat liberating. These operations roughly map to Create, Read, Update and Delete (CRUD). Heck, CRUD provides the foundational functions needed to implement a relational database, so I think while simple; these 4 methods can be used in interesting and powerful ways.

• Adjectives/Data Formats - There are well known data types (MIME types. Eg., text/html, image/jpeg)) that are natively supported by HTTP servers and browsers. Simple XML and JSON allow more custom data formats, that are both self describing and can easily be parsed by the user (When I say parse I also mean read with your eyes and parse with your brain.)

Built for Reuse

With the Sentence metaphor as a basic building block, we can build on the RESTful service model and add new metaphors like Feeds. The ATOM feed technology allows a user to create, update and subscribe to a Resources. Restful Feeds open up an interesting realm of possibilities. New Feeds can be composed from existing feeds and tailored, merged, sorted, filtered to provide a custom "skin" for your web services.

Ultra-Scaleable

The scalability of the HTTP and the web is well documented. The Sentence approach to web services allows standard HTTP server features to be used to optimize, secure and scale your services. For example, commodity HTTP caching proxies, firewalls and routers can be effectively used with your application without requiring special knowledge of your application or implementation platform.

Why WOA is SOA

So, given the great benefits that can be derived from Web 2.0, the next question that comes to mind is, how does this fit into my enterprise? Cool technologies come and go, but if they don't fit in with existing systems then they're never going to make it out of the lab. This is where another recent architectural trend can help the new WOA find a home and turn it from a neat idea to a way to gain value in your business. We're referring of course, to Services Oriented Architecture (SOA). SOA has emerged as the architecture of choice for building modern enterprise applications. The loosely coupled nature of SOA-based applications allow for business flexibility and reuse. Enterprise SOA provides a stringent set of capabilities and standards, that allow mission critical applications to be written using a SOA. Examples of technologies associated with enterprise SOA include WS_*, J2EE, and .NET. IBM's SOA home page defines SOA as:

"... a business-centric IT architectural approach that supports integrating your business as linked, repeatable business tasks, or services. SOA helps users build composite applications, which are applications that draw upon functionality from multiple sources within and beyond the enterprise to support horizontal business processes"

This is where the match comes in. SOA is all about providing easy access to the reusable business tasks in your enterprise (the services). It's also about combining together all the different sources of information you have inside and outside your enterprise to create new services. Web 2.0, on the other hand, is about making these things available to your customers and end-users. If you are thinking about building a mashup, then what better situation could you be in but having ready-made services providing the key business information in your enterprise available at your fingertips? Likewise, if you want your customers to provide your content, then you want to do that in a way that's consistent with your business needs - wouldn't it be better if you controlled access to services like "find the store nearest me" rather than having an over-exuberant customer scrape it off your website and get out-of-date information?

From this perspective, WOA is just a simplified instantiation of SOA that uses "the Web" as the SOA platform. You can look at a WOA and compare it to your enterprise SOA by thinking about the different foci of the two approaches. A primary focus of a SOA is in its flexibility and its ability to support a diverse and rich set of endpoints. The rich set of Ws-* standards that have been developed to deal with complex enterprise-level issues like security, transactions, and reliability are meant to promote interoperability between applications that could be written on widely diverse platforms. By comparison, a hallmark of a WOA is its simplicity and optimization for a very small set of clients and protocols.

Collectively, the WOA technologies can be used to create a radically simplified service platform; using REST and ATOM to form the basis of the service invocation model; JSON and XML as the data interchange format; and AJAX is the model for a rich client. This platform can also be used to create an architectural "bridge" between WOA and enterprise SOA, allowing services from the enterprise to be simplified and reach the masses via the web. We would refer to this as “extending your SOA to the Web”.

Patterns for extending your SOA to the Web

So how do we connect our enterprise SOA to the new applications built using web technologies? How do we protect and grow our existing enterprise investment while still taking the greatest advantage of the new Web 2.0 technologies. There are a few patterns that you can take advantage of that allow you to combine the two:

• Web Adapter: The simplest approach is to build adapters that can translate from SOAP to REST, and from XML to JSON. In this way, you can expose your internal enterprise services to the web, while filtering the results down to those aspects that are most applicable to the web.

• Services Catalogs: A key to making web-oriented services consumable is to make them available. Catalogs and repositories are critical for discovering services.

• Data Adapter: One of the most straightforward uses cases for web 2.0 is that of quickly building services that expose enterprise data in specific ways. Constructing REST services from SQL queries is an important pattern the achieve this goal.

Extending your SOA with Project Zero

So how does Project Zero fit into this story? Project Zero is a full-stack platform optimized around the concepts and technologies in WOA.  It is also a platform optimized around the goals of Web 2.0, to provide a simple environment for exposing and accessing services on the web.  Project Zero provides a programming model and runtime that is centered on building REST based services easily. It provides a scripting environment for easy development and it provides a set of conventions that exposes the concepts of REST directly to the application writer. Zero provides support for the key technologies around REST, including support for the creation and consumption of feeds (in either ATOM or RSS format), the processing of data in XML and JSON format, and the construction of rich web interfaces with AJAX technology (based on the Dojo Toolkit ).  Everything about Zero is designed specifically with the construction of WOA applications in mind.

Once you have such an optimized environment, you can easily create applications for the web. Project Zero is a great platform for building new applications following this model. Those new applications can have a rich user interface and can exposes content and capability over the Web as new REST services.  Those applications can be remixed, as mashups, with other applications on the web to provide new features and new value. Of course, many interesting applications will need to access existing services that have been exposed using a more traditional SOA model. That is when the real value becomes apparent. Zero becomes an on-ramp to your existing SOA infrastructure, allowing you to expose existing services using the technologies of the Web more easily and more quickly. A Zero application can make use of those SOA services for its own purposes, or it can simply serve as an adapter to expose those services to the web so that others can more easily leverage the value present in your SOA.

Summary

So now that you have the option of having both a WOA and a SOA you can understand why both would be necessary. New technologies like AJAX and ATOM certainly don't obviate the need for an SOA – they simply help expand its reach directly to the client desktop in a way that wasn't practical before.