Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All

A Software Factory Approach To HL7 Version 3 Solutions

 

Mauro Regio and Jack Greenfield
Microsoft Corporation

Bernie Thuman
Blueprint Technologies

June 2005

Applies to:
   Blueprint Technologies
   Health Level 7 (HL7) Version 3 (V3)

Summary: This white paper, developed by Microsoft in collaboration with Blueprint Technologies [BPT] as part of Microsoft's Health Level 7 (HL7) Software Factory initiative, presents a vision for a software factory in the context of Health Level Seven Version 3 (V3). (32 printed pages)

An implemented HL7 software factory, as described in this white paper, is intended to be used by HL7 V3 application developers in order to simplify the specification, design, implementation, testing and deployment of HL7 V3 conformant applications. A more specific vision for the factory is provided below:

Develop a Software Factory that makes it easier (easier than it is today) for Healthcare Solution Providers to architect, design, and implement HL7 V3 conformant applications within a Web services environment that is built utilizing Microsoft tools and underlying platform components.

Before describing the vision for such a factory, an overview of Microsoft's software factory approach is provided.

Contents

Software Factories
Introduction
Chronic Software Development Problems
HL7 Software Factory Vision
Overview
Existing Assets
Constraints
Stakeholders
Context
The Problem Domain
The Solution Domain
The Architecture
The Application Development Process & Tools
The Software Factory Schema
HL7 Software Factory Example
References

Software Factories

The content in this section has been summarized from other materials (see [GR+A04], [GR+J04], and [GS+SD04]) regarding Microsoft's Software Factories approach.

A more detailed discussion is provided in the book Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools, by Jack Greenfield and Keith Short, from John Wiley and Sons [GS04]. More information can also be found at the MSDN Software Factories site and at the Software Factories site here.

Introduction

Increasingly complex and rapidly changing requirements and technologies are pushing the limits of the current approach to software application development. Because of these trends, stakeholders are increasingly turning to software product line practices to reduce risk, cost, and time to market while improving product quality through systematic reuse. Adopting organizations are starting to demand the kind of tool support available in Rapid Application Development (RAD) environments for software product lines.

This section provides a summary of a methodology developed at Microsoft called Software Factories. The goal of the methodology is to enable the automation of life-cycle tasks in software product line contexts by integrating innovations in model-driven development (MDD), component-based development (CBD), and agile development methods. Software Factories is based on a four-part pattern for building patterns, models, frameworks, and tools for specific domains, such as user interface construction, database design, or business domains such as healthcare and homeland security.

Chronic Software Development Problems

We have identified four chronic problems with current software development methods and practices that are preventing us from increasing the level of automation (and therefore capacity) in software development. Four major problems have resisted solution for at least two decades: monolithic construction; gratuitous generality; one-off development; and process immaturity.

Monolithic Construction

We have not been able to implement development by assembly on a commercially significant scale. The problem is not that we fail to recognize the opportunity. Development by assembly has been part of the vision of industry pioneers for decades, certainly since the advent of object-orientation, if not earlier. It is not that we have under-invested in trying to realize these gains. Development by assembly has been the goal of academic and commercial investment in object-oriented and component-based development methods. Garlan and others have suggested the following reasons [GAO95]:

  • Communications protocols closely tied to component implementation technologies.
  • Weak component specification and packaging technologies.
  • Encapsulation technologies that fix component boundaries at development time.
  • Consumer supplier relationships in the software industry are immature.

Gratuitous Generality

Current software development methods and practices generally offer more degrees of freedom than are necessary for most applications. Most business applications, for example, consist of a few basic patterns. They read information from a database, wrap it in business rules, present it to a user, let the user act on it under the governance of the rules, and then write the results back to the database. Of course, this is an over simplification, since real world business applications generally contain a variety of challenges, such as interactions with legacy systems, large amounts of data, large numbers of concurrent users, or stringent quality of service constraints, which make the implementation of these basic patterns harder than it sounds. Having developed many business applications, one comes to realize that while there are always wrinkles that make each project unique, and specifics that vary, the work is mostly the same from project to project.

One-Off Development

We are unable to achieve commercially significant levels of reuse beyond platform technology. The primary cause of this problem is that we develop most software products as individuals in isolation from other software products. We treat every software product as unique, although most are more similar to others than they are different from them. Return on investment in software development would be far higher if multiple versions or multiple products were taken into account during software product planning. Consequently, we rarely make commercially significant investments in identifying, harvesting, packaging and distributing reusable assets. The reuse that does occur is ad hoc, rather than systematic. Given the low probability that a component can be reused in a context other than the one for which it was designed, ad hoc reuse is almost an oxymoron. Reuse rarely occurs unless it is explicitly planned in advance.

