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.
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.