4. Application Software Entity Standards

The architectural approach taken for the USIGS emphasizes the use of components-small, simple building blocks that can be assembled into more complex software entities. The use of software components has become a standard approach to building applications programs. The USIGS components within the Application Software Entity fall into two major categories (consistent with the DoD Technical Reference Model): Mission Area Applications and Support Applications. Support Applications are then subdivided into Common Support Applications, Common Facilities, and Domain Objects (or Shared Domain Services in the OGC Services Architecture).

• Mission Area Applications (subsection 4.1) are applications programs that often include a user interface and perform specific operations that are required for specific missions. These applications invoke Common Facilities, Domain Objects, and Object Services as required. On occasion, a Mission Area Application may also invoke the services of a Common Support Application. The term "Mission Area Application" relates to "Mission Application" in the DII COE architecture model and to "Application Object" in OMG's Object Management Architecture (OMA).
• Support Applications (subsection 4.2) are the second major partition within the Application Software Entity of the DoD TRM. For USIGS, this category has been further divided into:
  1. Common Support Applications (subsection 4.2.1) are application programs that often include a user interface, are used regardless of mission, and include office automation software such as word processors, spreadsheet programs, presentation authoring programs, etc. These applications invoke Common Facilities, Domain Objects, and Object Services as required.
  2. Common Facilities (subsection 4.2.2) are components that are invoked by application programs in order to provide a specific service or set of services that are of general utility. These components invoke other Common Facilities, Domain Objects, and Object Services as required. They are invoked by Mission Area Applications, Common Support Applications, Domain Objects, and other Common Facilities.
  3. Domain Objects (subsection 4.2.3) are components that are invoked by application programs in order to provide a specific service or set of services that are applicable to or within a single information domain. These components invoke other Domain Objects, Common Facilities, and Object Services as required. They are invoked by Mission Area Applications, Common Support Applications, Common Facilities, and other Domain Objects.

Thus, Application Software Entity standards refer to interfaces that are borne by components that are used to build applications, not the applications themselves. Hence, most of the discussion in this section will address interface standards for Common Facilities and Domain Objects. Mission Area and Common Support Applications will use these interfaces as required, so no specific standards are identified for them.

Figure 4-1 is a modification of the Object Management Group's (OMG's) Object Management Architecture (OMA). It depicts the software entities listed above within the context of USIGS. The distributed object bus and component interfaces enable the integration of both COTS and GOTS software components in the construction of Mission Area Applications. The distributed object bus is implemented by various commercially-available, CORBA-compliant Object Request Brokers (ORBs). The ORB provides an infrastructure allowing the various software components or objects to communicate, independent of the specific platforms, programming languages, or operating systems involved. The figure also reflects current efforts to develop a set of APIs (GIAS and GIXS) that provide open, standardized interfaces to geospatial exploitation and information access services.

Figure 4-1. OMA Applied to USIGS (a Work in Progress)

4.1 Mission Area Applications

Mission Area Applications are components that bear no interfaces, but may use services in the MCG&I domain among others. There are no specific standards for Mission Area Applications.

4.2 Support Applications

4.2.1 Common Support Applications

Common Support Applications typically have a user interface, but bear APIs for use by other components. Some, however, bear APIs in lieu of user interfaces. In these cases there may be standards for these APIs, but most are proprietary, product-specific APIs for which little more than the APIs, themselves, are published.

4.2.2 Common Facilities Standards

This subsection lists and discusses all Common Facilities that are mandated or emerging relative to the USIGS. To date, all Common Facilities identified for the USIGS have been, or are in the process of being, defined by the OMG. Common Facilities are components with generic capabilities and are not specific to any one information domain. For instance, the Printing Facility is expected to be used by all applications whether they are Mission Area or Common Support Applications. Typically, products based on Common Facilities interfaces are available as separate shrink-wrapped products or bundled with other products, such as the bundling of the Printing Facility with a printer. Table 4-1 lists the following information for each standard or specification:

• The specification name
• The specification status: 'P' designates a public specification, 'E' indicates that proposals for the specification have been submitted but none has been selected, and blank indicates that a Request for Proposals has been issued but proposals have not yet been received
• The USIGS status: 'M' designates Mandatory, and 'E' Emerging
• The date of the document containing the specification
• Relevant documents.