Process Immaturity

We are unable to consistently develop software products on schedule and within budget. This suggests that software development processes are immature. Most tend to one of two extremes. They are either overly prescriptive, optimizing for managing complexity at the expense of managing change, or overly permissive, optimizing for managing change at the expense of managing complexity. A mature development process is a prerequisite for automation, since tools cannot automate poorly defined tasks.

Critical Innovations

The economic and technical problems preventing a transition from craftsmanship to manufacturing can be overcome by applying critical innovations that take new ground in the assault on complexity and change. All of these innovations exist today, and have displayed notable potential in commercial products, although most of them are not yet fully mature. They fall into four areas: systematic reuse, development by assembly, model-driven development, and process frameworks. Let's consider each of these areas in turn.

Systematic Reuse

One of the most important innovations in software development is defining a family of software products, whose members vary, while sharing many common features. This enables a more systematic approach to reuse, by letting us identify and differentiate between features that remain more or less constant over multiple products and those that vary.

Software product lines exploit product families, identifying common features and recurring forms of variation in specific domains to make the production of family members faster, cheaper, and less risky. Rather than hope naively for ad hoc reuse opportunities to serendipitously arise under arbitrary circumstances, they systematically capture knowledge of how to produce the family members, make it available in reusable assets, and then apply those assets during the production of family members. Products developed as family members reuse requirements, architectures, frameworks, components, tests and many other assets.

Figure 1 describes the major tasks performed and artifacts produced and consumed in a product line.

ms954602.hl7softfac_01(en-us,MSDN.10).gif

Figure 1. Product Line Approach

Model-Driven Development

Raising the level of abstraction is one of the keys to advancing progress in software development. Moving to higher levels of abstraction yields many benefits, including higher productivity, fewer defects, and easier maintenance and enhancement. This is the goal of model-driven development (MDD). MDD uses models to capture high level information, usually expressed informally, and automates its implementation, either by compiling models to produce executables, or by using them to facilitate the manual development of executables. This is valuable since this information is currently lost in low level artifacts, such as source code files, where it is difficult to track, maintain, or enhance consistently.

For the purposes of MDD, we are interested in models that can be processed by tools, and we propose to use them in the same way that we currently use source code. Models used in this way cannot be written in languages designed for documentation. They must be precise and unambiguous. Also, in order to raise the level of abstraction, a modeling language must target a narrower domain than a general purpose programming language.

A language that meets these criteria is called a domain-specific language (DSL), because it models concepts found in a specific domain. A DSL is defined with much greater rigor than a general purpose modeling language. Like a programming language, it may have either textual or graphical notation.

Two examples of graphical DSLs are illustrated in Figure 2, which is a screen shot from the Microsoft Visual Studio 2005 Team System. The DSL on the left describes components, such as Web services. It is used to automate component development and configuration. The DSL on the right describes logical server types in a data center. It is used to design and implement data center configurations. Web service deployments are described by dragging service components onto logical servers. Differences between the resources they require and the resources available on the logical servers onto which they are deployed are flagged as validation errors, as illustrated.

ms954602.hl7softfac_02(en-us,MSDN.10).gif

Figure 2. DSL Example in Visual Studio 2005 Team System

Development By Assembly

Critical innovations in the areas of platform independent protocols, self description, variable encapsulation, assembly by orchestration and architecture-driven development are required to support development by assembly.

  • Platform Independent Protocols—Web services technologies (WSDL, SOAP, and XML, for example) succeed where earlier component assembly technologies failed by separating the technologies used to specify and assemble components from the technologies used to implement them.
  • Self Description—Self description reduces architectural mismatch by improving component packaging to make assumptions, dependencies, behavior, resource consumption, performance, and certifications explicit.
  • Variable Encapsulation—Variable encapsulation (an adaptation of Aspect Oriented Programming (AOP)) reduces architectural mismatch by enabling the publication of partially encapsulated components that can be adapted to new contexts by selecting and weaving appropriate non-functional aspects with their functional ones.
  • Assembly By Orchestration—Given adequate contractual mechanisms, services can be assembled using an orchestration engine, such as Microsoft BizTalk Server, to manage the sequences of messages exchanged between them.
  • Architecture-Driven Development—While preventing the assembly of mismatched components is better than constructing invalid assemblies, it does not necessarily promote the availability of well-matched components. This is the purpose of architecture. This reduces the risk of architectural mismatch by imposing common assumptions and constraining design decisions.

Process Frameworks

