Is REST Capable of Solving Systems Integration Issues?

| by Boris Lublinsky Follow 1 Followers on Jun 23, 2010. Estimated reading time: 5 minutes |


In his new post Steve Jones writes that instead of being a driving force for the enterprise, many times IT has an opposite effect :

... most of the modern world is driven by computers, computers are what makes economies tick and its integration that matters in a networked world. The immature and techno-centric way in which IT approaches enterprise solutions is ensuring that far from being an accelerator that works ahead of business demand it is IT that is all too often the dragging anchor to growth. This obsession with purist solutions that solve problems that don't exist are just exercises in intellectual masturbation which are actively harming developed economies.

In Jones’ opinion, IT today is in much worse place that it was 5 years ago due to the fact that it is becoming more self fulfilling prophecy by concentrating on new "cool" tools and technologies and keeping to miss the boat on enterprise support.

Jones considers that one of the hardest things in the enterprise architecture is systems integration, which remains to be one of the most complex undertakings. And yet, solving integration problems continues to be more art than science:

... REST hasn't improved this situation in the enterprise in any marked way. It’s been 5+ years since REST started being hyped and in comparison with the benefits that WS-* delivered to the enterprise in 5 years it’s been zip, zero, nada.

Despite the fact that REST is being touted as a cure for all integration challenges:

  • It’s as hard to do a large scale programme with a large integration bent as it was 5 years ago.
  • Vendors have been left to their own devices which has meant less innovation, less challenge and higher costs as the Open Source crowd waste time on pet projects that aren't going to dent enterprise budgets.

The problem that Jones describes is that vendors including SAP, Oracle and IBM are still heavily backing Web Services, while mainstream developers are trying to switch to REST. As a result:

No one is holding them to account. With all of the cool, and smart, kids off playing with REST... and the like we've got an intellectual vacuum in enterprise IT that is being "filled" by the vendors in the only way that vendors know how. Namely by increasing the amount of proprietary extensions and software and pushing their own individual agendas.

Some of the examples of this situation that Jones is giving include:

... Siebel's Web Service stack has a pre-OASIS specification of WS-Security, last updated in 2006 by the looks of it... IBM is still pushing the old MQSI cart horse as an "Advanced ESB".

He continues by stating that in spite of several specifications and some minor improvements, there has been virtually no innovation in Web Services space over the last five years. On another hand, there is not much that has been achieved by REST. He considers problem to be twofold:

  1. Most people in IT appear to know bugger all about it. Now I continue to be surprised at how little people who work in IT read about what is going on, but I was really surprised at how little traction REST had.
  2. EVERYTHING is manual and there is still no standardized way to communicate on WTF you are doing between teams

Granted, REST community is trying to improve the situation, but it does not help much, according to Jones:

Now before RESTafarians jump up and talk about all of the wonderful WEB things they've been doing. That is great and wonderful, but it’s not my world, my world is having 300 systems that vary from 20+ years old to just being built and I need to get them all working together. Even when REST was the right "architectural" solution it was the wrong "programme" solution as it would have driven us off a cliff. My world does have stratospherically large budgets however... you know what, if you want to make real cash wouldn't it be a good idea to address the richest part of the IT market?

Jones concludes by saying that WS, not REST, is the solution for system integration:

... the last 5 years have been poor ones for enterprise IT. WS-* is the only viable system to system integration mechanism for large scale programmes, but it’s stagnating. REST has some cool stuff at the front end and for people who can invest in only the very highest caliber individuals but is delivering bugger all for the average enterprise environment.

Jones post has caused quite a strong reaction. Joel Potisch considers that one should not do REST with a WS mindset:

The only way I see REST hurting enterprise IT is that the people who actually want to develop and deploy working, maintainable, distributed systems have gotten the hell out of enterprise IT and its blind adherence to WS-* for the vendor support... Doing REST with a WS-* mindset will absolutely set you back five years. The RESTafarian mindset is not blind obedience to the new cool shiny thing, but rather the recognition that REST, done properly, eliminates 90% of the commonalities in distributed systems, and causes whole classes of problems to simply disappear.

Christopher Atkins believes that although REST is a great approach for systems,integration, in most cases its usage requires carefull planning:

