Killing Eterna-threads: REST vs. SOAP

I've heard it said that "Any field that still must use the word Science in its name is still more art than science".  I went to school majoring in "Computer Science", as did many of the readers of this blog.  I think most of us get it that it really is as much art as science still.  Evaluating art relies on subjective judgment.  Evaluating science relies on objective judgment.  These judgments are usually made by experts.  I love the origin of the word "Expert", described as "a person wise through experience", because it is absolutely applicable to this discussion.

In software design, especially the design of information systems, there is still no one true way.  Anyone with experience in the "Art" of software design understands this.  There are lots of different ways to do things, and some are better and some are worse, and which one is better often depends upon the environment, use case, and requirements of the situation.

Often when I'm asked a question about "Should I do X or Y?" or "How do I do X?", my first response is "What are you trying to do?"   I'm trying to understand the environment, use case, and requirements that will let me suggest one solution or another based on my expertise.

Just last week I was in a room full of W3C Standards and IT Experts.  These included authors/editors of W3C standards, committee chairs, book authors, et cetera.  The debate over REST and SOAP which we've frankly stopped discussing for a while in Healthcare IT is still going strong over there.  One thing that was truly obvious to the experts in THAT room is that the relevant points in the REST vs. SOAP debate depends upon the environment.  In "the web", REST dominates with loose binding, dynamic, resource-oriented approaches, and ad-hoc mash-ups.  In "the enterprise", SOAP dominates with strong contracts, definable composition approaches, strong security models, and expected and pre-agreed upon behaviors.

I've seen eterna-threads before ... you know, those debates that never die, and never get solved either.  I build rules for them in my e-mail client so that they get appropriately routed.  The challenge here is not one of science.  These debates cannot be addressed in an OSI 7-layer model.  Instead, you have to jump to OSI-layer 8 or 9 (religion/philosophy and politics) to understand them.  The two camps have even been identified as "Cats" and "Dogs".  I'm stuck in the middle.

To give an example, the author of the Web Application Design Language (WADL) was present at the meeting I attended.  He reports how he was resoundingly "spanked" for not understanding the RESTful "philosophy" regarding interface contracts.  Arguably, that author understands RESTful approaches as well as any practitioner of the art.  In fact, what he did was bring in a requirement "outside" the typical environment where RESTful approaches work, and attempted to integrate that requirement into a RESTful framework. Since the REST crowd didn't see that as a requirement of their "typical" environment, they rejected it as being antithetical to the RESTful approach.

Fielding's paper describes REST as an architectural style and demonstrates its appropriateness for the web.  What others are wanting is a demonstration of this particular style's appropriateness for other environments, such as the enterprise.  We would like to see how features of the current "SOAP" style (e.g., contracts, definable composition, pre-agreed upon or well-defined behaviors, and strong security models) could be addressed using a RESTful approach.

One of the outcomes of the meeting was a suggestion to document best practices in RESTful approaches, and to describe how some of these other requirements: Strong contracts, well-defined behaviors, and strong security models can be applied to REST.  As several "RESTful" experts acknowledge, these aren't antithetical to the approach, they simply haven't been well documented and understood by that community.

It is my sincere hope that a document how REST can work in the enterprise environment is produced, and that it might help the rest of us understand.  If it gets done well, perhaps we can put this eterna-thread to REST.

Meaningful Use IFR Comments

Like just about everyone else I know involved in healthcare in the US, I've been reviewing the IFR and the NPRM. As you can imagine, I have quite a few comments on the IFR that I'd like to share. 

The IFR seems to be a very realistic and pragmatic approach.  That part of it appeals to the pragmatist in me, but there are other parts that are disconcerting.  Given the state of the industry, this IFR can work, however, as a taxpayer, I really wish the IFR was making better use of the incentives that are being provided.  I'm also an optimist, and I may be too optimistic in my hopes that we can move faster -- time will tell.

The IFR represents a state of EMR use that is just a little bit more than the status quo for organizations that have already implemented an electronic medical record system. While the EHR industry itself seems ready for more than what's been specified, it appears that ONC expects that deployed systems are not. If you look at the adoption numbers for EMR systems, this seems to be reasonable. Providers are still somewhere in the 10-25% range for adoption depending on whose statistics you look at and what markets you are focused upon.  The adoption rate has also increased quite a bit in the last few years (though not as much in the last year I expect).  That means that there are a lot of providers out there with relatively recent EMR implementations that may not be completely ready for meaningful use.  Many will need to have new interfaces implemented to support the IFR.  Given the low bar that has been set, it appears that upgrades might be able to be avoided for many providers with existing systems.  Providers may want to upgrade anyway to get better implementations of the standards that have been selected by the IFR.