The key to process maturity is preserving agility while scaling up to high complexity created by project size, geographical distribution, or the passage of time. Experience suggests that a small amount of structure increases agility by reducing the amount of work that must be done. This principle can be applied in the context of a software product family to manage complexity without reducing agility using process frameworks.

We can specialize and tailor a formal process for a specific product family into a highly focused process framework. A process framework contains detailed information about the project, such as tool configuration, paths to network shares, developer start up instructions, pointers to documentation for APIs to be used by the team, names of key contact people for important process steps like configuration management, defect tracking, team policies regarding check-in, coding style and peer review, and many other details specific to the project and to the project team.

Once a process framework is defined, micro processes can be stitched together to support any work flow that the project requires, including top down, bottom up, outside in, test then code, code then test, in any combination, or a totally ad hoc work flow, as long as the constraints are satisfied. The work flow can also be resource driven, allowing work to be scheduled to maximize overall throughput using methods like PERT and CPM, and to be started when the required resources become available. Many different kinds of resources can drive the scheduling, including artifacts like requirements and source code, people like developers or program managers, products like configuration management or defect tracking systems, and facilities like opening of a port or allocating storage on server. This is called constraint-based scheduling.

Integrating the Critical Innovations

The software factory approach integrates the critical innovations into a four-part pattern (a.k.a. the Software Factory Pattern) as summarized below:

  1. Developing reusable assets (frameworks, patterns, processes, for example) in order to bootstrap the development of products using a common architectural style.
  2. Developing domain-specific tools to support the development of products by adapting, configuring, and assembling framework-based components.
  3. Using tools to engage customers and to respond to changes in requirements rapidly by building software incrementally, keeping it running as changes are made.
  4. Capturing design decisions in a form that directly produces executables.

What Is a Software Factory?

A software factory is a product line that configures extensible development tools like Microsoft Visual Studio Team System (VSTS) with packaged content and guidance, carefully designed for building specific kinds of applications. A software factory contains three key ideas: a software factory schema, a software factory template and an extensible development environment:

  • Think of the software factory schema as a recipe. It lists ingredients, like projects, source code directories, SQL files and configuration files, and explains how they should be combined to create the product. It specifies which DSLs should be used and describes how models based on these DSLs can be transformed into code and other artifacts, or into other models. It describes the product line architecture, and key relationships between components and frameworks of which it is comprised.
  • The software factory template is like a bag of groceries containing the ingredients listed in the recipe. It provides the patterns, guidance, templates, frameworks, samples, custom tools such as DSL visual editing tools, scripts, XSDs, style sheets, and other ingredients used to build the product.
  • An extensible development environment such as VSTS is like the kitchen where the meal is cooked. When configured with the software factory template, VSTS becomes a software factory for the product family.

To press this analogy further, the products are like meals served by a restaurant. Software factory stakeholders are like customers who order meals from the menu. A product specification is like a specific meal order. The product developers are like cooks who prepare the meals described by the orders, and who may modify meal definitions, or prepare meals outside the menu. The product line developers are like chefs who decide what will appear on the menu, and what ingredients, processes, and kitchen equipment will be used to prepare them.

Realizing the Software Factory Vision

Software Factories are based on the convergence of key ideas in systematic reuse, model driven development, development by assembly, and process frameworks. Many of these ideas are not new. What is new is their synthesis into an integrated approach that lets organizations with domain expertise implement the Software Factory pattern, building languages, patterns, frameworks and tools to automate development in narrow domains.

We think key pieces of the Software Factory vision will be realized quickly, and some over several years. Commercial tools that can host Software Factories are available now, including Microsoft Visual Studio .NET and IBM WebSphere Studio. DSL technology is much newer than most of the other technologies, and relies on families of extensible languages. DSL development tools and frameworks are currently under development (see the Microsoft Visual Studio 2005 DSL Tools site), however, and have already started to appear in commercial form.

HL7 Software Factory Vision

This section elaborates upon the HL7 software factory vision as previously noted:

Develop a Software Factory that makes it easier (easier than it is today) for Healthcare Solution Providers to architect, design and implement HL7 V3 conformant applications within a Web services environment built utilizing Microsoft tools and underlying platform components.

After providing a brief factory overview, this section elaborates upon this vision through answering the following questions:

Table 1

QuestionSection#
What assets can be used to bootstrap the factory's development?0
What constraints exist on the production environment?0
What constraints exist on the development environment?0
Who are the factory's stakeholders?0
How will the factory fit into the overall development process?0
How will the products developed using the factory fit into a production environment?0
What problems is the factory trying to solve?0
What solutions is the factory trying to provide?0
What does the factory's software architecture look like?0
What does the application development process look like?0
What tools will be provided to automate development within the factory?0
What does the factory's schema look like?0

