MIAS DIY
From Schoolforge-UK
This approach is receiving most attention in our MIAS group discussions and previously in our main discussions, with the focus initially on implementing the SIF concept using REST web services architecture. Subsequently, attention has turned to using the Jabber/XMPP protocols and libraries, which offer a robust message-passing approach that appears better suited to the role of the Zone Integration Server (ZIS).
Contents |
REST
REST stands for REpresentational State Transfer architecture. The concept is described in the dissertation by Roy Fielding, and a tutorial on REST can be found here (PDF). The REST concept uses HTTP and XML in a simple way and URLs are used to access and modify data resources. For a query all the properties of an 'object' are returned with further URL links to allow drill down. Thus a client tool can easily navigate to the data it needs. A demo of a REST service that exposes a SQL database is available here and another tutorial also allows updates via a 'REST Gateway' component. There is a RestFaq which provides a clear intro as part of a REST Wiki.
The advantages of REST are that it employs widely understood standard protocols (HTTP and XML) whereas SOAP adds an additional protocol layer on top of these.
A DIY version of SIF would implement the Zone Integration Server and Client Agents using REST principles. It would use URL's to identify the data resources (i.e. the MIS application databases) and it would use the Common Basic Data Set in place of SIF data objects.
However, the original SIF is based on a message passing architecture, and this has significant advantages for scalability, decoupling and ruggedness. While REST offers scalability (the web is built on it!) and decoupling, it could fall down on ruggedness.
SIF specifies two modes of updating: "Request/Response" and "Publish/Subscribe" (event reporting). Using REST architecture, a simplified version of SIF could be implemented for "R/R" only, however implementing "P/S" would be a much more complex task.
Jabber/XMPP
Jabber/XMPP offers an alternative architecture and a well-established set of tools. Jabber is a complete open-source, secure Instant Messaging (IM) system, like AIM, ICQ, MSN, Yahoo, etc. The base protocols have been approved by the Internet Engineering Task Force (IETF) under the name Extensible Messaging and Presence Protocol (XMPP). Google's IM solution, Google Talk is built on XMPP.
XMPP is designed to reliably stream XML content, and REST solutions can be built quite nicely on top of XMPP). Moreover, XMPP permits a "Publish/Subscribe" mode as well as "Request/Response". These two attributes - ruggedness and asynchronicity - mean that using XMPP would enable a FLOSS project to more closely match the SIF specification.
While the latest SIF specification (ZIP) defines HTTPS as the default communication protocol, it does appear to leave the door open to other protocols (see 3.2.5).
There are many libraries for "Jabber-enabling" code in a variety of languages - see also Jabber Studio.
The Jabber/XMPP resources appear to be ideal for rapid development of message-passing applications - see J-EAI, xDash and Mimir (also discussed here).
What a Zone Integration Server does seems much more like a Jabber server than a web server. A Jabber server is already set up to handle presence and confirm message receipt, two things that a ZIS needs to keep track of that a web server doesn't. A XMPP server would therefore be a perfect solution for a ZIS, while using an open and well supported protocol with plenty of open source client libraries available.
A list of XMPP servers can be found here, and among these, xmppd is a minimal Python based server which could be suitable for quick prototyping work, with some documentation here. The Twisted networking framework (Twisted intro), also in Python, can support both XMPP client and server implementations. Alternatively, Jabber "chatbots" offer another approach to rapid prototyping, of which Neutron is a Python based example.
It should be possible to prototype a ZIS and Client Agent both as XMPP clients which delegate message passing to a XMPP server and ultimately to develop the ZIS itself around an XMPP server in a production version.
(Watch this space...)
Client Agents
Client Agents have two components. For example, one component for SIMS would be developed using the SIMS COM API, as it is supported. This component would also ensure data base integrity on update (the so called business rules). Using COM adds deployment constraints as the code using COM will need to be running on a Windows box (although this needs to be confirmed).
A FLOSS reference implementation of an agent will be needed to help other developers create agents.
Conclusions
Such a DIY project would however be evolutionary, and would not offer any kind of widely-usable "standard" until an advanced stage.
Of course, the project would also require funding, at the very least to help participants meet together and decide who does what. Collaborative "code sprint" sessions are also a good way to achieve short-term results that individuals can subsequently build upon. More substantial funds are needed if the project is to achieve a usable result within a definite timescale, say 6-12 months.
Back to MIAS Approaches
