Difference between revisions of "RIMBAA: Infoway MBT"
Astechishin (talk | contribs) |
Astechishin (talk | contribs) |
||
| Line 9: | Line 9: | ||
==History== | ==History== | ||
| − | The contract to build was awarded in late 2009 to Intelliware to create the tool to generate Java Jar or .Net DLL with the interface API implemented. The initial Java versions of the MBT (Message Builder Tool) were available in beta during the summer of 2010. Full versions of the Java version were reputed to be running in late 2010, early 2011. The author has been unable to confirm if the .Net is available. | + | The contract to build was awarded in late 2009 to Intelliware to create the tool to generate Java Jar or .Net DLL with the interface API implemented. The initial Java versions of the MBT (Message Builder Tool) were available in beta during the summer of 2010. Full versions of the Java version were reputed to be running in late 2010, early 2011. The author has been unable to confirm if the .Net version is available. |
==Architecture== | ==Architecture== | ||
| + | |||
| + | The source input is the MIF files generated for the constrained (jurisdiction localized) message RMIMs and Interactions. | ||
| + | |||
| + | |||
| + | ==Discussion== | ||
| + | ===Pros=== | ||
| + | *Message validation occurs at generation time for no cost | ||
| + | *Developers are protected from dealing with XML generation | ||
| + | *Using the generated API on both ends of the exchange guarantees interoperability (but not working interoperability :) ) | ||
| + | |||
| + | ===Cons=== | ||
| + | *The variation in message implementations can be minor compared to the workflow differences from jurisdiction to jurisdiction. Workflow differences cannot usually be hidden behind an API. | ||
| + | *The implementation technologies are not limited to Java and .Net | ||
| + | *Many developers are comfortable generating XML | ||
| + | *Examples of instances are in XML, generation of the XML instances using the API is now 'magic', the developer now has less resource when problems arise. | ||
Revision as of 03:44, 15 September 2011
In progess - not complete
Background
In Canada the standard for exchange of information is defined at the national level but each province or territory will localize based on their local constraints. The national vendors are then faced with a balkanization of the national standards. To assist is dealing with this complex environment, Canada Health Infoway contracted a company to provide a process to allow vendors to build against a single, fairly consistent programmatic interface and with simple configuration move from jurisdiction to jurisdiction.
History
The contract to build was awarded in late 2009 to Intelliware to create the tool to generate Java Jar or .Net DLL with the interface API implemented. The initial Java versions of the MBT (Message Builder Tool) were available in beta during the summer of 2010. Full versions of the Java version were reputed to be running in late 2010, early 2011. The author has been unable to confirm if the .Net version is available.
Architecture
The source input is the MIF files generated for the constrained (jurisdiction localized) message RMIMs and Interactions.
Discussion
Pros
- Message validation occurs at generation time for no cost
- Developers are protected from dealing with XML generation
- Using the generated API on both ends of the exchange guarantees interoperability (but not working interoperability :) )
Cons
- The variation in message implementations can be minor compared to the workflow differences from jurisdiction to jurisdiction. Workflow differences cannot usually be hidden behind an API.
- The implementation technologies are not limited to Java and .Net
- Many developers are comfortable generating XML
- Examples of instances are in XML, generation of the XML instances using the API is now 'magic', the developer now has less resource when problems arise.
