Everest Clean-Up

It's been awhile since I've posted anything new on this blog and I must apologize, we've been very busy with various projects at the MARC-HI (now called MEDIC) and I haven't been able to post any updates.
One of the tasks that we've performed is a clean-up of the Everest source code, a migration to SVN, and a new roadmap for Everest features.

Clean-up of Source Code

The Everest source code has undergone some clean-up to facilitate the migration to SVN. This includes better documentation on the source code itself, clearer versioning (see roadmap) and some general enhancements to the way things are done in the Everest Framework.

Public SVN Access

The Everest source code is now publicly available via SVN at https://fisheye.marc-hi.ca/svn/Everest. Read only guest access is provided via the "Guest" account, patches can be submitted via the forums or e-mailed to an Everest team member.
The structure of the SVN repository is as follows:
/branches/1.0 – The branch from which the Everest 1.0 release was built
/branches/1.1 – The unstable "feature" branch for the 1.2 release of Everest
/trunk – Stable development trunk.
This branching structure may seem odd but we do have some rationale for structuring the repository like this. The development branches (odd numbers) are not guaranteed to compile or pass unit tests and are where we do the majority of our work on the main roadmap, whereas the trunk is always guaranteed to compile and pass regression tests and only includes new features that are stable.

New Versioning Scheme

The new Everest versioning scheme is as follows:

Major.Minor.Patch

Where Major is the major version (currently the 1.0 series) which are guaranteed to be backwards compatible with previous versions. Minor version numbers are revision or releases which introduce new functionality to the framework. Odd minor version numbers denote a development version whereas even numbers are releases (for example 1.1 is the development branch for 1.2 and 1.3 for 1.4, etc.).
Patches are normally used for tags and represent a collection of bug fixes for the framework components.
The team hopes that these changes will make Everest clearer and will open the gateway to encourage new developers to work on the framework. We're working on a methodology for allowing public commits to our repositories however this will most likely not be completed for quite some time.

Everest in WCF vs. WCF in Everest

The connector architecture in the Everest framework is designed to be consistent regardless of the underlying transport. The four patterns provided by the connectors in Everest (Listen/Wait, Listen/Wait/Respond, Send and Send/Receive) provide common patterns for communicating on a variety of transports including queues, http, files and others.

When it comes to communicating or hosting services that respond using the WCF framework, the current Everest connector pattern is implemented in the form of a WcfServerConnector and WcfClientConnector. While this is great for consistency with the rest of the Everest framework it is awkward for developers who are familiar with WCF. In this manner of speaking WCF is used within Everest. In order to be truly easy to use, we needed to make Everest in WCF.

The current development branch of Everest (1.1) includes this functionality. Consider the process of receiving a message on the WCF connector, the function looks something like this:

/// <summary>

/// Message is available
/// </summary>
static void connector_MessageAvailable(object sender, MARC.Everest.Connectors.UnsolicitedDataEventArgs e)
{

    var connector = sender as IListenWaitRespondConnector;

    var receiveResult = connector.Receive();

    // Determine the type of interaction

    if (receiveResult.Structure is PRPA_IN201305UV02)
        ; // Do something here
    if (receiveResult.Structure is PRPA_IN201307UV02)
        ; // Do something here

    connector.Send(transactionResult, receiveResult);

}

Which makes sense from an Everest connectors point of view, however it is quite awkward to a typical WCF developer. In the new Everest framework version we can use the familiar WCF pattern as illustrated below:

[EverestSerializerFormat(Formatter = typeof(XmlIts1Formatter), GraphAide = typeof(DatatypeFormatter), ValidateConformance = false)]
[ServiceContract(Namespace="urn:hl7-org:v3")]
public interface IServiceContract
{
    /// <summary>
    /// Do something
    /// </summary>
    [OperationContract(Action="*")]
    IGraphable Anything(IGraphable request);

}
public class ServiceBehavior : IServiceContract
{

    #region IServiceContract Members

    /// <summary>

    /// Default message
    /// </summary>
    /// <returns></returns>
    public IGraphable Anything(IGraphable request)
    {
     
         // Determine the type of interaction
       if (request is PRPA_IN201305UV02)
          ; // Do something here
         if (request is PRPA_IN201307UV02)
          ; // Do something here
                    
        return transactionResult;        
    }

    #endregion

}

The EverestSerializerFormat attribute is very similar in functionality to the XmlSerializerFormat attribute and instructs the WCF layer to use Everest as the serialization engine rather than the built-in XML or data contract serializer.

Alternatively, developers can now piggy-back on the other WCF services to classify operations that are to be executed:

[EverestSerializerFormat(Formatter = typeof(XmlIts1Formatter), GraphAide = typeof(DatatypeFormatter), ValidateConformance = false)]
[ServiceContract(Namespace="urn:hl7-org:v3")]
public interface IServiceContract
{
    /// <summary>
    /// Handle PRPA_IN201305UV02
    /// </summary>
    [OperationContract(Action="PRPA_IN201305UV02")]
    PRPA_IN201306UV02 DoSomething(PRPA_IN201305UV02 request);

    /// <summary>

    /// Handle PRPA_IN201307UV02
    /// </summary>
    [OperationContract(Action = "PRPA_IN201307UV02")]
    PRPA_IN201308UV02 DoSomethingB(PRPA_IN201307UV02 request);

}

One limitation of using the EverestSerializerFormat attribute is the lack of access to validation errors and the result details.

Everest Developer’s Handbook Available

One of the big projects that I've been working on over the past year is the creation of an in-depth guide to the Everest framework intended to be used by developers. I'm happy to announce "The Official Advanced Everest Developer's Handbook" is now available for purchase at lulu.com in both e-Book and Hardcover editions. As part of the launch, I am providing the e-Book free of charge and a 25% discount on the beautiful hardcover version for the month of May 2012.
This handbook is an in-depth look at the Everest Framework components and is intended to document how the Everest Framework implements various HL7v3 constructs and includes:

• Over 100 examples of using various Everest Framework components
• In-depth documentation about the Everest Data Types library
• Documentation about the GPMR tooling and generating new RMIM assemblies
• Documentation about advanced concepts of the framework such as attributes, utility classes and writing custom formatters and connectors.

Proceeds from the sales of the books are used to fund further enhancements to the Everest Framework at Mohawk College.
"The Official Advanced Everest Developer's Handbook (Hardcover)"

"The Official Advanced Everest Developer's Handbook (e-Book)"

Finally, a shout goes out to Ken Wong, a Mohawk graduate who donated some of his free time in designing the Cover and first page artwork. Obviously the art pays homage to the "Advanced Dungeons and Dragons" books released in the early 1980's.