ODP viewpoints provide a framework for specifying ODP systems. They are not of concern to end users (viewpoints have nothing to do with the end users view of a system: transparencies provide this). The viewpoints of ODP-RM have two main uses: firstly, as a framework to specify other ODP component standards; and secondly, ODP viewpoints are a useful framework for system development, whether the system is an ODP system or not. ODP is therefore worthy of study, even if you have no interest in distributed systems at all, as viewpoints are widely applicable, and deal with many issues that arise in the development of any system.
ODP provides five viewpoints, which together provide the necessary and sufficient means to specify complete systems. While specifications between viewpoints should be consistent, there should be a minimum of redundant information. You should note that viewpoints provide neither a methodology, nor a notation, they are merely a framework, and as such there are several possibilities for methodologies and notations.
The five ODP viewpoints enable separation of concerns, which means that each viewpoint can focus on the details which are of concern to it, and ignore the details of the other viewpoints. This is the basis of abstraction in system design. On the other hand, the viewpoints are used to describe the same system, and therefore cannot be descriptions that are contradictory; the viewpoint descriptions must be consistent, as they are describing different aspects the same thing, or the same thing in different ways. We thus identify how the viewpoints should correspond. Separation of concerns and viewpoint correspondences are really two sides of the same coin.
Generally, separation of concerns can be supported by methodologies, while viewpoint correspondences can be used by tools to automatically derive elements of one viewpoint description from another. This can be done in either direction: in the forward direction the process is generally compilation, in the reverse direction we have reverse engineering.
The five ODP viewpoints are as follows:
Each viewpoint uses a viewpoint language to develop a viewpoint specification. For example, the enterprise viewpoint uses an enterprise language to develop an enterprise specification. The viewpoints are also not layers such as those in the OSI reference model. The ODP viewpoints are also necessary and sufficient for system specification. This is in contrast to OSI, where many people question whether seven layers are really necessary, or whether this was only done in order to compete with SNA. The relationship between the ODP viewpoints can be pictured in an number of ways. Figures 4.1 and 4.2 are two such ways that the viewpoints can be related.
Figure 4.1
Figure 4.2 shows a slightly different arrangement of the viewpoints. You can picture the relationship between the viewpoints in whichever has the most meaning for you.
Figure 4.2
The rest of this section gives the details of the five ODP viewpoints.
The enterprise viewpoint defines the basic objectives of a system. Using the enterprise viewpoint, you define the purpose and scope of the enterprise and policies which define permissions, obligations, prohibitions that apply to a system, and policies that relate to interactions of the enterprise with the external environment, or environment contracts.
An enterprise could be anything. The common example is a bank as this is an institution just about everybody has an experience of, but the enterprise viewpoint can be used to specify more technical entities such as database systems, mail systems, file systems, operating systems, ODP/CORBA Trader or enterprises such as schools, universities, small businesses, non-profit organisations, telephone companies, chair lift services. The scope of the enterprise concept is very broad.
The enterprise viewpoint also observes roles within the system, and defines how those roles behave according to the policies. These roles define basic objects that will be in the system, for example, a bank teller (whether a person or ATM) has a role of serving customers according to the policies of the bank. Activities are also identified, for example create an account for a new customer, deposit and withdraw funds. These activities must also be subject to the banks policies.
Policies may be internally defined by the bank, such as how they serve customers, that is processes. Policies may define business benefits and obligations for both the bank and customer, for example only customers may withdraw money, and only if they have a positive account balance, or credit card transactions may entitle the customer to frequent flyer points. Such policies are set internally by the bank, but policies may also be defined externally to the enterprise, which are environment contracts such as government laws or rules set by regulatory bodies, safety rules, industry agreed codes of practice.
Communities will also be identified. These will be groups of objects or roles which together perform some objective. For example, a bank branch is a community of branch manager, loans manager, customer relations manager, tellers (both automatic and people.)
Federations are also identified in the enterprise viewpoint. Different banks might decide that they want to federate so that customers from each bank may use a combined ATM network. Note that federations may themselves be made up of several enterprises that have their own enterprise specifications. An issue with federation is which roles, policies, activities and communities from each federating enterprise become visible in the federated enterprise, and how to resolve differences between these. This turns out to be a more difficult problem than you might think: just consider the number of management negotiations, the policies and laws set by governments about this issue!
While distribution should not generally be specified in the enterprise viewpoint, there may be policies that stipulate distribution, for example our bank might wish to keep parallel systems working in different cities in case of a power outage or some such other catastrophe in one location.
The enterprise viewpoint corresponds to the other viewpoints in a specification, as the other viewpoints must satisfy the policies defined in the enterprise viewpoint. Some of the roles, communities, activities, etc., identified in an enterprise specification will probably have direct correspondences in the information and computational viewpoints. For example, enterprise activities relate to dynamic schemas in the information viewpoint, which in turn relate to the actions and interactions of computational objects. Communities and roles within the communities will relate to security domains and securities profiles within those domains.
The information viewpoint defines the semantics of information and semantics of processing on information in the system. This is done using three schema: the invariant schema, the static schema, and the dynamic schema.
The invariant schema defines conditions that must always be true on a set of information (state of an object). For example, the balance in a bank account might always have to be greater than zero.
The static schema defines conditions that will hold after certain events have occurred. For example after initialisation, an object must satisfy certain initial conditions, or a computer processor after a system reset will satisfy conditions such as all registers are zero. Such events are not part of the usual processing of an object, and as such the entity is forced into a particular state satisfying a static schema. All static schema must satisfy the invariant schema.
The dynamic schema defines transformations (state changes) that can occur on the state of an object in the course of normal processing, in contrast to a static schema, which forces an object into certain states. Dynamic schema define preconditions for operations to occur and the postconditions that must result after an operation. The results of such state transformations must also satisfy the invariant schema. The dynamic schema also define a contractual basis for operation invocation, as it defines what the client must provide, and what the server will accomplish in return.
Dynamic schema can cover many conditions. For example a withdrawal on a bank account may only occur if the balance is greater than zero, and if the daily limit has so far not been exceeded for the day, and if this condition is fulfilled, the account balance must be reduced by the amount withdrawn. Other examples are that the square root of a REAL may only be taken if the REAL is non-negative; an array element may only be accessed if the index is within the current bounds of the array; the top element of a stack may only be accessed if the stack is not empty; a program must not contain syntax errors if code is to be generated. Dynamic schema can also constrain transformations, for example the marital status of a single person may not be changed to divorced or widowed.
The information viewpoint must conform to the policies of the enterprise viewpoint. Some roles, activities and behaviours identified in the enterprise viewpoint should correspond to the schema definitions in the information viewpoint. For example, policies may become constraints in any of the schemas. Roles and activities may relate to dynamic schema statements. Some of these may be objects that are visible in the computational viewpoint. The information viewpoint will define constraints that must be satisfied by the engineering viewpoint. Since ODP-RM does not mandate these correspondences, they can easily be defined in some methodology, and automatically transformed from an enterprise specification to an information specification, without the need for redundancy. Also as modifications are made to statements in an enterprise specification, these can be automatically applied to an information specification, without the need for rework. A smart tool will check for consistency with previously existing statements, rather like a compiler detects syntax errors, only in a much more sophisticated manner.
The computational viewpoint enables specifications which define functional decomposition of a system into objects which interact at interfaces. ODP defines three different kinds of interfaces which are used for different purposes: operation interfaces, stream interfaces and signal interfaces.
An operation interface is an interface where all interactions are operations. This is the most familiar to programmers as routine calls. ODP distinguishes two kinds of operation, the interrogation which is a function which returns a result, and an announcement, which just invokes an operation with no result. An interrogation suspends the caller which waits for the result to be returned. An announcement does not necessarily suspend the caller, and the caller and server can execute in parallel until further synchronisation.
Operations are defined by signatures, which include the operation name, the causality, that is whether it is the client (calling) signature, or server (called) signature, the number, names and types of parameters, and in the case of interrogation a set of termination types which contain the number, names and types of the termination parameters. The signatures of the client and the server must be complementary; the server must be able to respond to all operations that the client can invoke (that is the client signature specifies a subset of all operations that the server can respond to), the server must be able to receive all parameters that the client sends, that is the client parameter types must be subsets of the types the server can receive, and in the case of returned parameters, the client must be able to receive all types that can be returned, that is the specification of the return types in the server signature must be a subset of those that the client can receive.
A stream interface is an interface where all interactions are flows. Streams carry data such as multimedia video and audio flows. Streams may also be used for file transfers. Streams have signatures which include the name of the flow, the causality, that is if the signature is the producer (sender) or consumer (receiver), and the type of the information transferred.
Again producer and consumer signatures must be complementary. The consumer must be able to receive at least as many types as the producer can send, that is the types that the producer can send must be a subset of the types that the consumer can process. For example, in document transfer, a producer might be able to send text or postscript formats. This means that the consumer must be able to handle at least text and postscript, but may also be able to handle rich text format (RTF). If the server is replaced by an improved service, then it should be able to handle more types, for example it might add Adobe's PDF format to documents it can receive. The mechanism where a server increases its capabilities is known as contravariance.
It would be inappropriate for ODP stream interfaces to specify anything about who initiates a stream interaction, you should note that the initiator does not relate to who is the producer or consumer. In the above example, the producer initiates the transfer, as a client sends data to a service for processing. This is commonly becoming known as push. However, a consumer can also initiate the interaction, for example you might load a document from the WEB. This is commonly becoming known as pull. Note that push/pull is used here as an example, it is not a part of ODP terminology or concepts.
Yet another scenario is that the interation could be initiated by a third party, who represents neither the producer or consumer. So it is important to realise that the terms push/pull, producer/consumer, client/server do not necessarily correspond, hence ODP identifies only producer and consumer in stream interfaces, but these can be used to specify the kind of interaction applicable to your application.
In the pull case it is best for the producer to offer a variety of format types, and you can choose one that you know you can view or print. In this case a producer might improve its service by offering a greater variety of document types. This is again contravariance, but of the producers signature. Note this means that servers can be consumers or producers: as a consumer files are sent to the server for processing; but as a producer the server sends files to requestors. However, it is always desirable for a server to improve its service and therefore have a contravariant signature, and for a client to have a covariant signature which makes life simpler for the client, as it can worry about less formats. So variance of signatures between client and server is complementary, as when the service improves, life becomes simpler for the customer.
A signal interface is an interface where all interactions are signals. Signals carry primitive invocations such as events or interrupts. Signals have signatures which include the name of the signal, the causality, that is, if the signature is the signal initiator or responder, and names and types of the parameters.
You should note that operations and flows are high level interfaces, and that signals are a primitive interface. Operations and streams can be defined in terms of signals. Signals provide a more general interface, but lack the convenience of operations and flows. Signals are more general in the sense that operations and flows are inherently asymmetric: operations define an unequal client-server relationship, and flows a producer-consumer relationship. Signals define equal relationships which are needed for peer-to-peer communication, useful for such interactions such as multi-party binding. An example of peer-to-peer communication is a telephone call. While one person initiates the call, once the initial call establishment is complete, who initiated the call becomes irrelevant.
In order to understand further the difference between operations, streams and signals, consider the causality of interfaces as defined above. In operations, the signature causality is either client or server; in streams the causality is producer or consumer; and in signals the causality is initiator or responder.
The purpose of binding is so that liaisons can be created between objects in order for interactions to occur. Interactions can only occur after a binding, that is some kind of communication path, has been established between objects. Communications people have no problems with this concept, as in communications, bindings are usually explicitly established. However, programmers find the concept more difficult, as binding is often implicit, even for example with dynamic binding in the case of polymorphic routine calls. In the case of static binding, a compiler binds a call to its target routine. Thus even though programmers are rarely explicitly aware of binding, binding is a prerequisite for any interaction.
In ODP, binding can be implicit or explicit. ODP allows implicit binding for languages and notations which do not allow or require explicit binding actions. For example, most procedural languages do not need explicit binding, apart from a routine name, in order to invoke routine calls. In the case of static binding, a call identifier unambiguously maps to a routine, whereas in dynamic binding the call identifier is ambiguous, and the appropriate routine is determined dynamically at run time. Another common example is with files: a file descriptor may be explicitly bound to a file by an open operation. However, in many cases this is not mandatory and a file will be implicitly bound to a file descriptor on the first read or write, without an explicit open. Hence, ODP does not explicitly specify implicit binding, which is usually a matter of convenience.
Explicit binding is of more interest to ODP, and is the subject of a specific component standard on "Interface References and Binding."
Whether binding is implicit or not, binding is either primitive or compound. With primitive binding, two objects are bound directly. Compound binding is built up of primitive bindings where two or more objects are bound via an intermediate binding object.
The computational viewpoint must conform to the policies of the enterprise viewpoint. Some roles, activities and behaviours identified in the enterprise viewpoint will be computational objects. Some of these may have definitions visible in the information viewpoint. Again entities defined in an enterprise specification could be automatically carried through into the computational viewpoint, with the advantage that a tool will save redundant work, carry forward changes, and automatically check for consistency.
All computational objects are implemented in the engineering specification as basic engineering objects. The engineering viewpoint may have other objects of its own, but these are not visible in the computational model. Computational viewpoint bindings are implemented as engineering viewpoint bindings, which correspond to engineering channels composed of stubs, binders and protocols.
The engineering viewpoint focuses on how object interaction is achieved in the distributed environment. Various ODP functions are specifically concerned with the engineering viewpoint, and we have already been introduced to clusters and cluster managers, capsules and capsule managers, nodes and their nucleus.
The basic engineering object is the manifestation of a computational object in an engineering specification. A computational specification is concerned with the object itself, whereas an engineering specification is concerned with how the object is created, where it occurs in the system, that is in which node, capsule and cluster, how to dynamically track the object through activations, deactivations, relocations, etc, and how objects interact via channels. This is an example of separation of concerns, as the computational viewpoint is concerned with the objects themselves, whereas the engineering viewpoint is concerned with the means of deployment. You should note that this framework makes ODP useful in system specification whether you are dealing with distributed systems or not. Objects that support the infrastructure also occur in the engineering viewpoint, such as stubs, binders, protocol objects, interceptors. Since these are abstracted away, that is not visible, in the computational viewpoint, they are not basic engineering objects.
You should note that computational or basic engineering objects are those objects that are specific to the system being built. Basic engineering objects could be generated by combining the abstract computational description with the engineering deployment specification by a system generator such as a compiler. Other engineering objects are part of the run-time infrastructure and will either be generated automatically by the system generator, or be a part of the cluster manager, capsule manager or nucleus.
A channel provides the means for basic engineering objects to interact. Channels establish bindings between objects in different capsules. Computational bindings (as discussed in the computational viewpoint) do not necessarily require a channel. Bindings between objects in the same cluster or capsule, do not require a channel. Objects which are not located within the same capsule but on the same node may also use system-specific mechanisms to accomplish interaction. Such bindings are local bindings and they may be defined by a particular language and compiler in order to optimise performance. Local bindings are not subject to ODP standardisation. On the other hand, distributed bindings require ODP engineering channels in order to communicate with objects that are located in other capsules or nodes. Distributed bindings are the subject of ODP standardisation.
A distributed binding will most likely be much more expensive to establish and use than a local binding. However, it is the means to enable distribution in order to optimise performance using multiple distributed processors. ODP system optimisation will therefore be the task of balancing where to use local as opposed to distributed bindings. It is likely that you will use local bindings for fine-grained objects, but distributed binding between coarse-grained objects. The importance of separation of concerns means that such optimisation is only done in the engineering viewpoint, and that large scale redesign is not necessary, as the basic system design in the information and computational viewpoints is not affected by optimisation concerns. ODP also provides the soft option for evolving monolithic systems towards distribution, as systems may be designed or reverse engineered using ODP viewpoints, but deployed in a monolithic fashion. Such systems will be future-proof, as they can evolve towards distributed systems without redesign, using different vendors systems as defined in the technology viewpoint, and by just adjusting the engineering implementation of the system.
A channel involves client and server stubs, client and server binders, client and server protocol objects, and optionally an interceptor.
An interface reference is an engineering reference to an interface of an object to which distributed binding may take place. An object may bind to an interface when it is in possession of its interface reference. The interface reference contains enough information to enable binding to occur. As an example an interface reference is rather like a link on a WEB page. When you click on the link, your browser binds to a new server, which interprets some part of the reference in order to send you the appropriate information.
We have already explained nodes, capsules and clusters as part of their management functions. Nodes are basically a single system resource (single or multiple processor) under the control of a single nucleus. Nodes contain capsules. A capsule owns an address space and so can be thought of in terms of a traditional protected process. ODP is not specific on how this works, as different systems will differ in the details. For example, a capsule could be a run time stack with associated off-stack storage (commonly a heap). Some systems need to allocate all storage with a single large memory block, with the stack growing in one direction, and other storage using the left over memory. Other systems may allocate a stack, and separate storage blocks, which may themselves be shared between processes. The exact mechanisms are beyond the scope of ODP. As far as ODP is concerned, a capsule represents a single encapsulated domain of protection.
Several tasks could share data within the common address space. However, the address space will be protected from access by other processes, hence providing robustness and security. A task within a capsule may only access memory directly within the capsule's address space, but cannot access memory controlled by other capsules. The memory access mechanism within a capsule is not the concern of ODP; hence it can be optimised according to the run time layout of the capsule itself. As a process cannot directly access memory beyond the boundaries of the capsule, these interactions are enabled by ODP engineering channels, and hence are the concern of ODP standardisation, although ODP may standardise such channels as the CORBA ORB, or DCOM, etc.
Clusters are the smallest grouping of objects within a capsule. Objects are grouped into a cluster in order to perform common functions such as checkpointing, persistent storage, deactivation and reactivation and transfer to another node. These operations function on nothing smaller than a cluster, although a cluster could of course contain a single object. You can see a conceptual view of many of the elements present in the engineering viewpoint in figure 4.3.
Figure 4.3
The engineering viewpoint must conform to the policies of the enterprise viewpoint. It describes the means of implementation of the artefacts described in the enterprise, information and computational viewpoints. Computational objects are implemented in an engineering specification as basic engineering objects, which may be automatically generated by some tool such as a compiler. Computational bindings are realised using engineering binding and channels. An engineering specification still says nothing about particular implementation technologies that will be used. This is the role of a technology specification described using the technology language in the technology viewpoint.
The technology viewpoint is used to build technology specifications of particular configurations of hardware and software elements and networks. Hardware specifications may specify the types, power and number of processors that are used. Software specifications describe operating systems, development environments and other software infrastructure that is needed. These technologies may be the subject of other standards, or of an enterprises purchasing policies. As technology is constantly changing, the other four viewpoints must be specified to be as independent from the technology viewpoint as possible. Hence there is a noticeable lack of viewpoint correspondences.
The technology viewpoint enables further separation of concerns as complete systems can and should be specified without too much consideration of particular technology that will be used. This means that as new, more powerful, cheaper to purchase and cheaper to run technologies are introduced a system may be painlessly evolved. Thus systems specified using the ODP framework are as future proof as possible. The almost complete separation of the technology viewpoint from other viewpoints minimises the problem of being stuck with so called legacy systems.
Aside from identifying particular technologies to be used, a technology specification may define how a system will be implemented on the technology set. This might include run-time layouts for a particular operating system, or the choice of particular programming languages so that these details might be as hidden as possible.
As few as possible. However, technology choices may be dependent on quality of service parameters defined in other viewpoints, and conversely, choice of technology will affect the quality of service required by other viewpoints. These considerations affect concerns such as reliability, transaction throughput, end user response time, etc.