Characteristics of IPs

Goal of this document

The goal of this page is to create something that's basically an extension of [1] - in other words: if one accepts the notion that the 3 interoperability paradigms (IPs) exist next to each other, and that certain categories of use-cases may be best served by one IP or another one, (given the inherent characteristics of that IP) then how does one answer the question what the best IP is for a given use-case? If your answer is that IP X can be used to cover all use-cases: that may (or not) be true, but we’ll have to work in a mixed environment for a pretty long time.

Notes:

• This discussion is in no way bound by, nor limited to, the ArB of SOA/HSSP work. It is a bottom-up approach, which may someday ïn the middle" meet the top-down approach used in the ArB documents.
• Given that the result will be 'guidance' (only), because of the grey areas that could be covered by multiple IPs there may not be any form of 'official adoption' by HL7.
• when we talk about services, then we’re talking about services that have a RIM-based static content model.
• Rene: Personally I don't think we should use too many SOA terms. That mainly because I, like most people in HL7 (and most readers of the future paper), have a messaging background, and using too many SOA terms will surely cause the readers to stop reading. In order to express some of the differences we may need to use SOA terms, but it would probably be best to tread lightly.

shared context

In case of documents almost no context is shared, for messages some context is shared and in case of real-time service calls a lot of context is shared.

The less shared context (contractual) between communicating partners, the more the requirement to include the context of the data within the data itself. Thus a document contains lots of context, and a service contains almost not context at all. Systems with a lot of shared context are said to be ‘closely coupled’, systems that share little or no context are ‘loosely coupled’. ('Shared' here means 'having in common', rather than 'actively sharing' as in communicating that context, which is actually the opposite thing).

One also recognizes this in the way that things are addressed (when communicated): documents are addressed to a human reader or an organization, messages are sent to an application (as a whole), services are sent to a process within an application.

Another aspect: if we look to the mechanisms where messaging (notably v2) has been most successful, then it's "notifications": something has happened in my application, and I'm sending a single snapshot of the data (including contextual related information) to other applications to enable them to synchronize their database. Query-mechanisms, and order/confirmation type of exchanges, although they have been implemented, have been far less successful. For order/confirmation type workflows I assume that's because they actually assume tightly-coupled systems whereas most traditional messaging systems are not.

To loosely quote Charles Parisot (about IHE XDS): The more tightly coupled the systems are, the more detailed (use-case specific) the queries are. Or in other words: if your systems are loosely coupled, use only generic queries.

scope of the semantic model

Rene: Ernst de Bel mentioned that he's using a "add participation to act" service. To me this highlights another characteristic of messages v. services: services are more atomic in scope, because of the real-time characteristics of services. The example given was "a meeting where multiple people attend" - in the messaging IP one would send 1 message after the meeting was finalized (and maybe 1 when it begins). In de services IP one would use a "add participant to meeting" service whenever someone enters the room.

The semantic content models in a service tend to be relative small - one doesn't send a snapshot of a complicated object structure to update 1 attribute (which one does in messaging).

"add note to identified Act" has a service-like ring to it, much more so than a message, yet it is defined in the v3 messaging standard as an interaction. "add participant to identified act" is another prime example of a service, and it doesn't exist as a v3 message.

development environement

Michael: I have noticed that the Services model is easier to use in the current development environments like Java6 en .Net.

• Rene: Are you saying that the choice of development environment more or less forces you to puck one paradigm over another one? That would not be a good thing - one chooses the most appropriate paradigm first, and then the most appropriate tool to support that paradigm.. (I'm aware it happens the other way around, but it's not something I'd mention as a best practice).

Transformation between paradigms

• how to transform message constructs into services? why might you want to do this?
  • To me this is only worthwhile if two applications use different paradigms. It would require a pretty intelligent agent to do the translation. Rene spronk 13:02, 10 October 2008 (UTC)