Open-system environment reference model

Open-system environment (OSE) reference model (RM) or OSE reference model (OSE/RM) is a 1990 reference model for enterprise architecture. It provides a framework for describing open system concepts and defining a lexicon of terms, that can be agreed upon generally by all interested parties.^[1]

This reference model is meant as an environment model, complementary to the POSIX architecture for open systems. It offers an extensible framework that allows services, interfaces, protocols, and supporting data formats to be defined in terms of nonproprietary specifications that evolve through open (public), consensus-based forums.^[2] This reference model served in the 1990s as a basic building block of several technical reference models and technical architectures.

In 1996 this reference model was standardized in the ISO/IEC TR 14252 titled "Information technology -- Guide to the POSIX Open System Environment (OSE)".^[3]

YouTube Encyclopedic

1/3
Views:
192 283
5 185
1 351 472

Transcription

This is a model called the tragedy of the commons. Which should be called the problem with open access, since it has little to do with a commons. And tragedy is a kind of dramatic. Let's say there's some land with grass on it that people use as pasture for their animals. Nobody owns it and anyone can come and graze their livestock here. We're assuming that people don't communicate or work together. So we would call this an open access field. Let's assume the number of animals this field can feed is based on the quantity and quality of the grass, which is based on the health of the soil and it can only hold this many animals. This is the carrying capacity. If animals are added beyond this, the grass can't re-grow fast enough to support them all. Also the grass protects the soil from erosion. If too many animals are around eating the field may decline in productivity lowering the carrying capacity. The animals will be less healthy and provide lesser quality products lowering the profit each animal provides. So it's in this group's best interest to keep the number of animals on the field at or below the carrying capacity. But every herdsman that puts animals on the field will get the direct benefit that that animal provides for them. But they would only share a portion of the costs of the degraded field. If the field were at carrying capacity and a herdsmen decides to add an extra animal. The added animals takes some of the food that would have gone to the others. This reduces their value. The owner of that additional animal comes out ahead because even though all his animals also are less healthy, he has more of them. But each herdsmen acts under these incentives and will keep adding animals to their herd or let their animals graze longer, so long as it's profitable to themselves. But really they are all losing out. Kind of like the prisoner's dilemma. Contrast this to a situation where one person owns it. If they add extra animal, they're only hurting themselves so they don't do it. Since new people can't be excluded from using the field, there's almost no point in boycotting use because someone else could just come in. None of the herdsmen own the field and they can see the field may not be around forever. They see no point in conservation and just try to use it before someone else does. OK so we go on to can apply this model to unregulated open access fisheries, open access forests, an unregulated college dorm dish sink. But the problem with applying this model to the real world, is that we have to assume, among other things, that people don't communicate or work together. Which isn't true.... With a field like this, people will generally get together and make plans together and make plans about its use. They may act as a single unit, or just partition it sections, and they'll regulate the number of people that can use it. And if people are working together and communicating then it's not really open access. It's not like every management situation is open access until somebody does something about it. So you don't tend to see the open access problem because people don't work together. You tend to see it in situations where people can't work together. The open access problem tends to appear not where people don't communicate or don't work together, but where they can't communicate or can't work together. Sometimes people are forced into a situation where they're not allowed to work together. Check out this video. Also the larger the management area is the more difficult communication and influencing each other becomes. For example the global management of greenhouse gas emissions tends to take on some open access properties. Basically this model is a way of communicating that: when people can't work together on a resource you call it open access... and it's bad. Which is why the model should have been called, the problem with open access. This episode is brought to you by, Hardin's canned animal meat. Now orphan free.

History

The development of the open-system environment reference model started early 1990s by the NIST as refinement of the POSIX (Portable Operating System Interface) standard. POSIX is a standard for maintaining compatibility between operating systems, and addresses interoperation for communications, computing, and entertainment infrastructure. Its development started late 1980s by the POSIX Working Group 1003.0 of the Institute of Electrical and Electronics Engineers (IEEE).^[1]

The NIST hosted workshops and conducts other support activities to assist users in addressing open systems requirements, preparing for the use of new technology, and identifying the international, national, industry and other open specifications that are available for building open systems frameworks, such as the government's applications portability profile for the open-system environment.

NIST sponsors the semiannual Users' Forum on Application Portability Profile (APP) and Open System Environment (OSE) to exchange information and respond to NIST proposals regarding the evaluation and adoption of an integrated set of standards to support the APP and OSE. The quarterly Open Systems Environment Implementors' Workshop (OIW), co-sponsored by NIST and the Institute of Electrical and Electronics Engineers (IEEE) Computer Society, provides a public international technical forum for the timely development of implementation agreements based on emerging OSE standards.^[4]

OSE/RM topics

The open-system environment (OSE) forms an extensible framework that allows services, interfaces, protocols, and supporting data formats to be defined in terms of nonproprietary specifications that evolve through open (public), consensus-based forums. A selected suite of specifications that defines these interfaces, services, protocols, and data formats for a particular class or domain of applications is called a profile.^[1]

