Just as their synchronous counterparts, asynchronous modeling tools also share
common attributes. These common parts were reflected in the Asynchronous API for the code mappers,
which is as follows:
- HeadersOnStartup:
- tool-specific code that must be placed in the output files (e.g. special
#includes, etc)
- Encoder:
- tool-specific code that outputs code per ASN.1 Type. The code generated reads data from pertinent modeling-tool generated data structures and encodes them into caller-specified buffers using either Unaligned Packed Encoding Rules or memory dumps of ASN1SCC generated pointerless data structures.
- Decoder:
- tool-specific code that outputs code per ASN.1 Type. The code generated reads data from caller supplied buffers and decodes them into pertinent modeling-tool generated data structures. The source data can be either bitstreams generated using Unaligned Packed Encoding Rules or memory dumps of ASN1SCC generated pointerless data structures.
Compared to the Synchronous API, the extent of this API appears to be somewhat smaller. The reason for this difference can be traced to the nature of Asynchronous tools: They are supposed to be used to model asynchronous processes, which can call (and be called) whenever they choose to. The only guaranteed procedure in the context of these calls is the translation that takes place between the tool-generated data structures and the corresponding ASN.1 compiler generated data structures. The implementations of the Encoder and Decoder methods can also employ re-use by inheriting from the RecursiveMapper (and thus having the recursive descent into the ASN.1 Abstract Syntax Tree and the callbacks of simple mapping methods for free); still, Asynchronous tools are indeed less amenable to ``categorization'' and ``templating'' than Synchronous ones.
Calls to type specific mappers are done from within the base RecursiveMapper class, and are thus exactly the same as in Table 11.1.