... it seems to me that the major challenge with employing the REST architectural style in enterprise IT systems integration is that none of the systems that need integrated were constructed with REST in mind... At the very least you'd need... to provide REST semantics, i.e. unambiguous methods that define the internal state machine via hypertext... Disambiguating the integration interface by defining it both in terms of simple contracts and hypermedia that exposes the internal state machine is absolutely the deus ex machina of the web. I just don't believe that REST can be effectively applied to integration scenarios in most IT shops; either the TPS systems don't have an FSM to expose (i.e. straight OLTP/RDBMS apps) or the IT "talent" is incapable of realizing the benefits of REST.

Dan Creswell considers the main problem is not with the technology or standards used but people:

90%+ of people in IT aren't brilliant, a large proportion aren't even good... That's the problem right there. Doesn't matter what they use be it… REST, WS-*, Databases, Java, etc, they will produce rubbish.

It is hard to disagree with Jones, that in spite of all the hype and buzz, the IT industry is currently stagnating and integration problems today are no less complex or cannot be solved faster than five-six years ago. Time will show whether we will turn back to using WS-*, or REST will finally catch up with the enterprise computing.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Convoluted rant by James Watson

This is little more than a rant full of rhetoric, self-contradictions and misconceptions. He writes: "Now I continue to be surprised at how little people who work in IT read about what is going on, but I was really surprised at how little traction REST had." But he also blames REST for the lack of progress in the last 5 years. I've seen mostly resistance to REST in the enterprise space. If no one is using REST how is it the problem? More over, how can it be blamed for the horrible mess that's been built with WS*?

I actually agree that the focus on shiny new toys is a big problem. WS* is the shiniest toy. I just happens to not be new any more. The shine is coming off of it and reality is setting in. The big problem I see in the integration space (my specialty) is magical thinking. Most of the decision makers in the enterprise think that as long as you are using WSDL and SOAP, all your systems will know how to talk to each other without any human intervention.

I also completely disagree with the idea that 90% of the people in IT are not good. I think there are a lot of people that aren't good but the real issue is that people who are smart are seen as 'dangerous' in IT. IT leadership makes decisions based solely on sales pitches and brochures and any questioning of the vendor's claims is extremely unwelcome. You basically have a situation where all the 'good' people are seen as uncooperative because they won't support with what my coworker recently called "childish dreams." Time after time, I hear vendors say things like "our tool can integrate with X." When questioned, they usually say something to the effect of "if you write the code required to make it do so." Fast forward to 6 months later and management is asking why we are still writing code because one of the main reasons they purchased the product was because it integrated with X "out of the box."

Good discussion by Kevin Smith

Interesting, Boris.

If I could give my 2 cents, most of the problems that I see are:

- Many people using WS are applying the WS-* standards in the wrong way
- People using REST are not using standards and doing whatever the heck they want.

Identity propagation is a great example, where the identity of the end user is conveyed between a message sender and a recipient.

There are good standards - the WS-Security * Token Profile messaging standards that have been vetted by OASIS for years. But I have seen implementers build solutions incorrectly because they either don't understand the various options of the standards, or they use a vendor that only supports certain aspects of the standards.

At the same time, there are so many identity propagation solutions I've seen in RESTful approaches that are non-standard or proprietary. is a god-awful way to do it, but I see it done. Some people base64-encode and compress a SAML assertion to 900 characters and place it on a URL That is great, but it is not a standard approach. I see some good stuff coming out of the OpenID and OAuth communities, though.

So my hope is that the same efforts will be put into RESTful approaches that were done in the WS-* community. Without some standard ways to do things, interoperability will go out the window + systems integration is more difficult.

Re: Convoluted rant by Jean-Jacques Dubray


very courageous to say what you say, I can only second it (though I agree with Steve). I think you should also mention that any plumber, carpenter or gardener has more tool to do his/her job than any IT staff. At best your manager is going to give you visio on a 1024x768 pentium III laptop with 100 Gb of disk.

Re: Good discussion by Jean-Jacques Dubray


it is refreshing to see pragmatic people commenting on REST/WS-*. I would also add that one of the key problem is that we always encode the semantics of OO-based, monolithic programming models which are incompatible with any kind of distributed model. The day we will understand that OO is at the core of all problems, we will stop misusing distributed technologies.

Re: Good discussion by Kevin Smith


Thanks for your comment.. I'm not sure if I completely understand, though.. Can you give an example of "encoding the semantics of OO-based, monolithic programming models which are incompatible with any kind of distributed model?" Thanks!

