RE: [HAPI-devel] [for review] use case for "Processing and forwar ding hl7 query me ssages"

[Tripp, B. <Bry...@uh...>]

Hi Leslie, 

Thanks very much for the comments.  Responses below ... 


> 	[Leslie Mann]  
> 	Bryan, I read the above as implying a single replying 
> application.
> If that is true then I think the use case would already 
> handle this with
> only a topic and reply queue as should there not be only a single HL7
> responding application? My knowledge of Hl7 is pretty 
> rudimentary but would
> not any messages in this problem class be addressed to a 
> single application
> and if multiple applications are being queried/messaged, that multiple
> messages would be required by the sending application, each 
> of which would
> be handled as above. I think the problem here is in trying to 
> extend the HL7
> model (which is point-to-point?) to pub-sub.

Exactly, HL7 is pretty silent on pub-sub.  If we send a message to a Topic
we're outside the bounds of HL7, since it no longer has a single
destination.  Any number of clients can grab it and if its reply-to is set,
any number of clients can reply.  This might confuse the HL7 applications to
which we connect, although they would probably just quietly log an error.
HL7 doesn't allow us to address a message to multiple receiving applications
either.  

> 	[Leslie Mann]  
> 	Perhaps an outbound topic could handle both points 3 
> and 4.  Each
> bridge needing to manage unsolicted messages would subscribe 
> to the outbound
> topic and setup an appropriate message selector.  Any JMS 
> messages received
> would be put on the outbound HL7 conection.  Applications 
> needing a PTP
> reply can have the JMSReplyTo point to a temporary queue setup by the
> sending application and the bridge can send any HL7 responses 
> back via the
> queue to the originating application. This setup would simply 
> be the inbound
> setup turned "upside down". 

If I understand correctly you're suggesting a Topic where I suggested a
Queue?  This seems reasonable.  The advantage is that we can route outbound
messages all over the place.  The downside is that we run into the same
problem with what to do if multiple JMS clients try to respond.  

Actually, on second thought I might disagree with you.  Within JMS a message
could pass through any number of topics for  routing and conversion.
However we should make it possible to send a message specifically to a
particular destination.  For example let's say someone wants to route a
message from system A to system B.  If the system A bridge publishes to a
Topic and the system B bridge consumes from a Queue, you could just hook up
a forwarder that reads from the Topic and writes to the Queue.  It's clear
then that the message is going to system B (only).  

This doesn't prevent you from going through intermediate topics.  For
example let's say systems C, D, and E need ADT messages from system A.  You
could have a forwarder that reads from the system A topic and posts to an
intermediate topic (let's call it "System_A_ADT") using a selector that gets
only ADT messages.  Then you could set up three pass-through agents to read
from System_A_ADT and write to the outbound queues of systems C, D, and E.
In other words a message could bounce all over the place within JMS, but
once it's "outbound" I think it should be bound somewhere in particular.
Does that make sense?  

> 	[Leslie Mann]  
> 	Bryan, can you elaborate on what you mean by "one 
> Destination" to
> "another Destination"?  I'm fixated right now only 2 pub-sub 
> topic clouds,
> one for  "inbound" and another for "outbound" JMS messages 
> with temporary
> queues setup as necessary for "direct to originator" replies and
> applications that are sitting right on the "clouds".  I can 
> now see having
> the apps move back from the "clouds" and instead be connected 
> by a series of
> chained queues that would connect FormatConvertors or 
> ContentConvertors as
> needed to the topic clouds.  This would allow each app to 
> massage messages
> as desired.  

I couldn't have elaborated better myself :) 

>Are you thinking about having multiple inbound XML,
> traditional, etc topics with conversions/formatting done at 
> source rather
> than at destination?

I think we're on the same page ... you would massage the messages with
topic-convertor chains, and JMS clients could grab messages from whatever
Topic has them in the form they want.  

Bryan 


This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact the
sender and
delete all copies. Opinions, conclusions or other information contained in
this e-mail may not be that of the organization.