Standard/ Specification	Spec Status	USIGS Status	Document Date		Relevant Documents
Control and Mgmt of Audio/Video Streams	P	E	September 23, 1997 (Revision expected 4Q 1998)		OMG telecom/97-05-07 OMG telecom/97-06-04 (Errata OMG telecom/97-05-07)
Mobile Agents Facility	P	E	February 10, 1998		OMG orbos/97-10-05 (Update of Revised MAF Submission)
Meta Object Facility (MOF)	P	E	November 19, 1997		OMG ad/97-08-14 (Revised MOF Submission) OMG ad/97-09-04 (Errata to OMG ad/97-08-14) OMG ad/97-08-15 (Appendix to OMG ad/97-08-14)
System Management Facility	P	M	November 21, 1996		OMG 1995/95-12-02 (X/Open Sysman RFC Submission copyright information) OMG 1995/95-12-03 (X/Open Sysman RFC Cover pages) OMG 1995/95-12-04 (X/Open Sysman RFC Front pages) OMG 1995/95-12-05 (X/Open Sysman RFC Main text) OMG 1995/95-12-06 (X/Open Sysman RFC Index)
Common Management Facilities	P	M	September 23, 1997		Systems Management: Common Management Facilities (XCMF), Open Group CAE Specification C423
Unified Modeling Language	P	E	November 19, 1997		OMG ad/97-08-02 (UML Proposal Summary (1 of 10)) OMG ad/97-08-03 (UML Summary (2 of 10), v1.1) OMG ad/97-08-04 (UML Semantics and appendices (3 of 10), v1.1) OMG ad/97-08-05 (UML Notation Guide (4 of 10), v1.1) OMG ad/97-08-06 (UML Extension for Objectory Process for Software Engineering (5 of 10), v1.1) OMG ad/97-08-07 (UML Extension for Business Modeling (6 of 10), v1.1) OMG ad/97-08-08 (Object Constraint Language Specification (7 of 10), v1.1) OMG ad/97-08-09 (OA&D CORBAfacility (8 of 10), v1.1)
CORBA Component Model	E	E	June 27, 1997 (RFP) Nov 9 & 10, 1997 (Initial Submissions)		OMG orbos/97-06-12 (CORBA Component Model RFP, Final Version) OMG orbos/97-11-03 (Data Access Submission to Components, Scripting, and Multiple Interfaces and Comp. RFPs (combined)) OMG orbos/97-11-04 (SSA Initial Submission to the CORBA Component RFP) OMG orbos/97-11-07 (DSTC Initial Submission to the Components RFP) OMG orbos/97-11-23 (Expersoft Initial Submission to the Component Model RFP) OMG orbos/97-11-24 (Joint Initial Submission to the Components Model RFP -- BEA Systems, ICL, IONA, International Business Machines, Netscape Communications, Oracle, SunSoft, Unisys, Visigenic Software) OMG orbos/97-11-35 (Rogue Wave Revised Initial Submission to CORBA Component RFP) OMG orbos/97-12-21 (Combined Inline Software/Genesis Submission to Multiple Interfaces and Component RFPs)
CORBA Scripting Language	E	E	June 27, 1997 (RFP) July 6, 1998 (Revised Submission)		OMG orbos/97-06-13 (CORBA Scripting Language RFP, Final Version) OMG orbos/98-07-02 (Revised Scripting Language Submission)
Printing Facility	P	E	July 28, 1998		OMG orbos/98-02-12 (Errata to the Printing Facility Revised Submission) OMG orbos/98-01-05 (Xerox Revised Printing Facility Submission)
Stream-based Model Interchange		E	December 1997		OMG ad/97-12-03 (Stream-based Model Interchange Format RFP)

4.2.2.1 Control and Management of Audio/Video Streams

Description: The Control and Management of Audio/Video Streams specification addresses 12 issues:

1. Topologies for streams
2. Multiple flows
3. Stream description and typing
4. Stream interface identification and reference
5. Stream set-up and release
6. Stream modification
7. Stream termination
8. Multiple protocols
9. Quality of service
10. Flow synchronization
11. Interoperability
12. Security

This document specifies a set of interfaces that implement a distributed media streaming framework. The principal components of the framework are:

• Virtual Multimedia Devices and Multimedia device - represented by the VDev and MMDevice interfaces respectively
• Streams - represented by the StreamCtrl interface
• Stream endpoints - represented by the StreamEndPoint interfaces
• Flows and flow endpoints - represented by FlowConnection and FlowEndPoint interfaces respectively
• Flow Devices - Represented by the FDev interface.

A stream represents continuous media transfer, usually between two or more virtual multimedia devices. A stream endpoint terminates a stream. A simple stream between a microphone device (audio source or producer) and speaker device (audio sink or consumer) is shown in Figure 4-2.