What is most disappointing are some mistakes made in the regulation with regard to the capabilities of the standards, and some factual misstatements in the prefatory material.  I understand how difficult it is to write 136 pages of complex text in 3 months, but the key to avoiding them is in following the standards activities.  Many of the issues I identify below have been discussed in great detail here, in SDO discussions, HITSP discussions and in discussions with NHIN work groups, and I believe could have been avoided if there had been more direct ONC participation in harmonization efforts.  I hope this will be addressed in the future.

I won't provide comments here on the prefatory material in the Interim Final Rule, as that material is not itself the regulation.  What follows are some of my observations about the IFR.

§170.202 Transport standards for exchanging electronic health information.
If you want to find the SOAP 1.2 standard, please look on the W3C web site and not the OASIS web site.With all of the discussion of SOAP vs. REST that has been going on in the HIT Standards and Policy Committees, I would expect ONC to demonstrate a better understanding of these standards in the IFR.

Also, with regard to REST, does ONC really mean to suggest that any transport that uses a RESTful approach should be supported?  REST is an architectural approach that can work with HTTP, FTP and SMTP (ever used subscription commands with a mailing list server? That's RESTful). Most RESTful architectures use HTTP as their transport standard.  I would suggest that intention was to use HTTP in a RESTful manner and would hope that they clarify the in the final rule that HTTP is the other transport standard.

§170.205 Content exchange and vocabulary standards for exchanging electronic health information.
(a)(1)

The IFR defines both "Implementation Specifications" and "Standards".  But the IFR adopts an Implementation Guide as a standard.  I would hope that IFR acknowledges the CDA Standard as well as the CCD Implementation Specification.

The magic of the AND in the IFR is a perpetuation of the un-harmonized use of standards in the industry that we've been trying to move away from since about 2006.  We must support two standards, and then make one of them go away in two years.  I really don't have any concern about a competition between the selected standards, because I believe the best one will win.  What I am concerned about is that the IFR makes no choice now, and thus incentives are A) not supporting movement in the industry, and B) supporting duplicated effort the costs of which will be borne by providers.  I don't think this was the point of choosing standards in the first place.



(a)(2)(iv)  and (c)(2)
While we'd like everyone to use RxNORM eventually, the IFR itself selects the vocabularies that went into it but not RxNORM itself.  I believe this is just an oversight and hope that it too is corrected in the final rule.

§170.210 Standards for health information technology to protect electronic health information created, maintained, and exchanged.
(a)(1) I was able to find at least 10 symmetric 128 bit fixed block ciphers capable of using a 128, 192, or 256 bit encryption key.  That's not sufficient identification of a standard, and as John Moehrke points out in his blog, could allow XOR with a fixed encryption key which is extremely insecure (it can be broken in seconds).  Most of the cipher algorithms have notable defects and several were NOT chosen as the replacement for DES because of those defects.  Couldn't we just say "AES", or better yet, "a FIPS 140-2 approved cipher function" (see Annex A of FIPS 140-2).  This might provide an incentive for some vendors to support AES in versions of their IT products installed at healthcare institutions today.  Furthermore, it would also support other suitably secure ciphers readily available by providers for communication and storage (e.g., via VPN, TLS and through disk encryption).



(b) This is just a minor nit.  With regard to SHA-1 or higher, I'd prefer that they list out the specifics (SHA-1 or SHA-2 family).  SHA-3 is currently under development and is expected in 2012, but do we want to identify something that doesn't exist yet?  There should be sufficient time to change the regulation to adopt SHA-3 when it becomes readily available (which will be a couple of years after it gets selected).



§170.299 Incorporation by reference.
(c)(3) The title of the HL7 CCD does not contain the words "Level 2".  That's a concept found in the CDA Standard.  Inclusion of this term could imply that "Level 3" is prohibited, but that would be counterproductive given other requirements of the IFR (e.g., medication reconciliation) which would seem to require it.



§170.302 General certification criteria for Complete EHRs or EHR Modules.
I find the text which appears in multiple locations following this structure to be confusing to read.
At a minimum, the version of the standard specified in §170.###(a)(#)(i)(A).
It should be altered to read:
The standard specified in §170.###(a)(#)(i)(A) or a later version of that standard.
It means the same thing and is easier to understand.


