96
`
`SOEFWARE ARCHITECTURE DESIGN
`
`integration‘ c_oVde;for 2N-g1"interfaces:=
`«
`b)tVerti?ca?tArchitecture’
`E
`E
`
`Figure 4.20. System extension using the four architecture patterns.
`
`“2
`
`SAP 1009 (Part 2 of 3)
`CBM of U.S. Patent No. 8,037,158
`
`112
`
`

`
`SOFTWARE ARCHITECTURE PATTERNS
`
`97
`
`r”1teg§{atI‘o_Rn céde for 2 to_2N+A-L1 interfaces .—.‘R?V At?) 711,
`’
`A
`V(d)T_Hybtid Architébturej V
`A
`A
`'
`‘
`
`Figure 4.20.
`
`continued.
`
`113
`
`113
`
`

`
`98
`
`SOFFWARE ARCHITECTURE DESIGN
`
`create the system. The second scenario is a systemextension. In each case,
`a sixth application is added to the system. The new application obeys the
`same architecture pattern conventions. The third scenario is an applica-
`tion replacement. A new application is integrated in place of the one in the
`original architecture. In the fourth scenario, the two systems are merged to
`create a common interoperable system with twice as many applications.
`In the analysis, the development cost is incurred for all ofthe integration
`code needed to implement the architecture-level interfaces. This includes
`both client and server codes for a particular application-to—application con-
`nection. If architecture standards allow the reuse of integration code, then
`this is reflected as a cost savings.
`Figure 4.20 shows the results of the analysis for an arbitrary size sys-
`tem, Where N is the number of applications. This model shows that the
`custom architecture requires high costs for initial system development and
`all forms of system modification. The vertical architecture provides no real
`cost benefits for initial development and system extension. It saves about
`half the cost of component replacement, and it is cost neutral to system
`
`, jintefgrate thesystem... multiplies the ,co,:f_and com‘ I
`afzthe implemented system-
`I
`L
`E
`‘
`, ‘E
`N Nut:/1beriof.Ap licatirfinsifi »*"lnte‘grated:
`
`Figure 4.21. Comparison of architecture patterns.
`
`114
`
`114
`
`

`
`SOFTWARE ARCHITECTURE PATTERNS
`
`99
`
`Figure 4.22. Example of cost savings N = 7
`
`merger. This indicates that the vertical standards provide for intersystem
`interoperability (a capability also shared by the horizontal and hybrid archi-
`tectures). The horizontal architecture provides the most ease of extensibility.
`The cost of system extension is constant regardless of the size of the system.
`As We stated earlier, the horizontal architecture provides many benefits, but
`it is not practical to assume that a community of developers Will be strictly
`limited to common horizontal interfaces. The hybrid architecture includes a
`range of costs between the horizontal and vertical architecture examples.
`System extension is likely to cost at the 2N + 1 level of the custom archi-
`tecture in three out of four cases. The key lesson is that architectural benefits
`are very sensitive to the Way that the system is designed and extended. Po-
`tential benefits are significant, but they are likely to be jeopardized by sub-
`sequent system extensions which are not conformant to the architectural
`vision and detailed tradeoffs made by the architect.
`Figure 4.22 shows the relative cost savings with respect to the custom
`architecture when N = 7, a typical system size. The hybrid can provide the
`cost benefits of the horizontal architecture with the specialized functional-
`
`115
`
`115
`
`

`
`100
`
`SOFTWARE ARCHITECTURE DESIGN
`
`ity benefits of the vertical architecture. Average cost savings for the hybrid
`architecture are substantial for development and all forms of system mod-
`ification. In summary, the hybrid architecture is our recommended basic
`pattern for software architectures.
`
`Advanced Architecture Pattern: Separation of Facilities
`
`An advanced architecture strategy involves the separation of facilities. The
`Internet services have successfully demonstrated this approach. The Inter-
`net facilities are partitioned between the front-end tools (the user facilities)
`and the back-end information sources (the application facilities). The infor-
`mation sources are strictly back-end servers that can be shared by multiple
`clients. The user facilities are strictly front-end applications that serve one
`user. Some client applications can access multiple types of servers. The user
`has a choice of front-end styles for viewing data.
`The Internet communication standards are defined in terms of lower-
`
`level communication layers, typically at the Internet Protocol (IP) level.
`Compared to CORBA, the IP level requires a substantial amount of client
`and server software in support of each interface. CORBA may have future
`impact on the Internet because it enables the rapid creation of many new
`services and customized interfaces.
`
`The Internet provides an important example of how to structure an ar-
`chitecture in a distributed environment (see figure 4.23 on page 101). Shared
`data and services should be migrated toward the back-end application facil-
`ities. Customized user functionality should reside in separate user interface
`applications. Shared functions and data do not belong in the user facilities,
`and user interaction should not be associated with the shared services.
`
`Beyond the Internet, there are many other reasons why architectures
`should be partitioned in this manner. In general, architectures should min-
`imize the software investment in the user facilities and migrate as much
`functionality and data as possible to shared application facilities (see figure
`4.24 on page 102). In the following paragraphs we make some of the key
`arguments why this strategy is necessary.
`Shared services such as data repositories and search engines often re-
`quire special processing resources. Repositories may have massive storage
`requirements and need high-speed disk interfaces. Computation~intensive
`services may need special processors to provide adequate response-time per-
`formance. For a shared service involving many users, it is usually cost effec-
`tive to provide specialized processors, buses, and storage systems, tailored to
`the needs of these services. The cost of special hardware can be distributed
`among many users.
`
`Most user interface facilities are platform-specific. Applications do not
`port easily between platforms unless some form of cross-platform develop-
`ment environment is being used. To take advantage of the best capabili-
`
`116
`
`116
`
`

`
`SOFTWARE ARCHITECTURE PATTERNS
`
`101
`
`Figure 4.23. Partitioning of Internet.
`
`ties of each platform, it is necessary to write the user interface code in a
`platform-dependent manner. Platform dependence will continue to be an is-
`sue with user interface software because the industry desktop market will
`continue to become increasingly fragmented. Emerging technologies such
`as COSE/CDE, OLE/COM, OpenDoc, OPENSTEP, Fresco, and Taligent are
`environments that will drive the need for partitioned software.
`Architects should minimize software investments in platform-dependent
`software. This can be done by migrating as much functionality as possible
`to shared application facilities. Dependent software is expensive to port
`between platforms; the quantity of this type of software should be minimized.
`Any vendor-dependent software also is in danger of premature obsolescence
`and high operation and maintenance costs.
`Simplifying the role of user facilities allows the creation of more cus-
`tomized user interfaces. It is very difficult or impossible to create a common
`user interface that is readily accepted by all user groups. The groupware
`software market is well aware of this issue. The failure of many group
`
`117
`
`117
`
`

`
`102
`
`SOFTWARE ARCHITECTURE DESIGN
`
`y Facilities‘
`
`Figure 4.24. Separation of user facilities from shared application facilities.
`
`scheduling tools is an example of how user interfaces are closely tied to
`individual user preferences and group culture. By simplifying the role of
`user facilities, more customized user interfaces can be created to meet the
`needs of special—interest users’ groups. Simplified user interface facilities
`require less code and are less expensive and faster to build and specialize.
`They also adapt to end-user needs and changing requirements.
`The emerging market of user-interface rapid prototyping tools will en-
`able dramatic reductions in the cost of user-interface development. Many of
`these tools will interface directly with CORBA. Independent software ven-
`dors such as Bluestone, Integrated Computer Solutions, Oberon, Netlinks,
`and others are developing or already have CORBA products on the market.
`It may soon be possible to implement a complete customized user interface
`Within hours. This interface might provide all of the desired CORBA invoca-
`tions Without substantial development. As platforms and user needs change,
`new user interfaces can be created just as easily.
`
`118
`
`118
`
`

`
`SOFTWARE ARCHITECTURE PATTERNS
`
`103
`
`Some application domains may require an additional category of sepa-
`rated facilities. Workflow represents the organization’s business process. An
`automated workflow supports the business process across multiple software
`packages. Workflow software can perform functions such as data transfer of
`results, automatic manipulation of data using multiple packages, and user
`notification.
`
`In general, shared application facilities should be completely indepen-
`dent of workflow. The shared application facilities should be among the
`most stable subsystems in the architecture and should support flexibly
`many modes of utilization eliminating any hard-coded workflow from the
`access protocols. In some environments, workflow is naturally merged with
`the user-interface facilities. In others, the user interface facilities need to
`be workflow independent. This is often the case where there are multiple
`workflows in an organization that share common applications. Workflow
`can provide useful animation to a set of passive user facilities and shared
`application facilities. It is a good example of "why good functionality through
`architecture—level APIs must be provided. A workflow process may need
`to control virtually any type of function that a software package provides.
`Workfiow can be highly volatile, as an organization adapts to meet changing
`business needs. For this reason it is probably prudent to separate work-
`flow in the architecture in order to localize the changes needed as workflow
`changes.
`'
`
`Other Architecture Patterns
`
`There are a variety of other widely used architectural paradigms. In the fol-
`lowing sections, we identify these paradigms and establish their relationship
`to the design of software architectures.
`
`Ad Hoc Architecture Ad hoc architectures are created whenever a system
`is integrated directly at the implementation level. These architectures con-
`tain a spontaneous mixture of communication levels and mechanisms; they
`are architectures without a vision. By choosing the most expedient ways
`to create interoperability, an ad hoc architecture can show some immediate
`interoperability benefits, but these benefits are short-lived and usually very
`dependent on particular software versions and the particular programmers
`who create the integration solution. These systems are very brittle; they sel-
`dom can adapt to any changes to the system, such as new software versions,
`new network configurations, porting to new platforms, and so forth. During
`the life cycle of such a system, programmers usually move on to new respon-
`sibilities, and new programmers find ad hoc systems impossible to maintain
`and extend.
`
`For some organizations, such as small independent software vendors
`with a very stable programmer workforce, an ad hoc architecture may be
`
`119
`
`119
`
`

`
`’ 104
`
`SOFTWARE ARCHITECTURE DESIGN
`
`reasonable, particularly if the product is undergoing frequent revisions that
`impact architecture-level issues. For most other organizations, ad hoc archi-
`tectures are practical only for small-scale prototypes, such as user-interface
`mockups.
`‘
`Software architecture designs should be initiated as early as possible
`in prototypes that are likely to migrate into operational systems. The pro-
`cess of creating a good architecture for a system is very closely related to
`prototyping experiences and should proceed in parallel. A key goal of any
`operational system prototype should be the creation of a robust software
`architecture that can adapt to the changing requirements of the users. Ad
`hoc architectures do not meet these needs, except in very special organiza-
`tions.
`
`Methodology-bound Architectures Systems designed with rigorous soft-
`ware methodology can employ many architectural principles, such as com-
`ponent isolation and well-defined software boundaries. Occasionally, after
`we explain architectural principles to groups, someone responds: “We have
`all that, but we still cannot create a successful system.” Obviously these
`projects are missing some ingredients.
`The missing ingredients are more cultural than technical. Methodology-
`bound projects have a skewed value system, in which priorities in the
`methodology override the priorities of good architecture. For example, a
`commonplace methodology-driven question is: “Is that feature really object
`oriented?” This question may be very appropriate at an object-oriented pro-
`gramming level, but it has minimal relevance to software architecture. An
`architecture must use a wide range of concepts well beyond the scope of a sin-
`gle methodology. [Shaw, 93] The architecture must provide a stable solution
`over a decade-long system life cycle, well after the demise of today’s popular
`methodologies. Other methodology-driven priorities include the mandatory
`creation of large quantities of design documentation that may be of little
`or no use to the developers and maintainers of the system. As the system
`evolves, the design documentation rapidly becomes obsolete.
`In computing, we have seen many methodology trends come and go. Cur-
`rently there are more than two dozen documented object-oriented method-
`ologies. [Hutt, 94] The persistent trend is to move on to new methodology
`concepts.
`To design good architectures, organizations must recognize that popular
`methodologies are transient. In fact, methodologies involve some of the most
`dynamic, rapidly evolving ideas in computing technology. The methodology
`business is also one of the most fragmented in the computing industry. There
`is little or no hope of standardization of methodologies; hence, there is no
`movement toward stability. Methodology practices will change dramatically -
`over the course of a system life cycle. Good software architectures must
`provide much more stability than the methodologies that may be employed
`to create them.
`
`120
`
`120
`
`

`
`SOFTWARE ARCHITECTURE PATTERNS
`
`105
`
`There is probably no way to fix a methodology-bound architecture
`without fundamental cultural changes that allow software architects to de-
`sign and implement their Vision without the encumbrances of methodology-
`driven project culture.
`
`Object-Oriented Architecture Object orientation includes as one of its
`basic principles the modeling of natural real-World objects in the software
`system. This notion has roots in the semantic database modeling work of
`Dennis McLeod at the University of Southern California, where the comput-
`ing object does not only represent the real-World object, “it is the object.”
`An important question for software architects is whether to include ab-
`stractions of domain objects at the system level. We have already said that
`it is not acceptable to publish unabstracted object models at the system
`level. Without abstractions, the architecture cannot manage system com-
`plexity effectively. There are two important considerations: (1) the stability
`of the domain models compared to the system life cycle and (2) whether
`hard-coding the domain models into the architecture provides significant
`system-level benefits.
`Even in highly domain-dependent applications, such as simulation, the
`architect has a choice of whether to hard-code the domain objects into the
`core of the software architecture or to separate the domain-dependent hier-
`archies from the domain-independent hierarchies. For example, a domain-
`independent architecture can incorporate domain information in object
`method parameters as opposed to hard-coded attributes and API—level spec-
`ifications.
`
`Client-Server Architecture Client-server is the precursor technology to
`distributed objects. Client-server technology is associated with remote pro-
`cedure calls such as ONC and DCE, whereas distributed objects are as-
`sociated with CORBA, which is the predominant industry standard for
`distributed objects. Distributed objects are peer to peer, whereas client-
`server is a constrained architecture with well-defined client and server sub-
`
`system roles.
`Client-server technology contains some very useful concepts for the
`system architecture (as opposed to the software architecture), which in-
`cludes hardware selection and physical allocation decisions. Client-server
`can be viewed as the antithesis to the migration of functionality from the
`mainframes to the desktop. In client-server, the focus is on creating high-
`performance centralized processing services. The centralized services run
`on high-performance systems with tightly integrated mass storage facili-
`ties. The capital resources are focused in the centralized server facilities
`and minimized on the desktop. When fully migrated to client-server, the
`desktops should be commodity terminals, such as personal computers or X
`Terminals. This model works because the cost of the centralized resources
`
`are shared among many users; sufficient savings usually can be obtained
`
`121
`
`121
`
`

`
`106
`
`SOFTWARE ARCHITECTURE DESIGN
`
`from the reduced costs of the commodity desktop systems. When properly
`configured, the client-server systems deliver better performance at lower
`cost than either mainframe-based systems or PC-LAN systems.
`Client-server is not concerned with interoperability. Each application
`functions as a vertically integrated “stovepipe” system, self~contained and
`providing all levels to the user from user interface to back-end mass storage.
`In most client-sever systems, interoperability between applications is limited
`to desktop cut and paste—that is, exchange of text and bitmaps, not objects.
`The second problem with client-server technology is that it is often
`vendor- and product-dependent. Since client-server products are vertically
`integrated, often there is no user-defined software architecture. We have
`heard people claim that “our architecture is <<place your favorite product
`here>>.” In that case, the system is vulnerable to the commercial decisions
`of a single supplier, and there is a lack of control of the timing of product
`upgrades and associated maintenance costs. Users are forced to follow the
`vendor’s lead or risk obsolescence. Many organizations have regretted this
`loss of control.
`
`Most client-server vendors include API access to their products, so that
`they can be incorporated readily into user-defined software architectures.
`Techniques presented herein can be used with these products to create soft-
`ware architectures that provide vendor independence through component
`isolation. If a client-server product does not provide this level of API access,
`consider excluding it from the system. Lack of API access indicates the prod-
`uct has a closed, vendor-controlled architecture that could become a serious
`liability over the system life cycle. Even when an API is available, it should
`be mapped to your own IDL interface that you control.
`
`Message-oriented Architecture Message-Oriented Middleware (MOM)
`is designed to provide message model capabilities in a distributed environ-
`ment. The networking world experience has shown that messaging can be
`quite beneficial. Message systems provide fault tolerance. Messages can be
`queued, routed, or stored until a system is available for reception. The sys-
`tem, therefore, does not have a single point of failure. Currently MOM can
`be based on the RPC model, on message queueing, or on models that attempt
`to utilize the best aspects of both. The main benefit of this architecture is
`its support of both the synchronous mode of communication as well as the
`asynchronous mode. However, it currently is immature. Thus, developers
`today face multiple nonstandard APIs and questions as to how MOM will in-
`teroperate with other architectures. MOM may require more code to utilize.
`
`COMMENTS
`
`The design of highly effective software architectures involves a great deal of
`intuitive judgment and experimentation. Rigorous methodologies that are
`executed mechanically can impede this creative process. The ability to create
`
`122
`
`122
`
`

`
`COMMENTS _
`
`107
`
`simplifying abstractions is a key innate talent of the software architect. Few
`individuals practicing in the software industry have this ability—perhaps
`as few as one in five software designers. [Coplien, 94] The next major trend
`in computing methodology, “design patterns” in part resulted from recogni-
`tion of this fact. The Design Pattern practitioners are focused on project-
`centric solutions. Their concepts are synergistic with ours, in that we both
`are interested in techniques for creating better software architectures. Our
`approach goes beyond a project-centric focus to include the creation of stan-
`dard reusable architectures that can fill important standards gaps and ad-
`dress interoperability needs for communities of developers. We have found
`that many recognized authorities minimize the importance of standards.
`In our opinion, without organizational interface standards there is mini-
`mal reusability and no leverageable technology progress from generation to
`generation of software systems.
`A common misconception in object-oriented systems development in-
`volves the difference between obj ect-oriented programming and architecture-
`based systems integration. Many developers have practiced integration by
`providing system—level exposure to their object classes and methods. This
`practice is problematic because it multiplies the complexity of the archi-
`tecture by the complexity of the internal object models of each subsystem.
`When a typical program comprising 100 classes and 1,000 methods is inte-
`grated with ten other similar programs, a system complexity of 1,000 classes
`and 10,000 methods results. These methods would be used sparsely across
`program boundaries in a manner that is highly dependent on specific ap-
`plications. In effect, the architecture becomes highly brittle because all the
`subsystems become intimately interdependent upon each other’s detailed
`object schemas.
`There is an interesting analogy here between software architecture and
`pop psychology. The discovery and definition of healthy boundaries is one
`of the fundamental principles of Gestalt psychology, the scientific basis for
`much of today’s pop psychology movement. Highly interdependent, brittle
`software systems are analogous to codependent personalities. In both cases,
`there is a poor definition of boundaries between independent entities. This
`lack of good boundary definition leads to dysfunctional behavior. In comput-
`ing, this behavior is exhibited by the fact that 50 percent of software cost
`is attributed to system discovery (where the programmer is trying to find
`out how the system works). In addition, so-called codependent systems lack
`adaptability. The systems are unable to grow to address new requirements
`and challenges without great expense. Difficulty in debugging and defect
`correction is another important result of poorly defined system boundaries.
`Object-oriented programming and architecture-based systems integra-
`tion are quite different practices with very different goals. The software
`architecture’s role is to help control complexity and manage change in the
`system. Ideally, the software architecture provides a system—level abstrac-
`tion that needs to contain only enough detail to provide the required sys-
`
`123
`
`123
`
`

`
`108
`
`SOFFWARE ARCHITECTURE DESIGN
`
`tem-level interoperability. Generally designers err on the side of too much
`complexity with insufficient abstraction. The most important and difficult
`decisions are not what details to put into the software architecture but what
`details to leave out [Brinch Hansen, 76].
`The Rule of Three Iterations is another important analogy for the ar-
`chitecture process. This analogy was explained to the author by Professor
`Brinch Hansen at USC; it contains some important truths. Generally, three
`iterations of system implementation are needed to create a mature software
`architecture. We can illustrate this analogy with some well-known automo-
`bile models. The first prototype resembles a Ford Pinto. It is a fairly minimal
`design with some obvious Weaknesses. The second prototype resembles a
`GM Cadillac. Success with the first prototype often leads developers to try
`to build an overly ambitious system. This system dramatically fails to meet
`expectations. The third prototype resembles a Volkswagon Beetle. Due to
`lessons learned, it is a simple, elegant design that provides the desired func-
`tionality, but with a very economical implementation. It is hoped that the
`third prototype becomes the operational system, because it can be developed
`and maintained at a very reasonable cost.
`Using this analogy as a guideline, the architecture process should con-
`tinually evolve the design towards a Beetle-like system, altogether avoiding
`the overly ambitious Cadillac-like system. The Beetle-like system carries
`many benefits:
`
`Cost effective in declining budget times
`More versatile
`
`More adaptable
`More migratable
`More efficient
`
`124
`
`124
`
`

`
`
`
`Security
`
`With the advent of open systems and networking We have seen accompanying
`social by—products, such as viruses, ’I‘rojan horses, unauthorized accesses,
`and damage by disgruntled employees. Security is an essential capability
`needed by the public and private sectors, in government, finance, medicine,
`and general business. These industries need to protect information from
`unauthorized access and modification, to protect privacy, to guard trade
`secrets, and to protect data.
`Extensive research has been performed on computer security, such as
`secure operating systems and secure databases. In the past, not many im~
`plementations were commercially available, particularly in the challenging
`multilevel-security (MLS) arena. MLS security enables the interoperation
`of systems operating at different levels and supports multiple levels on the
`same system. While the number of available products and technologies that
`address this area is increasing, these implementations are not prevalent.
`MLS is still a difficult issue; without it users may not attain all of the desired
`benefits that distributed object management can provide while answering
`all of their security needs.
`Because computer security historically has been viewed as a small spe-
`cialty market, the commercial success of security technologies has been
`disappointing. Available security technologies are limited to specialized ver-
`sions of platforms and products. These specialized versions are typically
`generations behind the state of the art in terms of cost, features, perfor-
`mance, robustness, and usability. In order for security to be effective it must V
`be ubiquitous, but security is unlikely to achieve pervasive support if sup-
`pliers do not bundle it with mainstream platforms. One necessary change
`
`109
`
`125
`
`125
`
`

`
`110
`
`SECURITY
`
`is a fundamental recognition by suppliers that virtually all end users need
`security, not just selected narrow markets.
`Some end users believe that the only available course of action is to
`wait until MLS security is commercially available-—they ignore security or
`opt for physical isolation. We believe that this sort of argument should not
`be accepted anymore. Security must be taken into consideration, especially
`during system architecture design. Even though security may not be avail-
`able in some of the newer emerging technologies, architects should plan on
`integrating and phasing it in.
`Architects and developers sometimes View security as too difficult and
`defer it rather than build it into the architecture from the start. Often they
`believe that security complicates a system, imposes restrictive policies and
`procedures, and may impact performance. Mainframes and PCs had colo-
`cated disk packs or hard drives that were physically secure. Local area
`networks, remote access, and global internetworking have made security
`a complex challenge. Distributed systems introduce new problems, such as
`applications that run across several systems. When we add object-oriented
`technology to the equation, we find that conventional security mechanisms
`and architectures are woefully insufficient. The CORBA architecture at-
`tempts to provide transparent object location and activation, while the secu-
`rity policy may require a client to know it is communicating with a trusted
`object.
`Security has many diverse aspects, examples of which include physical
`security, personnel security, information security, prevention of electromag-
`netic emanations and their interception, operations security, computer se-
`curity, and network security (software and hardware). In this chapter we
`concentrate on the technology related issues.
`We look further into advanced security issues that arise when using
`an object request broker (ORB) in a distributed system. We review several
`important security standards and research projects that apply to multiple
`levels of security architecture. In addition, in Chapter 7 we present the
`security support as implemented in the DISCUS framework.
`
`The Need for Security
`
`A common misconception is that only governments are interested in secu-
`rity. Often software vendors or systems integrators argue that they are not
`concerned with security because they target the commercial World. Inter-
`estingly, while their requirements are somewhat different, security needs in
`the commercial world are just as prevalent as in the government.
`Governments are interested mainly in protecting information (often mil-
`itary) from enemies. As such, they are interested both in preventing unau-
`thorized disclosure and in maintaining data integrity. Limits are imposed on
`who can access information for updating and modification and also on who
`
`126
`
`126
`
`

`
`SECURITY
`
`111
`
`can access the information for reading. The private sector is driven mainly
`by business decisions and their cost effectiveness. In the banking industry,
`protecting someone’s account balance total from being read is not as im-
`portant as protecting it from being modified. The private sector is therefore
`more interested in protecting information from being changed (i.e., restrict-
`ing write access). Sometimes, although not as often as in the government or
`military, companies are interested in restricting any access to information,
`especially trade secrets from competitors [Chalmers, 90].
`Nowadays, the needs of the government and the private sector seem to be
`converging. Viruses, Trojan horses, worms, and wide use of the Internet have
`raised the user community’s awareness for security, possibly with varied
`emphasis. For example, the military may be concerned with data integrity
`in the case of data that affects nuclear weapons launches. The private sector
`also is concerned with the integrity of the data and wishes to protect it from
`unauthorized modification. This takes the form of well-formed transactions
`
`and separation of duties in the workplace. Separation of duties provides
`security, for example, by requiring several signatures in order to validate
`some operation (e.g., purchase order, release of funds, etc.). Similarly, in the
`military it may require several people to authorize a nuclear launch.
`
`Security Issues
`
`At some level both camps are interested in authentication, auditing, moni-
`toring, and of course good performance. Because of these requirements, care
`must be taken when designing a security system. Here are a few things to
`consider, especially when introducing security into a distributed, heteroge-
`neous environment [Fairthorne, 94—a1so known as the OMG Security White
`Paper]:
`
`0 The security model must be independent from specific security algo-
`rithms. It must enable access to and selection of, the algorithms and
`support more than one security policy. This is important because dif-
`ferent platforms and domains may have different security policies. (See
`section titled Security Policies on page 114.) Governments also may regu-
`late some of the mechanisms (e.g., cryptographic algorithms), therefore,
`different installations of a system may need to use different algorithms.
`The model also should be extensible.
`
`0 The model must support small systems and very large distributed sys-
`tems. This means that the mechanisms must