Migrating an Open, Object-Oriented Application Framework to Azure

Developer Support

Premier Dev Consultants, Nas Baig and Troy Oller share insights migrating a legacy application framework to Azure.


I have supported many IT infrastructure and modernization programs for the DoD, DHS and Intelligence agencies including the Theater Medical Information Program (TMIP). The TMIP is a Joint-Service system that integrates information from existing medical information systems and provides it to deployed medical forces. TMIP supports all medical functional areas, including command and control, medical logistics, blood management, patient regulation and evacuation, medical threat/intelligence, health care delivery, manpower and training, medical capability assessment, and sustainment analysis.

As a lead integration engineer, I managed and promoted the following systems integration efforts: system analysis, design, development (TMIP core framework), testing and implementation of a large “system of systems” for the joint medical community. The TMIP Framework successfully leveraged and implemented the Microsoft Windows file folders interface, COM and early .NET framework as well as other components. In this blog, I start with a high-level overview of the TMIP Open, Object-Oriented application framework and technology stack that was designed and implemented fifteen years ago and explore recommendations (Table 1) for migrating TMIP to Azure.  The goal– to support the DoD mission and for bring continuous value and future expansions to stakeholders and end users.

The TMIP Framework is designed to work in environments renowned for low or interrupted communications. The store and forward capability guarantee critical medical data is available to health care providers and decision makers. Some of the TMIP key features are: Able to function in bandwidth limited environments, low to no communications (store and forward). Provides secure and configurable communication channels. Provides multiple messaging protocols. Writes to and reads from applications through the Windows file folders interface.

“The .NET Framework is a key Microsoft offering, and is intended to be used by most new applications created for the Windows platform. The pre-coded solutions that form the framework’s Base Class Library cover a large range of programming needs in areas including: user interface, data access, database connectivity, cryptography, web application development, numeric algorithms, and network communications. The class library is used by programmers who combine it with their own code to produce applications.” (Wikipedia)

The role of an open, object-oriented, application framework is to provide common services such as: databases, security, communication, a persistent data interface that encapsulates the local database, and the framework interface. TMIP provides a publish-and-subscribe interface via its Event Handler (EVH). These components, and certain Core components, submit objects as XML documents. The XML documents contain information about patient vital signs, patient medical history, health service encounters, patient personal physician, prescription information etc. Although XML is somewhat standardized, the key to success is to standardize the XML Document Type Definitions (DTDs), which define the tag structures and interpretation of data elements within the XML document. The TMIP interface DTDs are taken from the Health Level 7 (HL7) 2.3.1 XML medical message standard and are compliant with the Joint Technical Architecture (JTA).

An application framework is targeted to a particular business area and application domain (i.e., there is no universal framework) and it is typically designed to address a narrow range of problems (e.g., user interface). A framework is not a complete application by itself but can be customized to produce new applications or to fit new environments, usually by mixing and matching components. And, of course, to be an open, object-oriented application framework, the framework must be OO (i.e., exhibit data abstraction through encapsulation, provide polymorphism, and support inheritance) and be based on open system standards or HL7. Object-oriented application frameworks have attracted a great deal of attention as a mechanism for increasing software quality while reducing development costs for applications within a particular domain. One particular form of object-oriented application framework is the middleware integration framework, which provides common services, common object models, and a common integration layer to simplify the integration of heterogeneous software components. In this model, components do not integrate with each other. Instead, they integrate themselves into the object-oriented integration layer through the common object models and common object-oriented services. This is the approach that TMIP has taken.

Some of the problems and challenges that TMIP faced were: to collect heterogeneous, legacy stovepiped applications—each independently developed to address a portion of a particular application domain—and allow them to share data so that they can cooperate. Unfortunately, since they have been independently developed, the legacy systems will typically have different database structures (schemas), different data element names, as well as different data types for the same data elements. For example, CHCSIIT, SAMS, DMLSS-AM, DBSS, CHCS NT all have different database structures, database engines, schemas, users as well as different interfaces and GUIs. The common DLL files conflict was a major issue. The Prime System integrator solved TMIP’s legacy heterogeneous problem by offering an application framework with standard interfaces for all external applications. The TMIP Framework is targeted to military medicine domain and requires all clinical (internal) and external components to be compliant or based on open system standards such as the CORBA medical domain or Health Level 7 (HL7) and with Joint Technical Architecture (JTA) in order to share data with in the TMIP. [1]