Figure 4-2. A Basic Stream Configuration

A stream may contain multiple flows. Each flow carries data in one direction so a flow endpoint may be either a source (producer) or a sink (consumer). An operation on a stream (for example, stop or start) may be applied to all flows within the stream simultaneously or just a subset of them. A stream endpoint may contain multiple flow endpoints. Both flow producer endpoints and flow consumer endpoints may be contained in the same stream endpoint. There may be a CORBA object representing each flow endpoint and flow connection (i.e. the flow itself), but not all systems are required to expose IDL interfaces to these flow objects. Figure 4-3 illustrates a stream which consists of several different flow connections. Note that not all flow endpoints are involved in the stream, i.e. there may be 'dangling' flow endpoints. Note also that flows can travel in both directions within the same stream. When two stream endpoints that support separate flow endpoints are bound, a compatibility rule can be used to determine which flow endpoints connect to each other.

Figure 4-3. Stream Connection Compatibility Rules Can Allow Unconnected Flow Endpoints

A multimedia device abstracts one or more items of multimedia hardware and acts as a factory for virtual multimedia devices. A multimedia device can support more than one stream simultaneously; for example, a microphone device streaming audio to two speaker devices using separate non-multicast connections. For each stream connection requested, the multimedia device creates a stream endpoint and a virtual multimedia device.

The specification discusses each of the main IDL interfaces in detail. There are two basic 'profiles' for the streaming service:

• The 'full profile' in which flows endpoints and flow connections have accessible IDL interfaces. This profile is optimized for flexibility.
• The 'light' profile in which flows endpoints and flow connections do not expose IDL interfaces. The light profile is a subset of the full profile. It is optimized for systems that need to minimize memory footprint and the number of CORBA invocations.

USIGS Status: Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.

4.2.2.2 Mobile Agents Facility

Description: Mobile agents (also called transportable agents) are a relatively new technology that is fueling a new industry. Because the technology and the industry are new, mobile agent systems (for example, Crystaliz's MuBot, Dartmouth College's AgentTcl, IBM's Aglets, the Open Group's MOA, GMD FOKUS's JMAF/Magna, and General Magic's Odyssey) differ widely in architecture and implementation.

The differences among mobile agent systems prevent interoperability and rapid proliferation of agent technology, and has probably impeded the growth of the industry. To promote both interoperability and system diversity, some aspects of mobile agent technology must be standardized.

An important goal in mobile agent technology is interoperability between various manufacturers' agent systems. Interoperability becomes more achievable if actions such as agent transfer, class transfer, and agent management are standardized. When the source and destination agent systems are similar, standardization of these actions can result in interoperability. However, when the two agent systems are dramatically different, only minimal interoperability can be achieved.

Interoperability in this specification is not about language interoperability. Mobile Agent System Interoperability Facilities (also called MAF, an acronym for the original proposal, Mobile Agent Facility) is about interoperability between agent systems written in the same language, but potentially by different vendors and systems that are expected to go through many revisions within the lifetime of an agent. Language interoperability for active objects that carry "continuations" around is technically difficult to achieve. Furthermore, it is not needed, because the support for different languages can be replicated at each node.

This specification does not define standardization of local agent operations such as agent interpretation, serialization, execution, or deserialization. However, these actions are implementation-specific, and there is currently no compelling reason to limit agent system implementations to a single architecture.

There are several areas of mobile agent technology that the document specifies to promote interoperability:

• Agent management
• Agent transfer
• Agent and agent system names
• Agent system types
• Location syntax

USIGS Status: Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.

4.2.2.3 Meta Object Facility (MOF)

Description: The Meta Object Facility (MOF) provides a CORBA-compliant architecture for defining and sharing semantically rich metadata in distributed heterogeneous environments. This submission is intended to be a foundation for sharing metadata across the life cycle in component-based and object-oriented development.

A key goal of the MOF specification is to provide extensibility and self-discovery in systems. This goal is achievable because the MOF interfaces can be used to discover new extensions and new components that are being constantly introduced in distributed environments.

Another goal of the MOF specification is to provide the specification of rich semantics to enable two systems or applications to meaningfully share information. This goal is achieved by providing domain-specific metamodels (such as the OA&D metamodel - UML) that conform to the MOF metamodeling architecture. Note that CORBA uses the Dynamic Invocation Interface (DII) for discovery of CORBA interfaces and the proposed CORBA Component Model RFP (work in progress) also addresses the self-discovery (introspection) of CORBA components.