Overview

The HL7 software factory is intended to address problems encountered within an overall Healthcare Enterprise business context. In order to provide shape to the HL7 software factory, initially, the factory is defined in the context of two core business domains that includes:

  • Laboratory Management—includes the problem of integrating the clinical laboratory into the healthcare enterprise.
  • Public Health Reporting—includes the problem of reporting safety related events in the healthcare enterprise.

The factory solution, in the Healthcare Enterprise problem domain context, is to enable:

  • Applications to realize HL7 V3 collaborations (i.e. a series of HL7 interactions) that collectively support an overall business goal (complete a laboratory observation, for example).
  • Applications to communicate over a Web services infrastructure that is based on open standards and conformant with HL7 V3 Web Service Profiles.

The factory solution makes the following assumptions:

  • Applications were not designed for HL7 V3.
  • Applications were not designed for collaboration.
  • Applications were not designed to communicate over a Web services infrastructure.

As will be shown in subsequent sections, HL7 Collaboration Ports are the "end products" produced by the factory.

Existing Assets

One of the first steps in defining a software factory is to survey existing assets (architectural styles, domain specific standards, or platforms, for example) that can be leveraged to "bootstrap" the factory.

In the case of the HL7 software factory, several categories of existing assets can be used in this bootstrapping process. These include:

Table 2

Asset CategoryDescription
Healthcare Information System AssetsAssets specific to healthcare information system development and interoperability. For example, the following HL7 and IHE artifacts are considered assets within this category:
  • HL7 Version 3 Ballot Publication
  • HL7 Version 3 Message Development Framework
  • HL7 Repository and Tools
  • HL7 Model Interchange Format
  • HL7 Use Case Models
  • HL7 Information Models
  • HL7 Interaction Models
  • HL7 Hierarchical Message Definitions
  • HL7 Implementation Technology Specifications
  • HL7 Web Service Profiles
  • IHE Laboratory Technical Framework
Architectural AssetsAssets that can be used to facilitate the definition of the factory's software and system architectures. For example, the architecture for Microsoft's BizTalk Server 2004 has greatly influenced the factory's architecture as outlined in Section 0.
Implementation AssetsAssets that can be used to support the implementation of artifacts produced by the factory. Primarily, this refers to reference implementations of HL7 V3 conformant applications.
Factory Development AssetsAssets that can be used to build the factory itself. For example, the Microsoft Domain Specific Language (DSL) SDK can be used to establish the HL7 Collaboration Port DSL as depicted in Section 0.
Platform AssetsAssets (run-time components, for example) that are part of a deployed HL7 factory solution. For example, the Microsoft .Net Framework and the Web Services Enhancements for Microsoft .NET can be used as the underlying Web services platform for the factory.

Constraints

When defining a factory, it is important to identify constraints on products developed using the factory and constraints on the factory itself. These include:

Application Constraints—requirements imposed on the applications developed using the factory—such as standards, external interfaces, or localization, packaging, licensing, installation, operational, and administrative requirements.

Factory Constraints—requirements imposed on the application development process by the factory—such as technology, vendor or platform preferences, acceptance and reporting criteria, budget and schedule constraints, or development policies and guidelines.

As an example, the following constraints are assumed by the HL7 software factory:

Table 3

Constraint TypeConstraint NameConstraint Description
Application ConstraintHL7 Application Role ConformanceIn order to adhere to the HL7 V3 standard, HL7 applications should be conformant with HL7 designated application roles. In order to claim HL7 conformance to an HL7 application role, the supporting software must: 1) Send all messages that are required to be sent by the application role, 2) Receive all messages that are required to be received by the application role, 3) Carry out application role receiver responsibilities.
Application ConstraintHL7 Web Service Profile ConformanceApplications developed using the factory should be conformant to the following Web service profiles:
  • HL7 Web Services Basic Profile
  • HL7 Web Services Addressing Profile (optional constraint)
  • HL7 Web Services Reliable Messaging Profile (optional constraint)
  • HL7 Web Services Security Profile (optional constraint)
Factory ConstraintDevelopment and Platform TechnologiesHL7 software factory application development will use the following Microsoft development and platform technologies:
  • Microsoft Visual Studio 2005 Team System
  • Web Services Enhancements for Microsoft .Net version 2.0
  • Microsoft .Net Framework
  • Microsoft BizTalk Server 2004
  • Microsoft SQL Server
  • Microsoft Active Directory
  • Microsoft Windows Server Platform

Stakeholders

