Recently, while discussing standards with a group of colleagues, I received the following email:
"Having a simple web service interface for problems, medications, allergies, etc. is a great goal. We have seen the value of this as this is what Google Health has done using the CCR and ATOM standards. Since it is a RESTful service and not SOAP, there is no WSDL. Creating a web service interface does not solve the underlying problem though. One still needs to clearly and simply define the XML structure of a problem, medication, and allergy. WSDLs point to XML Schemas to define the inputs and outputs of the services."
I realized that the array of acronyms in this paragraph merited a blog on it's own. The gist of the discussion is how to use the web and HTTP to send structured data from application to application. SOAP and REST are two approaches to web services. Here's a brief overview of the pros and cons of these two cool technologies:
The Simple Object Access Protocol (SOAP) was developed at Microsoft in 1998 as a platform neutral alternative to middleware techologies like CORBA and DCOM. It was first introduced in 1999, modified in May 2000 when it was submitted to the W3C and the current version was finalized in 2005. Since then, SOAP has become the most popular approach for exchanging XML message.
The basic structure of SOAP is similar to HTML itself - a header and body. Here's a fictitious example of a SOAP exchange for requesting a patient's hematocrit from a lab system:
Typically, there are tools available to help generate valid SOAP messages, because the syntax can be a bit complex.
Representative State Transfer (REST) was first described in Roy Fielding's Thesis in 2000. REST is an architectural style that can be summed up as four verbs (GET, POST, PUT, and DELETE from HTTP 1.1) which act upon the resources available on the network (Uniform Resource Identifiers - URIs). REST is easier to implement than SOAP for programmers familiar with the basic techniques of the web itself. Here's a fictitious example of a REST exchange for requesting a patient's hematocrit from a lab system:
REST is similar to the way you request a web page from a browser, but instead of unstructured data, the response is computer readable discrete data. REST does lack some of the advanced features of SOAP such as security, policy, and reliable messaging.
Here's a great comparison from an article comparing SOAP and REST.
SOAP
Pros:
* Langauge, platform, and transport agnostic
* Designed to handle distributed computing environments
* Is the prevailing standard for web services, and hence has better support from other standards (WSDL, WS-*) and tooling from vendors
* Built-in error handling (faults)
* Extensibility
Cons:
* Conceptually more difficult, more "heavy-weight" than REST
* More verbose
* Harder to develop, requires tools
REST
Pros:
* Language and platform agnostic
* Simpler to develop than SOAP
* Small learning curve, less reliance on tools
* Concise, no need for additional messaging layer
* Closer in design and philosophy to the Web
Cons:
* Assumes a point-to-point communication model--not usable for distributed computing environment where message may go through one or more intermediaries
* Lack of standards support for security, policy, reliable messaging, etc., so services that have more sophisticated requirements are harder to develop ("roll your own")
* Tied to the HTTP transport model
Like everything in the standards world, requirements and use cases suggest the best approach to implement.
Now let's decode the email that was sent to me. The author suggests using a simple representation of medical data sent over a simple REST approach as means to easily transmit problem lists, medications, and allergies. Certainly there are some use cases, such as what Google Health is doing, where that works well.
As I've said in my 2009 Goals, I hope to work with all interested stakeholders this year to ensure the US has a clear path for transmission of clinical summaries between applications that meets complex and simple use cases. My hope is that the next generation of the Continuity of Care Document and the Continuity of Care Record will be developed jointly so that all the requirements are defined and met in a harmonious process.
Friday, January 9, 2009
Subscribe to:
Post Comments (Atom)
9 comments:
Excellent Read !
I think your comparison is framed a little bit from the SOAP point of view. In the REST world, being "tied" to HTTP is not a negative, it's a significant benefit. HTTP provides built-in mechanisms for caching, compression, extensibility, resource relocation, error messages, and more. Extensive HTTP libraries are built into just about every language out there. Why build a complete SOAP stack, which 90+% of the time will be run on top of HTTP, without utilizing the power of HTTP and instead reinventing it in higher layers?
What's the point of a Web-based system for data that doesn't speak HTTP today? The flexibility of "any transport" is likely unnecessary complexity.
(It's worth noting too that there are important "mostly REST but not quite" approaches that continue to utilize the power of HTTP without sticking to just the 4 verbs.)
SOAP 1.2 has a feature known as the "Web Method Specification Feature". This exposes the HTTP method through the binding which allows, among other things, for SOAP users to use GET to retrieve SOAP envelopes that encapsulate the state of the resource identified by the URI. This is radically different than with the common use of SOAP 1.1
Does this mean SOAP 1.2 applications will suddenly become more RESTful? No, probably not. Most SOAP users will probably continue to use SOAP...
John - I'm interested in your comments on MD FIRE/MD PnP interoperability standards for medical devices. I was intrigued by the Dec 29th Boston Globe article "Medical devices lag in iPod age" (http://www.boston.com/news/science/articles/2008/12/29/medical_devices_lag_in_ipod_age/). After a little searching, found a paper by Dr. Julian Goldman, et. al. that describes an initiative to conform to purchasing standards for medical devices that comply with MD PnP.(http://mdpnp.org/uploads/ASA_2008_Exhibit_Handout_Contract_Reqmnts_MD_PnP_.pdf) Is BIDMC participating? If so, do you have any success stories to share with your blog readers?
What I'm seeing with respect to REST versus SOAP (and don't forget it's companion WSDL) is the increasing rule of "good enough" (something you've discussed in other threads) which is questioning the need for the sheer complexity of SOAP. Of course there were good reasons and intentions for the complexity in SOAP, but I believe we'll see it go the way of CORBA which, like SOAP, disappeared under the weight of the "kitchen sink" that became attached to it! REST by comparison is quick, dirty, fast and loose and....well, just plain "good enough" and works.
Want to earn some money online? Free paid surveys are an ideal way to get started. You can find several websites which provide such an opportunity. All you require doing is registering with these sites with and providing them with authentic information, regarding education, career.
http://www.freemillionairemakerdvd.com/go
I thought this an interesting comparison from your perspective. Do you have any thoughts on web services in general vs. older mechanisms like EDI files exchanged via ftp for claims processing and such?
The SOAP vs. REST discussion keeps on going. I recently posted my own opinions on this topic, noting that there is a place and a need for both. See: http://motorcycleguy.blogspot.com/2009/07/soap-vs-rest-and-common-data-transport.html
I really see no purpose for SOAP.
SOAP makes things slower, more cumbersome, ties you into particular implementations.
The tech giants like Google and Apple have moved away from it for good reason - I blogged about this a while ago:
http://blog.interfaceware.com/hl7/soap-oxymoron/
Post a Comment