Difference between revisions of "Stateless Queries"
Rene spronk (talk | contribs) |
Rene spronk (talk | contribs) |
||
| Line 5: | Line 5: | ||
The argument against a stateful implementation is that the server side query session state would complicate load balancing and fail over (large server farms using SOAP to serve a multitude of clients). The query mechanism in HL7 is essentially 20 years old, which means it has a proven track record, but we also have to realize that 20 years ago issues such as "load balancing" were probably not a design consideration. | The argument against a stateful implementation is that the server side query session state would complicate load balancing and fail over (large server farms using SOAP to serve a multitude of clients). The query mechanism in HL7 is essentially 20 years old, which means it has a proven track record, but we also have to realize that 20 years ago issues such as "load balancing" were probably not a design consideration. | ||
| − | Possible solution: Add a new (optional D-MIM) attribute in the queryAck and queryContinuation classes, called something like "continuationToken". This allows the server to send back a continuationToken containing the continuation state (which those that brougth the use case forward envision to be the relational database id of the last "record" returned). A stateless server could then conceptually add this id to the selection conditions. | + | Possible solution: Add a new (optional D-MIM) attribute in the queryAck and queryContinuation classes, called something like "continuationToken". This allows the server to send back a continuationToken containing the continuation state (which those that brougth the use case forward envision to be the relational database id of the last "record" returned). A stateless server could then conceptually add this id to the selection conditions. The attribute would be conditional in queryContinuation: if a responding system values querAck.continuationToken, a querying system SHALL populate queryContinuation.continuationToken with that value. |
Revision as of 06:03, 25 August 2006
This page documents an INM Workitem, i.e. an issue within scope of the INM Committee that either is still being discussed, or the resolution of which has not yet been included in an INM ballot.
HL7 Sweden has brought forward a use-case for a stateless query. The current query mechanism is based on the fact that it is assumed that the receiving application maintains the state of the result set. A query continuation message (part of the Query Transmission Pattern) need not contain more than the queryID, the responding system needs to derive everything from that ID.
The argument against a stateful implementation is that the server side query session state would complicate load balancing and fail over (large server farms using SOAP to serve a multitude of clients). The query mechanism in HL7 is essentially 20 years old, which means it has a proven track record, but we also have to realize that 20 years ago issues such as "load balancing" were probably not a design consideration.
Possible solution: Add a new (optional D-MIM) attribute in the queryAck and queryContinuation classes, called something like "continuationToken". This allows the server to send back a continuationToken containing the continuation state (which those that brougth the use case forward envision to be the relational database id of the last "record" returned). A stateless server could then conceptually add this id to the selection conditions. The attribute would be conditional in queryContinuation: if a responding system values querAck.continuationToken, a querying system SHALL populate queryContinuation.continuationToken with that value.