Similar specific mechanisms can be found in Microsoft COM and various proprietary repository and tool implementations. The MOF addresses the discovery of metadata in general, and addresses the broader issues of rich semantic metadata interoperability typical in development, data warehouse and business object environments. It is expected that discovery interfaces optimized for specific purposes (as in Java Beans) will use standard CORBA services and mechanisms, such as the MOF-to-IDL mapping in this specification, to coexist and interoperate with general MOF interfaces.

Typically, the MOF will be used for manipulating meta objects to provide integration of tools and applications across the life cycle using industry standard metamodels, such as the OMG UML. Proliferation of systems dependent on standard metadata services, such as the MOF together with industry standard metamodels such as UML, accelerates the market for component software in general and model driven component software development, because components meeting specific semantics and requirements can be discovered using the MOF interfaces. Additional work in the areas of standard metamodels for database technologies, component management and tracking, transaction discovery and legacy integration is expected in the future.

USIGS Status: Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.

4.2.2.4 System Management Facility

Description: The OMG System Management Facility is a profile of the Open Group's Systems Management Reference Model and consists of three basic components:

• Managers which implement Management Tasks and other composite management functions.
• Managed Objects which encapsulate resources. Resources are the entities within a system or network of systems that require management.
• Services which provide the X/Open System Management (XSM) Support Environment. The XSM Support Environment consists of the capabilities and interfaces that are necessary to support the other components of the Reference Model.

Usage: This specification has been mandated for use within the USIGS. However, a profile of this specification for USIGS is required.

4.2.2.5 Common Management Facilities

Description: This specification extends and contains additional APIs for the System Management Services defined above.

USIGS Status: Mandatory

Usage: This specification has been mandated for use within the USIGS. However, a profile of this specification for USIGS is required.

4.2.2.6 Unified Modeling Language (UML)

Description: The Unified Modeling Language (UML) and corresponding facility interface definition are comprehensive. However, these specifications are packaged so that subsets of the UML and facility can be implemented without breaking the integrity of the language.

The UML Semantics is packaged as shown in Figure 4-4.

This packaging shows the semantic dependencies between the UML model elements in the different packages. The IDL in the facility is packaged almost identically. The notation is also "packaged" along the lines of diagram type. Compliance to the UML is thus defined along the lines of semantics, notation, and IDL, in the following sections:

• Compliance to the UML Semantics
• Compliance to the UML Notation
• Compliance to the UML Extensions
• Compliance to the OA&D CORBAfacility Interface

Figure 4-4. UML Class Diagram Showing Package Structure

Even if the compliance points are decomposed into more fundamental units, vendors implementing UML may choose not to fully implement this packaging of definitions, while still faithfully implementing some of the UML definitions. However, vendors who want to precisely declare their compliance to UML should refer to the precise language defined herein, and not loosely say they are "UML compliant."

The UML and MOF are based on a four-layer metamodel architecture, where the MOF meta-metamodel is the meta-metamodel for the UML metamodel. As a result, the UML metamodel may be considered an instance-of the MOF meta-metamodel. This is sometimes referred to as loose (or "non-strict") metamodeling, where a M_n level model is an instance of a M_n+1 level model. Since the MOF and OA&DF have different scopes, and diverge in the area of relationships, it has not been possible to apply strict metamodeling. In strict metamodeling, every element of a M_n level model is an instance of exactly one element of M_n+1 level model. Consequently, there is not a strict isomorphic mapping between all the MOF meta-metamodel elements and the UML meta-metamodel elements. In principle, strict metamodeling is difficult (or sometimes impossible to accomplish) as the complexity of new concepts (for example patterns and frameworks) continues to increase. In any case, using a small set of primitive concepts such as those defined in the MOF, it is possibly to define arbitrarily complex metamodels. In spite of this, since the two models were designed to be interoperable, the two metamodels are structurally quite similar. Association classes are also discussed.

USIGS Status: Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.

4.2.2.7 CORBA Component Model

Description: The OMG has solicited proposals for a distributed component model based upon the OMA, and that is capable of inter-operating with other emerging component technologies, particularly the JavaBeans component model.

USIGS Status: Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.

4.2.2.8 CORBA Scripting Language

Description: CORBA Scripting Language is part of a coordinated strategy to introduce a component model into the OMA. The scripting language will be capable of scripting CORBA components.

USIGS Status: Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.

4.2.2.9 Printing Facility

Description: This facility handles management (scheduling, spooling, locating) of print servers and routing of print jobs. The printing facility is able to meet a range of printing requirements from simple documents up to high volume production printing.