(j) Check insurance Eligibility and (k) Submit Claims
These two functions are more often found in what the industry calls "practice management" or "revenue cycle management" systems rather than EHR systems.  I agree with the selected standards, but wonder whether conflating these systems together with the EHR is useful.

The text found in §170.306 (d) regarding Electronic copies of healthcare information should be moved up to §170.302 and altered slightly.  First of all, the need to be able to view discharge summaries is much more frequent in ambulatory settings where followup care is performed, than in inpatient settings, where one would hope the patient wouldn't wide up again, so both ambulatory and inpatient settings need to be able to view the discharge summary.  

§170.306 Specific certification criteria for Complete EHRs or EHR Modules designed for an inpatient setting.(d) This text talks about exchanging diagnostic test results, problem list, medication list, medication allergy list, immunizations, procedures and discharge summaries in a CCD.  

I've said in the past (see If I had a Hammer) , repeatedly that neither the CCR nor the CCD contain appropriate sections for discharge summaries.  These are ancillary documents that can be referenced by the CCD or CCR, but should not be incorporated into it as a whole document for several reasons.

1. The discharge summary is a separate report required by accreditation agencies of inpatient hospitals
   
2. It contains information duplicated (problems, meds, allergies, procedures, et cetera, ) in the standards identified in §170.205(a)(1) of the IFR (CCD and CCR).
3. But there is no place in the CCR (or the CCD) for a "complete" discharge summary.  These are transmitted in both as references to other docuements.
   
4. The discharge summary also contains important information for which there is no real place in the CCR (and thus the CCD).  For example, the discharge summary contains Admission and Discharge Diagnoses, and Hospital Course.  You could put the Admission and Discharge diagnoses in the problem list, but you would have no way to identify them as such, and that could be confusing and might result in patient safety issues if the Admission DX which was changed at Discharge to something else (e.g., from Heart Attack to Ulcer).  Not having a place to put Hospital Course misses much of the detail of the Discharge Summary.
   
5. Presently, it is often available as text, which would make it suitable for transmission using CDA, but not CCD.

This post is already long enough, so I'll comment later on the NPRM.  

As always, the comments that I make upon this blog reflect my own opinions and not necessarily that of my employer.

Synthesis

‘When I use a word,’ Humpty Dumpty said, in a rather scornful tone, ‘it means just what I choose it to mean, neither more nor less.’

‘The question is,’ said Alice, ‘whether you can make words mean so many different things.’
‘The question is,’ said Humpty Dumpty, ‘which is to be master – that’s all.’
-- Lewis Carol, Alice in Wonderland

It's been interesting reading the shift in discussions around REST vs. SOAP in the blogosphere this week now moving towards HTTP and HTML , or device-based connectivity.  See blog posts from John Halamka, Sean Nolan, and Wes Rishel.  My head exploded with insight -- and the sleep that I promised myself is gone by the wayside.

I'm a web, HTML and XML geek from way back.  In 2001 I claimed 7 years of experience with XML (a test my employer passed).  I've got dog-eared copies of the HTTP specifications (as well as HTML and XML specs) sitting on my shelf that are rather aged.  In the thirty years since the development of the OSI seven layer model, we've now seen a shift in how we view HTTP.  Most mappings of the web stack refer to HTTP as an "application layer" protocol, but SOAP, REST, Web Services and Web 2.0 seem to have driven it down the stack to "transport" by layering yet more on top of it.

The complexity of what has been identified as "SOAP" in all these discussions is not SOAP at all, but rather the information models in SOAP.  There's an important difference between the information models that SOAP and RESTful implementations offer that needs to be considered.  These models by the way, are not demanded of SOAP and REST, they just happen to be broadly adopted models that are often associated with these different protocols.

What REST implementations typicall offer that SOAP typically does not is something that HL7 geeks will recognize as a "model of use".  Models of use offer up business friendly names and representations for sometimes fairly complex semantic constructs (and they do it compactly).  The business concepts map closely to the Business Viewpoint of the HL7 SAEAF model.

What ebXML, HL7 Version 3, and similar protocol specifications offer up through SOAP that REST does not is a model of meaning.  The model of meaning maps closely to the Information Viewpoint represented in the HL7 SAEAF model.  Models of meaning are more complex, and contain a lot more explicit information, but they are bigger and harder to understand.  They become a language in which one must express the meaning of "simple" business concepts (although I note those concepts are not really all that simple).

