Let’s face it, services in general, and RESTful services in particular often can incur a performance penalty. Sometimes the benefits of the REST approach outweigh the drawbacks. But it is something to study. That is just one of many reasons why the architects charged with overseeing use of services have to be especially well-trained and experienced. Vendors in the rush to the market sometimes gloss over the details. We got a bit of a look behind the use of REST in an important IBM Rational program that represents a re-architecting of its Jazz Application Life-Cycle (ALM) software suited.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
REST has many uses, particularly with Greenfield projects that share data without high throughput requirements. There are means to speed up REST apps – cloud computing over time may be one such means. But you can’t enter the REST world with blinders on.
Just as the industry may have gone too far in embracing stateful binary communications in the early Web services days, it may go too far in embracing REST in every instance. In the real world, things will vary.
IBM Rational has a significant in-house REST project underway. It’s called Jazz, and it is a collaborative platform for exchanging application lifecycle management (ALM) data and artifacts. IBM did not really set out to do Jazz as a REST app. They re-architected the original Jazz platform, announcing a related Open Services Life-Cycle Collaboration (OSLC) initiative, about a year ago. It’s not an either/or proposition – a variety of means are available to connect via Jazz. Think of OSLC, still in germination, as ASCII for the developer of the future. In order for it to be loosely-coupled and widely supported it may not be able to actually do too much.
REST still seemed like a new thing a year ago when IBM told us they were using it in Jazz. At the time, I asked them – and their competitors – if REST would really work in this context. All said, ‘yes’ – some said ‘yes, probably.’
I pressed a noted XML scientist, asking, “Will this really work fast enough?”
“Sure,” he said, ‘just buy an XML accelerator.” I thought that was kind of droll – and I think the scientist may then have winked.
“Not everyone has the money for those things,” I said.
“Sometimes you have to spend money to make money,” he replied. Then, surely, he winked. Soon, we discovered that both of our spouses could justify large shopping mall expenditures based on this principle of spending a buck to make a buck. This made sense, and neither of us would argue with the boss. But there did seem to be a slight hole in the RESTful balloon.
With Jazz and OSLC, IBM was pursuing a new notion of collaborative ALM, said Danny Sabbah, general manager, IBM Rational, in an interview at the IBM Rational user conference last week.
In time, possibly, IBM may introduce Jazz in an open-source form that may resemble OSLC. For now, the company is merely surfacing aspects of OSLC so people can get a handle on what it is about.
Said Sabbah: “When you are trying to do a open-source normalization, you need to have community buy in. Loose coupling is encouraged.”
As a result, OSLC was surfaced not as a set of Java-based frameworks, but instead as a set of RESTful APIs. “It encourages participation from many angles,” said Sabbah. “All you need is an XML stream that you can query and get and parse and flow.”
There are drawbacks – and there are upsides. “At the core, it’s extremely inefficient,” admitted Sabbah. “On the other hand, it [serves as] the least common denominator for anyone who wants to take part.”
IBM, he said, will build-out OSCL collaboratively based on who wants to communicate. A Change Management profile of OSCL has just reached v.1.0.
“If you used XML and mashups for everything, the performance would not be acceptable. We have a hardened version optimized for running on J2EE, but we also have the set of RESTful APIs. That keeps it open.”
That is the essence of SOA, said Sabbah. “You have services definitions and you have services deliverables. What is behind it can vary.”