USIGS Status: Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.

4.2.2.10 Stream-based Model Interchange

Description: This asks for a stream-based model interchange format (SMIF) and solicits proposals for a transfer format specification for file export/import of models, and a transfer format specification for unique identification of the version of the MOF meta-metamodel and any metamodels referenced but not included in an SMIF-compliant transfer.

USIGS Status: Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.

4.2.3 Domain Object Specifications

This subsection lists and discusses all Domain Objects that are mandated or emerging relative to the USIGS. Those of greatest concern to USIGS are those in the MCG&I domain (specifically the MCG&I domain services being defined by NIMA and the OGC). Interfaces from other information domains are listed as well, since not all operations within the USIGS are specific to the MCG&I information domain. In many cases, specifications have been developed for other information domains that may be profiled to satisfy USIGS requirements.

Table 4-2 lists the following information for each domain object standard or specification:

• The applicable domain
• The specification name
• The specification status: 'P' designates a public specification, 'E' indicates that proposals for the specification have been submitted but none has been selected, and blank indicates that a Request for Proposals has been issued but proposals have not yet been received
• The USIGS status: 'M' designates Mandatory, and 'E' Emerging
• The date of the document containing the specification
• Relevant documents

Domain	Standard/ Specification	Spec Status	USIGS Status	Document Date		Relevant Documents
MCG&I	Geospatial and Imagery Access Services (GIAS)	P	M			NIMA USIGS GIAS Specification, Version 3.2, 28 July 1998 [GIAS98]
	Open GIS Simple Feature	P	E			OGC, The OpenGIS Specification Model, Topic 5: The OpenGIS Feature, Version 3, Doc. No. 98-105, 1998
	Geospatial and Imagery eXploitation Services (GIXS)	E	E			NIMA USIGS GIXS Specification, Draft Version 0.7, 5 June 1998 [GIXS98]
Business Objects	Common Business Objects	P	E	July 27, 1998		OMG bom/98-07-14: Task and Session CBO's errata OMG bom/98-07-05: Task and Session CBOs revised Submission
	Workflow Management Facility	E	E	May 9, 1997 (RFP) March 9, 1998 (Revised Submissions)		OMG cf/97-05-06 (Workflow RFP) OMG bom/98-03-01 (Nortel Revised Submission to the Workflow Management RFP) OMG bom/98-03-04 (JFLOW revised submission -- CSE Systems, CoCreate Software, Concentus Technology, DSTC, Data Access, Digital Equipment, EDS, FileNet, Fujitsu, Genesis Development Corporation, Hitachi, IABG, ICL, International Business Machines, Oracle, Plexus, SSA, Siemens Nixdorf Informationssysteme, Xerox)
	Calendar Facility		E	December 5, 1997		OMG bom/97-12-07 (Calendar Facility RFP)
Manufac-turing	PDM Enablers	P	E	July 28, 1998		OMG mfg/98-02-01 (Errata to document mfg/98-01-01) OMG mfg/98-01-01 (Joint Revised PDM Enabler Submission)
Electronic Commerce	Electronic Payment	P	E	June 15, 1998		OMG ec/98-06-06 (Oracle/Tandem Revised Electronic Payment Submission)
	Negotiation Facility	P	E	June 27, 1997 (RFP) June 8, 1998 (Initial Submissions)		OMG ec/98-02-04 (Revised Negotiation RFP (Updated submission schedule)) OMG ec/97-06-05 (Negotiation Facility RFP) OMG ec/98-06-02 (OSM/Inline Software Joint Initial Submission to the Negotiation RFP) OMG ec/98-06-03 (Negotiation Facility CDL) OMG ec/98-06-04 (Negotiation Facility IDL)