Models of use are easy for people to understand and to perform simple and often very useful computations with (e.g., pretty UI).  Models of meaning are easy to perform complex and often revealing computations with (e.g., clinical decision support).  Geeks like me who've been immersed in various models of meaning don't have large problems speaking those languages and crossing between them, but trying to teach people new languages is rather hard after a certain age.  I seem to have a knack for computer languages that I just wish applied to spoken ones.

The benefits of models of use are conciseness and direct applicability to business processes, but to cross "models of use" boundaries often requires a great deal more translation (e.g., from clinical to financial).  That's because the concepts communicated in a model of meaning assume a great deal of implicit domain knowledge.  The hidden domain knowledge into the model of use makes translations hard.

The benefits of models of meaning are explicit representations of domain knowledge using a controlled information model.  All the possible sematic relationships are explicitly stated and controlled.  This simplifies translation between different models of meaning because one can work at the more atomic level of the controlled information model.  This is why (computer or human) language translators build "parse trees" first, and translate from those "models of meaning".  Models of meaning are more readily marshalled into data storage systems.

The importance of models of meaning in healthcare IT comes into play when we start talking about clinical decision support.  I illustrated one of these examples in Gozinta and Gosouta back in August.  In short, the "model of use" described in the guideline needs to be translated into a "model of meaning" representation in order to compute the guideline through a decision support rule.

So, I think I've successfully convinced myself that we need both model of use and model of meaning in the HIT standards space.  The simple business oriented representations are needed to make implementations easier for engineers.  The more complex information models are needed to compute with.

I think I see a way through the muddle, but it will take some time.  The right solution will not just adopt the first model of use that comes to us.  We will need to put some thought into it.  I believe that we can provide some motion towards an answer that could begin to use in 2013 (or earlier), would be easily adapatable with solutions deployed for 2011.

But if we move towards a model of use in communication patterns, we run into a translation problem that someone has to address.


In a nutshell, WE need to fully specify (in a normative way) translations from model of use to model of meaning and back.  The former is easy (with a common model of meaning), the latter more difficult.  Compilers are easy (use to meaning), but decompilers are hard (meaning to use).  When I say WE, I've got all my big hats on: HL7, IHE and HITSP.  And, we need to agree on a common model of meaning (and this we is the SCO, for which I have no hat).  The HL7 RIM is a really good start for a reference information model in healthcare (Wes and I both know that you can say almost anything in HL7 V3, and I have the V3 model to prove it.)

Having a common reference model provides the interlingua that will truly allow for interoperable healthcare standards.  If all models of use can be expressed in one (and nearly only one) model of meaning based on a common reference model, then translation between the models of use becomes a real possibility.  I know I can translate the "transports" that we've all been talking about into a model of use that would make a number of nay-sayers really happy.

There's also a way to use the same WSDL to enable either SOAP or RESTful transports which makes interfacing a lot easier and more negotiable.  The last problem is how to secure all of this RESTfully, which I'm somewhat unsure of.  I'm not sure it's safe to leave in the hands of the giants that gave us SOAP and WS-* (and insisted on XDS.b) but maybe they've learned their lesson

There's a lot more engineering that is needed to really make this work, and this blog posting is already too long to go into all the details.  The solution isn't simple (making hard problems easy never is) and it needs to address a lot of different business considerations.  There's also a need to address the migration issues for the current installed base (not just one, but at least 10 different HIE's in the US are using the HITSP protocols, many in production, and that doesn't count the Federal agencies, and a heck of a lot more internationally have been using the IHE specifications upon which the HITSP protocols are built for even longer).

My main concerns about all of this discussion is CHURN and disenfrancisement.  Over the past five years we've taken huge steps forward, and this seems like a big step backwards.  It may be a step backwards that prepares for a huge leap ahead, and because of that, I'm willing to engage.  I get what REST can do (this blog and my whole standards communications campaign are built on RESTful protocols).  The concern about disenfranchisement is the suggestion that a group of uber architects could do this quickly and outside the bounds of a governance model that organizations like IHE, HITSP and HL7 impose.  If this is to work, it needs the buy-in of those organizations, and their constituencies.  It needs to have two key goals:  simplicy and compatibility with the industry investments of the last five years.  XML was a three year long project that replaced SGML and changed the world.  It had those same two key goals.

