페이지 이력

Following the ODP model, there are four types of Engineering Viewpoint objects: Engineering Objects (EV Objects)  Basic Engineering Objects (EV BEO), Container Objects (EV Container) and Channel Objects (EV Channel). EV Objects provide functionalities which enable BEO distribution, EV BEOs map one to one with CV objects from the CV, EV Containers are used to group EV Objects and EV BEOs, and EV Channel objects are used to connect EV BEOs across containers

Engineering Objects

An engineering object (EV object) is any object of interest in this viewpoint. For this reason BEOs, Container Objectsand Channel Objectsare also engineering objects (specialisations of). EV objects support computational requirements, distribution transparencies or infrastructure aspects of the system. The main distinction is made between BEOs, which represent computational objects ( Computational Viewpoint), and other engineering objects, whose aim is to provide basic engineering functions, such as managers, interceptors and directories

In the ENVRI RM, Computational Viewpoint are generic and can be used by any subsystem. In the EV, Computational Viewpoint can be specialisations  to better describe a fully working subsystem. In practice, RIs may already have defined their systems and the division between subsystems may not be obvious (or as strictly defined as in the RM). In this case the subsystems will be viewed as logical not physical grouping of objects. This decomposition (logical or physical) can be used to identify practical interfaces for inter-operating between subsystems in different RIs. The different types of EV Containers allow the definition of both physically distributed and logically distributed containers. Thus, subsystems can be tightly coupled or extremely loose. The definition of EV channels will depend on the distribution model selected. 

...

A Basic Engineering Object (BEO) is a special kind of Engineering Objects, which is used to give a representation of a computational object in the engineering viewpoint. The EV is concerned primarily with the engineering of machines and of network communications. Some computational objects may represent human actors, but for these there is just a simple placeholder BEO; the engineering of communication with them is a matter for HCI standardisation, but is not detailed in the reference model and so it is not discussed further here

The set of BEOs can be seen as abstractions of the computational design. The resulting description hides distinctions between objects with similar communications requirements, and retaining only the information about the computational objects that characterizes them as users of the distribution platform being provided. Therefore, the BEO is the primary object to be placed on a particular node, and which initiates communication across the network. All other engineering objects are secondary elements defined in a EV an Architectural Model (Draft), whose goal is to provide the functions necessary to support distribution. This includes a variety of supporting objects, like repositories or directories, which are drawn from a set of common functions called ODP functions ^Footnote03.

...

The engineering viewpoint language defines four types of container objects to describe the principal controlling elements involved in any engineering specification: node, nucleus, capsule and cluster

책갈피
RefFootnote04 RefFootnote04

^Footnote044. The figure to the right shows the containment relationships between containers, and engineering objects.

...

The engineering viewpoint is concerned with defining a channel architecture that represents the communication infrastructure, which allows engineering objects to interact. The basic element is the channel, which is the engineering equivalent of a computational binding. A channel consists of stubs, binders, protocol objects and interceptors, communicating Basic Engineering Objects, generally residing in different nodes

Stubs transform or monitor information in the channel. This includes, for example, the marshalling and unmarshalling of message elements, the translation of local interfaces into interoperable interface references, or provision of message content encryption. Stubs are the elements that enable access transparency in the communication between two objects written in different languages (such as C++ and smalltalk). The client object talks to its local stub, which is in charge of translating the request into a neutral format that is sent along the channel and that the server stubs understand. The received request is then translated by the server stub to the language of the server, and passed to it. The response from the server follows a similar route back to the client, with the stubs again translating the messages. The result is that the client and server objects both think that they are talking to local objects written in their own language ^Footnote05.

...

The engineering viewpoint defines a referece architecture. This Architecture is defined in three parts: the component model, and the way the components are integrated. The integration of components is defined as the node architecture and the channel architecture. The 

...

^{RefFootnote01 1}

²

^{RefFootnote03 3}

⁴

⁵