HEALTH SYSTEMS TECHNOLOGIES, INC.
APPLIED RESEARCH TEAM
PROPOSAL TO THE ACTIVEX FOR HEALTHCARE COMMITTEE
An Architecture and Framework for Healthcare Interoperability
Some three quarters of all large systems are "operational failures" that either do not function as intended or are not used at all.
The art of programming has taken 50 years of continual refinement to reach this stage.
W. Wayt Gibbs
"Software's Chronic Crisis", Scientific American, Sept. 1994
Whether or not there really is such thing as a software crisis, this much is clear: the rate of change in software perpetually lags behind the rate of change in requirements; and a software system tends to become less and less responsive to change as it ages. Object technology has been perceived by some to represent the end of legacy systems-by enabling the encapsulation and reuse of discrete sub-modules of functionality. Some object methodologists contend that object-oriented techniques lend themselves more readily to real-world depictions of the problem domain and therefore facilitate greater adherence to requirements. While object-oriented techniques provide real benefits in terms of abstraction, polymorphism, genericity, etc., which have been shown in some cases to dramatically improve the adaptability of software systems, the languages, development tools, and methodologies of object technology by and large seem to fail to address the central problem facing software engineering: that the problem domains from which requirements are derived are not closed and static, but rather open and dynamic.
Object methodologies involve the production of models and diagrams which describe a problem domain as a bounded collection of requirements which are believed to be true at a point in time. Little facility is provided for incorporating new or changed information into the static models produced by these techniques. Since a business is a dynamic and rapidly-changing system, it is not difficult to see that software developed to support a static model is doomed from the start.
Change is either planned or unplanned. Of these two, the latter presents the greatest challenge to software systems. Planned change is easy to predict-in fact, if a development team can accurately predict that a particular module will be affected by a specific change, then it is likely that enough information could have been gathered regarding that change to provide support for it in the first place. Software that is not already addressing a planned change by the time it arrives typically suffers from a lack of attention and analysis. And software that plans for a specific set of changes in the future is essentially deferring work that could technically be done today. This is not to suggest that planning for known change is in any way intrinsically bad-this is all part of a reasonable development process. Yet this fact clearly differentiates the two categories of change: the planned and unplanned.
Change which is unplanned is sometimes due to a deliberate or ignorant lack of analysis. And yet, there are many changes in a problem domain for which there existed no certain rational means of prediction. Hindsight nearly always renders such changes as inevitable (or at least predictable), and we tend to forget that hindsight provides us with a wealth of information which could not possibly have been obtained at the time a decision had to be made.
Because unplanned change of this nature is inherently unpredictable, it's impossible to state with any certainty which components in a system are more or less vulnerable change. Each component is equally vulnerable to unanticipated changes in requirements. It is futile to expect that an open and dynamic problem domain can continue to be serviced by systems which are either entirely static or which only selectively employ dynamic components. Since any component might be affected by an unplanned change, every component must be dynamically changeable.
Certainly dynamically-bound components are no panacea to the problem of software adaptability (there is no such thing as a panacea to any difficult problem). However, it seems unlikely that any progress can be made toward highly adaptable software systems without generic and system-wide support for dynamic binding.
This document proposes a framework for constructing entire applications out of dynamically-bound component parts. It is assumed that the interoperability and adaptability requirements of the healthcare informatics industry are not significantly different from the needs of software engineering in general, and as such, the framework presented here makes no specific reference to healthcare applications or components. Since the experience level with component software varies among AHC members, this document begins with the conceptual basis of the framework. Component experts will also find this overview useful, since software components have only recently entered the mainstream of software development and much of the theory behind components is still in the formative stage.
There has been significant work in component-based computing among other organizations, most notably Object Management Group's (OMG) Business Object Domain Task Force (BODTF) and CORBAmed. Since Windows DNA already implements-and will continue to implement-many of the services which are not yet standardized by these groups, it is not clear that the standards being developed by the OMG afford direct plug-and-play compatibility in a Windows DNA environment.
Our proposal begins with a brief restatement of the definition of software components, followed by a discussion of application composition. Application separation, a concept now firmly established in client/server and three-tiered computing, is examined with an eye toward its applicability to components and the applications which are composed of them. The final section introduces and describes a meta-model describing the proposed framework.
Software components are objects which have been specifically designed to plug in to a framework of other components regardless of their origin. It is still quite common to find object-oriented systems with complex and tightly-coupled interdependencies, and which assume the presence of particular implementations. Component-based systems are distinguished from these in that each component is considered an external entity which has not been designed to operate under any particular host. In contrast, object-oriented systems are frequently developed without consideration as to how those objects might be integrated into alternative host applications.
Other features commonly associated with components-such as late binding and separation of interface and implementation-are secondary attributes. What makes an object a component is a question of intent. Any object is a component if it was designed to collaborate with "foreign" components outside the owner's control.
Beyond this intent, there are a number of attributes which all components seem to manifest:
n Static encapsulation-components are self-contained, relatively fixed units of functionality. This does not mean that they contain everything necessary to use them (in fact, quite the opposite is true-components always depend on the presence of other components), but rather a component is self-contained in that it exists independently of and can be stored and managed separately from the applications in which it is used. A component is fixed in that it can be relied upon to provide a consistent set of services over time, from version to version.
n Black-box abstraction-components present an abstraction of their services to those components and applications which invoke them. This abstraction maintains an essentially opaque boundary around the software which implements it.
n Well-defined interaction protocol-the method by which services offered by a component are invoked is clearly specified and strictly enforced so that applications which invoke them can achieve predictable and reliable results. In addition, it has been argued that the services which a component requires are every bit a part of its interface and should be just as clearly defined. This is especially true when using dynamic means to bind a required service with a suitable provider.
As stated above, for a software system to adapt sufficiently to unanticipated change, it must support change in all of its components. This type of support is best implemented at a fundamental layer of abstraction.
A software system which allows every component to change is naturally composed entirely of components. The process of constructing such an application is one of configuration and assembly more than it is one of programming and compiling. The ability to assemble an application entirely out of component parts is known as application composition.
At any given moment, the scope of a composite application's functionality is determined by its configuration. Under application composition, when one component requires the services of another, it knows nothing about the component which fulfills the service-only that there is some claim that the service will perform as required. Rather than make specific reference to a particular component, the requesting component asks the framework to make the binding using a declaration of the service requirements. The requesting component merely describes the service that it needs in generic terms and the framework is responsible for resolving the request to a specific implementation. This can be as simple as a type declaration or as elaborate as behavioral type inference.
COM does not provide any common facility for configuring an application entirely out of component parts. Application development environments like Visual C++ and Visual Basic bind to specific implementations of particular interfaces using CLSID and/or ProgID. These bindings become a compiled part of the application unless the programmer manually implements a configuration scheme and provides a setting for each binding.
In order to support dynamic binding in COM, a general facility is needed which binds a generic request from a client component to a specific implementation which can satisfy the request. Specifically, this amounts to service through which a COM component supplies an IID and receives in return the CLSID of a component which has been configured as the desired implementation.
Such a facility forms the basis of a framework designed to support application composition. For an application to be completely composed, there are other requirements.
Figure 1: An Architecture for Application Composition
The application configuration must describe the component which launches at startup. This should be a component which supports an interface (e.g. - IHCCompositeApplication) which supplies a startup method and provides access to the framework. The startup component would be responsible for opening the main application window(s), if applicable, starting network event listeners, etc.
The framework must supply a set of component services which operate in the context of each composite application, and a set of framework services which operate in a global context for all composite applications across the network boundary.
The component services should include but are not limited to the following items:
n Properties-A facility which allows components within an application to ascribe properties to sibling components. Because components may be plugged in to the framework which are not aware of these services, properties should be implemented either through aggregation or by a namespace facility. Properties allow client components to attach custom data to the other components which they use.
n Privileges-A facility allowing components to check for the presence of sufficient privileges on the current account.
n Aggregation-Support for COM aggregation by implementing an Outer Unknown. This allows the composite application to extend of-the-shelf components in a configurable manner.
n Binding-The dynamic binding facility described above. For fully distributed applications in which components are stored in a central repository, the local binding facility would use the resource exchange framework service to load remote components (see below).
The framework services might include such items as the following:
n Authentication-A facility for obtaining the current user's access information, probably built on top of NT unified logon. CCOW's user context object might fit in here.
n Resource Exchange-A trading facility which allows components which require a service involving particular resource availability to find a component which can meet its requirements.
n Replica Management-A facility which allows objects distributed among many applications to refresh state and resolve conflicts when they are working on the same logical instances.
n Identity Resolution-A master index facility which allows instance data across disparate persistent stores to be resolved to a single logical instance.
n Concurrency-Optimistic/pessimistic locking at logical instance level.
n Licensing-A common facility for enforcing and metering component licenses in a distributed environment.
n Metadata Management-A central repository allowing objects to work with dynamic schema. This may also be the central repository of application configurations. This should be implemented in such a way that the central repository facilitates but is not required for application composition.
Interoperability in a compositional framework becomes primarily one of sound architecture and design. The heuristics by which functionality is separated into component parts is of utmost importance to reducing inessential complexity and maximizing adaptability. Coarse-grained components which expose only those services offered at the highest level of abstraction (e.g.-presentation) severely reduce their utility-especially in a compositional framework. As some component vendors have already learned, concealing the semantic and data management functions of their component behind an opaque wall of abstraction (stretching the concept of information hiding to its absurd extreme) severely hinders their components' ability to integrate into a host application.
Examples:
n The component manages a database of persistent data to which the host application refers. If the only access to this data is through the presentation layer, then referential integrity issues can often be insoluble or at least extraordinarily complex.
n The component displays data from two possible sources: internal volatile memory, or as a Jet Database Engine data source. The host application needs to store information that is not easily mapped to a Jet-style Recordset (e.g.-business objects) and which exceeds the limits of the component's internal volatile storage. Early grid objects had this limitation. TrueGrid eventually provided a fetch event which greatly enhanced the utility of their control.
n A control for graphical diagrams (e.g.-schematics) offers a fixed set of options for realignment, reformatting, or redraw behavior. Perhaps they neglect to consider that the client may wish to constrain nodes in a hierarchical chart to a particular left-to-right sequence. Instead, the control reorders elements at a level in the hierarchy by size. Or, the control provides no facility to constrain connectors in the diagram to horizontal/vertical vertices at 90° angles.
Each of these issues would be less likely to occur if the component vendor decomposed their component into layers of abstraction, and allowed the component user to override or extend behavior at each layer.
It is fairly well established at this point that applications have three major layers of abstraction. These are often referred to as tiers, as in a three-tiered architecture. These layers, or tiers, are:
n Data Management-the physical, long-term storage of application data.
n Business Rules/Business Process-the shared business logic of the application.
n Presentation-the interface used by agents external to the application (might be users or foreign applications).
Many developers now accept that a clean separation between these layers is part of a good application architecture. Three-tiered architecture, like traditional client/server, is a form of this separation that often implies a particular hardware configuration: Presentation belongs on the client workstation; business rules and business process on an application server; and data management in a big DBMS either running on the same server as the business logic, or on a separate server. Recent trends in web applications are challenging the separation along hardware lines. Yet even among those who recognize that presentation can run on a server and that semantics can run on a client (while maintaining proper separation), it is quite common to see application separation resulting in three large executables, each one exclusively handling a single layer of abstraction. While three-tiered applications offer significant benefits for adapting to unanticipated change, there is no need to preserve the separation of applications along hardware or executable lines when considering an architecture for application composition.
In the recent excitement surrounding the broadscale use of components in applications, some thought has been given as to the role that application separation plays in a fully component-based system. The typical assumption seems to be that componentization will result in a market for components which reside comfortably in a single layer of abstraction. In other words, it seems to be assumed that one will purchase presentation components from one vendor and combine them with business rule components from another vendor and data components from yet another vendor.
While there is good reason to believe that this may be the end result of a long process of evolution in software engineering, in reality it is unnecessary and presents a significant barrier to the widespread adoption of component-based computing.
As application vendors begin to offer component solutions derived from selected modules of their flagship applications, they will have an interest in providing more complete solutions than are typical of the current market in grid, graphical, and calendar controls. Components which provide application functionality tend to span multiple layers of abstraction-most commonly presentation and business rules. Yet data services are beginning to be introduced as outgoing interfaces-that is, an interface that the hosting application provides which allows the component access to persistent data storage. Since the component vendor defines this outgoing interface, it crosses partway into the data layer of abstraction.
If a component is expected to remain entirely within a single layer of abstraction, then application composition becomes artificially dependent on the development of widely accepted standards for interfaces outside that layer. This aggravates the network externalities already present in the market for off-the-shelf components.
Application composition begins with the application vendor. Whether there exists a market for third-party components is immaterial to the case for component-based software development. Application vendors which adopt composition as their model, even if every significant component is developed in-house, will be uniquely positioned to respond to the increasing rate of change as the 21st Century approaches. Two independently developed applications, each composed entirely of internally-developed components with proprietary interfaces, offer far greater flexibility in integration and interoperability than monolithic, two-tiered, or three-tiered applications integrated using industry standards for messaging.
This is due to two critical factors:
n Interfaces can be wrapped-If the domain model of the two applications are logically compatible, then foreign components from application A are easily accommodated by providing a wrapper which integrates the component into application B.
n Composed applications are inherently more adaptable-if the domain model of the two applications are logically incompatible, then composition allows one or both to adapt to a common logical view. If two composite applications are so logically incompatible that such a change cannot be made, then it is unlikely that they could be integrated using any other means.
The principle of application separation applies just as well to coarse-grained components which traverse several layers of abstraction as it does to entire applications. A coarse-grained component which is itself cleanly separated into presentation, business rule, and data layers of abstraction (even if by defining outgoing interfaces) is inherently suited to a compositional framework, even if its interfaces are all proprietary.
The correct decomposition of individual software components along these three major layers of abstraction is currently far more important to the widespread adoption of application composition than any standardized IDL specification for business objects.
The importance of proper separation of coarse-grained components requires that the concept of three layers of abstraction be refined and clarified. HST has been developing a theory of good separation for almost 5 years. This theory is presented below and is the basis of the framework proposed herein.
Figure 2: Three layers of abstraction, revised
Each layer of abstraction described below works with a different conceptual model of the system and its problem domain. Each layer of abstraction has a set of requirements that it enforces, and a set of requirements that it satisfies. Enforcement means that that layer does not possess sufficient information to determine how to satisfy a particular requirement. Each layer enforces a requirement by throwing an exception when it is not met. Satisfaction means that that layer possesses sufficient information to meet the requirements of the layer(s) beneath it.
We start with semantics because it is the central concept of the application, not because it is the lowest layer of abstraction. The semantic layer contains the idealized logical object model of the application and consists of universal statements and generalizations. It is positioned between the presentation and data layers.
It is common to assume that the semantic layer contains business rules and business processes which offload common tasks from the front-end for performance reasons. This confuses two completely separate issues: separation for performance, and separation for adaptability. Separation for performance decides the physical location where components will reside and execute. It is not driven by the need for good abstraction. In fact, much of the logic which is commonly implemented in stored procedures for performance reasons can often violate the principles of abstraction. Separation for adaptability does not bother itself with the physical location of components.
The semantic model is the most abstract of all three layers. It tends to bear the most resemblance to the general view business domain. It typically consists of business objects which maintain state on behalf of the presentation layer. The business objects are an idealized representation of the objects in the problem domain, and should be devoid of physical storage artifacts (e.g.-many-to-many resolution tables, foreign keys, etc.). Transactions are implemented within business object methods or stand-alone procedures which maintain semantic integrity.
This layer establishes the semantic meaning of all the things contained in the business domain, and it concerns itself only with those semantic truths which are common to all processes and tasks in the domain. As such, it consists only of verifiable truth statements, rather than task or process constraints.
n An example of a good semantic truth statement is-"a Provider must be specified in an active contract (under appropriate terms) in order to be selected by an eligible member as a PCP." This is good because it merely states one condition which must be met for a PCP assignment to have meaning. A provider which is not covered by a valid contract is not a PCP.
n An example of a rule that is not semantic is-"an authorization must start in `pending' status before it may be changed to `authorized.'" This particular state transition is not an intrinsic part of the semantic meaning of an authorization. This is a business policy which imposes a constraint on the task of obtaining authorization, not semantic meaning. It is perfectly valid to reason about an authorization with the initial state of `authorized' or `denied'.
The analysis model in Ivar Jacobsen's OOSE methodology seems to bear the most resemblance to the conceptual model of the semantic layer.
The semantic layer enforces semantic integrity. It throws exceptions when truth statements are violated by the presentation layer.
The semantic layer satisfies referential integrity and data constraints. It must be aware of the physical schema's requirements and avoid transactions which violate the requirements of the data layer.
The data layer maintains the persistent data on behalf of the semantic layer. It contains the physical storage model of the problem domain, tuned and denormalized as appropriate for performance, and provides transactional capabilities.
When stored procedures and triggers are used to enforce or satisfy semantic meaning, artifacts of the physical model tend to encroach upon the logical model of the semantic layer. This imposes artificial physical dependencies on the semantic model. Adaptability suffers as a result.
The data layer's model of the problem domain is the physical representation of persistent object data in sets, files, and/or tuples. It contains only those rules which are required to keep the data physically intact, without regard to semantic meaning.
The data layer enforces referential integrity and data constraints. It prevents the semantic layer from invoking transactions which would result in corruption or loss of the physical data.
The data layer satisfies the requirements of transaction processing: Atomicity, consistency, isolation, and durability (ACID):
n Atomicity-all actions must be completed successfully for the transaction itself to be considered successful.
n Consistency-after a transaction executes, the system and its resources are in a steady state or the transaction is aborted.
n Isolation-the effect of a transaction is not evident to other transactions until the transaction is committed.
n Durability-the effects of the transaction are permanent and should not be affected by system failures. This is also known as persistence.
It is commonly assumed that the presentation layer is the user-interface. We have found it far more useful to consider presentation to be any interface which supports the business processes, tasks, or units of work of goal-directed agents.
Since a user-interface surfaces the functionality of a system to users, supporting either their discrete tasks or the overall business process, it can be thought of as the boundary between the system and an agent-the user-which operates within a framework of goals, policies, and established procedures. When two systems collaborate on a unit of work via messaging middleware based on domain-specific protocol such as HL7, one system assumes the role of an agent. Like a user, it has goals, policies, and established procedures. Just like a user-interface, the messaging middleware is the boundary between the agent and the system. As such, domain-based messaging is a function of the presentation-layer.
Not all messaging middleware is domain specific. Messaging can be-and is-employed as a means of communication between components within a distributed application. Only when the messaging protocol itself is designed to support a particular business problem domain does it belong to presentation. Otherwise, is belongs to the framework services.
The conceptual model of the presentation layer is that of the agent. Presentation is tailored to the specific goals of the individual agent. It understands the logical model of the semantic layer and presents it in a manner which has meaning to the agent's task. It is common for the presentation layer to hide or simplify certain complexities of the semantic model, but not in a way that violates the semantic meaning. Where the semantic layer deals in universals and generalizations, the presentation layer deals with circumstances and particulars.
In a sense, presentation is the mediator between two potentially conflicting conceptual models-the shared business model (semantic layer), and the agent's particular assumptions and goals.
The presentation layer enforces workflow-based requirements and task constraints. Ultimately, it is the agent which possesses the knowledge to satisfy these requirements and constraints.
The semantic integrity enforced by the semantic layer is satisfied by the presentation layer. Presentation encapsulates the information necessary to determine how the truth statements of the semantic layer are to be satisfied in the business process.
When an individual component is separated along its layers of abstraction, it is far easier to add to a host application. By working with individual sub-components at each layer of abstraction, the host application has much greater control over a component's behavior. As a result, the component becomes a more integral part of the host.
However, separation means more than simply defining an interface for each sub-component. The manner in which a component is coupled to its own sub-components can either contribute to or detract from adaptability.
In general, components and sub-components should support aggregation, allow for external instantiation, and provide connection points for all internal state changes.
Aggregation allows the host application to extend the functionality of the component or sub-component, and to attach "riders" (i.e.-references within the host application which are dependent on the component or sub-component).
External instantiation means that the component exposes the means through which its sub-components are constructed. There are two common approaches to external instantiation: initialization properties and outgoing factory interfaces. In the former approach, the component interface exposes a property for each sub-component. The host application constructs the sub-component directly and then assigns it to the property. In the latter approach, the component interface defines a factory interface for each sub-component. Through configuration settings or properties, the host application identifies the specific implementation of each factory which should be used whenever the component needs a sub-component of a particular interface. Regardless of the approach, the component typically provides default implementations of each sub-component. External instantiation provides the host application with the opportunity to extend the sub-component's functionality via aggregation or to hook or override the sub-component's functionality via an interface wrapper.
Connection points allow the host application to detect and respond to changes in a component or sub-component's state. This is commonly used to enable, disable, or refresh presentation objects in the host application, though other types of processing like replication, synchronization, auditing, and message exchange can be triggered by such events.
The concepts and assumptions discussed above have been used to produce the framework meta-model in Figure 3. This diagram is a purely conceptual model rather than a class diagram of actual component interfaces. If the committee accepts this proposal, it is expected that specific framework component and service interfaces will be specified in a collaborative process by interested member companies. Not all of the classes depicted in the meta-model would necessarily be given a specific COM interface. For example, the subclasses of Component (except Application) are distinguished more by the role they play than by a specific interface.
For the purposes of this discussion, it is best to consider each class as a concept than as an actual software component.
Each class shown in the meta-model is described below. The following sections divide the meta-model in to sections and describe the role that each class plays within the framework.
The core of the meta-model is the abstract class Component and its subclasses (see Figure 4). With the exception of Application, each subclass of Component is distinguished less by a specific interface than by its position in the three major layers of abstraction. Every composite application consists of a hierarchical collection of Component objects, including one-and-only one Application object.
Components invoke the services of other components using the Dynamic Binding link class. It is assumed that each application has its binding information maintained in a persistent configuration store. When a given Component is first instantiated, its Dynamic Bindings are loaded from the configuration store. At this time, the framework could decide to resolve its bindings either immediately, in a background thread, or at the direct request of the Component. To resolve a Dynamic Binding, the Component invokes the Bind method of the instance which corresponds to the desired Interface (IID) and Key value (String). The Component is then given a reference to the IUnknown interface of the COM object which has been configured to answer the binding.
Each call to Bind constructs a new instance of the configured class. It is up to the Component to maintain and release the references produced by a Dynamic Binding.
Aggregation is supported by the framework. If the configured class supports COM aggregation and the Dynamic Binding's Aggregate flag is set, the Component's IUnknown is automatically used as the Outer Unknown for the binding.
The subclasses of Component are by no means limited to those shown in the meta-model; and Application is the only subclass required by the framework. The subclasses shown are merely to categorize several types of components one would be likely to see in a composite application. Each subclass is described below, from right to left:
n Application-this is the first component loaded by the framework and implements the main thread of execution. It owns the Win32 process and provides a standard set of application services to other components. Application is further described in the section on the Framework and Framework Services (below). The Application object typically has another component (typically Presentation) which is loaded at startup using Dynamic Binding.
n Presentation Component-components which surface the application to its designated agents. For GUI applications, this includes Window objects, which represent forms, controls, dialog boxes, etc. Command objects represent the main program for console applications, or handle specialized events for any application type-such as listening for data on a socket, or processing messages. Message Handler objects listen for the arrival of messages. AHC Msg Hndlr components implement IHCMessageRecipient and are invoked when an AHC message component is received for the application by the AHC Message Manager. Context Participant is included to show how a composite application might support CCOW. (The AHC Data Control represents a customized version of the standard Microsoft Data Control which allows data-aware controls to bind to any Component subclass as if it were a Jet Engine data source.)
n Business Object-objects which implement the semantic layer of abstraction. Business Object instances typically maintain application data on behalf of the presentation layer. As such, Business Objects as described in this framework are stateful objects and are not the best candidates for MTS. No assumption should be made that Business Objects must execute on a server. It is possible that scalability and overall performance are improved by retrieving Business Objects from a central repository and executing them on the client workstation.
n Query-data layer components which perform parameterized queries on application data stores. They are separated from Transactions since database read operations do not benefit much from MTS.
n Transaction-data layer components which are used by Business Objects to write instance data to persistent data stores. These components make excellent MTS components. Note that we depart from Microsoft's use of the term "business object". It is more common in the industry to find business objects defined as representations of real-world things. Yet what Microsoft calls a business object is really a stateless and atomic unit of work and bears little resemblance to anything in the real world. This framework hopes to clear up this confusion by making a clear distinction between coarse-grained, stateful Business Objects and fine-grained, stateless Transactions.
Figure 5: Properties and Connection Points
It is common for applications using a component to associate custom application-specific data to it. The meta-model indicates that every Component object may have any number of Property objects. Properties are not used by the Component to which they are attached, but rather by other Components in order to associate custom application data. This principle is similar to the ItemData property commonly found in List, Outline, and Grid controls. Properties are named units of data (Property Value) or named collections of other Properties (Property Collection). Property Values store Variants, so a Component can use them to store just about anything, including references to other Components.
The Properties described in the meta-model should not be confused with the ordinary properties implemented by COM objects. Perhaps a more appropriate name could be selected by the committee.
Components should communicate state changes using the standard COM connectable objects architecture. Each Component implements the IConnectionPointContainer interface, and one or more Connection Points. Each Connection Point implements the IConnectionPoint interface. The Component should specify a different outgoing Sink interface for each class of event it ejects.
Figure 6: Framework and Framework Services
The Framework object is the application context. It manages the resources that are shared by all composite applications, including the repository-from which configuration information and components are loaded-and the binding mechanism which uses it. Whether the Framework spawns a process into which the Application component is loaded; or whether each Application component must be implemented as an executable which connects to the active Framework, applications will share a single Framework. Since the Component objects which make up an application can be distributed across many machines, the Framework and Application instance must also be distributed-that is, each Component instance running within a particular application must share the same logical Application and Framework instances even if they execute on different computers.
The set of Framework Services cataloged in the meta-model is neither exclusive nor exhaustive. Each instance of a Framework might offer a different suite of services. Each Framework Service depicted the meta-model is described below. Each is a good candidate for an MTS Resource Manager.
n Repository-maintains each Application's configuration information, including bindings. Microsoft Repository seems like an ideal technology for thee services. However, the Repository interfaces should not mandate it.
n Binding-uses Dynamic Bindings to locate and load Component instances from the Repository.
n Authentication-user-authentication services. Various implementations might support biometrics, certificates, public keys, etc. This also maintains the security context for each running application. Windows NT unified logon and CCOW user context would likely be utilized here.
n Concurrency-optimistic and/or pessimistic locking services for persistent instances.
n Identity Resolution-indexing services, such as a Master Patient Index. Manages the resolution of identity of instance data in one persistent store to the same logical instance in another persistent store.
n Resource Exchange-a facility which allows components requiring a resource or service to barter for the most suitable provider. Load balancing is a potential use for this facility.
n Licensing-a standardized facility for managing component license agreements, particularly in a distributed environment.
n Replica Management-a facility for managing the distributed state of volatile replicas of persistent instances. An extension of the Concurrency facility, notifies other applications when one application changes the persistent state of an object for which the others are holding an in-memory replica.
Figure 7: Application
An application in this framework is a pre-configured solution to a well-defined class of business problems. It consists of a collection of Components configured together to support a particular set of business processes.
Since the Application is itself a type of Component, it is possible to conceive of extraordinarily simple applications which consist of only one component-the Application itself. In most cases, however, the Application component, upon startup, will use one of its Dynamic Bindings to construct the entry point to the application-usually a presentation component.
Each running instance of an Application supports a single authenticated agent connection. An Application, being a composite entity in this framework, is not the same as an executable-in fact, a single Application can invoke the services of Components running in the process space of many executables in a networked environment. However, while many of the application's components will be distributed, there is typically a single primary process within which the Application component will load and execute-as well as a majority of its presentation components.
As depicted in the meta-model, the Application component includes a property for command-line arguments, and a component for standard I/O (stdin, stdout, stderr). This is intended merely to indicate that the Application component should provide component-based access to the standard characteristics and capabilities of a Win32 process.
Each running Application instance maintains the context of the current User Role. User Roles are recursive-existing User Roles can be combined to define others. A User Role "inherits" the Privileges of the User Roles on which it is based. Every agent's user account has a User Role that it plays in the context of the Application. Each account's User Role is part of the Framework's configuration maintained by the Repository services. When the Authentication services verify the identity of the agent, the Framework provides the Application with the respective User Role.
Each Component can define a set of Privileged Operations. Each Privileged Operation makes up part of the Component's metadata. Privileged Operations are not necessarily identical to the methods and properties implemented by the Component. This is because the functions performed by a Component can frequently be generalized for the purposes of security-it is common for several features of a Component to be logically grouped together into a single privilege. The Privileged Operations of a Component are an integral part of its design, and are implemented during its construction. When a Component is registered with the Framework, its Privileged Operations are added to the Framework configuration repository so that they can be defined in User Roles. A User Role is defined by creating Privileges. Each Privilege grants access to a Privileged Operation of a Component.
A Component uses the Authentication services of the Framework to verify that the current agent's User Role grants the Privilege necessary to invoke a particular Privileged Operation. Such privilege checks are an integral part of the Component's functionality.
It is common for a user's privileges to apply only within a particular business context. For example, a provider may have access to view insurance benefits only for patients who have selected her as a PCP, or for which an authorization or referral has been generated; or a registration clerk at a particular clinic in a larger provider network may only verify eligibility for patients covered by health plans for which the clinic has contracted; or a administrative person at the same clinic may only create referrals for a pre-defined set of providers. In the context of a composite application, these contexts can actually be more restrictive than was anticipated by the Component designers. This problem might be addressed using subclasses of Privilege-though none are listed. This is an open issue that would need further analysis by the ActiveX for Healthcare Committee.
Achieving adaptability to unanticipated change hinges on two critical factors: applications that are composed entirely out of components (application composition), and logical separation into well-defined layers of abstraction (application separation). Interoperability is simply one dimension of overall adaptability that is served by these principles.
There need not be a market for off-the-shelf components for these principles to be successfully applied. Application vendors that adopt such a framework and approach, even if every component is developed in-house, will be far more responsive to unexpected changes in technology, languages, standards, and most importantly, requirements. The possibilities for interoperability, even if no industry standards are employed, are far greater for a composite application than for a monolithic or even three-tiered application (where each tier is a large executable with no componentization) using industry standards. Yet, perhaps ironically, industry standards for business-oriented component interfaces have far greater utility in a composite environment.
In other words, it is better to adopt a compositional architecture without industry standards than it is to adopt industry standards without composition. Naturally, the best of all worlds is support for industry standards within a compositional framework.
Since composition and separation are the critical issues hindering adaptability and interoperability, the ActiveX for Healthcare Committee should apply efforts in the following areas, ranked in order of importance:
n Principles of proper separation-the AHC should adopt a theory of application separation. The committee should implement programs that assist member companies in achieving proper decomposition and separation of their applications. This could include articles; white papers; tutorials and workshops at tradeshows; seminars; and case studies of member companies who have either successfully re-engineered their legacy applications, or have employed these techniques in their new products.
n Framework specifications-the AHC should adopt a framework for application composition. Standardized interfaces for framework components should be developed by member companies and approved by the committee. Demonstrations of composite applications built to these specifications should be developed and highlighted by the committee at tradeshows. Member companies should be encouraged to deploy and certify production applications supporting the framework components. The committee should solicit a tools vendor to productize the framework components.
n Domain-specific specifications-the AHC should leverage the work being done by standards bodies such as OMG and HL7 to develop domain information models for business object components within the framework.
n Logical compatibility with alternate frameworks-the AHC should make an effort to achieve and maintain compatibility at the conceptual level with alternative frameworks such as OMG's Common Facilities. Using wrappers, it should be possible for components developed in alternative frameworks to interoperate with components developed to the AHC framework and vice versa.
Don Box. Essential COM. Addison-Wesley, Reading, MA, 1998.
Kraig Brockschmidt. Inside OLE. Microsoft Press, Redmond, WA, 1995.
Dawna Travis Dewire. A Look at Transaction Management. In Client/Server Computing, December 1995.
Ivar Jacobson. Object-Oriented Software Engineering. Addison-Wesley, Reading, MA, 1992.
Oscar Nierstrasz and Dennis Tsichritzis. Object-Oriented Software Composition. Prentice Hall, Englewood Cliffs, NJ, 1995.
Object Management Group. Common Facilities RFP-4: Common Business Objects and Business Object Facility. Object Management Group, Framingham, MA, 1996.
Object Management Group. CORBAmed RFI. Object Management Group, Framingham, MA, 1996.
James Rumbaugh, Michael Blaha, et al. Object-Oriented Modeling and Design. Prentice Hall, Englewood Cliffs, NJ, 1991.
