Balancing ease of implementation, support and functionality is key to choosing which Web services protocols will work best in your SOA deployment.

Web services are most often used to implement an SOA. Fortunately, and unfortunately, there are many Web service standards to choose from. To follow-up on our last installment, an introduction to SOA, we will now outline the most prevalent Web standards used in SOAs.

Related Articles

Web services are defined protocols for data exchange, via the Web. This does not necessarily mean that services will be exposed to the Internet, just that these are a set of agreed-upon “Web standards” that many products support.

When deciding on which protocols to use, it is often the techies' recommendations that hold the most weight. They will likely recommend the one that is easiest to implement, the most widely supported and the most likely to work well in your environment; in that order. To have a successful SOA deployment that stands the test of time and continues to be extensible, all three factors are extremely important, interoperability being paramount.

WS-I

The Web Services Interoperability Organization is dedicated to establishing best practices for Web standards, ensuring interoperability regardless of operating system, platform, or programming language. The WS-I is responsible for defining best practice literature such as the WS-Security and WS-Transaction specifications. These help developers and businesses ensure they are conforming to practices that everyone else is adopting, which ensures interoperability.

WS-I also publishes specifications, test suites, and examples of how to deploy these protocols. In essence, WS-I is a governing body comprised of many organizations such as Microsoft and IBM, whose mission it is to promote interoperable Web services. Ensure you spend some time reading their literature after this article, which should give you enough background to understand what they are talking about.

Using Protocols

Web services are dependent on protocols to ensure communication is meaningful. The content of the data sent between services must be previously agreed upon before either side can make sense of what it receives. SOAP is an example of the most widely used protocol for exchanging data. SOAP uses XML, allowing either side to decipher what was sent and to format messages sent back and forth.

Clarifications

We will cover a few architectures in a moment, but also refer to some Web service protocols. It is important not to confuse the two, so here is a quick primmer.

Software architectures such as REST and RPC are not protocols; they are methodologies that dictate how protocols are implemented.

WSDL, the Web Services Description Language is a language used to describe a particular Web service in a formatted way, so that programs can parse it. WSDL does not itself provide any functionality in the way of Web service interaction.

The protocols themselves, such as SOAP, XML-RPC, or DCOM, define exactly how messages will be passed and how a program can understand the data its given.

There are two main types of architecture used in an SOA: the RPC family of protocols, and the Representational State Transfer (REST) methods.

RPC

Remote Procedure Call methods allow developers to “call” functions the same way they are used to when programming on a single system, but to a remote system. The drawback to RPC-like services is that people tend to implement them like the programming languages they are familiar with on a given platform. It’s even easier to call a remote procedure if it’s similar to a local one, after all.

This logic violates the concept of “loose coupling,” which essentially means that remote procedures should not be dependent on any particular operating system or programming language.

SOAP is the successor to XML-RPC, which is just a Remote Procedure Call that wraps its messages in XML. SOAP uses HTTP to send data, which is nice and simple, but does have some drawbacks. Regardless, most Web services these days use HTTP for communication, largely because they all build upon SOAP.

REST

The Representational State Transfer (REST) method fundamentally differs from remote procedure calls because of the level at which it operates. A REST call looks just like any other Web request via HTTP, instead of RPC calls which look like standard function calls. The focus of REST is to operate with stateful resources rather than individual messages, which results in a more standard and widely understood method of interacting, like HTTP itself. REST handles passing blocks of simple data, where RPC passes complex procedures.

RESTful services often use SOAP, but this is not required, as a REST is just a method of interacting, not a protocol itself. REST does not require any additional messaging layers, like SOAP, but being able to use SOAP allows for quicker adoption and development times.

To REST, or RPC

The question of whether or not to use REST is certainly a good one. It is likely to be the method of the future, but your SOA needs to interoperate with every piece of software you currently use. REST adoption has been slow, largely because of Web server support. While a REST system can use WSDL to describe a SOAP message over HTTP, there just isn’t enough support to truly use it. Apache, for example, does not even support the methods required to use REST without installing an add-on module.

Other standards that are not part of the Web Services family do exist, but as you may expect they are not widely supported. Jini, WCF, and CORBA are a few examples, and when a vendor approaches you with a product that only works with one of these technologies, run, don’t walk, the other way. Web services are widely supported these days, and adoption is only growing. SOA itself is said to be new, unstable, and risky, but these risks are largely mitigated when you choose an appropriate Web services standard that is widely supported.

In the end, sticking with good old SOAP on top of some type of RPC-like system is the only viable mechanism for building an SOA with Web services these days. If you do, the chances of vendor lock-in are dramatically reduced.

Please enable Javascript in your browser, before you post the comment! Now Javascript is disabled.

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.

Thanks for your registration, follow us on our social networks to keep up-to-date