Several stakeholders are critical to the success of the HL7 software factory. This includes (but is not limited to):

  • Healthcare Providers—these are the end users of the applications developed using the factory.
  • Solution Providers—users of the factory that produce HL7-based applications.
  • Software Factory Architects and Developers—specifies the factory and implements factory assets.
  • HL7 Tools Committee—specifies tools used by the HL7 community that implement HL7 conformant applications.

Context

It is important to understand the context for a software factory from two perspectives:

  • Production Context—Specifies where the end products produced by the factory reside in a production setting.
  • Development Context—Specifies where the software factory fits within the overall development environment.

Production Context

In the case of the HL7 software factory, HL7 Collaboration Ports are the end products produced by the factory. Figure 3 provides the production context for HL7 Collaboration Ports in relation to HL7 application systems. In this scenario, the establishment of an HL7 Collaboration Port for the Hospital Information System is the end product produced by the factory. More specifics regarding HL7 Collaboration Ports are provided in Section 0.

ms954602.hl7softfac_03(en-us,MSDN.10).gif

Figure 3. HL7 Collaboration Port Context

Development Context

Figure 4 depicts the overall context for the factory in terms of HL7 software factory and HL7 Collaboration Port development processes.

ms954602.hl7softfac_04(en-us,MSDN.10).gif

Figure 4. HL7 Software Factory Context

The Problem Domain

Before embarking on establishing a specific solution, the software factory approach focuses on defining the problem domain. This includes defining the problems that are to be solved by the factory in addition to modeling these problems in the form of a problem feature model. A feature model provides a means to model the common and variable elements within a particular domain and is used as a source of configuration information (see [CE00] for more on feature modeling).

Prototypical Problems

The HL7 software factory is intended to address problems encountered within an overall Healthcare Enterprise business context. As previously stated, initially, the factory is defined in the context of two core business domains:

  • Laboratory Management—includes the problem of integrating the clinical laboratory into the healthcare enterprise.
  • Public Health Reporting—includes the problem of reporting safety related events in the healthcare enterprise.