Finance	Currency	P	E	July 28, 1998		OMG finance/98-04-01 (Errata 3.0 to the Currency Revised Submission) OMG finance/98-03-03 (Revised Currency Submission)
	Party Management	E	E	June 27, 1997 (RFP) March 9, 1998 (Revised RFP) July 6, 1998 (Revised RFP		OMG finance/97-06-04 (Party Management RFP, Final Version) OMG finance/98-03-02 (Party Management Facility Submission) OMG finance/98-07-05 (Joint Initial Party Management Submission)
Healthcare	Person Identification Service	P	E	July 28, 1998		OMG corbamed/98-02-29 (Final adopted PIDS specification including errata sheets)
	Lexicon Query Service	P	E	July 28, 1998		OMG corbamed/98-03-22 (Lexicon Query Service, final Submission)
	Clinical Observations		E	Dec 5, 1997 (RFP) May 19, 1998 (Initial Submissions)		OMG corbamed/97-12-28 (Clinical Observations Access Service (COAS) RFP) OMG corbamed/98-05-05 (Initial Clinical Observations RFP Submission, update with minor editorial changes)
	Healthcare Resource Access Controls		E	February 13, 1998 (RFP)		OMG corbamed/98-02-23 (Healthcare Resource Access Control RFP)
	Healthcare Data Interpretation		E	April 3, 1998 (RFP)		OMG orbamed/98-03-30 (Health data Interpretation Facility RFP) OMG corbamed/98-03-29 (Health Data Interpretation Facility RFP, abbreviated version)
Telecommunications	Notification Service	P	E	July 28, 1998		OMG dtc/98-04-01 (Errata #2 to the Notification Service) OMG telecom/98-03-05 (Errata to Telecom Joint Notification Submission (telecom/98-01-01)) OMG telecom/98-01-01 (Revised Joint Notification Service Submission)
	Telecom Log Service		E	February 13, 1998 (RFP) July 6, 1998 (Initial Submission)		OMG telecom/98-02-11 (Telecom Management Log Service RFP) OMG telecom/98-07-01 (Joint Telecom Log Service Initial Submission); Expersoft, Hewlett-Packard, Nortel, Telefonica, I+D

4.2.3.1 Geospatial and Imagery Access Services (GIAS)

Description: The Geospatial and Imagery Access Services (GIAS) specification defines the core interfaces of the United States Imagery and Geospatial Information System (USIGS) libraries for client access to geospatial information. USIGS has a common information management framework that enables sharing of data, services, and resources among IGC members and their consumers. The GIAS provides client access, which includes search, discovery, browsing, and retrieval of information and its associated meta-data. Geospatial information is defined to include imagery and imagery-based information, maps, charts and any other data that has a well-defined association with a point or area on the Earth.

The GIAS specification defines, through the use of OMG IDL, the interfaces, data types and error conditions that represent a geospatial information library. A GIAS-based geospatial library has interfaces that allow a client to search and discover information (data sets/products) contained in the library, inquire about details of a particular data set/product and arrange for the delivery of the data set/product to another location or to another system. Also provided are interfaces to allow a client to nominate information to be included in the library. There are also interfaces to allow library-to-library interchange of information as well as interfaces that support management and control of the client-library interactions.

USIGS Status: Mandatory

Usage: The definitions and semantics associated with the elements of the GIAS specification are intended to be as general and as broadly useful as possible. It is not intended to be a description of any single implementation or system but is intended to allow great latitude in the design and implementation schemes for geospatial libraries. However, to ensure interoperability, all systems that must interoperate must make the same interpretations concerning this general specification. A profile of the GIAS specification for the intended community of use is a critical supplement to the GIAS specification itself. A profile is a formal documentation of the specific interpretations, limits, and conventions chosen by the community of use. The USIGS community will be producing profiles of the GIAS specification that document these factors.

4.2.3.2 Open GIS Simple Feature

Description: The purpose of this specification is to provide interfaces to allow GIS software engineers to develop applications that expose functionality required to access and manipulate geospatial information comprising features with 'simple' geometry using OMG's CORBA technology. It is envisaged that this specification will become a candidate for inclusion in the OMG's work as a vertical CORBAfacility covering geospatial information management.

In the design of this specification, the approach has been to use, where possible, existing CORBAspecifications to allow leveraging of the past and present efforts of OMG and vendors of other CORBA compliant products and specifications. Where it has been deemed inappropriate, alternative specifications have been developed that follow as closely as possible existing CORBA specifications.

USIGS Status: Emerging

Usage: The specification is broad enough to allow maximal flexibility in implementation. In particular, it has been designed with two implementation models in mind:

• The exposure of existing (legacy) geospatial data and applications whether they be RDBMS or proprietary file repositories through some form of object 'wrapping'.

• The development of new distributed object-oriented GIS applications.

This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time.

4.2.3.3 Geospatial and Imagery eXploitation Services (GIXS)

Description: The GIXS is an emerging suite of standard interfaces to geospatial exploitation services. These services can be broadly described as those currently provided by GOTS software packages such as JMTK, RULER, and FPE. Functional areas include image processing/exploitation (e.g. mosaicing and registration), mensuration and geopositioning, and geospatial analysis (e.g. line-of-sight analysis, terrain masking, and mobility analysis). The intent is to broaden this suite of APIs to address access to other geospatial services that are not currently offered by commercial software packages.

USIGS Status: Emerging

Usage: While the GIXS is still emerging, its use for access to geospatial services is strongly encouraged. The GIXS will serve as a migration path from the current interfaces associated with JMTK, RULER, and FPE. The USIGS Interoperability Profile (UIP) Working Group is working to mature the GIXS in coordination with on-going USIGS development programs. Contractor/developer participation in this maturation process ensures a viable interface that meets the needs of the IGC. A profile of the GIXS specification for the intended community of use is a critical supplement to the GIXS specification itself. A profile is a formal documentation of the specific interpretations, limits, and conventions chosen by the community of use. The USIGS community (facilitated by the UIP Working Group) will be producing profiles of the GIXS specification that document these factors.

4.2.3.4 Common Business Objects

Description: Common Business Objects (CBOs) represent the obvious objects and relationships in the end user view of a distributed system. End users are the people that directly interact with the system. The Task and Session Model, which is the first CBO specification, does the following:

• Defines common objects for people, using (with some specialization) separately defined models; e.g., organization models
• Specifies common place objects that contain distributed and heterogeneous resources<
• Defines objects that represent atomic units of work used by synchronization rules for managing parallel activity and resource sharing
• Defines a common user model with people, places, resources, and processes

USIGS Status: Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.

4.2.3.5 Workflow Management Facility

Description: The Workflow Management Facility defines interfaces and their semantics required to manipulate and execute interoperable workflow objects and their metadata. The Workflow Management Facility will serve as a high-level integrating platform for building flexible workflow management applications incorporating objects and existing applications. This solicits proposals for the Workflow Management Facility.

USIGS Status: Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.

4.2.3.6 PDM Enabler

Description: PDM Enabler interfaces establish standards for the services provided by Product Data Management (PDM) systems. These interfaces made available through ORBs provide the standard needed to support a distributed product data management environment as well as providing standard interfaces to differing PDM systems.

USIGS Status: Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.

4.2.3.7 Calendar Facility

Description: The CORBA Calendar Facility that will allow applications to incorporate calendar services. Users should be able to manage calendars by adding, updating, and deleting calendar items; users should be able to perform queries on calendars; and users should be able to maintain metadata such as rules and alarms. Users should also be able to coordinate between many calendars.

USIGS Status: Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.

4.2.3.8 Electronic Payment Facility

Description: The Electronic Payment facility interfaces are an Object Framework that supports the implementation of industry standardized electronic payment protocols in an OMA-compliant system and specifications for one or more industries payment protocols.

USIGS Status: Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.

4.2.3.9 Negotiation Facility

Description: The Negotiation Facility enables multiparticipant negotiation and an object framework supporting dynamic negotiation rule substitution, rule verification, and interfaces through which domain policy can be used to control the disclosure of information and the decisions taken during the course of negotiation.

USIGS Status: Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.

4.2.3.10 Currency Facility

Description: Currency Facility supports the definition and management of currencies. This is distinct from "money," which is an amount of one or more currencies. This facility will address currency representation, currency validation, and money algebra.

This document contains the specification of a set of business objects and related abstractions that support international currency as defined in the OMG's Currency Request for Proposal (OMG Document: finance/96-09-04). The specification describes the objectives and business requirements for each object or component. It then presents the complete specification and reviews compliance to the stated requirements.

The business abstractions defined in the specification include:

• a currency component
• basic business objects for currency, money, and exchange rate
• calculation and formatting mechanisms for the use of money

USIGS Status: Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.

4.2.3.11 Party Management Facility

Description: This RFP solicits proposals for specifications for the common features of a Party Management Facility for the Financial Service Industry. These facilities are part of systems that are commonly known as Client or Customer Information Systems.

USIGS Status: Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.

4.2.3.12 Person Identification Service

Description: The Person Identification Service (PIDS) functionality is under severe demands for integration with other clinical and financial information systems, but it must integrate with these systems without coupling with them. These paragraphs delineate the scope of the PIDS specification by explicitly identifying those problems that are addressed by the PIDS. The PIDS addresses the following specific problems.

Identification

The PIDS directly supports the identification of people currently receiving care in a specific venue and ID Domain, and will support identification in the face of highly incomplete identifying information.

ID Correlation

The PIDS supports both manual and automated correlation of IDs and records associated with health care consumers that have received care in different settings, and will address the problems of correlating IDs among the ID Domains of highly autonomous and frequently-reorganizing entities.

Patient Confidentiality

While the PIDS itself is not required to enforce confidentiality, its interfaces are delineated so that "request interceptors" (implemented by CORBA Security Services or otherwise) can enforce any policy that is defined in terms of:

• the user's identity
• the person identity that is the target of the information request
• the ID Domain(s) involved, and
• the person traits requested

Thus it will become reasonable to expect and demand that PIDS implementations compete on the basis of their abilities to enforce complex or individualized confidentiality policy and to protect person information from inferential analysis.

USIGS Status: Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.

4.2.3.13 Lexicon Query Service

Description: The focus of the Lexicon Query Service specification is to define a set of common, read-only methods for accessing the content of medical terminology systems. What constitutes a medical terminology system can vary widely, from a simple list consisting of a set of codes and phrases at one extreme, to a dynamic, multi-hierarchy classification and categorization scheme at the other. The focus was on determining what could be construed to be "common" elements of terminology systems. "Common" in this case means the set of elements in which the semantics are fairly widely accepted, even though they may not be present in all or even many of the terminology systems available today. Our goal was to produce a specification that could be used to implement a reasonable and useful interface to any of the major medical coding schemes.

A key goal of this specification is to provide a single, agreed-upon way to ask a given question of a terminology system. Terminology systems may vary radically in their forms of representation and access. For example, the question "Is penicillin an antibiotic?" could be presented to one system in the form "Does there exist a subtype relationship in which the concept code for antibiotic is the supertype and the concept code for penicillin is the subtype?" In another system, the question may be presented as "Is there a record in the drug database whose key is 'penicillin' that has the value of 'Yes' in the antibiotic column?" The intention of this specification is to provide only one specific interface that may be used to answer any given question, regardless of the underlying implementation. While this may increase the complexity of some implementations, we believe that this approach will greatly simplify the process of writing terminology clients.

The primary guide in the formulation of this specification was the set of requirements specified in the Lexicon Query Service RFP. The RFP was deliberately limited to requesting read-only services, in the belief that read access was the most immediate, feasible, and pressing need. In the specification there is further subdivision of read-only services into two categories:

• High volume on-line services. These services are used by an on-line production system. The services include translation, inference, presentation, and the like.
• Perusal and browsing services. These services are used occasionally as a means of understanding the content and structure of the specific terminology.

The primary focus of this specification is the first category of services, the high volume on-line type of service. It was believed that the immediate needs rested within that specific area, and that was the area that contained the most commonality and was the best understood. Perusal and browsing services were addressed only as necessary to satisfy specific RFP requirements.

USIGS Status: Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.

4.2.3.14 Clinical Observations Facility

Description: Examples of clinical observations include the following: laboratory results, vital signs, subjective and objective observations and assessments, observations and measurements provided by a specialist who interprets images and other multi-media data. Interoperable specifications that support the activities involved in accessing clinical observations are sought. The specifications should leverage existing standards such as HL7 and DICOM.

USIGS Status: Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.

4.2.3.15 Healthcare Resource Access Controls Facility

Description: This solicits proposals for resource access control facilities based on the CORBA Security service. Such a facility will provide a uniform way for application systems to enforce resource-oriented access control policies in the healthcare domain.

USIGS Status: Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.

4.2.3.16 Healthcare Data Interpretation Facility

Description: This solicits proposals for a Healthcare Data Interpretation Facility (HDIF) that will provide a general-purpose infrastructure capable of the following:

• accommodate a variety of intelligent transforms for clinical data
• enable easy integration of so-called intelligent systems into existing healthcare information systems
• provide common interfaces for performing intelligent transforms on healthcare data distributed across disparate healthcare data domains.

USIGS Status: Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.

4.2.3.17 Notification Service

Description: This solicits proposals for a service which extends the capabilities of the OMG Event Service to support filtering capability, a service which satisfies scalability demands of event-driven applications running within large, distributed, heterogeneous networks, a service which satisfies event management demands of distributed systems, network, and telecommunications management applications, and a specification of notification types and contents applicable to particular vertical domains.

USIGS Status:Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.

4.2.3.18 Telecom Log Service

Description: The purpose is to solicit proposals for a CORBA-based Log Service that is similar to that provided by Log Control Function (LCF). This Log Service, in addition to support CORBA objects in a pure CORBA environment, is to be used by TMN systems via gateway function as well.

USIGS Status: Emerging

Usage: This specification has not been specifically profiled for use in USIGS. Therefore, the specification has not been mandated at this time. Use of this specification is encouraged, however.