The REST of the SOA story

Representational State Transfer (REST) has been gaining steam over the past two years. While it's nothing new under the sun -- in fact it's now seven years old -- the simple, HTTP-based programming style has potential that is just being tapped.

It's also helping to better define service-oriented architecture. Far too many think of SOA as being synonymous with the SOAP messaging protocol. While SOAP, along with WSDL and UDDI, was the standard in vogue five years ago when SOA began to enter the mass consciousness, it is not the basis for SOA. SOAP is one way to build a Web service, it is not the only way to do it.

REST is a perfectly viable alternative. Last week Burton Group made the argument that REST will become the dominant method for building Web services by the end of the decade. In an interview with SearchWebServices.com, IBM WebSphere CTO Jerry Cuomo revealed that he sees big potential in REST as well.

It could be just the wake up call that those stuck in the SOA-SOAP paradigm need. SOA isn't a programming initiativ

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Guest Commentary Getting a grip on JavaFX 1.2 for Rich Internet Applications (RIA) On the road to SOA – Part 1, Boubez on early insights On the road to SOA – Part 2, Governance is fundamental SpringSource approach to adding enterprise class management and deployment features to Tomcat SOA Pattern of the Week (#6): Canonical Schema Legacy: Can't Live With It, Can't Live Without It Review of protocols for cloud services - Part 1 SOA and TOGAF: A Good Fit? Using atomicity to gain SOA granularity Too Many Servers: A Case for Enterprise Architecture and TOGAF 9 Representational State Transfer (REST) How do I balance throughput requirements and interoperability? IBM Sabbah's say on REST for collaborative ALM Report on REST- REpresentational State Transfer Are tools available to work with OSGi today? Expert Query: What is the difference between RESTful transactions and Web Services transactions? Progress/Actional SOA diagnostic tool builds on Mindreef purchase SOA goes beyond 'rip, replace, repeat' Inside the SOA big tent; Azure at PDC; more On lightweight Java frameworks and service-oriented architecture Learn about Ruby on Rails programming

RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary REST  (SearchSOA.com)

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

e and it never was. It's an architectural approach. Done right, SOA should enable you to make right-fit programming decisions, to pursue good new ideas in the programming arena without having to fear that it's going to be wholly incompatible with what you've previously built.

SOA should deliver agility. It should future-proof your applications. There's always going to be hot new acronym that may, or may not, matter to you. You need to assess those things for yourself. For instance, last week we ran a Q&A with ZapThink's Jason Bloomberg in which he raised serious questions about SCA and JBI.

While SOA is an acronym, that doesn't mean it's got a one-to-one equivalence with all other acronyms. Understanding the difference between architecture and programming is critical. Your programming preferences will change, but at no point does that absolve you from having to pay attention to your architecture. More than anything that's what the increased focus on REST makes clear, that a good architecture better enables you to incorporate change.