Re: Good discussion by Jean-Jacques Dubray

If you look at JAX-RS or JAX-WS, don't you think that the only goal ultimately is to alway reify a protocol to invoking a method on a class? It doesn't matter what the inherent capabilities of the protocol could be (bi-directional interfaces, asynchrony, extensible message types...), in the end, we always hit the same method on the same class. I contend that there lies the problem. OO runtimes are inherently monolithic and synchronous in nature. I am not sure it makes much sense to hook a bunch of them together as part of a larger solution.

Re: Good discussion by Duraid Duraid

And the alternative of OO is?

Re: Convoluted rant by James Watson

very courageous to say what you say, I can only second it (though I agree with Steve). I think you should also mention that any plumber, carpenter or gardener has more tool to do his/her job than any IT staff. At best your manager is going to give you visio on a 1024x768 pentium III laptop with 100 Gb of disk.

Thanks for the compliment. My situation is different because the business I work for is flush with cash. The problem I have is that our management thinks that all problems are solved by tools. Before we can even familiarize ourselves with the last tool, a new one is foisted upon us. Most of our projects are built in a unique way. In other words they are all crap because they are all the first attempt at using a tool.

What the people I work with want to do is solve problems, especially those that cause annoyance. But no problem can be solved until a comprehensive search has been made for an 'off-the-shelf' solution which invariably results the purchase of a tool that doesn't solve much of anything (2 years later.) If not that, there's surely a consulting firm that's "done it before" (they haven't, at least not well.) So instead of letting one fairly inexpensive resource work on the issue for a week or two, we'll blow though months and hundreds of thousands of dollars and still not have the problem resolved.

I've also worked in software building non-trivial apps from the ground up. The challenges that internal IT developers face are no less difficult that what most software vendors deal with and the complexity is often much greater. It would be nice if software vendors could control their arrogance and listen for once.

Re: Good discussion by Satadru Roy

I think it's unfortunate the JAX-WS Provider and Dispatch model of programming have not been emphasized as much as they could have been. Working at the raw XML message level should be the first choice imho and not this 'map everything to an object and a method call' model that lot of developers assume is the only choice.

Re: Good discussion by Kevin Smith

Good point. I think it all comes down to how the services are developed. Tool vendors make it easy - "turn your POJO or your class into a web service". The resulting services therefore are really "distributed objects".

Re: Good discussion by Joseph Taylor

And apart from how good the services are developed, there is also the practical side:

1. What tools are available to auto-generate RESTful clients? WADL and WSDL2 are far from perfect.
2. What about the other important containers services like security and transactions? You could use HTTP authentication and compensations for transactional cases, but in my experience it takes a long time to get it to work properly between enterprise boundaries.
3. What about the resource formats? In my first few RESTful projects, our chief forced us to use ATOM, RSS and XML. Little did we know that the size of the payloads were as big and bloated as SOAP messages. Software engineers like converting everything to strong-types (JAXB, DTOs, .....) still stuck to WS mindset.

In my opinion, keep you data structures simple, do not think resources as methods to a class and provide decent examples to any consumers of your services. BTW, there's plenty of good stuff out there about how to do REST properly, especially Stefan Tilkov's presentations.

Re: Good discussion by Jean-Jacques Dubray

The alternative is Metamodel Oriented Programming (MOP) You can also take a look at WSPER.