Two types of elements are used in the model: entities consisting of the application software, application platform, and platform external environment; and interfaces including the application program interface and external environment interface.

APP service areas

The Application Portability Profile (APP) is an OSE profile designed for use by the U.S. Government. It covers a broad range of application software domains of interest to many Federal agencies, but it does not include every domain within the U.S. Government’s application inventory. The individual standards and specifications in the APP define data formats, interfaces, protocols, or a mix of these elements.

The services defined in the APP tend to fall into broad service areas. These service areas are:^[1]

Operating system services (OS)
Human/computer interface services (HCI)
Data management services (DM)
Data interchange services (DI)
Software engineering services (SWE)
Graphics services (GS)
Network services (NS)

Each service area is defined in the following sections. The figure illustrates where each of these services areas relates to the OSE/RM. Assume that software engineering services are applicable in all areas. Each of the APP service areas addresses specific components around which interface, data format, or protocol specifications have been or will be defined. Security and management services are common to all of the service areas and pervade these areas in one or more forms.^[1]

Classes of interfaces

There are two classes of interfaces in the OSE reference model: the application program interface and the external environment interface:^[1]

Application programming interface (API) : The API is the interface between the application software and the application platform. Its primary function is to support portability of application software. An API is categorized in accordance with the types of service accessible via that API. There are four types of API services in the OSE/RM:
- Human/computer interface services
- Information interchange services
- Communication services
- Internal system services
External environment interface (EEI) : The EEI is the interface that supports information transfer between the application platform and the external environment, and between applications executing on the same platform. Consisting chiefly of protocols and supporting data formats, the EEI supports interoperability to a large extent. An EEI is categorized in accordance with the type of information transfer services provided.

OSE profile

A profile consists of a selected list of standards and other specifications that define a complement of services made available to applications in a specific domain. Examples of domains might include a workstation environment, an embedded process control environment, a distributed environment, a transaction processing environment, or an office automation environment, to name a few. Each of these environments has a different cross-section of service requirements that can be specified independently from the others. Each service, however, is defined in a standard form across all environments.^[1]

An OSE profile is composed of a selected list of open (public), consensus-based standards and specifications that define services in the OSE/RM. Restricting a profile to a specific domain or group of domains that are of interest to an individual organization results in the definition of an organizational profile.^[1]

OSE reference model entities

The three classes of OSE reference model entities are described as follows:^[1]

Application software : Within the context of the OSE Reference Model, the application software includes data, documentation, and training, as well as programs.
Application platform : The application platform is composed of the collection of hardware and software components that provide the generic application and system services.
Platform external environment : The platform external environment consists of those system elements that are external to the application software and the application platform (e.g., services provided by other platforms or peripheral devices).

Types of information transfer services

There are three types of information transfer services. These are transfer services to and from:^[1]

Human users
External data stores
Other application platforms

In its simplest form, the OSE/RM illustrates a straightforward user-supplier relationship: the application software is the user of services and the application platform/ external environment entities are the suppliers. The API and EEI define the services that are provided.^[1]

Applications

Basically, the open-system environment model is a basic building block of several technical reference models and technical architecture. A technical architecture identifies and describes the types of applications, platforms, and external entities; their interfaces; and their services; as well as the context within which the entities interoperate.

A technical architecture is based on:

a Technical Reference Model (TRM); and
the selected standards that further describe the TRM elements (the profile).

The technical architecture is the basis for selecting and implementing the infrastructure to establish the target architecture.^[6]

A technical reference model can be defined as a taxonomy of services arranged according to a conceptual model, such as the Open System Environment model. The enumerated services are specific to those needed to support the technology computing style (e.g., distributed object computing) and the industry/business application needs (e.g., Human Services, financial). ^[6]

References

This article incorporates public domain material from the National Institute of Standards and Technology

^ ^a ^b ^c ^d ^e ^f ^g ^h ⁱ ^j ^k ^l Joseph I. Hungate et al. (1995) "Conference Report: Application Portability Profile and Open System Environment Users Forum Gaithersburg, MD May 9–10, 1995" in: Journal of Research of the National Institute of Standards and Technology. Volume 100, Number 6, November–December 1995
^ ACM Sigsoft (1993) 15th International Conference on Software Engineering, May 17-21, 1993. p.349
^ Wolfgang Kresse, Kian Fadaie (2004) ISO Standards for Geographic Information. p.72
^ STANDARDS FOR OPEN SYSTEMS: MORE FLEXIBILITY FOR FEDERAL USERS NIST Bulletin 1996. Accessed 13 Dec 2008.
^ Department of Defense (1996). Technical Architecture Framework for Information Management. Vol. 2. April 1996
^ ^a ^b Consolidated Definitions and References at acf.hhs.gov. Accessed 12 Dec 2008.

From Wikipedia, the free encyclopedia