From: Thomas, P. R <Pat...@qu...> - 2024-02-08 16:16:09
|
This singleton will be for listening to the single JMS queue. It will be a Spring bean, which is a singleton by default anyway. The fewer objects I have to recreate for each message, the more efficient it should be. Singletons are usually designed to be accessible by multiple threads, but in this case, it will only be the JMS listener that will access it. The service that will create the HL7 messages to send to the JMS will create HAPI objects each time and will need to be thread safe since multiple users can send messages to the JMS queue simultaneously. Each user can send multiple messages in a block, and the messages have to stay in order. It does seem a little inefficient to create HAPI objects, convert them to a string message, send it through JMS, parse the string back to HAPI objects, then send the HL7 message through LLP. But I think the JMS built-in capabilities to handle multiple messages and fail overs is better than anything I could design myself to send the messages more directly. Thank you, Patrick R. Thomas From: Stewart Anderson <ste...@se...> Sent: Thursday, February 8, 2024 9:31 AM To: Thomas, Patrick R <Pat...@qu...>; hl7...@li... Subject: RE: Thread Safe Queue for HL7 messages CAUTION! This email originated outside of Quest Diagnostics. DO NOT click links or open attachments unless you recognize the sender and know the content is safe. Please report suspicious emails to: ph...@qu...<mailto:ph...@qu...> If I recall correctly a singleton is a class that is available across the entire jvm, so if you intend it to handle all messages from lots of queues, I'd think it might quickly become a bottleneck for messaging. No expert in this but, from an integration perspective it would be more scalable and better from the perspective of different services stopping and starting for various reasons to be individually controllable like you can in most IE platforms. Don't know what your platform is or anything though. S Stewart Anderson Integration Consultant P: +44 20 3982 6826 M: +44 77 7999 6873 W: servita.com<https://www.servita.com/> [cid:image001.png@01DA5A77.A909F0E0]<https://www.linkedin.com/company/servita/> [cid:image002.png@01DA5A77.A909F0E0] The Smiths Building, 179 Great Portland Street, London, W1W 5PL From: Thomas, Patrick R via Hl7api-devel <hl7...@li...<mailto:hl7...@li...>> Sent: Thursday, February 8, 2024 1:54 PM To: hl7...@li...<mailto:hl7...@li...> Subject: Re: [HAPI-devel] Thread Safe Queue for HL7 messages CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. I have a follow-up question. The documentation says that HapiContext is not intended to be a singleton. Should it be fine to create one HapiContext in the singleton that I create to handle the incoming messages from my queue? It seems very inefficient to recreate the objects I need to send each message. Thank you. ______________________________________________________________________ The contents of this message, together with any attachments, are intended only for the use of the person(s) to which they are addressed and may contain confidential and/or privileged information. Further, any medical information herein is confidential and protected by law. It is unlawful for unauthorized persons to use, review, copy, disclose, or disseminate confidential medical information. If you are not the intended recipient, immediately advise the sender and delete this message and any attachments. Any distribution, or copying of this message, or any attachment, is prohibited. ______________________________________________________________________ The contents of this message, together with any attachments, are intended only for the use of the person(s) to which they are addressed and may contain confidential and/or privileged information. Further, any medical information herein is confidential and protected by law. It is unlawful for unauthorized persons to use, review, copy, disclose, or disseminate confidential medical information. If you are not the intended recipient, immediately advise the sender and delete this message and any attachments. Any distribution, or copying of this message, or any attachment, is prohibited. |