Stream: implementers
Topic: messaging
Grahame Grieve (Mar 05 2016 at 04:18):
Starting a thread about messaging
Grahame Grieve (Mar 05 2016 at 04:25):
I got some comments at HIMSS about messaging. It seems to me it would be useful to add some sentence like this to the both the messaging page and MessageHeader page:
"Messaging and the MessageHeader describe a way to exchange data based ona store and forward architecture. In general, there is no need to use either in the context of a classic web orientated architecture implied by the use of a RESTful interface, and the RESTful interface provides alternative mechanisms for the same functionalty (RESTful interactions, named operations, pub-sub). Implementers wondering why messaging should be used should not, in general, choose to use messaging"
Josh Mandel (Mar 05 2016 at 04:59):
I'd be strongly in favor of such language. Even of going further with a specific mention of the Subscription resource (which can accomplish some messaging-like goals within FHIR's REST API pattern).
Grahame Grieve (Mar 05 2016 at 05:29):
If I wrote those words, pub/sub would be a link to the subscription resource, but I suppose that since there's also _history, it would be necssary to link to something that explained both and their relationship
Josh Mandel (Mar 05 2016 at 05:31):
Ah. Some people consider exposing data for polling on search to be a form of publishing/subscribing.
Grahame Grieve (Mar 05 2016 at 05:34):
ummmmmmm, well, maybe
René Spronk (Mar 05 2016 at 07:57):
Well, the suggested wording is negative in that it focuses on "don't use this .. etc.". How about creating a postive worded statement "messaging can/should be used for xxxx" - same effect as the above wording. What you aim to do is to provide advise as to when people should use what paradigm, but you'll have to do so in a paradigm-neutral fashion based on best practices, or otherwise both Messaging and Documents will (in future) contain the advise "don't use this, only for Backwards compatibility reasons, use REST instead". This may well be what the current RESTful fans would like the standard to state, but it doesn't reflect the current realities out there. Yes, add guidance, but phrase it as a positive sentence - whilst essentially conveying the same kind of content.
Grahame Grieve (Mar 05 2016 at 12:18):
Well, what's xxxx in your statement? We're consistently getting a lot of confusion because people who know the web orientated architecture can't imagine what xxxx is
René Spronk (Mar 05 2016 at 13:29):
In all of our FHIR materials we have wording about when a particular paradigm is appropriate. For messaging the list tends to be
Event driven
behavioral expectation
Always request/response
Async option
Loosely coupled, worse case assumption
Stuff other than CRUD
Unit of work = * resources
So the only real question to answer is: when to use an operation, and when to use a message. That question is a bit more tricky, for (if carefully done) one could create an operation that mimicks the behavioural characteristics of a message.
But I agree that someone with (solely) a web background will have a hard time understanding messaging and its purpose. So indeed we may wish to scare them away from messaging by noting that "if you've never worked with messaging before, don't play with this at home." - too many undocumented assumptions in messaging. At least with REST one is aware that there is little in terms of assumptions as to how things are processed.
Lloyd McKenzie (Mar 05 2016 at 22:53):
A couple more: Messaging allows server-driven orchestration (client sends a bunch of stuff, server decides what to create or update and in what order), it also supports routing
James Agnew (Mar 07 2016 at 03:24):
Implementers wondering why messaging should be used should not, in general, choose to use messaging
+1
Paul Knapp (Mar 07 2016 at 09:41):
And forward the comments to INM to assess and implement.
Grahame Grieve (Mar 07 2016 at 09:42):
Sure, though since this is about not:messaging, it's not purely just up to INM, I think
Paul Knapp (Mar 07 2016 at 09:45):
I can't see 'scaring someone away' when what they may need is more knowledge as being a net beneficial approach.
Grahame Grieve (Mar 07 2016 at 09:46):
well, it you want to write a book explaining this, go for it. But in the meantime, v2 style store and forward messaging is alien to most implementers, and we're just trying to manage them without having to completely educate them
Brian Pech (Mar 07 2016 at 16:13):
I think we should encourage exploration of using FhIr resources and profiles in a messaging context and see what we can learn from those endeavors. The standard claims it supports such an exchange style and if so we should encourage such exploration.
Richard Kavanagh (Mar 07 2016 at 17:10):
In England we developing both messaging and RESTful solutions for different scenarios. There are many reasosn that cause us to choose one solution over the other.
Grahame Grieve (Mar 07 2016 at 19:02):
It's fine if you want to, and we have no intent of removing it, though it's the one section that attracts people demanding us to remove it since it demonstrates that we have no architectural understanding, and because it creates confusion for a whole swath of stakeholders. I am just trying to deal with the confusion
Paul Knapp (Mar 08 2016 at 05:21):
I don't see how having a section on Messaging 'demonstrates that we have no architectural understanding'. We have content models to support the information the business needs to be conveyed. Those content models can be exchanged over a variety of exchange protocols. Different business have different architectures and so one picks an exchange protocol which suits the business - and as Richard points out above many factors may be considered in that assessment.
Grahame Grieve (Mar 08 2016 at 05:22):
I didn't say I thought we had a lack of architectural understanding. I'm just telling you what people say. You can deny their reality if you want.
Grahame Grieve (Mar 08 2016 at 05:24):
the problem that i'm trying to deal with is that many implementers have no framework in which to understand messaging, and get really confused when it turns out that there's other ways to do the same things as messaging, and then they end up misusing it because it's there and they somehow feel as though they're not doing things properly if they don't use it somehow
Paul Knapp (Mar 08 2016 at 05:40):
It sounds like education on 'the tools of the trade' is lacking. I'll try to engage INM, ITS, Brian, Rene, Richard to see what could be added into the FHIR spec. It may just be links to existing HL7 or other external information on messaging or information exchange paradigms.
Grahame Grieve (Mar 08 2016 at 05:41):
sure. make it hard for everyone.
Grahame Grieve (Mar 08 2016 at 05:41):
or maybe we could add my original proposal with a link to somewhere to go for that kin of information
Paul Knapp (Mar 08 2016 at 05:42):
Huh? Hard? Isn't links what I concluded with?
Grahame Grieve (Mar 08 2016 at 05:42):
you appeared to disagree with my simple wording and proposed links instead
Paul Knapp (Mar 08 2016 at 05:51):
I think we would do the community a better service by providing some education or links to material or sample consideratons and not by saying 'Implementers wondering why messaging should be used should not, in general, choose to use messaging AND implementers wondering why RESTful designs should be used should not, in general, choose to use REST'.
Grahame Grieve (Mar 08 2016 at 05:52):
see, you did. as usual, you are complicating everything and making everything hard for everyone
René Spronk (Mar 11 2016 at 09:51):
FHIR provides many options to cover any specific use case, without expressing a preference 'because it's up to the implementer/context'. Are we ready to express a preference, by stating that one paradigm is preferred over another one? I wouldn't wish to go there. In our FHIR material we mainly talk about REST (FHIR was designed with REST in mind), but cover the other paradigms as well. The rationale for using one paradigm or another can be reasonably well documented. But such a rationale may well be on the wiki and not part of the spec.
René Spronk (Mar 11 2016 at 09:53):
I dont have a problem with a warning for the '80%': "should you have a REST background, then please consider using transactions and/or operations instead of messaging" works for me. Yes, one can add a link with the underlying rationale.
René Spronk (Mar 11 2016 at 09:58):
We will need some documentation for those with a messaging background as to how one can cover the same functionality (if possible at all) using transactions and operations.
Grahame Grieve (Mar 11 2016 at 10:50):
Right. We're not trying to disparage it, just save confusion for the rest guys
Brian Pech (Mar 15 2016 at 17:25):
I would like to point out that there are interested parties who are hoping to use FHIR resources in exchange scenarios that use a paradigm other than REST. Paul is not trying to make things complicated but to point out these other uses. I'll grant there has not been a substantial exploration of these other paradigm but I am aware of several parties interested in this area.
Grahame Grieve (Mar 15 2016 at 18:19):
we have no problem with that, and will continue to support that. We're just trying to deal with the confusion that many people have expressed to me about message header - it's a paradigm thing. People who understand HL7 v2 are never confused about it, and people who don't find it really confusing, and we want something simple to say about that
Grahame Grieve (Mar 15 2016 at 18:19):
it's proving hard to get any progress on this because the messaging people are overly sensitive about this, I think
Paul Knapp (Mar 15 2016 at 18:33):
These are people who have never encountered a message paradigm in any of their work/studies? That's unfortunate.
Grahame Grieve (Mar 15 2016 at 18:34):
yep.
Paul Knapp (Mar 15 2016 at 18:34):
Weird - I thought they were web savvy.
Grahame Grieve (Mar 15 2016 at 18:36):
we require everyone who is educated to know all that we know
Paul Knapp (Mar 15 2016 at 18:40):
No, just thought they'd at least be familiar with TCP/IP.
James Agnew (Mar 15 2016 at 19:18):
I think it's safe to say that there are lots of people building applications these days who have never dealt with anything resembling "messaging" in the sense that HL7 uses the term
Last updated: Apr 12 2022 at 19:14 UTC
