SOA, WOA, Contracts and REST

I am working with several companies now that are doing major overhauls of their IT systems. These companies are retiring old systems and purchasing new ones using SOA to integrate the newly purchased systems. SOA for integration is not new but replaces proprietary EAI/MOM technologies with open standards.

These IT overhauls are large programs with many projects and vendors involved. One of the customers is buying five COTS packages with contracts in place into introduce a lot of new features. The company I work for is doing the application integration plus building a lot of public services for their partners and customers.

We run very large SOA programs (hundreds of services) with complex dependencies between different vendors by using contracts and governance. As a committee we agree on service and schema definitions â€“ the service contracts. Individual vendors cannot change the contract without notifying the other players and approving the changes. This approach is called contract first development. The contracts, schemas and registry/repository entries are the interface definitions used by the entire program.

It is interesting that in practice, real SOA projects, we find that WSDL is in fact an incomplete service contract. WSDL lacks semantic information (e.g. metadata about schemas). Starting with an annotated schema for example will give you more metadata than just the WSDL. And for very complex data domains we often start with a UML model then generate schemas by constraining the model. The domain model has still more metadata and formal definition.

Yet REST and now the WOA crowd continue to argue that SOA, contracts and governance are just unnecessary complexities. The whole web works off REST so why not every-one's IT shop? Just mash everything up without any contracts (stuff like security, transactions and service levels) and let it evolve.

I really wish things were that easy but they are not. Take a look at a good REST example and see if you think the documentation starts to look a bit like a contract. The Amazon Simple Storage Service (S3) REST interfaces are popular and they have a well defined API. Look at the S3 REST Developer Guide and see what you think. Does it look like a contract definition for a set of APIs? Do you think it would work if you didnâ€™t follow their rules? Would you expect them to let you know if they changed the API or would your program just evolve automatically? By the way, I think the Amazonâ€™s SOAP API looks much simpler.

Now think about the SOA programs I described above with every vendor building their own REST interfaces with no contracts - without even a consistent way to define what a contract is. That, without governance, would be anarchy and surely the program would fail.

A Service Oriented Architecture is an architecture that allows you to construct solutions from reusable assets. Our society is at large "Service Oriented", things like currency/banking, standards, transportation infrastructure (with different quality of services), addressing (zip codes,...), property rights... are key elements of the "architecture" of our society. Pretty much everything in our society is governed otherwise the degree of reuse will constantly miss the mark and lead to a lot of inefficiencies.

I don't see how something accessible via "HTTP" guarantees reusability. Do you equate accessibility with reusability? If this is the case, this is quite naive. This would be the equivalent of saying, we only need a "transportation facility" in our society to guarantee reuse. We don't need currency/banking or any other capability. Do you think also that when a bridge or an airport is built, it has not been governed?

Now as a technology, I don't know of any information system (such as ERP, CRM, PLM...) build in 100% RESTful way. Do you really think that the Web as an information system includes the capabilities that are necessary to build data and process centric information systems? If you have some examples, I'd love to have some pointers to them.

As Chief Technologist and National Practice Director for SOA with Perficient, Inc., I get the opportunity to work with a lot of customers implementing SOA and transformational architectures such as cloud computing. See my bio page for my contact information or just post a comment if you want to talk about your architecture projects.

Popular White Paper On This Topic

9 Comments

Don't expect anything will do it. REST sounds a lot like PEST if you ask me. This is what the Burton group had to say today:

"What will drive REST adoption eventually is that it brings structure in the form of "constraints" to the sometimes chaotic world of Web services, which includes those pesky rogue services, according to Burton. This will provide a level of maturity for SOA development."

I actually don't think most people really understand REST - especially the constraints. This is a from another post I did.

Thanks for the comments. I certainly was not arguing that statefull is the way to go for SOA. I just want to point out the constraints for REST. I have used session keys in URIs and cookies to pull back server side application state. This seems like a grey area with respect to REST.

This is from Dr. Fielding's dissertation. "We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server."

I had a rather interesting discussion with Steve Vinoski about REST a couple of months ago on my blog. Link

I detect and agree with an underlying assertion in your post: that the REST/WOA folks have failed to understand the problem that you are trying to solve, and in doing so, have created a distraction from solving it.

The moment someone starts talking about WOA and integration, I start to smile. They have become distracted. If you care about an ecosystem, and a large number of services that interact in complex ways, like I do, then REST is not an improvement.

REST is not a bad thing. I like REST. But it doesn't solve the core problems of integration.

Yes, I agree. We recently build a very nice applicatoin that used data services, ESB and BPM as architecture layers. But in the presentation layer we used JSON, Ajax and REST due to the UI requirements. It worked great - mixing JMS, WS, SOA and REST.

I agree with Eric points in this post (besides, I believe that service orientation has nothing to do with integration because they are working against each other).

I am very interested in the example posted on 8/30/2008, in particular,
- how you incorporated ESB into Service Descriptions and Contracts,
- did you use orchestration or choreography for BPM,
- how you resolve a conflict between usually fine-grained UI (e.g. Ajax) and coarse-grained interfaces of the busienss services,
- did you use WSDL over JMS?

Disclaimer: Blog contents express the viewpoints of their independent authors and
are not reviewed for correctness or accuracy by
Toolbox for IT. Any opinions, comments, solutions or other commentary
expressed by blog authors are not endorsed or recommended by
Toolbox for IT
or any vendor. If you feel a blog entry is inappropriate,
click here to notify
Toolbox for IT.

With the SOA Blog Eric Roch brings over 25 years of IT experience including systems development, architecture, consulting, and ...
more

With the SOA Blog Eric Roch brings over 25 years of IT experience including systems development, architecture, consulting, and executive level management. The SOA Blog author is currently Chief Technologist and the National Practice Director for SOA with the consulting firm Perficient Inc. (NASDAQ: PRFT). In the SOA Blog Eric shares his insight on SOA news, software, architecture, and implementation.
less

Receive the latest blog posts:

Share Your Perspective

Share your professional knowledge and experience with peers. Start a blog on Toolbox for IT today!