Open Transmission Wrapper Issues
Back to Infrastructure and Messaging TC
As part of the discussion of the newly proposed Transmission Wrapper (in MCCI R2), and of the Abstract Transport Specification (ATS) document, we'll need to take a fresh look at the Batch/Message Transmission Wrappers and the underlying use-cases.
This page attempts to document some of the issues. Feel free to edit.
Scope of the current Transmission Wrapper
It has been suggested by proponents of service based architectures that the current Transmission Wrapper contains classes and attributes which are not related to Transmission. Possible candidates include:
- versionCode: The version code applies to the entire interaction, but given that the Transmission Wrapper is relatively small in scope it is mostly related to that which is transmitted.
- interactionId: Effectively defines the structure of that which is transported. Currently the only need to be aware of the interactionId at the Transmission level is to distinguish between a Message and a Batch.
- profileId: Profiles apply to the entire interaction, but given that the Transmission Wrapper is relatively small in scope it is mostly related to that which is transmitted.
- processingCode: Application-level parameter for use by a receiving application.
- processingModeCode: Application-level parameter for use by a receiving application.
- acceptAckCode: Application-level parameter for use by a receiving Message Adapter. Accept-level acks are about syntax/conformance, not about Transport.
- responseModeCode: Application-level parameter for use by a receiving application.
- referenceControlId (Batch): used for application-level duplicate checking
- name (Batch): Free text, application level
- batchComment (Batch): Free text, application level
- transmissionQuantity (Batch): Application-level count of the number of messages in a batch
- batchTotalNumber (Batch): Application-level checksum
Manifest
- The English NHS has defined a requirement to add Manifest Items for each Message contained in a batch (e.g. InteractionId, Message.id).
- Others (Mead Walker, Robert Hausam) have come forward with use-cases for the inclusion of a BatchTypeCode and time-interval of a Batch (e.g. this is a batch containing all invoices from 20050101 up tp 20050201)
This raises the question whether we can define a very lean Transmission Wrapper that only contains Transmission oriented issues (and which can be omitted in a sevrice oriented architecture), and create a "Manifest" (or: "Bill of Lading") class which contains generic versions of the above attributes.
Control Act Wrapper
The control act wrapper plays an important part in this. It represents the Trigger Event of the transmission. Therefore it would make sense to include all things related to the expected behaviour of a receiver of this trigger event at this level, including:
- explicitely identified receiver responsibilities
- processingCode: Application-level parameter for use by a receiving application.
- processingModeCode: Application-level parameter for use by a receiving application.
- acceptAckCode: Application-level parameter for use by a receiving Message Adapter. Accept-level acks are about syntax/conformance, not about Transport.
- responseModeCode: Application-level parameter for use by a receiving application.