The next table includes a sample (only a snippet) of the prototypical problem list to be addressed by the factory for these domains. Each problem (P#) is aligned to those encountered by specific business stakeholders and are further mapped to a set of problem features.

Stakeholders: H = Healthcare Providers, L = Laboratories, P = Public Health and Regulatory Agencies, M = Manufacturers

Features: OP = Order Placement, OT = Order Tracking, OF = Order Fulfillment, WM = Work Management, HER = Health Event Reporting, PIM = Patient Information Management

Table 4

It is important to note that the notion of HL7 V3 is considered part of the solution domain as defined in Section 0. Keeping HL7 out of the problem domain allows the problem domain to remain independent of changes to HL7 standard variations.

Problem Feature Model

Figure 5 represents a snippet of the problem feature model (only the Laboratory Management domain is shown) for the HL7 software factory.

ms954602.hl7softfac_05(en-us,MSDN.10).gif

Figure 5. Problem Feature Model (Snippet)

The Solution Domain

In the software factory approach, the solution domain includes identifying the solutions (to the problem domain) that are to be provided by the factory in addition to modeling these solutions in the form of a solution feature model.

Solution Domain Definition

The primary intent of the HL7 software factory solution is summarized by the following problem statement (from a solution perspective):

Problem Statement: Enable healthcare applications to collaborate using HL7 V3 defined interactions on a Web services infrastructure.

Further, the factory will provide a solution that enables:

  • Applications to realize HL7 V3 collaborations (i.e. a series of HL7 interactions) that collectively support an overall business goal (complete a laboratory observation, for example).
  • Applications to communicate over a Web services infrastructure that is based on open standards and conformant with HL7 V3 Web Service Profiles (these are application constraints).

The factory solution makes the following broad assumptions:

  • Applications were not designed for HL7 V3.
  • Applications were not designed for collaboration.
  • Applications were not designed to communicate over a Web services infrastructure.

From a high-level perspective, the factory will enable disparate applications to exchange HL7 V3 conformant messages as depicted in Figure 6.

ms954602.hl7softfac_06(en-us,MSDN.10).gif

Figure 6. HL7 Collaboration Model

More specifically, the factory is to enable collaborations between HL7 application roles (implemented by application systems, for example Ordering System, Laboratory System, Result Reporting System), such as in the HL7 storyboard in Figure 7.

ms954602.hl7softfac_07(en-us,MSDN.10).gif

Figure 7. HL7 Storyboard

This sequence diagram depicts interactions between HL7 application roles and the relative timing of each HL7 interaction in relation to other interactions.

Prototype Solution (Requirements) List

The next table includes a sample (only a snippet) of the prototypical solution list to be addressed by the factory. In this case, "solution" is synonymous to "requirement" (in other words, these requirements provide solutions to the problems identified in Section 0 in addition to taking into account constraints as eluded to in Section 0). Further, each requirement (R#) is mapped to a set of solution features.

Features: HL7 = HL7 Interaction Models, WS = Basic Web Services, WSS = Web Service Security, WSR = Web Service Reliable Messaging, AI = Application Integration (non-Web Services), OR = Orchestration, ADM = Administration

Table 5

Solution Feature Model

The solution feature model for the HL7 software factory is quite extensive and only snippets are provided here.

For example, Figure 8 models the set of interactions and application roles within the HL7 V3 Laboratory Domain as features in the solution feature model. A mapping is to be defined between problem domain features and these HL7 solution domain features.

ms954602.hl7softfac_08(en-us,MSDN.10).gif

Figure 8. HL7 Laboratory Domain Feature Model

Since one of the primary goals of the HL7 software factory is to enable HL7 V3 defined interactions on a Web services infrastructure, non-functional features related to Web service interaction is also important to model as in Figure 9. This portion of the feature model includes mandatory and optional features for basic application to application communication over a Web service infrastructure, and in addition more specific details about addressing of application endpoints over the network and support of reliable messaging.

ms954602.hl7softfac_09(en-us,MSDN.10).gif

Figure 9. Basic Web Service, Addressing and Reliable Messaging Features

The Architecture

In addition to understanding the problems to be solved by the factory and features of the solution domain, a key asset established as part of a software factory is its software architecture (a more elaborate description would include the technical architecture as well). It defines the components and supported interactions between those components and provides the overall framework upon which applications are developed and deployed.

As previously indicated, HL7 Collaboration Ports are the "end products" produced by the factory. The high-level software architecture for HL7 Collaboration Ports is provided in Figure 10.

ms954602.hl7softfac_010(en-us,MSDN.10).gif

Figure 10. HL7 Collaboration Port Software Architecture

The high level message flow (numbered in Figure 10) through the HL7 Collaboration Port proceeds as follows:

  1. System A (Hospital Information System, for example) determines that a message must be sent to System B (for example, Laboratory Information System). System A places the message to be sent into a message queue and notifies the Collaboration Port Adaptor (Receiver) to send the message to the provided destination (System B).
  2. The Collaboration Port Adaptor (Receiver) pulls the message content from the message queue and provides a message stream to the Message Receiver.
  3. The Message Receiver asks a Message Filter (Receiver) to place the message stream into the collaboration port's internal message object structure.
  4. The Message Receiver then notifies the Message Dispatcher of the message receipt.
  5. The Message Dispatcher forwards the message to a Message Sender that has previously registered with the Message Dispatcher to receive messages of this type. Optionally (indicated by 5* in the diagram), the Orchestration Manager may have registered to receive the message for orchestration processing.
  6. The Message Sender asks a Message Filter (Sender) to process the outbound message. In this case, the message is translated into an XML stream.
  7. The Message Sender then forwards the XML stream to the Collaboration Port Adaptor (Sender).
  8. The Collaboration Port Adaptor (Sender) packages the XML stream into a SOAP request and sends it to the target system (System B).

The Application Development Process & Tools

The software factory approach not only specifies reusable assets in the form of components and frameworks, but also defines an overall application development process to be used by factory consumers and the set of tools to facilitate automation within the factory.

The Process

Figure 11 depicts a high-level application development process framework defined by the HL7 software factory (dashed lines indicate feedback cycles). The process encompasses an iterative development process model in order to provide continuous feedback and more immediate results.

ms954602.hl7softfac_011(en-us,MSDN.10).gif

Figure 11. HL7 Collaboration Port Development Process Flow

The Tools

The following table lists several tools that are envisioned to support development within the HL7 software factory.

Table 6

ToolDescriptionMicrosoft Tool Mapping
HL7 Collaboration Port DesignerProvides a means to develop a visual model and corresponding meta-data for an overall HL7 Collaboration Port environment. An example of a visual model produced by this designer can be found in Section 4.Microsoft VSTS 2005 (extension to Application Designer)
Microsoft DSL SDK  
HL7 Collaboration Port Code GeneratorProvides the facility to generate source code (in C#) and additional project artifacts (WSDL, for example) using the meta-data produced by the HL7 Collaboration Port Designer.Microsoft VSTS 2005

Microsoft DSL SDK

Microsoft Recipe Framework

Logical Systems DesignerProvides a means to develop a visual model and corresponding meta-data for a HL7 Collaboration Port's technical architecture. An example of a visual model produced by this designer can be found in Section 4.0Microsoft VSTS 2005 (Logical Systems Designer)
Orchestration DesignerProvides a means to develop a visual model and corresponding meta-data for the orchestration of message flow between application components.Microsoft BizTalk 2004 Orchestration Designer
Integrated Development Environment (IDE)Provides a common environment for all development tools (compilers and visual designers, for example) and activities conducted by HL7 Collaboration Port developers.Microsoft VSTS 2005
Solution BuilderProvides the mechanism to configure an HL7 software factory template within the VSTS 2005 development environment. This includes configuring problem and solution feature models and generating a Visual Studio solution, projects and initial artifacts (models, for example).Microsoft VSTS 2005

Microsoft Recipe Framework

Class DesignerProvides a means to develop a visual model and corresponding meta-data for a set of classes within the VSTS 2005 environment. The Class Designer provides code generation facilities in addition to automatically synchronizing models and source code.Microsoft VSTS 2005 (Class Designer)

The Software Factory Schema

As previously stated, a software factory schema can be viewed as a recipe. It lists ingredients, like projects, source code directories, SQL files and configuration files, and explains how they should be combined to create the product. It specifies which DSLs should be used and describes how models based on these DSLs can be transformed into code and other artifacts, or into other models. It describes the product line architecture, and key relationships between components and frameworks of which it is comprised.

Figure 12 is a graphical depiction of the HL7 software factory schema. It depicts the schema's 1) viewpoints, 2) viewpoint contents (tools, assets and artifacts produced), and viewpoint mapping relationships.

Click here for larger image.

Figure 12. HL7 Software Factory Schema (click for larger image)

HL7 Software Factory Example

This section provides an example walk-through of a small portion of the HL7 software factory as presented in this white paper.

Please note, even though the screen shots below show how a software factory could be built and hosted within Microsoft's Visual Studio 2005 development platform, the screen shots presented here are not part of a specific Microsoft product and are only provided for illustrative purposes.

Configuring The Solution

After configuring the problem domain (not shown here), the next step is to finish configuring the solution feature model as in Figure 13. The idea is that the solution feature model is pre-configured (for example, certain HL7 interactions and application roles are selected as part of the solution) based upon the configuration of the problem feature model.

Click here for larger image.

Figure 13. Configuring the Solution (click for larger image)

The left pane allows a factory user to select which features to include in the solution as part of a factory instantiation. The middle pane shows the same information conveyed in the left pane, but in a graphical notation. The right pane shows a standard view of the Visual Studio 2005's Solution Explorer.Modeling and Configuring the Solution

The next step is to use the HL7 Collaboration Port Designer (a DSL-based tool) to model and configure the context for the collaboration port. Again, the idea is that an initial collaboration port model is created based upon the solution feature model's configuration (see prior step). This model specifies the collaboration port, external system interfaces and the adaptors used to communicate message content between systems.

Click here for larger image.

Figure 14. Modeling and Configuring the Solution (click for larger image)

The middle pane shows the visual model for the given collaboration port and enables the user to graphically manipulate the topology of a collaboration port and its environment. The left pane allows a factory user to configure a selected model element. In this case, the user is configuring a "Web Service Requestor" (selected in the middle pane). The right pane shows a standard view of Visual Studio 2005's Solution Explorer.

Generating Implementations

The next step is to use the HL7 Collaboration Port Designer (a DSL-based tool) to implement part of the solution for the collaboration port. This step invokes a specialized HL7 software factory code generator (the HL7 Collaboration Port Code Generator) that interprets the model's configuration, matches the model with pre-established code templates and generates the resulting source code for further compilation, framework completion, etc.

Click here for larger image.

Figure 15. Generating Implementations (click for larger image)

In this case, the user selects the "Implement…" menu item from the context menu for the visual model in the middle pane. All other panes are as described in the prior section.

Modeling and Configuring the Deployment Environment

The next step is to use the Logical Systems Designer to model and configure the HL7 Collaboration Port's deployment environment.

Click here for larger image.

Figure 16. Modeling and Configuring the Deployment Environment (click for larger image)

The left pane shows the set of modeling elements that can be placed onto the graphical diagram in the middle pane. Again, the right pane shows a standard view of Visual Studio 2005's Solution Explorer.

References

[BEE04]G. W. Beeler. Documentation of HL7 Internal Tooling Structure, Metadata, and Semantics, Release 1. HL7 Methodology & Modeling Committee. May 2004.

[BPT]Blueprint Technologies, Inc.

[BOS00]J. Bosch. Design and Use of Software Architectures: Adopting and evolving a product-line approach. Addison-Wesley. 2000.

[CE00]K. Czarnecki, U. W. Eisenecker. Generative Programming: Methods, Tools and Applications. Addison-Wesley. 2000.

[CIS04]Data Center Networking: Internet Edge Design Architectures. http://www.cisco.com/application/pdf/en/us/guest/netsol/ns304/c649/ccmigration_09186a008014ee4e.pdf. Cisco Systems, Inc. 2003.

[GAO95]D. Garlan, R. Allen, J. Ockerbloom. Architectural Mismatch: Why Reuse Is So Hard. IEEE Software 12, 6, 1995.

[GLO04]H. Glover, BSc, PhD. HL7 V3UK Implementation Progress. http://www.hl7.de/iamcda2004/finalmat/day2/UK%20Progress%20HG.pdf. International Meeting, Acapulco, October 19th 2004.

[GR+J04]J. Greenfield. Case for Software Factories. http://msdn.microsoft.com/architecture/overview/softwarefactories/default.aspx?pull=/library/en-us/dnmaj/html/aj3softfac.asp. July 2004.

[GR+A04]J. Greenfield. Software Factories: Problems and Innovations. http://msdn.microsoft.com/architecture/overview/softwarefactories/default.aspx?pull=/library/en-us/dnbda/html/softwarefactwo.asp%23softwarefactwo_topic3. August 2004.

[GS04]J. Greenfield and K. Short with S. Cook and S. Kent. Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools. Wiley. 2004.

[GS+SD04]J. Greenfield and K. Short. Moving to Software Factories. http://www.softwarefactories.com/ScreenShots/MS-WP-04.pdf. Software Development Magazine, July 2004.

[HIN03]A. Hinchley. Understanding Version 3: A primer on HL7 Version 3 Communication Standard. Alexandar Monch Publishing. 2003.

[HL7V304]HL7 V3 Ballot Publication. Health Level Seven, Inc. 2004

[IHEL104]IHE Laboratory Technical Framework: Volume 1 Integration Profiles. http://www.rsna.org/IHE/tf/LabTFVol1_v1_1__FT.pdf. Integrating the Healthcare Enterprise. 2004.

[IHEL204]IHE Laboratory Technical Framework: Volume 2 Transactions. http://www.rsna.org/IHE/tf/LabTFVol2_v1_1_FT.pdf. Integrating the Healthcare Enterprise. 2004.

[MDF99]HL7 Modeling and Methodology Committee. Message Development Framework Version 3.3. http://www.hl7.org/Library/mdf99/mdf99.pdf. Health Level Seven, Inc. December 1999.

[ONA03]A. Onabajo. et. al. Wrapping Legacy Medical Systems for Integrated Health Network. http://www.netobjectdays.org/pdf/03/papers/ws-mells/544.pdf. Department of Computer Science, University of Victoria. 2003.

[TATA04]HL7 Web Services Profile Reference Implementation Guide Version 1.0. Tata Consultancy Services. 2004.

[TM03]D. Trowbridge, D. Mancini, D. Quick, G. Hohpe, J. Newkirk and D. Lavigne. Enterprise Solution Patterns Using Microsoft .Net: Version 2.0. Microsoft. 2003.

[WSA04]W3C Web Service Addressing (WS-Addressing). http://www.w3.org/TR/2004/WD-ws-addr-core-20041208/. World Wide Web Consortium (W3C) Working Draft. December 2004.

[WSB04]WS-I Basic Profile Version 1.0. http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html. Web Services Interoperability Organization (WS-I). 2004.

[WSPA04]R. Ruggeri, et. al. HL7 Web Services Basic Profile. Health Level Seven, Inc. 2004.

[WSPB04]R. Ruggeri, et. al. HL7 Web Services Addressing Profile. Health Level Seven, Inc. 2004.

[WSPR04]R. Ruggeri, et. al. HL7 Reliable Messaging Web Services Profile. Health Level Seven, Inc. 2004.

[WSPS04]R. Ruggeri, et. al. HL7 Web Services Security Profile. Health Level Seven, Inc. 2004.

[WSR04]Web Services Reliable Messaging Protocol (WS-ReliableMessaging). http://msdn.microsoft.com/webservices/understanding/specs/default.aspx?pull=/library/en-us/dnglobspec/html/ws-reliablemessaging.asp. BEA Systems Inc., International Business Machines Corporation, Microsoft Corporation, Inc, and TIBCO Software Inc. 2004.

[WSS04]Web Services Security: SOAP Message Security 1.0. http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf. Organization for the Advancement of Structured Information Standards (OASIS). 2004.

Show:
© 2015 Microsoft