Assembling systems from components while also providing these IQoS properties is still largely an unsolved problem. Providing these properties involves complex trade-offs among competing goals, such as those for maximum speed, security, reliability, safety, etc. In addition, the code that implements these properties must generally be tightly interwoven with code that supports the functional logic. This breaks the "component" model, and makes the systems both hard to construct, difficult to maintain, and hard to adapt or reuse when the requirements for non-functional properties change.
Modern DoD systems exhibit the need for both component-based development, and support for IQoS. For example, the ATAIS report [BFHH+98] discusses this subject in some detail. A number of DARPA-supported activities, including the Quorum program, the OMG-DARPA Workshop on Compositional Software Architectures [Tho98], and the MCC Object Infrastructure Project (e.g., [Fil98]), are addressing aspects of this problem. In addition, both the Object Management Group and the international standards community are working in this area. Several major themes are coming out of this work which describe key directions for further work in addressing IQoS issues in component-based systems.
Solution Approaches. One of these themes is the representation of key parts of the system as explicit objects (reification) which can then be reasoned about and operated upon by the system (computational reflection). Reification of the object communication process is a common theme in projects addressing the problem of providing IQoS in component-based systems. This provides a foundation for intercepting messages between components and adding additional IQoS-related functionality. Addressing IQoS requirements typically also involves reifying other parts of the object system, e.g., Object Request Brokers, as well as lower level aspects of the system, such as multiple instances of servers, routings through the network, and individual network components, and providing management interfaces to those components.
An extension of system reification is the idea of defining abstractions for viewing each IQoS characteristic as a separate aspect, each with its own "aspect language", providing mechanisms for defining and enforcing consistency relationships among these aspects, and tools which can "weave" the separate aspects together (and take them apart when necessary) in building operational systems.
The need for more and better component and other metadata is another key theme. Such metadata is necessary to describe components, their functional capabilities, and their IQoS characteristics and requirements, as well as system level IQoS characteristics and requirements which cut across components. In the context of IQoS, this requirement for metadata means that definitions of IQoS characteristics, and the parameters that describe them, must become more formal and standardized. Such standardization has taken place in some parts of distributed architectures, e.g., in the network management area, but must be extended more generally.
A final theme is the development of frameworks and architectures for addressing the complexity of dealing with multiple IQoS characteristics in large-scale systems. Frameworks emphasize the fact that the range of agreements that must exist to support advanced forms of interoperability, such as "plug and play" among components purchased from independent software vendors, must generally be based on a unified design approach, together with consistent standards. A framework can be designed to provide built-in architectural functions and proven architectural properties. Based on the predefined characteristics of the framework, associated tools can combine framework/architecture-provided services based on declarations, and incorporate user-provided application logic into "the right place".
More Work is Needed. Despite these promising approaches to dealing with the integration of IQoS characteristics in component-based systems, there are numerous issues that remain in applying these techniques, as well as additional details that need to be developed. For example, more work is needed on how to:
Assembling systems from components while also providing these system-wide properties is still largely an unsolved problem. Providing these properties involves complex trade-offs among competing goals, such as those for maximum speed, security, reliability, safety, etc. In addition, the code that implements these properties must generally be tightly interwoven with code that supports the functional logic. This breaks the "component" model, and makes the systems both hard to construct, difficult to maintain, and hard to adapt or reuse when the requirements for non-functional properties change.
Modern DoD systems exhibit the need for both component-based development, and support for ilities and QoS. For example, the ATAIS report [BFHH+98] discusses this subject in some detail. A number of DARPA-supported activities, including the Quorum program <http://www.darpa.mil/ito/research/quorum/index.html>, the OMG-DARPA Workshop on Compositional Software Architectures [Tho98], and the MCC Object Infrastructure Project (e.g., [Fil98]), are addressing aspects of this problem. In addition, both the Object Management Group and the international standards community are working in this area.
This report describes the general problem area of providing ilities
and QoS in component-based systems, describes several common technical
themes identified by the various groups working on this problem, and describes
the range of future work necessary to solve this problem.
Various lists of ilities have been identified. For example:
Such considerations make it clear that it is difficult
to draw a line between "ilities" and "QoS", and in fact increasingly these
issues are being considered as part of a common problem. For example,
[Tho98] notes a general agreement that QoS should be defined to include
"ilities" as well as lower-level network issues. From this perspective,
mediating (for example) the need for security, varying degrees and levels
of security, at different times and situations, is analogous to providing,
negotiating, and adapting to changing bandwidth needs in a system.
Other recent work takes a similar point of view in merging these issues.
For example, an overview of higher-level QoS considerations
in the context of distributed systems can be found in [Han97], and a discussion
of the interaction between QoS issues and one of the ilities, survivability,
can be found in [Wel98]. Many of the issues raised in this latter
paper apply to interactions between QoS and other ilities. [STLW97]
also discusses the relationships between QoS and OMG services such as security
and transaction support. As a result, the rest of this report
will refer to the combination of non-functional "ilities" and "QoS" as
IQoS.
This approach is not good enough to meet the needs of many of today's systems. For example, the use of multimedia and the extensive use of shared networks for many different and independent traffic streams, some of which (such as command and control or industrial process control data) may have stringent QoS requirements, are leading to the development of systems that can "manage" QoS dynamically. Providing this capability is a particular problem in larger-scale systems (and those involving the Internet), in which end-to-end service must be provided in a distributed systems environment where different parts of the system have different owners. At the same time, there are increasing requirements for systems that combine these QoS/performance related aspects with other IQoS characteristics. Developing such systems involves complex tradeoffs--for example, enhanced interoperability may be provided at the cost of reduced security.
The need to manage QoS dynamically is not the only dynamic element complicating the development of today's systems. As noted in the Introduction, there is an increased emphasis on building systems from reusable components (i.e., by wiring such components together). In this view, it should ideally be possible to dynamically create a system to satisfy a given set of requirements, and either flexibly alter the configuration of components to deal with changing requirements, or "tear down" the system and rebuild a new one (reusing those components as necessary in the new system). This means that the individual components must be usable in many different environments.
IQoS requirements generally apply to many application domains. As a result, it is desirable (and promising) to also develop software to address these requirements in an application-independent fashion, and in a way that enables it to be reused across a wide range of possible application domains [SW96]. This suggests that the software to address IQoS requirements should itself be written in terms of components, or in a way that can be easily merged with components. In addition, to be effective, the realization of IQoS requirements in a resuable fashion should be transparent as far as the application developer is concerned. Ideally, it should be possible to design an application that concentrates on meeting a set of functional requirements, and then add components that address the additional IQoS requirements without disturbing the structure of the original design for the application. Achieving such a clean separation reduces the complexity of the application and thus enhances its maintainability. It is also important that the implementation of IQoS requirements be flexible and customizable, because it is not always possible to come up with a single mechanism for implementing a particular IQoS requirement that is appropriate for every application area. Thus, it should be straightforward for application developers to adapt the implementation of an IQoS requirement to meet the particular demands of their application domain, or to use a readily-available alternative implementation (e.g., found on the network). Moreover, using an alternative approach to implementing a particular IQoS requirement should not involve making changes to the application's source code. The problem is how to satisfy these requirements. Generally, we want to know how to achieve system-wide IQoS properties from separate sets of components, some implementing application functionality and some implementing IQoS capabilities, by composing these components to form a complete system.
On the surface, object service architectures such as OMG's Object Management Architecture (OMA) appear to support these requirements. The OMA provides a general object bus architecture (CORBA), which allows objects (components) to communicate with each other. Some of these components can implement application functionality. A general and reusable set of object services is also defined (transaction service, security service, replication service, etc.), which can be used to support various non-functional (IQoS) requirements. The general model in the OMA is that these object services can be considered as components too, since they have interfaces which can be invoked through the CORBA bus. Hence, in order to develop an application which also supports IQoS requirements, the application developer wires together the application components and the service components to form the complete application. The CORBA bus architecture provides a certain amount of distribution transparency in that when calling CORBA objects, object operations are invoked the same way whether the objects are local or remote. In addition, ORB vendors typically provide additional hooks which enable an invocation to potentially be intercepted, and enhanced or filtered by any number of implicit additional operations to provide other services. These services can be executed on the client, server, or somewhere in between. The OMG Security specification also provides for Interceptors which are used to splice security behavior into communication paths. These are almost general purpose, and could be generalized to support these implicit operations. In addition, while the OMA does not currently mention QoS, OMG is working on a general Quality of Service reference model[STLW97], and an extension to its reference model to address IQoS issues [Tys98], as noted above.
However, supporting IQoS requirements in an architecture such as the OMA is more complex than it appears on the surface, and there are a number of complex issues that must be addressed in order to support IQoS requirements in these architectures.
In application development in these architectures, the functional computation is implemented as a flow through a collection of objects. Adding service objects to this flow is not necessarily straightforward or transparent. The operations in an OMG service interface must typically be invoked in a particular pattern (a protocol) to use the service to achieve a given IQoS requirement. In some cases, the invocations to the service interfaces need to be interspersed with calls to the functional interfaces of other components. It is difficult to do this in a way way that is transparent to application programmers. If the invocations of services must be done explicitly in the components, the application developer is faced with the difficult job of understanding and managing the various services involved. Moreover, the code that must be added to the application to support IQoS requirements increases the complexity of the application's source code and makes it harder to reason about its correctness. The lack of clear separation of code supporting functional and IQoS requirements also makes the software less flexible, maintainable, and reusable.
The interceptor mechanism mentioned above, and various ORB hooks currently provided by vendors, potentially provide a way to at least separate the invocation of services from the application code, by invoking the services implicitly, just as invocation of network services is handled implicitly for distributed objects. However, current implementations still require that some developer understand and specify calls to the services in the appropriate orders. Moreover, the interceptor mechanism has currently been developed only in the context of security, and the ORB hooks are vendor-specific, making it difficult to use them in a general, reusable way for multiple IQoS requirements.
The problem is difficult enough when only a single IQoS dimension is involved. The problem becomes even more difficult when multiple dimensions (e.g., QoS plus reliability, security, etc.) are involved. This involves defining a complex mapping between a set of IQoS requirements, and calls to a lower-level set of services, some of which may be involved in satisfying multiple IQoS requirements, and some of which may conflict with each other or involve hard-to-understand tradeoffs. Overall, there is relatively little experience with connecting groups of services on the object bus to build large-scale applications which guarantee end-to-end composition of IQoS properties.
Dealing with the problem of providing reusable IQoS functionality in component-based systems requires coming up with answers to such problems as:
Providing a foundation for intercepting messages and adding additional functionality requires providing explicit access to parts of the communications process, and the ability for added code to explicitly reason about that process (e.g., in order to decide when to invoke specific added functionality). More precisely, this involves reification of various parts of the distributed object messaging process, in order to provide for hooks at agreed-on points in the messaging process, and various forms of computational reflection.
In a conventional object-oriented system, computation is performed by objects that represent entities in the application domain (e.g., platforms in a command and control application). Computational reflection [Mae87] is the activity performed by a system when doing computation about (and possibly affecting) the system's own computation. Most systems, in addition to computation about the application domain, include some reflective computation, examples being recording performance statistics, interface-related computation (e.g., tracking mouse position), control-related computation (e.g., determining what process to execute next), and self-modification (e.g., response to failures by bypassing failed components). In a reflective object-oriented system, the system, in addition to domain objects, also contains objects which represent aspects of its own structure and behavior (often referred to as metalevel objects). The motivation for providing built-in reflective capabilities in a system is to provide a general framework for developers to extend or tailor the system to specific application requirements in a modular way. For example, reflective (metalevel) techniques can be used to allow developers to provide the extensions to method calls to support remote method invocations. Another example of the use of reflection in a distributed context is the task of monitoring the behavior of a running object. It might be desired that, each time a given object accepts a message, this fact is reported to a monitor object. One approach to doing this would be to modify each method of the running object. However, a reflective system would allow this to be done by modifying the single metalevel script or procedure that controls the handling of all messages by that object.
The first step in reflection is the representation of specific aspects of the system explicitly as objects. This is called reification. The resulting objects are sometimes referred to as metalevel objects (or metaobjects). Decisions regarding the aspects of the system to be reified as metalevel objects constitute key design decisions in a reflective system. These aspects include such things as object classes, the internal structure of objects, and method invocation. The metaobjects representing reified aspects of the system must be defined so as to provide operations that support both reflective computation and reflective update. The operations defined for these metaobjects constitute the system's metaobject protocol. Invoking an operation of a metalevel object (such as a send operation on a message object) constitutes reflective computation. If the reflective computation updates reified objects, this constitutes reflective update (the result of the reflective operation modifies that aspect of the system).
Reflection is increasingly being investigated in the context of object-oriented systems as a way of constructing flexible, large-scale systems, because it offers a built-in mechanism for incorporating user-defined customization or specialized additions into the system. [Zim96] provides a general overview of the subject. A key issue in designing metaobject protocols, and in using reflection, noted in [KRB91], is trying to balance the objectives of:
Work addressing IQoS in distributed object systems (e.g., as described in [Tho98]) illustrates many variations on this theme of reifying communications. For example, MCC's Object Infrastructure Project (OIP) [Fil98] proposes wrapping components with a sequence of injectors using proxy-like mechanisms. These injectors provide the additional IQoS functionality. The OIP project has done some analysis suggesting that security (access control, intrusion detection, authentication, encryption), manageability (performance measurement, accounting, failure analysis, intrusion detection, configuration management), reliability (replication, transactions), and quality of service (soft-real-time priority management) can be achieved using this approach. BBN's QuO project [ZBS97] <http://www.dist-systems.bbn.com/tech/QuO> uses a layered stack of object delegates (proxy objects) to explicitly represent a connection between a client and server component. These delegates, together with explicit QoS contracts separated from the functional application code, interfaces to system resources and mechanisms, and other mechanisms, support insertion of IQoS functionality at many different levels of a system.
First class connection objects, in addition to their role in helping represent the IQoS aspects of a connection for other purposes, also help make the system more flexible and adaptable. Enabling the client and server components to reference the connection, rather than explicitly referencing each other, reduces coupling between the components, and enables alternative connections to be more easily established when necessary.
Some projects go further than simply reifying the distributed communication process, reifying aspects of local objects, and sometimes using unconventional object models in doing so. For example, [Agh98] has used the actor model (a concurrent object model in which each object has its own thread), together with actors representing connectors and component interfaces, in a two-level actor model for managing and enforcing IQoS. The levels include base level actors that are simply functional objects and meta level actors that watch system activities and resources, a set of core resource management services, i.e., basic system services, chosen by looking at patterns of system activities, where interactions between an application and its system can occur, and QoS brokers for coordinating multiple IQoS characteristics.
Using an object model that supports reification of local objects (or a reflective version of a conventional object model, such as Open C++ [CM93]) provides access to the internals of local objects. This can be helpful in dealing with some forms of IQoS functionality, since it is not always possible (depending on implementation details) to fully support a given IQoS requirement using only behavioral extensions spliced into the communication path. An example is found in some object DBMSs (ODBMSs), which, due to their implementations, require a persistent object to explicitly indicate when an object method has updated the object's state. These ODBMSs use mechanisms to provide transparent persistence which involve intercepting messages to objects, e.g., so that the ODBMS can bring into memory an object that is currently on disk (just as ORBs intercept messages to remote objects so that they can perform the appropriate marshalling and network operations). However, these mechanisms cannot intercept basic memory accesses that take place within an object, and hence cannot detect when a given method has, as a side effect, changed the object's state. A reflective model of local objects, however, might be able to provide the necessary hooks for detecting such accesses, since it could provide facilities for controlling and overseeing internal operations.
Addressing IQoS requirements typically also involves reifying other parts of the object system. For example, the ORB itself is typically reified to some extent in the process of reifying the communications process, since this provides the hooks necessary to deal with some lower level aspects of communication (and OMG specifications already reify the ORB to some extent). For example, QuO uses explicit ORB delegate objects to encapsulate ORB heterogeneity. Trading (yellow pages) services such as the OMG Trading Object Service are found in many distributed object architectures, and are provided to enable components to find other components within the system that offer specific services. These trading services represent another reification, that of the binding process. Making binding more explicit provides a way for components to select services based not only on functional capabilities, but also on IQoS tradeoffs, and also provides a way to flexibly rebind to different service instances when requirements or situations change.
It is also necessary to reify lower level aspects of the system, so that mappings can be defined between higher level specifications of required IQoS characteristics and configurations of lower level services, and so these can be reconfigured/rebound if IQoS characteristics drop below acceptable levels. Examples of such lower level system aspects are such things as multiple instances of servers, routings through the network, and individual network components. This also involves providing management interfaces to those components (some of which are hardware) to enable them to report information to managing software, and in turn to be controlled by that software. The "managed object" abstraction used in telecommunications network management standards [Pav96] is an example of this approach. The TINA consortium is attempting to integrate these concepts with CORBA distributed object concepts, in order to provide both network management, and higher level service management [Ash98, Pav96]. An "end point" for this lower-level reification would be the integration of ORB functionality with that of a distributed operating system. This would provide a merger of control of both local and distributed resources. The Legion project [GG99] is an example of work merging operating system and distributed object concepts.
Some approaches to adding IQoS functionality in a reified communication system involve increased use of events. In this approach, basic system components post events at various key points in their flow of computation. Additional components can then be added to detect these events, and insert additional processing into the flow of computation before returning control to the main flow. For example, [SKN96] describes an approach which uses first-class connector objects (called mediators) between objects in order to make the architecture more flexible. This approach elevates events to the level of architectural design abstractions, making them dual to, and as fully general as, operations (e.g., having names, type signatures, semantics). Execution models for distributed object systems have been based completely on events instead of on synchronous message sending. For example, [JS92] describes a distributed active object system based on this approach. Each node in this system is defined as containing:
Some of the kinds of additional interfaces identified in the process of further reifying distributed object systems exist now in commercial products (e.g., ORB vendors typically provide proprietary hooks of various kinds, as noted earlier). Current work in OMG on such things as security interceptors and the Portable Object Adaptor specification are examples of attempts to provide specifications for these "more internal" interfaces based on a standard (and hence portable) reification of distributed object system components, and on a more structured analysis of requirements.
The term aspects comes from Aspect-Oriented Programming (AOP) [KLMM+97]. AOP is a programming technique that recognizes the existence of aspects of a program that cut across its decomposition into modules or components. The general distinction is that a property of a system that must be implemented is:
AOP is an extended application of work in computational reflection and the design and use of metaobject protocols. In AOP terms, metaobject protocols are lower-level aspect languages whose join points are the hooks that the reflective system provides. Hence, reflection is a tool which can be used in AOP. For example, in some cases, an aspect language may be implemented as a metaprogram, called at each method invocation, which uses join point information and the aspect program to know how to appropriately deal with the requirements of the aspect. [KLMM+97] notes that they have sometimes defined aspect languages by first developing simple metaobject protocols for the component language, and then prototyping imperative aspect programs using them. Later, once it is understood what the aspect programs need to do, more explicit aspect language support can be defined.
Aspect languages can be viewed as a way of providing the power available when using runtime reflective access to key parts of a system (such as method invocation) without the difficulty, or the danger that the developer will abuse that power. AOP extends the idea of reification described in Section 4.1 to consider what are in effect multiple metaobject protocols (represented by aspect languages), one per IQoS aspect.
The use of the aspect concept can be helpful even if full-blown support for AOP is not available, by helping to structure the consideration of each IQoS characteristic separately. Separate metaobject protocols could be defined for the collections of metalevel objects representing the reifications necessary to deal with the different IQoS characteristics. The operations in these metaobject protocols could then be invoked at appropriate points in the control flow to achieve the required IQoS functionality. However, AOP in its purest sense involves more than simply separating components representing functional computation from components providing IQoS-related services. Rather, it involves the ability to have multiple views of the complete system, the different aspect-oriented views cutting across (being independent of) the encapsulation boundaries represented by the components, and being tailored to best-represent the representation of a particular IQoS characteristic, together with tools which can use these views to build a complete system. For example QuO provides a language (QDL) for describing aspects of an application's QoS and a code generator (similar to the AOP weaver) to create a single application from all the descriptions and functional code.
The value of having multiple tailored views of data in a database is well understood. Additional research is necessary to provide similar capabilities for programs (of which the original AOP work was a start). AOP represents an unconventional programming model. The challenge is to provide common abstractions for viewing each IQoS characteristic as a separate aspect, mechanisms for defining and enforcing consistency relationships among the views (a subject discussed in [Tho98]), and tools which can weave the resulting programs together (and take them apart when necessary) in building operational systems.
Component and other metadata is a key element in making use of the various forms of reification described earlier. It is necessary to describe components, their functional capabilities, and their IQoS characteristics and requirements, as well as system level IQoS characteristics and requirements which cut across components. It is used, for example, in Trading Services to enable choices to be made among components or services which provide the same functional interfaces, but which differ in various IQoS characteristics. It is also necessary in defining mappings between high level descriptions of IQoS requirements (e.g., end-to-end requirements) and descriptions of IQoS capabilities provided by lower level parts of the system (e.g., network bandwidth). QuO's Quality Description Language (QDL) is an example of a language used for explicitly specifying IQoS metadata.
Metadata is also critical in making components and systems flexible, evolvable, and scalable. For example, when a component describes the services it wants from other components rather than directly referring to those components, it allows the alteration of the component bindings when requirements change, or when components change or become unavailable. Additional metadata also allows the use of more heterogeneous components, since in a heterogeneous environment less mutual unterstanding can be assumed to be already built into components, and hence more information must be provided explicitly in metadata.
This requirement for more (and better) metadata involves the need for more precise semantics for metadata, and common agreements on those semantics. In the context of IQoS, this means that definitions of IQoS characteristics, and the parameters that describe them, must become more formal and standardized. Such standardization has taken place in some parts of distributed architectures, e.g., in the network management area, but must be extended more generally.
Numerous levels of agreement among components (e.g., on data formats, significant processing events, and messages to be interchanged in various circumstances) are generally necessary to construct systems based on reusable components. Such agreements are necessary because without them, even if two objects were semantically compatible, they would probably be unable to directly interoperate. A typical analogy used is that of the boards in a computer system, and the agreements on timing, voltages, and protocols that must exist in order to have an open component market with standard bus architectures. These sorts of agreements among objects are those that typically characterize an object framework. [GHJV95] describes a framework as a set of cooperating classes that make up a reusable design for a specific class of software, such as graphical editors, compilers, or financial modeling applications. A framework is generally customized to a particular application by creating application-specific subclasses of abstract classes from the framework. [GHJV95] notes that a framework defines the overall architecture of the application (or a specific part of it), including the overall structure, its partitioning into classes and objects, the key responsibilities of those classes and objects, how they cooperate, and the thread of control. A framework predetermines these aspects of a design so that the application developer can concentrate on the specifics of the application. In addition, because the patterns of interoperation between participating objects and classes are predefined, and the enabling assumptions built into the participants, specialized subclasses (assuming they do not change these assumptions, or that new assumptions are not introduced) are guaranteed to be able to cooperate.
A framework captures design decisions that are common to its application domain. Frameworks thus emphasize design reuse over code reuse, though a framework will usually include concrete subclasses that can be used immediately. Larger object-oriented applications can use a collection of cooperating frameworks. For example, Taligent's Common Point Application System [Tal95] defined a collection of frameworks that could be used in this way. When frameworks are used properly, most of the design and code in an application will come from, or be influenced by, the frameworks it uses.
The use of frameworks is becoming increasingly common and important. Frameworks emphasize the fact that the range of agreements that must exist to support advanced forms of interoperability, such as "plug and play" among components purchased from independent software vendors, must generally be based on a unified design approach, together with consistent standards. The framework can be designed to provide built-in architectural functions and proven architectural properties. Based on the predefined characteristics of the framework, associated tools can combine framework/architecture-provided services based on declarations, and incorporate user-provided application logic into "the right place". QuO [ZBS97] is an example of framework concepts applied specifically to the problem of incorporating QoS in distributed applications. The OIP project [Fil98] is also taking the approach of developing a set of QoS frameworks.
Some of OMG's work is based on the idea that, in order to provide functionality of direct interest to end users in particular application domains, application frameworks will need to be built in terms of objects that provide application, domain, facility, and service interfaces from the categories of interfaces defined in OMG's Object Management Architecture. For example, OMG's work on "Business Objects" has been largely based on this approach. In addition, developments within OMG of increasingly detailed service specifications, security service interceptors, POA, etc. can be considered as moving the OMG specifications in the direction of becoming more a collection of frameworks for addressing various issues.
The development of frameworks for dealing with IQoS issues does not
directly address the problem of what to do about the existence of more
than one such framework (e.g., the problem of interoperation between components
developed for one framework and components developed for a different one).
Adapters can probably be developed to deal with many of these cases, just
as adapters have been developed to deal with corresponding issues in hardware.
OMG's work on CORBA/COM interoperability is an example of the type of work
that is required here. While in an ideal world it would be possible
to efficiently deal with arbitrary amounts of component heterogeneity,
in practice this is unrealistic. It is similarly unrealistic to expect
that everyone will adopt a single framework of this type. However,
the reduction of the number of distinct frameworks to a few well-architected
ones would help the situation a great deal.
Further work is needed on a basic, more thorough understanding of IQoS. There are no common or precise definitions for IQoS characteristics, and their parameters. These definitions are needed as a basis for metadata definitions, and engineering goals. Research is also needed on how to classify applications in terms of their IQoS requirements. There is a great deal of knowledge lacking as to what is useful, not just in terms of the metadata descriptions of systems, but even in what basic system properties are important. Methodologies are also required both to analyze IQoS requirements, and to employ the various available technologies for addressing these requirements.
More work is also needed on how to define mappings from high level statements of IQoS requirements to configurations of components (and invocations of those components) that define implementations which provide the required characteristics (e.g., how to go from a requirement that a system be "secure" to a code specification for a particular kind of encryption). The ability of an application to characterize its IQoS requirements abstractly improves the flexibility with which IQoS can be provided. For example, a given IQoS characteristic can be provided by alternative combinations of lower-level service invocations, and these can be interchanged as necessary (e.g., if one service goes down) without affecting the application. Similarly, as application requirements or the definitions of satisfactory levels of IQoS characteristics change, the underlying mapping can change too.
Work is also needed on how to control the visibility of IQoS issues, so that application developers are not overwhelmed with the complexity of dealing with these issues. The key word here is control (rather than, e.g., eliminate). The ideal situation is sometimes described as complete transparency of IQoS, but this is in some cases inappropriate, and in other cases impossible. There are complex design and implementation issues which constrain how transparent a given IQoS capability can or ought to be. This is partially an issue of deciding where responsibilty for managing a given IQoS characteristic lies. For example, the reliability provided by a DBMS's transaction mechanism to a typical database application cannot be totally transparent to that application, because the definition of transaction boundaries is part of the application semantics. However, this does not mean that the application must be aware of all the details of that mechanism (e.g., manage individual locks). Similar considerations apply to completely insulating applications from the need to be aware of distribution. As noted in [WWWK94], this is only possible up to a point; in some cases, applications must make provision for dealing with some of the issues that arise in distribution. The basic requirement is to separate the ability to characterize application requirements for a given IQoS service in a reasonably abstract way on the one hand, from the requirement that the application be totally aware of the implementation of that service, and involved in managing it, on the other. In the case of database access, the transaction abstraction has been developed which deals with this problem. Similar abstractions are required for other IQoS characteristics.
Visibility is also an issue in dealing with the distinction between IQoS-aware and IQoS-unaware components. It is often convenient to be able to use existing components that may be IQoS unaware in an environment requiring IQoS capabilities without changing the components, perhaps just by wrapping them. Simplicity, seamlessness, and separation of concerns as well as cost favors this approach. But it some cases it may be necessary to break the encapsulation of a component to make it more IQoS-aware. Further work is needed to more fully understand the situations in which wrapping can be used to handle specific IQoS requirements, to identify how to define such wrappers, and to develop technologies to deal with situations in which wrapping will not work. For example, [GHM96] discusses an approach for analyzing the transactional capabilities supported by a collection of heterogeneous encapsulated components, identifying the transaction models which can be natively supported by that collection of components, and determining whether additional transaction models could also be supported by those components through the use of a set of add-on transactional services.
More work is also needed on when, where, and how to install IQoS. For example, while the general idea of reifying communication for inserting IQoS functionality seems basically reasonable, many questions remain to be answered about the details of using this general approach. More knowledge is required on what the appropriate architectural connection mechanisms need to be in order to provide adequate generality and ease of use in adding IQoS functionality (i.e., do we need expansion joints, interceptors, proxies, injectors, higher-order connectors, program managers, mediators, wrappers, filters, before-after methods, rules?), and whether this depends on the particular IQoS characteristic involved. More work is also needed to understand IQoS issues that may arise in employing these techniques (e.g., additional security requirements, since only authorized users should be able to install new behaviors in systems). Finally, more work is needed on understanding the range of system architectures into which IQoS characteristics can be injected.
Further work is also needed on understanding how to consider IQoS characteristics as multiple aspects with their own "aspect languages", and how to "weave" these aspects together to form complete systems. This involves consideration of numerous technical details of how to define the separate aspects, "weaving" techniques, etc. This may require the development of more advanced object/component models, more amenable to being broken up into aspects (supporting multiple views) and put back together than the current ones. At the same time, this also involves a greater understanding of higher level issues such as how IQoS characteristics compose, when they might interfere with each other, and tradeoffs among them (e.g., between reliability or accuracy and performance). For example, [Wel98] describes a number of issues involved in merging QoS concerns and survivability. Similar work is required for other IQoS characteristics. Needless to say, this work will become increasingly complex as additional numbers of IQoS characteristics are considered together. Work is also needed on tools to assist in evaluating possible conflicts and tradeoffs between these characteristics. For example, [Tho98] describes some discussion on the potential use of type and constraint systems to enable automated reasoning about systems and their compositions from parts, and which could validate consistency of aspect specifications when they are "woven".
Work is also needed on ensuring that performance and scalability requirements can be met while using these various techniques. Scaling issues have sometimes been a concern in distributed object systems when considering just functional computation. The addition of IQoS issues complicates the problem still further. For example, a discussion reported in [Tho98] identified, for security alone, such scaling factors as:
Work is also needed to investigate further integration of ORB technology and IQoS-related extensions with other infrastructure technology such as distributed operating systems. In a distributed object system, the ORB plus services plays a central role that is somewhat similar to the role of an operating system, but the ORB does not directly manage many of the resources involved. These resources are controlled by the various operating systems in the network. Distributed object-oriented operating systems such as Legion [GG99] <http://www.cs.virginia.edu/~legion/> illustrate the merger of distributed object and operating system technology. Such a merger could, for example, provide better means for ensuring that IQoS requirements are enforced. At the same time, of course, the implementation of operating systems, applications, and middleware in terms of objects tends to blur distinctions between such levels of software. Similar considerations apply to the Internet (e.g., the Web), considered as another "infrastructure technology".
Finally, further work is needed on architectures and frameworks which
provide structured environments for incorporating IQoS characteristics,
and for applying these various approaches. The work on further defining
(in fact, reifying) parts of the OMG OMA infrastructure to support QoS,
security, real-time, and other requirements is an example. Work is
also needed on dealing with the likely existence of more than one such
framework (OMG's work on CORBA/COM interoperability is an example).
All this work needs to be based on input from domain and technology groups
which have a background of work in relevant areas, e.g., the real-time,
security, and telecommunications communities,
in a way that merges the relevant technical experience of these groups.
The OMG in fact provides a venue where this can be done, even if the results
are applied in what are, strictly speaking, "non-OMG" technologies (e.g.,
Java-based systems).
I wish to acknowledge the helpful input of
Craig Thompson for important contributions to the ideas in this paper.
[AKFP+93] G. Agha, S. Frolund, W. Kim, R. Panwar, A. Patterson, D. Sturman, "Abstraction and Modularity Mechanisms for Concurrent Computing", IEEE Parallel and Distributed Technology 1(2), May 1993, 3-14.
[Ash98] C. Ashford, The TINA Service Composition Architecture, position paper, OMG-DARPA Workshop on Compositional Software Architectures, January, 1998 <http://www.objs.com/workshops/ws9801/papers/paper035.html>.
[BFHH+98] E. Brady, B. Fabian, M. Harrell, F. Hayes-Roth, S. Luce, E. Powell, G. Tarbox, "The Advanced Technology Architecture for Information Superiority", draft 10/16/98.
[CM93] S. Chiba and T. Masuda, "Designing an Extensible Distributed Language with a Meta-Level Architecture", Proc. Eur. Conf. on Object-Oriented Programming, 1993, 483-501.
[Fil98] R. Filman, Injecting Ilities, Workshop on Aspect Oriented Programming, ICSE-20, Kyoto, Japan, April 1998, <http://www.mcc.com/projects/oip/papers/inj_iliites.htm>.
[FNPS+95] J-C Fabre, V. Nicomette, T. Perennou, R. J. Stroud, and Z. Wu, "Implementing Fault Tolerant Applications Using Reflective Object-Oriented Programming", Technical Report No. 517, University of Newcastle upon Tyne, May 1995 (NTIS PB95-258703).
[GG99] D. Gannon and A. Grimshaw, "Object-Based Approaches", in I. Foster and C. Kesselman (eds.), The Grid: Blueprint for a New Computing Infrastructure, Morgan Kaufmann, 1999.
[GHJV95] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, Reading, MA, 1995.
[GHM96] D. Georgakopoulos, M. Hornick, and F. Manola, "Customizing Transaction Models and Mechanisms in a Programmable Environment Supporting Reliable Workflow Automation", IEEE Trans. Knowledge and Data Engrg., 8(4), August 1996, 630-649.
[Han97] G. Hansen, Quality of Service (QoS), Technical Report, Object Services and Consulting, Inc., January, 1997, <http://www.objs.com/survey/QoS.htm>.
[KLMM+97] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda. C. V. Lopes, J.-M. Loingtier, J. Irwin, Aspect-Oriented Programming, Proc. European Conf. on Object-Oriented Programming, Finland, Springer-Verlag LNCS 1241, June 1997 <http://www.parc.xerox.com/spl/groups/eca/pubs/papers/Kiczales-ECOOP97/for-web.pdf>.
[KRB91] G. Kiczales, J. des Rivieres, and D. G. Bobrow, The Art of the Metaobject Protocol, MIT Press, Cambridge MA, 1991.
[Mae97] Pattie Maes, "Concepts and Experiments in Computational Reflection", Proc. OOPSLA '87 Conf., ACM, Oct. 1987.
[MKIC92] P. Madany, P. Kougiouris, N. Islam, and R. H. Campbell, "Practical Examples of Reification and Reflection in C++", in A. Yonezawa and B. C. Smith (eds), Proc. Intl. Workshop on New Models for Software Architecture (IMSA) '92: Reflection and Meta-Level Architecture, Tokyo, November 1992.
[MMAY95] H. Masahura, S. Matsuoka, K. Asai, and A. Yonezawa, "Compiling Away the Meta-Level in Object-Oriented Concurrent Reflective Languages Using Partial Evaluation", Proc. OOPSLA '95 Conf., ACM, Oct., 1995.
[Mok98] A. Mok, The Objectization Problem - What It Is and What Can be Done About It, position paper, OMG-DARPA Workshop on Compositional Software Architectures, January, 1998 <http://www.objs.com/workshops/ws9801/papers/paper037.ps>.
[Pav96] J. Pavon, "Toward Integration of Service and Network Management in TINA", Journal of Network and Systems Management, 4(3), 1996, 299-318
[SKN96] K. Sullivan, I. Kalet, D. Notkin, "Evaluating the Mediator Method: Prism as a Case Study", IEEE Trans. Software Engrg., 22(8), August 1996, 563-579.
[SRD99] R. Stewart, D. Rai, S. Dalal, "Building Large-Scale CORBA-Based Systems", Component Strategies, 1(7), January 1999.
[SW96] R. Stroud and Z. Wu, "Using Metaobject Protocols to Satisfy Non-Functional Requirements", in [Zim96], 31-52.
[STLW97] C. Sluman, J. Tucker, J. LeBlanc, B. Wood, "Quality of Service (QoS) OMG Green Paper", Object Management Group, Object and Reference Model Subcommittee of the Architecture Board, OMG Document Number ormsc/97-06-04, December, 1997.
[Tal95] Taligent, Inc., The Power of Frameworks, Addison-Wesley, Reading, MA, 1995.
[Tho98] C. Thompson (ed.), OMG-DARPA Workshop on Compositional Software Architectures, Monterey, California, January 6-8, 1998, Workshop Report, February 15, 1998, <http://www.objs.com/workshops/ws9801/report.html>.
[Tys98] K. Tyson (ed.), "Reference Model Extension Green Paper", Object Management Group, Object and Reference Model Subcommittee of the Architecture Board, OMG Document Number ormsc/98-05-02, November, 1998.
[WBT92] D. Wells, J. Blakeley, C. Thompson, "Architecture of an Open Object-Oriented Database Management System", IEEE Computer, 25(10), October, 1992, 74-82.
[Weg89] P. Wegner, "Granularity of Modules in Object-Based Concurrent Systems", in G. Agha, P. Wegner, and A. Yonezawa (eds), "Proc. ACM SIGPLAN Workshop on Object-Based Concurrent Programming", SIGPLAN Notices, 24(4), April, 1989.
[Wel98] D. Wells, QoS & Survivability, Technical Report, Object Services and Consulting, Inc., August, 1998, <http://www.objs.com/Survivability/QoS&Survivability.htm>.
[WWWK94] J. Waldo, G. Wyant, A. Wollrath, and S. Kendall, A Note on Distributed Computing, SMLI TR-94-29, Sun Microsystems Laboratories, Inc., November 1994 <http://www.smli.com/techrep/1994/abstract-29.html>.
[Yok92] Y. Yokote, "The Apertos Reflective Operating System: The Concept and Its Implementation", Proc. OOPSLA '92 Conf., ACM, Oct. 1992.
[ZBS97] J. Zinky, D. Bakken, and R. Schantz, "Architectural Support for Quality of Service for CORBA Objects", Theory and Practice of Object Systems, 3(1), 1997, 55-73.
[Zim96] C. Zimmermann, Advances in Object-Oriented Metalevel Architectures and Reflection, CRC Press, Boca Raton, FL, 1996.
© Copyright 1999 Object Services and Consulting,
Inc. (OBJS)
© Copyright 1999 Institute for Defense Analyses
(IDA)
Permission is granted to copy this document provided this copyright statement is retained in all copies.
Disclaimer: Neither OBJS nor IDA warrant the accuracy
or completeness of the information in this report.