If we can synthesizes models of meaning and models of use together, we will truly have a model of meaningful use.

I'll probably get a heap of flack for this post tomorrow (or at least the pun), but what can I say? 

Hard vs. Easy and Real Metrics

I've been following the discussions on the SOAP vs. REST and HITSP selected transports.  Some of the details are well documented on John Halamka's blog, and in other articles I've written here in response.  In a way, it seems to me to be more of a public dialog about the percieved simplicity of REST opposed to the percieved difficulty in implementing the HITSP selected transport (XDR). 

I'm going to relate some numbers about XDS. If you understand XDS and XDR, you understand that the XDS outbound provide and register transaction is EXACTLY the same to a XDS repository, or to an XDR Document Consumer.  You did say reuse and simplicity were important, right?  What could be easier than that.  Processing the XDR inbound transaction is actually easier than the outbound transaction.

But if you are trying to implement the transport protocol yourself, you've already attacked the wrong problem and it's a waste of your time.  But even though it's a hard problem, it's NOT that hard -- I should know having done it thrice. Let me tell you a little bit about my experiences here:

From Scratch is The Hard Way
Raw XDS (without audits, TLS or CT) cost me about six weeks of effort six years ago (the first year) to "build from scratch" in Java (in about 4000 lines of code).  That INCLUDES connectathon testing.  There's another 3000 lines of code that dealt with CDA stuff that was product specific that also went into the effort.  The XDS part was the easy bit.

A couple of years ago, I rebuilt XDS transactions using a Java ESB and XSLT transforms over the CDA document.  I did that in four weeks of effort, INCLUDING connectathon testing.  The magic is all in about 5000 lines of XSLT, about 2000 of which I wrote.  About 200 lines of XSLT are a code generator, and 3000 of those are machine XSLTs generated from data contained within the IHE PCC Technical Framework  Of the remaining: 800 are hand tuned XSLT for the most common PCC entries, 400 in cda generation utilities, and another 600 in a converter that takes a CDA document and turns it into an XDS.b Provide and register transaction.  There's a little bit of custom Java glue in the ESB.  This is my main toolkit to test IHE profiles, and I've used it with four different profiles, and three different sources for the data that went out in two different connectathons. I routinely test the IHE profiles I help author at connectathon because it's one way for me to prove that they work and that IHE is not headed into the stratosphere.