TMIP Event Manager package includes sub-packages for delivering HL7 Version 2.3.1 XML and internal TMIP XML data from publishing components to subscribing components applications within a TMIP local area network LAN and remote sites. The Event Manager Package includes the following sub-packages:

  • Event Handler (EVH): Framework COM (Component Object Model) interface responsible for delivering messages from publishers to subscribers via COM. EVH only provides an interface to Visual C++ components.
  • Event Handler Bridge (EVB): Framework COM interface to allow Visual Basic components to use EVH. EVB provides a compatible interface to utilize the publish/subscribe Framework COM interface.
  • Messaging: The TMIP Framework provides a messaging service to the deployed applications, allowing electronic health records and other medical information to transmit from the Theater of Operations to home-based repositories.

The TMIP Framework processes four types of message formats from component applications. Of the four types of messages processed by the Framework, two types, HL7 Version 2.3.1 XML and HL7 Version 2.2. non-XML, result in data storage for reporting purposes. HL7 Version 2.2 non-XML data is converted into HL7 Version 2.3.1 XML prior to storage processing. All messages regardless of the format are securely packaged and sent to remote TMIP sites.

The above figure depicts four primary interfaces for TMIP component applications, CHCS II-T, SAMS, DMLSS AM, DBSS, and BMIS-T, to communicate with the Framework at a local TMIP site. These interfaces allow for data transfer between the Framework and the component applications:

  1. Microsoft COM Subscribe and Publish, this COM interface is named the Event Bridge/Event Handler.
  2. Three modules within the Framework used file-based interfaces to share data between the Framework and component applications: External File Services (EFS) for DMLSS &DBSS, Patient View File (PVF) CHCSIIT, and JMeWS Processing Unit (JPU).
  3. A TCP/IP Socket based interface is used by the Framework and CHCS NT component applications to send and receive messages.
  4. The TMIP LDB interface is for component applications that have connections to the LDB to insert data meant for the Framework into established shared tables. This interface allows for the immediate Oracle status code of the insert to be used as the indicator for successful hand-off to the Framework. Currently, only the CHCS II-T component application and the Framework utilize the TMIP LDB interface.

[1] Implementing an Open, Object oriented Application Framework with XML, Mike Leffer, Health Informatics, Litton PRC, a subsidiary of Northrop Grumman, June 2001, Pages 13-16.

Table 1 (below) summarizes the TMIP software packages that have been replaced with new packages in the TMIP Framework and Core components, for improved maintainability, simplicity, performance, and compatibility reasons. I have further added the last two columns to list Azure service components and recommendations to support faster and continues delivery of features and capabilities to end users in an agile way.

In retrospect, as software developers, thinking about factoring an application into component parts is nothing new. Typically, a tiered approach is taken with a back-end store, middle-tier business logic, and a front-end user interface (UI). What has changed over the last few years is that we, as developers, are building distributed applications for the cloud leveraging microservices architecture.

The changing business needs are:

  • A service that is built and operated at scale to reach customers in new geographical regions.
  • Faster delivery of features and capabilities to be able to respond to customer demands in an agile way.
  • Improved resource utilization to reduce costs. These business needs are affecting how we build applications.

 

Table 1: Use Case Analysis and Migration to the Azure

TMIP Framework, Core Components and SW Development Methodology

Old Package/Development Methodology

TMIP Replacement Package(s) Microsoft Proposed Recommendations
Waterfall and Incremental

The functional and operational testing of each TMIP application is supposed to occur prior to delivery to the TMIP PM for integration. In the past, this and other factors resulted in schedule slippage, and there were difficulties in sharing data with the various applications.

Incremental

TMIP incrementally progressed over time. A block number annotate each TMIP increment. Each block addressed the base-lined integration specifications based on the developed baseline created by the previous block.

  • Azure DevOps Server 2019
  • Azure Boards
For enterprises adopting Agile tools, setting up a hierarchical team structure provides several advantages to portfolio and program managers to track progress across several teams. Quickly and easily start tracking user stories, backlog items, task, features, and bugs associated with your project with Azure Boards.
Non-robust source code management Centralized Version Control System (CVS)
  • Azure DevOps Git
Distributed version and source code management system providing data integrity
User Maintenance Module (UMM) Security Administration (SCA) and Security Object (SCO)

SCO enhances compatibility

  • Azure DevOps Services
  • Azure DevOps Server 2019
To access the resources you manage in Azure DevOps—such as your code, builds, and work tracking—you must have permissions for those specific resources. Most permissions are granted through built-in security groups. You can grant or deny permissions to specific users, built-in security groups, or groups defined in Azure Active Directory (Azure AD) if integrated with Azure DevOps, or Active Directory if integrated with TFS.
Communication Services (CMS)

CMS did not support reliable/guaranteed delivery of data

New Communication Services (NCM)
  • Azure Service Bus
  • API Management
  • Azure Stack
  • NET applications on Azure
