The Evolution of Web Services Development in a RIA world

Web Services have become common place in today’s connected world. Companies like Google, Amazon, eBay, Microsoft, Yahoo, and Twitter expose web services to allow other developers to build on top of their infrastructure. In the consumer world these web service APIs have allowed for a variety of fascinating “mash-ups” of data. In the business world web services have allowed for greater intra-company and inter-company (Business to Business or B2B) communication. What used to be done through TCP and FTP and custom file formats can now be done with HTTP and XML. One of the key early advantages to web services was the better support for navigating the network (proxies, firewalls, etc…) and just working which was a common hang up of many of the prior remoting technologies.

In the early days of the Internet a group of individuals backed by Microsoft started work on a standard called SOAP. SOAP is often used as a foundational layer for web services. Especially in the early days people often were inherently referring to using SOAP when they talked about building or consuming web services. Through the years SOAP has continued to evolve. The WS-* family of specifications provide greater support for reliable messaging, transaction control, and security. The increased functionality comes with a cost though and a common criticism of SOAP is the complexity and overhead that come with it. Supporters have tried to counter these criticisms through better tooling and frameworks to abstract away the underlying complexity.

The Web in the meantime has continued to evolve and a new age of technologies has introduced richer, more interactive behavior to browser-based apps. AJAX, Flash/Flex, and Silverlight (Rich Internet Applications or RIAs) have redefined our expectations of what a browser-based app can do. Each provides the ability to update the user interface without requiring the web page refresh that is so common. Web Services are key enablers of this capability just not SOAP-based web services. SOAP libraries for consuming SOAP-based web services are either incomplete or altogether missing in JavaScript, Flash, and Silverlight. As an alternative to the complexity and overhead of SOAP a new style for building web services, called REST, has been advocated. RESTful based services leverage the capabilities of HTTP through the HTTP verbs of GET, POST, PUT, and DELETE. Data is often transmitted using POX (Plain Old XML) or JSON (JavaScript Object Notation) formats. These services are interacted with like the browser works with a web page and as such are natural fits for use by RIAs.

Some architectural problems do arise in the RESTful world. The browser sandbox tends to disallow cross-domain calls (i.e. calling an lds.org web service from mycustomwebsite.com is generally disallowed). Most solutions for this issue require actions on the server-side to resolve it. For cross-domain services the likelihood of a consumer influencing changes on the server-side is often remote. The lack of true SOAP support can also be a hindrance. Lack of SOAP support can removes certain types of services as options for use. In the case of services you are building the need to support AJAX-enabled Web UIs could begin to dictate software architecture decisions throughout your organization (like not using SOAP, what kind of authentication/authorization infrastructure you can use, etc…).

One of the emerging methods for enabling RIAs use of services regardless of their underlying architecture is the Proxy Pattern. The Proxy Pattern goes all the way back to the original Gang of Four (GoF) Patterns book. It is applied by deploying a service on the RIA’s web host that abstracts the remote implementation (whether it is SOAP, REST, etc…) and exposes it to the client. In some cases the proxy service might adapt the data format to one that is more palatable to the consuming client. In this instance we are compositing the Proxy Pattern with the Adapter Pattern. Doing this resolves the cross-domain limitations because we are making the remote service call on the server that doesn’t have this restriction. Additionally it enables the use of rich server-side libraries to simplify the communication with different services (like SOAP-based ones).

Our current standard at the Church for web services is SOAP. With the community development efforts that are underway as well as the ongoing industry shift to richer web apps there is a growing need to support clients without SOAP support. The Proxy pattern is one approach to enabling interoperability with our back-end systems without having the UI technology dictate our back-end architecture.

Advertisements
This entry was posted in Technology and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s