TLS
If your issue is with TLS, I also feel your pain, but rather than make you go through it, I want you to learn from mine.  The first time I dealt with TLS (five years ago), I spent much time (four weeks) on it to get it perfect, I wrote a FAQ on it that is fairly well known in IHE circles.  It includes source code to make TLS work with the IHE ATNA profile (again in Java).  The code base for this is VERY small (500 lines), the documentation in the FAQ is MUCH more important and hard won knowledge.  The audit trail code was more slogging than craft, and was about 1500 lines (that's not in the FAQ).  Last year, another engineer with a similar build as I and long hair wondered why everyone was asking him ATNA questions (they were looking for me) -- but he'd read the FAQ and had all the answers.  Maybe this year it'll be you.

In the overall scheme of things, 8-10 weeks to build and test a secure transport protocol from scratch is really a drop in the bucket, but I love my ONE day experience.  I implemented  XDS edge system transactions again, and got it working in ONE day using open source tools (including TLS and Auditing).  While that time obviously doesn't include connectathon testing -- those same tools have been through three years of connectathon tests by numerous vendors.  I challenge you to do that in a day the REST way.


Open Source is The Easy Way
Other people and organizations have addressed the Document Source side of the "provide and register" transaction repeatedly, and have provided freely available open source Java solutions.  I can count six in my head, but Open Health Tools is probably the most well known in the US, and there's also the Federally sponsored CONNECT project.  If you are a C#/.Net geek, dig a little into the Microsoft open source registry project.  You'll find some good documentation and sample code C#/.Net code to support the provide and register transaction there as well.  It's a little less refined, but you should be able to make it workable.

As for the inbound side, if all you want is the document attachments, nothing could be easier than the following few lines of Java (ripped off from a connectathon tested implementation):

public void visitAttachments(SOAPMessage m, Visitor v)
{
   Iterator i = m.getAttachments();
   if (i == null) return;
   AttachmentPart part = (AttachmentPart)i.next();
   while (part != null)
   {   v.visit(part);
       part = (AttachmentPart)i.next();
   }
}

I'm sure a similar C# implementation exists, I'm just not a C# coder, and don't know much about WCF.  Look to the documentation on the Microsoft open source site for implementing the Document Consumer.  Some of those same patterns will work as the reciever of the SOAP message to unpack the attachments.

If you want to do more with the inbound metadata associated with those parts you can readily do that. The metadata elements are only a single XPath query away from the XML body of the SOAP message.  These queries are about two lines of code in Java or C#, and any relatively experienced XML geek will know how to find it.  If you aren't that experienced, there's a dozen or so books at your local bookstore targeting your favorite programming language.

Using open source does not involve overly complex code.  The key is being willing to read through an understand a little bit about what someone else did, and learn from it.  If you have to write more than 200 lines of code to make an open source based XDR implementation work (not finished, just working), I'd be very surprised.  If it takes you more than two days to get both halves working, I'd also be surprised.  If you want some pointers, drop me a line.

It was fun once, but now I've been there and done that. Writing transports myself is something that I've learned I'd rather let someone else do.  That way, I can focus on the real issues.  So let's give this debate a rest.

     Keith

NOTE 1:  I'm a big fan of open source.  However, please don't take my mention of these tools as any endorsement by me or my employer for these specific tools.  You must evaluate the suitability and fitness of any software you use for your own purposes.

NOTE 2: I count my lines of code raw, and have about a 33% comment to code ratio (in java), mostly in javadoc.  And yes, I remember these numbers... I've been gathering personal metrics for years.

SOAP vs. REST and Common Data Transport

Recently there's been several discussions across many fronts on Common Data Transport which has re-energized the SOAP vs. REST debate. Although I don't specialize in infrastructure, I have developed both SOAP and REST-ful web services and would like to add my observations.

Arguments for both abound:

For REST-ful web services:

• can be called by a web page
• can be called from an XSLT Stylesheet (a restatement of the above, but with really useful ramifications)
• are easy to implement using off-the-shelf programming languages and libraries. A REST-ful webservice call can be implemented in a page or less of Java code in a single class.
• Can also be implemented using web page technologies such as ASP, JSP, PHP, et cetera.

SOAP Web Services:

• Have standards based and machine readable interface definitions (WSDLs) that can guide code generation. Most application development frameworks support SOAP.
• Support strong data typing in the information exchange.
• Support routing of web-service calls.
• Layers security into the protocol (e.g., WS-Security)
• Supports reliable messaging
• Are already supported by many healthcare standards

As usual when selecting tools, I would suggest that you select the right tool for the job. Let's take a specific example. Recently IHE created a specification for Sharing Value Sets. This specification is intended primarily to support an EHR's access to a collection of coded terminology. The profile oroginally suggested SOAP, and for various reasons, continues to include SOAP as part of profile. Some of these reasons are based upon the strengths of SOAP, which include the standards-based interface definition, strong data typeing and layering of security that are not readily addressed by REST.

However, there is one use case where this service can strongly support testing efforts that demands a REST-ful interface. IHE uses Schematron to test conformance of content to a specification. Many schematron implementations rely on XSLT. The interfaces defined by the SVS profile cannot easily be called if they support only a SOAP interface. The resolution by IHE was to support both REST and SOAP in the profile, and in noting that this was a "secondary" use of the profile, made REST an option. This was an easy decision because we obtained the benefits of both protocols for the different use cases, and the requirements of the two use cases were in fact different. The latter use did not have as strong a need for security or routing of the request. Testing efforts are done in a very different environment as is loading of vocabulary subsets into production EHR systems.

Yes, SOAP is more complex than REST, but with that added complexity comes added capability not present in the REST-ful framework.

My own answer to this debate is similar to the answer I give on any "religious war". My father told me regularly to pick the right tool for the job. Not everything is a nail, screw or bolt, so you need to have a toolbox that contains hammers, screwdrivers and wrenches. The guidelines I learned from my father were Hammer to nail, screwdriver to screw and wrench to bolt. Yes, you can hammer in a screw, or use a wrench to pound in a nail, but I've rarely been successful in tightening a bolt with either a screwdriver or a hammer -- for that I need at least a pair of pliers, and if I want it to stay fastened, a wrench.

The whole notion that there is "one-best-way" to communicate information flies in the face of everything I've learned over the last 40 years about tool selection. What is needed is not a common data transport, but rather, a common set of guidelines that we can use to understand how to best select a transport method for the problem at hand.