XMPP Implementation Development Team
This all volunteer team has been formed to advance the XMPP Implementation proposal to a concrete implementation. This is in the context of the process driven by the Concrete Implementation Workgroup. For those volunteering for this effort please subscribe to the following two pages so that you see changes/discussions via email or RSS.
Case for XMPP: The Case for XMPP
XMPP Implementation Proposal: http://nhindirect.org/XMPP+Implementation
XMPP Implementation Development Team: http://nhindirect.org/XMPP+Implementation+Development+Team
XMPP Based Demonstration: http://nhindirect.org/XMPP+Based+Demonstration
XMPP Capability Worksheet: XMPP Capability Worksheet
Prior Meeting Notes:
Meeting Notes from Concrete Implementation Extended Meeting session on 6/7/2010:
|EHR Doctors, Inc.
High Level ToDo List
1. Complete the volunteer list
2. Create a "software map" as described on the Minimum Threshold page.
3. Describe the end-user experience in the context of the XMPP implementation.
The Software Map for the XMPP Implementation is expressed using the following views to help software engineers understand how the abstract model is mapped to a concrete instantiation. The views that have been constructed to describe the implementation are:
- Use Case View
- COTS Products and Protocol View
- Deployment View
- Security View (This will be added as security specification gets implemented)
- Content View (This will be added to demonstrate the content exchanged between the end points as the prototype is finalized)
- Sample Sequence Diagrams (This will be added as the implemenation team finalizes the details of the implementation)
- End User Experience (Describe with screen shots the end user's experience on using the applications)
For each of the above views the 2 edge systems (Source and Destination) are represented by "Provider" and "Specialist" as an implementation example. This does not rule out any of the other use cases or use case actors. The HISP - HISP communication is not shown for simplicity. The Provider or Specialist edge can belong to a different HISP. One other point to note is that all Health Domain lookups are performed using DNS SRV records.
The architecture and design principles that were adopted in creating the software map are:
- Develop the implementation using Open Source technologies
- Keep the design simple for end user and industry adoption
- Use proven technologies and platforms that enable a large portion of the development community to quickly develop applications.
- Provide avenue for value added services at the HISP or Edge Systems to enable new business models.
- Allow Flexibility to integrate with NHIN Exchange.
The Use Case view shows a top level view of the abstract model in terms of "Clients" and "Servers"
The COTS Products and Protocol View maps the above use case view into COTS products and the protocols that are used for communication between the clients and the servers. The HISP - HISP communication also currently uses XMPP protocol, but could change based on the outcomes of the other work groups.
The diagram below shows the composition of a HISP Server application. The OpenFire XMPP Server is a sample XMPP Server that provides the necessary XMPP server side services. The OpenLDAP directory is used to provide end-user authentication. The MySQL database is used to store necessary transaction information. It could be potentially used for other purposes like Audit, and offline storage as the prototype evolves.
The Client Application in the diagram below is developed using the "Smack" Open Source XMPP Client library and Eclipse Java libraries.
The Deployment View shows an actual deployment of the Server sub-system on a windows cloud instance including port configuration that is required. There are other options where XMPP can ride on HTTP ports like 80 and 443 and can be adopted to avoid potential firewall issues. For simplicity of the prototype native XMPP ports were used.
The following are the open technical tasks that are pending to provide a reference implementation that meets the specifications of NHIN Direct:
|Expected Completion Date
|Convert Messages to MIME format
|The current implementation is using custom messages and have to be converted to MIME format
|Add TLS certificates for communication
|The current implementation is not using TLS and will need to be added
|Sign/Encrypt all messages
|The current implementation is not encrypting the message traffic and is not signed.
|This will be started once the Security WG finalizes the security policies
|Provide Implementation Overview to Development team
|Provide access to development team to cloud environment