Here is a couple of questions I'd love to put out - if you have the time, please let me know since I am genuinely curious:

• Who has implemented a successfully chained service, with some propagation of identity?
  
• If you have, what architectural approach/technology stack have you used?
  
• How are you propagating identity - "sender vouches", "holder of key", "just trust me"?
• How complex is the chain? Single step, multiple steps, complex orchestration?

There are really very few actual success stories I can find on this subject ... I have a sense why this could be, but I'd love to verify my suspicion.

Who does not know and dread the recurring discussion of a topic long thought dead? The most egregious one lately was a discussion about the applicability of RFC 2119 to a particular standard I was working on (to protect the innocent I will not disclose the name of the SDO) - the last time I had a discussion about the meaning of "SHOULD" was about 11 years ago... sigh!

But this is not the reason for my current urge to vent - a bug long thought dead is reappearing once more: the old discussion about REST vs. SOAP. It is really annoying for two reasons. Firstly, it is settled - both have their place, and pitting them against each other is pointless. But secondly, posing the question of "Is SOAP or REST better?" is - to paraphrase Mona Lisa Vito - a bu****it question.

Representational State Transfer (REST) is an architectural style, i.e. a general approach on how to design distributed computing architecture. While it was initially described by Roy Fielding using HTTP, and also uses constraints familiar from the web, it is not tied to a particular technology.

The Simple Object Access Protocol (SOAP) is - in contrast - a specific technology; more precisely an XML based protocol designed to transport data across a variety of different underlying transports. In real-world deployments it often uses HTTP (actually almost exclusively its POST method) as underlying transport for the SOAP Infoset. The architectural style used by many (if not most) SOAP designs is best captured by describing it as remote procedure call (RPC) oriented [1]. 

So a correct (in the sense of "apples to apples") comparison would align itself along the lines of comparing HTTP web service using an RESTful architectural style with SOAP web services using an RPC-based architectural style. A simple, incomplete table might look like this:

Architectural Style	RPC	REST
Commonly used protocol	SOAP over HTTP/POST	HTTP
Common payload	XML	Any Internet Media TYpe
Number of methods/verbs	many	four (PUT, GET, POST, DELETE)
Scalability technology	ESB	Load balancer

That's it - rant over.

[1] Note that while SOAP operates typically in two different modes (rpc/encoded and doc/literal), these have nothing to do with the architectural style of the distributed design.

Last night, Emdeon and MITRE went public with our collaboration on hData. This as been in the works for quite a while, and I am very glad that we were able to get as far as we have come. The work with Emdeon has been great so far, and the team has learned quite a bit about operational aspects that we were able to use in the future design of the product. Here are some quotes form the press release:

"In the era of meaningful use, the electronic exchange of clinical data will be essential. Because providers use disparate healthcare information technology solutions, an easy method of mapping and exchanging clinical data between and among systems is required. hData provides a way for the industry to map clinical data from any electronic health record (EHR) system and creates interoperability," said Miriam Paramore, senior vice president of clinical and government services for Emdeon.

and

"As the industry strives for simple, direct, secure and scalable transportation of health information over the Internet and between known participants in support of meaningful use, hData lowers the barrier to healthcare IT integration by focusing on ease of implementation," said Joy Keeler, healthcare IT program manager at MITRE. "Our work with Emdeon lays the foundation for more efficient healthcare information exchange, and further analysis of the pilot will provide us with important insights on reference implementation and standards in the months to come."

Health Data Management is also running a short story here. Meanwhile, here are the final ITS-WG specs:

hData Record Format-v15.pdf (394.38 KB)

hData RESTful API Specification-v13.pdf (243.27 KB)

The hData specs are well under their way through the bowels of HL7 - right now we are preparing them for official ballot submission within the ITS working group. Overall, the architecture has not changed that significantly since our earliest attempts, but we have added a number if useful features such as meta data, message API, and more. Since the demise of the RESTful profile at NHIN Direct, hData is the only project that I am aware of that tries to bring comprehensive RESTful architecture support to the Health IT industry.

I have uploaded the current versions, in case someone not on the ITS WG mailing list is interested.

hData Record Format-v14.docx (254.28 KB)

hData RESTful API Specification-v10.docx (80.31 KB)

Service chaining is - in my mind - somewhat underappreciated as use case is identity management. It is being paid some lip service, but often put off as too hard to solve. Yet, many of the issues I face in the mapping of complex business processes to a set of decomposed services involves service chaining. For the purpose of this article, here is a simplistic definition (made up by myself):

"Service chaining occurs when a service must invoke another service to complete a transaction."

In other words, a user invokes a service A. That starts working on the problem, but figures that it needs information from service B. Now, service B is being invoked, but there needs to be good understanding on who is invoking service B to perform a satisfying access control decision. Service B should ideally know the identity of the user and the invocation path (in this case just service A) to perform an access control decision.

Interestingly enough, this process can be decomposed into two important steps: the final access control decision by service B, and a reverse authorization decision by the user. For the following steps, strong cryptographic identification through public/private key pairs is assumed:

Step 1: The user invokes service A (authentication and authorization occurs somehow).

Step 2: Service A decides that it needs to invoke service B for completing the operation and tries to access.

Step 3: Service B challenges the access request with a signed statement (access request statement - ARS) that documents:

• Its identity by including an identifier (such as e.g. a URI) and its public key
• The operation service A is trying to perform
• The identity of service A, again through e.g. a URI and public key.

Step 4: Service A receives the ARS and forwards it to the user. The user evaluates the request, andauthorizes the ASR by signing it.

Step 5: Service A forwards the signed ARS to service B. Service B verifies the signature and returns service A the required information.

It is obvious that this process it WAY to expensive to implement in large systems, but these are the steps that are - explicitly or implicitly - taking place in any service chaining scenario. It gets a little more complicated once you allow delegation of authorization, i.e. service A might have permission to authorize access on behalf of the user for service B trying to access yet another service C.

The two major performance impacts in this model are: (i) signature creation and verification, especially over XML constructs, and (ii) ASR parsing and policy evaluation.

Nothing better that coming back from blog hibernation than dishing out a layer cake.

Since our new web guard just ate my description of this model, I will include a more detailed explanation later.

Today, we released the hData technical specifications: hData Record Format and hData Packaging and Network Transport. This is the mail that went out to the mailing lists:

Today we are releasing the first public version of the hData specification for the record format and the packaging and network transport (REST API). They are available here:

http://www.projecthdata.org/documents.html

We will be making some changes to the documents in the next few days to add a simple meta data model and streamline certain elements. Once this is complete, we are planning on moving the specification to a wiki and open up the process of editing. Until this is done, we would like to ask you sending your comments to hdata-general@googlegroups.com

At this time we are also exploring how the hData specifications can be licensed in an open source friendly way. Possible options include an OASIS style non-assertion covenant – please contact us if you have suggestions.

So far, this covers the core data and exchange architecture, but we have started to work on a RESTful security architecture, as well. The scenario we are trying to solve is outline in a recent presentation at NIST's IT Security Automation Conference. In support of this I have come up with a meta data schema, which I will put into the v0.8 version of the hData Record Format specification. Hopefully, I can upload that new version some time next week.

We are very much looking for comments and suggestions. 

tags: hData ehr health care hl7 hitsp

Marc just made my day by sending me the link to the official submission of WADL to the W3C. Quick background: WADL (Web Application Description Language) is a simple interface definition language, specifically targeted at RESTful applications. It is significantly easier than WSDL 2.0 (or WSDL 1.x for that matter), and has some good tooling support through the Jersey implementation of JAX-RS.

tags: wadl rest web services