Just to quote Bill Burke ( "In Java land, with the current tools available, it would be very hard to implement a common URL scheme that served up different versions of the same application using conneg. The problem being that you’ll probably have different versions of the same Java class that process this data."

Why would one think that the semantics of OO, invented 35+ years ago would make sense to build composite applications? OO has become a low level implementation language unsuitable to build modern solutions. Hacking protocols to call a method is not going to help in any way.

Re: Good discussion by Jean-Jacques Dubray

I'll second that !

Re: Good discussion by Jean-Jacques Dubray

Yeap, there is room for that but it does not mean that turning a POJO into a web service / resource is SOA, REST, Composite Apps, you name it.

Re: Good discussion by Duraid Duraid

Meta what? no seriously. Is any body doing this MOP stuff?

People are still try to achieve OO there is already a new thing?

Re: Good discussion by Jean-Jacques Dubray

What about the resource formats? In my first few RESTful projects, our chief forced us to use ATOM, RSS and XML. Little did we know that the size of the payloads were as big and bloated as SOAP messages. <blokquote></blokquote>

I am glad this kind of feedback is finally surfacing. REST is just a different encoding of the same programming model, nothing more, nothing less. It has pros and cons, just like WSDL/SOAP has pros and cons too.

Re: Good discussion by Kevin Smith

Very cool, Jean-Jacques. I'm going to look into MOP & WSPER.

Boris - see? All you have to do is to post WS vs. REST articles and you'll have an amazing response.

Re: Convoluted rant by Juan Manrique

Althougt I agree with much of the conclusions of Jones, I doubt arises whether he considered the technical proposals that Adobe has been offering since 4 years or so in what integration and data services are concerned. Some of its data protocols (Eg. AMF) have proved to be much more efficient than traditional XML-based Web Services in some cases. I'd really like to read opinions from both Jones and readers about if these platforms Adobe offers (more than 3) should be or not included within the categories mentioned in these interesting posts and analysis of this kind because I think Adobe is one of few software enterprises has offered new proposals in data services and integration. Thanks in advance.

Re: Good discussion by Jean-Jacques Dubray

OO is the problem not the solution. The reason why people are still "learning" how to do OO right, is simply because OO is unsuited to information system construction. It is an interesting formalism, but in the end it is just a formalism like so many other.

Metaprogramming or Metamodel Oriented Programming is about creating a model of your solution that is independent of specific formalisms cooked up by XYZ to solve a specific problem, generally unrelated with yours. REST is no different. It is a great formalism, it gave us the Web, but Resource Orientation alone, it not yet a formalism on which you can rely on to build enterprise solutions. You can keep banging your head on the OO or RO world, in the end solution models require a polyadic programming model, that is the solution.

Today, MOP is possible because of technologie like XText (Eclipse). In the end we are already MOPing. Look at all the annotations added to OO runtimes? Isn't about adding semantics that simply OO does not have? How long are we going to build on a limited foundation. OO is the problem, not the solution.

Re: Good discussion by Duraid Duraid

Sounds like WoW. So this MOP thing is going to solve everything?

Sorry I don't mean to sound sarcastic but how do i do that? where do I start? I visited the links provided and the stuff there is still in research/prototype phase. Is there something concrete?

Re: Good discussion by Jean-Jacques Dubray

Internal DSLs in Ruby have been MOPing for a couple of years now. What I don't like about them is that they are tied in to a particular technology. I prefer MOPing in a technology and architecture independent way.

Microsoft's Volta project was MOPing too.

I can certainly share what I am doing on the iPhone/iPad (just don't tell Steve Jobs, please).

MOP is not a solution, MOP is the right way to build solutions.

Re: Good discussion by Duraid Duraid

From what I read it seems that MOP does not eliminate OO but is a higher level language (meta language) that generates an OO model (or other model). I.e. this language will end up generating method calls etc and we're back to square one.

Also, it's important to realize that both WS-* and REST are RPC even if REST doesn't admit it. In all the RESTful frameworks an HTTP request getting translated into a procedure call that runs on a remote machine.

So in the end we still have to do OO directly or indirectly.

Re: Good discussion by Jean-Jacques Dubray

OO? you mean assembly language, right?

You can't change the semantics of runtimes, you can only encode your semantic into the semantics of an executable. The path to get there is yours to choose. You can use zeros and ones (yes my dad keyed in code bit by bits), you can write in assembly language, you can use pascal, prolog or OO. It doesn't matter.

The question is how do you express your semantics? Are they virtual (in your head) as you write "code" (01s, assembly, pascal, prolog, OO...) or are they explicit? Is it worth creating polyadic cogent programming language? is it worth bridging the rubicon that exist between DSLs and GPL? or do we have to be at war for ever?

you choose...

Re: Good discussion by Floyd Marinescu

Duraid Duraid, I'd like to kindly ask if you can edit your preferences and add your real name? We have a real name policy on InfoQ so that we can encourage and maintain a level of courtesy and seriousness in our discussions.


Floyd Marinescu

Re: Good discussion by Duraid Duraid

But this is my real name.

Re: Good discussion by Floyd Marinescu

But this is my real name.
Oh, ok, sorry for the mixup! :)

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

26 Discuss