We’ve been using the IB (IHB) in one production site since last year with very few issues. The IB is a web server that sits in front of Cloverleaf and provides the necessary hooks for web services. The IB is easy to install and certainly makes the calling of web services and providing of web services from Cloverleaf a seamless task.
We’ve had to call support a few times and found one memory leak bug (now fixed). The HealthVision support has been great and their response quick. Our Australian support managed to get information from other international users which was also helpful.
Our current production site reads (FTP) large data files in FRL or CSV format and translates this to XML for sending and on the reverse, receives XML messages which are used to create FRL files. This worked well with pretty much Cloverleaf out-of-the-box, with the message data being sent as a SOAP message body – in hindsight it should have been sent as an attachment!
We, as an organisation, are attempting to move to a SOA environment, employing the NEHTA standards and this is where a good (preferably great) understanding of XML, XML schema and WSDL’s is required. The Cloverleaf out-of-the-box setup will not work for us as we are using extra WSA variables, a message meta data schema and the message content schemas. As usual, Cloverleaf has all the hooks in place for the coding side of things, but the GUI WSDL creation tool output requires massaging with the extra schemas/namespaces! Thankfully, the architects are pretty cluey which has helped – XML namespaces can be a world of pain.
The IB security options appear to be satisfactory – I’ve not worked with these, so my comment is second-hand.
The IB uses SOAP 1.1 faults and we would like to use SOAP 1.2 faults (NEHTA) – no one else has asked HealthVision for SOAP 1.2, so, understandably they haven’t coded for it!
This is a quote from one of our architects documents with respect to web services…
There are many published standards for Web Services and many ways of implementing them. Simply adhering to these standards does not automatically guarantee that Web Services are interoperable or behave as expected.