This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Session"
Jump to navigation
Jump to search
| Line 10: | Line 10: | ||
*There is no sense to introduce a Session between two HL7 applications. In the Messaging Architecture as recognized by the HL7 specifications, the communication between HL7 applications can be very diverse, depending on various factors such as distributed/point-to-point communication, tight vs. loosely coupled system architectures, the [[Messaging Infrastructure Layer]] functionality etc. | *There is no sense to introduce a Session between two HL7 applications. In the Messaging Architecture as recognized by the HL7 specifications, the communication between HL7 applications can be very diverse, depending on various factors such as distributed/point-to-point communication, tight vs. loosely coupled system architectures, the [[Messaging Infrastructure Layer]] functionality etc. | ||
*How many messages get exchanged in the single Session is an implementors decision, and falls out of the scope of the HL7 definitions | *How many messages get exchanged in the single Session is an implementors decision, and falls out of the scope of the HL7 definitions | ||
| + | *Open Issue - it might make sense to connect the Session to the term "pipe" as it is used in the ebMS world. The value proposition - (1) defintion of the transfer mode based on the user request (e.g. polling); (2) this can be connected to inOrder delivery assurance | ||
*Open Issue - how this relates to the terms asynchronous / synchronous messaging? | *Open Issue - how this relates to the terms asynchronous / synchronous messaging? | ||
*Open Issue - how this relates to request/response MEP? | *Open Issue - how this relates to request/response MEP? | ||
Revision as of 14:10, 19 September 2006
Session Definition
Session establishes, maintains and terminates end-to-end connections (sessions) between Source and Destination. A Session lives in the Messaging Infrastructure Layer and may include one to many HL7 messages being transmitted.
Additional notes: This is the first attempt to define a Session in the HL7 world. The main aim is to introduce a definition that will bring value to HL7 standard development (especially HL7 Dynamic_Model), and not have yet another term that is ambiguous and nobody will use.
The following list enumerates open issues, additional information, and well known defintions in the other reference models and technologies.
- OSI Reference Model Session (5th Layer) Defintion: Session establishes, maintains and terminates end-to-end connections (sessions) between two applications on two network nodes. It controls the dialogue between the source and destination node, which node can send when and how long. Also provides error reporting for the Application, Presentation and Session layer. Protocols/API's that operate on this layer include: RPC, SQL, NETBIOS.
- Session in the HL7 dynamic model does not have a value if it is established in between two network nodes. It needs to encopass Source to Destination message delivery
- There is no sense to introduce a Session between two HL7 applications. In the Messaging Architecture as recognized by the HL7 specifications, the communication between HL7 applications can be very diverse, depending on various factors such as distributed/point-to-point communication, tight vs. loosely coupled system architectures, the Messaging Infrastructure Layer functionality etc.
- How many messages get exchanged in the single Session is an implementors decision, and falls out of the scope of the HL7 definitions
- Open Issue - it might make sense to connect the Session to the term "pipe" as it is used in the ebMS world. The value proposition - (1) defintion of the transfer mode based on the user request (e.g. polling); (2) this can be connected to inOrder delivery assurance
- Open Issue - how this relates to the terms asynchronous / synchronous messaging?
- Open Issue - how this relates to request/response MEP?
