SOAP/WS-* vs. REST and The Art of Politecture

Those of you who've worked on very large scale enterprise-wide architectures know that it's always the people and politics that are the biggest hurdles. I came across the term "politecture" in Nick Malik's blog here. You can follow the link for the definition, but it's essentially an architecture that's been designed with the influence of political factors. Some may say this isn't right, but I think it's perfectly fine, even necessary when you're designing a large scale architecture that has to be adopted by many people and organizations.

So what's this have to do with the SOAP/WS-* vs. REST debate? I tend to agree that there are very many scenarios in large scale distributed systems in which a simpler RESTful approach is a technically superior solution. However, IBM, Microsoft, OASIS et al. have done such a good job touting the power of standards in the WS-* world that most folks within large enterprises are sold on the WS-*-based architecture. Whether or not those standards actually help you is a topic for another discussion, but the point is that within most large enterprises you're going to have a much better chance of getting people to adopt your WS-* "standards-based" architecture than you will with a "maverick" REST-based architecture. Is this a problem? Maybe, but from what I've seen usually not. So what if you end up with a technically more complex solution? I can solve the technical problems that result from the added complexity of WS-*. Like I said at the beginning of this post, it's the people and political issues that are the biggest hurdles. From my experience, it's usually the people and politics that cause projects to fail or be canceled. If I can't get people to adopt my architecture because I'm going with a "non-standards-based RESTful architecture", I'm not even going to have a project to worry about it failing because WS-* is more complex, less interoperable, etc.

As an architect, you're not implementing, but you need to get everybody to agree to what you've defined so that they will implement it. If this means making some compromises that perhaps result in a less technically superior solution, but will allow you to achieve consensus then go ahead and do it. As I've painfully realized in my transition from developer to architect over the past few years, things are not so black and white with architecture, i.e. you can't always just go with the solution that makes the most technical sense. If you fail to see this or cannot adapt to this, then you will not be a successful architect.

Scenarios for RESTful Web Services

The RESTful approach is very attractive for large scale integration scenarios that cross many organizational boundaries. This is because the constraints imposed by the REST principles emphasize interoperability and scalability. The constraint of uniform interfaces supports those scenarios in which the consumer base for the services is so broad that it makes it difficult to create and maintain a large set of custom interfaces. In such cases, it makes more sense to apply a design in which a single interface can support all the required interactions. Unfortunately, modeling everything as a set of resources that are all exposed through a uniform interface is not always easy. Developers are accustomed to designing a specific interface for each piece of functionality or data that they wish to expose; forcing them to always use a uniform interface is antithetical to this. However, scenarios in which services are just providing access to data can easily support the uniform interface constraint. This is because any kind of data can be manipulated through the same set of create, read, update, and delete operations. Thus, scenarios in which it is primarily data that needs to be shared through web services make REST an easy choice.

soa, web services, REST, SOAP

Scenarios for SOAP WS-* Web Services

The SOAP WS-* approach provides a broad set of standards and specifications for quality of service features and also gives developers a lot of flexibility to define custom interfaces for the services that they wish to expose. This flexibility is useful for application-to-application integration scenarios internal to an organization. This is also useful in scenarios in which legacy applications need to be exposed to the rest of the enterprise. In either of these scenarios, the existing applications often constrain how the services may be exposed, so the flexibility to design service interfaces that can adapt to these constraints is important. Additionally, in these scenarios the services are often providing complex functionality and processes that may be difficult to model in a resource-oriented manner with uniform interfaces. It is also these types of scenarios that typically require many of the complex quality of service features that the SOAP WS-* approach has broad support for. Finally, these types of scenarios are more commonly found inside a single organization and less so across organizational boundaries. The SOAP WS-* approach typically results in large number of custom interfaces, but when this is occurring within a single organization, they are a lot easier to control and maintain than in scenarios where there are many organizations that are dependent on those interfaces.

soa, web services, REST, SOAP