Data is transferred between different applications and services using messages. A message is in binary format, which can contain JSON, XML, or just text.

Publish, manage, secure, and analyze your APIs in minutes. Expose a Function App via API Management by linking it to a new or existing API is now available

Build and run applications with more than 100 cloud services across 54 regions around the globe. Build and run cloud applications using consistent Azure services on-premises to meet regulatory or technical requirements.

Build modern, scalable cloud apps on a cloud platform designed for .NET

Communication Administration (CMA) New Communication Administration (NCA)

Different format displays required to support NCM

  • Azure Service Bus
  • API Management
Data is transferred between different applications and services using messages. A message is in binary format, which can contain JSON, XML, or just text.

Publish, manage, secure, and analyze your APIs in minutes. Expose a Function App via API Management by linking it to a new or existing API is now available

Message Services (MGS) New Message Services (NMS)

NMS provides HL7 compatibility and uses OAQ (via the QUE package) for reliable persistent storage

  • Azure Service Bus
  • Integration Services
  • Microsoft Azure Service Bus is a fully managed enterprise integration message broker. Service Bus is most commonly used to decouple applications and services from each other and is a reliable and secure platform for asynchronous data and state transfer. Data is transferred between different applications and services using messages. A message is in binary format, which can contain JSON, XML, or just text.
  • Implement message-based communication workflows with Azure Service Bus
  • Write code that uses Service Bus topics
  • Code with topics vs. code with queues
  • Setting filters on subscriptions
Persistent Interface (PSI)

PSI does not handle HL7 XML or the new object-relational database structures.

New Persistent Interface (NPI) and HL7 Processor (PHL)
  • API Management
  • Event Grid
  • Enterprise Integration Pack
Publish, manage, secure, and analyze your APIs in minutes. Expose a Function App via API Management by linking it to a new or existing API is now available

Use Event Grid to power your event-driven and serverless apps. Event Grid connects data sources and event handlers. For example, use Event Grid to instantly trigger a serverless function. Alternatively, you can use Event Grid with Logic Apps to process data anywhere, without writing code.

Validate XML with schemas in Azure Logic Apps with Enterprise Integration Pack

LERSM Reports (LERSM) LERSM

Uses the Oracle Reports COTS to implement GUI, SQL and report output.

  • . NET applications on Azure
  • Forms Server and Cognito Forms Marketplace
  • Reports
  • Az sql
  • SQL Server on Virtual Machine
  • Az sql vm
  • Build modern, scalable cloud apps on a cloud platform designed for .NET
  • Create digital forms using and publish your online forms that integrate with your backoffice
  • Create more powerful forms
  • Azure API Management
  • Manage Azure SQL Databases and Data Warehouses.
  • Easily migrate your SQL Server workloads to the cloud
  • Manage SQL virtual machines
Medical Surveillance System (MSS) MSS

Uses the Oracle Reports COTS to implement GUI, SQL and report output.

  • Forms Server and Cognito Forms Marketplace
  • Reports
  • Az sql
  • SQL Server on Virtual Machine
  • Az sql vm
  • Create digital forms using and publish your online forms that integrate with your backoffice
  • Create more powerful forms
  • Manage Azure SQL Databases and Data Warehouses.
  • Easily migrate your SQL Server workloads to the cloud
  • Manage SQL virtual machines
Log Handler (LGH)

LGH uses the Windows NT event log, which crashes the system when the event log reaches a maximum size limit

Universal Log Handler (ULH)
  • Az monitor log-profiles
  • Log Analytics data security
  • Az webapp log
  • Log Analytics data security
  • Manage activity logs
  • The Log Analytics service manages your cloud-based data securely by using the following methods: Data segregation, Data retention, Physical security Incident management, Compliance, Security standards certifications
  • Manages Web app logs
  • The Log Analytics service manages your cloud-based data securely

REFERENCES

  • TMIP-Operational Requirements Document., Version 1.0_October 14, 1999.
  • Software Design Description, Prepared by PRC INC, a Northrop Grumman Company, McLean, VA, September 17, 2001.
  • Leffer, Mike Implementing an Open, Object oriented Application Framework with XML, Litton PRC, a subsidiary of Northrop Grumman, June 2001.
  • Devops Resource Center – Azure Devops https://docs.microsoft.com/en-us/azure/devops/learn/
  • Azure Devops Services | Microsoft Azure https://azure.microsoft.com/en-us/services/devops/?nav=min
  • Technical Documentation, Api, and Code Examples https://docs.microsoft.com/en-us/

0 comments

Discussion is closed.

Feedback usabilla icon