This section covers some miscellaneous topics which have not been covered in full so far.
Sometimes we have the luxury of specifying a system from scratch. As has been seen from the ODP viewpoint framework, a system should be specified mainly without consideration of distributed aspects. Once this specification is done, we develop an engineering specification which is concerned with the deployment of the system. In this case we are concerned to map our required functionality onto the available system resources, and in a distributed system, these resources are likely to be remote. In this case we are partitioning our system to match the resources.
In contrast, the more common case is that distribution arises from the amalgamation of previously existing systems, which might be from several different enterprises, implemented using different application systems and different vendors products. This approach which results in distributed systems is known as federation. How to federate can present very complex problems, as different domains can have different policies and protocols for handling different issues. Federation is concerned with crossing both administrative and technological boundaries.
Interceptors may be necessary to enable federation. Between technological domains, you may need an interceptor to translate protocols and data formats. Between administrative domains, you may need interceptors to enforce security and thus act as a guard against invalid access.
You might have noticed that the design of distributed systems has a lot in common with the design of object-oriented systems. One of the major tasks in object-oriented design is to partition a system into objects defined by classes. However, in order to facilitate reuse, you might want to combine the facilities in libraries provided by several different vendors. This turns out to be more difficult than it sounds, as different libraries can use different conventions, and have names that clash. Federation is similarly difficult.
When establishing a channel between two federated objects an optional interceptor may be placed between the corresponding protocol objects. This has a variety of purposes varying from protocol and data translation, to channel monitoring, and preventing security violations as for example an Internet firewall.
Conformance is an important topic in ODP. Each specification in a viewpoint should state how implementations should be tested in order to show that they conform to the specification. It is important to assess that an implementation satisfies the requirements of the system. Thus an important part of ODP viewpoints is that they identify tests that must be carried out. This also reduces the ad hoc nature of testing. In order to perform conformance testing, conformance points are identified where the system may be monitored for conformance.
You should note though that as a great deal of programming-by-contract is built into ODP, the need for explicit testing is reduced. For example the invariant, static and dynamic schema of the information viewpoint define conditions that can be automatically tested for conformance in the realised system.
QoS addresses how well your system satisfies certain requirements. It addresses whether a system can degrade or whether it fails. For example, if you are transmitting a video signal, and the transporting medium starts to degrade, do you allow the picture to get fuzzy, maintain sharpness but discard colour information, or do you just terminate the transmission, wait until the medium is fixed and try again later. ODP specifications should contain QoS statements which might include such things as mean time between failure, transaction response times, and many others.
One suggestion is that QoS statements can be made in a contractual framework. If QoS contracts cannot be met, then how does the system degrade or fail, and if so does the customer agree to paying for a partial service, and does the service provider agree to giving discounts or not charging for the service? All these interesting questions should be covered by QoS considerations.
Open Distributed Processing is different from just networking, as in networking users and programs are aware of the networked environment. In distributed processing the fact of networking is masked by transparencies, and more importantly for developers, the effort is shifted from the applications developer to the infrastructure. Distributed systems to date have been built using mainly ad hoc, in-house approaches which differ from application to application. The ODP transparencies can be provided by design, or by the ODP functions. ODP functions provide not only transparencies, but other common services required in a distributed environment. In order to handle complexity in the task of building distributed systems, ODP defines a framework for specifying systems. This consists of the five ODP viewpoints. The viewpoints framework has been road tested in producing the International Standard for ODP and CORBA Trading function. The viewpoints framework is also being used to create other ODP component standards. Whether you are developing distributed systems or not, the ODP approach to system modelling is highly relevant. As such viewpoint modelling provides a useful framework to produce processes which could satisfy ISO 9000 requirements. I hope that I have shown that ODP standardisation effort has resulted in a sophisticated state of the art framework for system specification, which has a very broad range of applicability.
ODP host site:
(Links to many papers, standards documents, etc.)
http://www.dstc.edu.au/AU/research_news/odp/ref_model/
ODP-RM documents at ISO:
http://www.iso.ch:8000/RM-ODP/
Other sites worth a visit:
http://www-cs.open.ac.uk/~m_newton/odissey/RMODP.html
http://www.fokus.gmd.de/ghindex.html (Search for ODP)