(original) (raw)

��ࡱ�>�� ��
��������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������ܥhW� e:�{
��
@�j�jj�n�������V
V
V
V
V
b
v�
4V
�
i2
@r
�
�
�
�
Z�
<"





/2
�
��
a
X�
��
��B
at�
�
B
B
�
�
�����


&�
�
�
B
F���
���


��U;��
��&
@v�&��@����B


�
y�
Thoughts on *** DRAFT *** OMG Green Paper OMA-NG:� The Next Generation OMG Object Management ArchitectureOMA (Summary) Craig Thompson, OBJS, and Ted Linden and Bob Filman, MCC OMG ORMSC/97-09-01: OMG green paper (architectural discussion paper) *** full paper containing additional detail at http://www.objs.com/staging/OMG-OMA-NG.html *** Background: presentated to the OMG Object and Reference Model Subcommittee (ORMSC) at OMG Dublin the week of 22 September 1997. OMG ORMSC, which reports to the OMG Architecture Board, is currently considering whether and how to update its "Object Management Architecture Reference Model" (OMA-RM) and OMA Guide, which is the central architectural handbook of OMG.� Thesis: In the near future, it will no longer be good enough forto provide an architecture tohat merely enables the desired behavior (program semantics). Instead, there are a host of other system properties, or �ilities� (e.g., reliability, interoperability, security, quality of service, manageabilitymanagability, extensibility, and scalability) that users will rightly come to expect the OMA to support. Target: extensions needed to the OMG Object Management Architecture Guide, especially the "OMA Reference Model" Acknowledgments: reflects lessons learned in OBJS DARPA projects, MCC OIP project, and NIIIP (�users with a clue�) OMA-RM and OMA Guide History OMA RM 1.0 � 1990 � described ORB, Object Services, Common Facilities, and Application Objects. Chapter in OMA Guide, which included other chapters: Introduction, Overview, Technical Objectives, The Object Model, Glossary OMA RM 2.0 � 1992 revision � added the explicit mention of the Interface Description Language and IDL and the CORBA specification. OMA RM 3.0 � 1995 revision (the current official version, ab/97-05-05, ftp://ftp.omg.org/pub/docs/ab/97-05-05.ps) removed some examples of object services and common facilities, replacinged them with explicit reference to adopted CORBAservices and CORBAfacilities. The glossary was slightly reduceddownsized from the 1992 version. The object model chapter has been revised into the �Core Object Model.�that may lead to upgrades in the OMG Object Management Architecture Reference Model (OMA-RM) and the containing OMA Guide, which is (was once) the central architectural handbook of OMG.�� The paper is for presentation to the OMG Object and Reference Model Subcommittee at the OMG Dublin ORMSC meeting the week of September 22 1997.�� The paper contains two kinds of discussion:� in a few places, we point out changes needed to improve or upgrade the OMA-RM or OMA Guide to current practice.� But mostly the paper contains ideas on architectural directions OMG needs to head to meet the challenges of the next several years. *** FOURTHFIRST DRAFT �-- September 10August 13 1997 *** Purpose of this paper:� The central architectural documents of the OMG, the OMA-RM and OMA Guide, are being revised by the OMG Object and Reference Model Subcommittee (ORMSC) to reflect the challenges of the next few years. Both the Object Services and Consulting�s (OBJS) Scaling OSAs to the Internet and Microelectronics and Computer Technology�s Object Infrastructure projects have been dealing with distributed object issues beyond the frontier of the current architecture. This paper aims to relayprovide the architectural guidance based on lessons learned in these OBJS project Scaling OSAs to the Internet project and the MCC project Object Infrastructure pProjects to the ORMSC. the OMG Object and Reference Model We Subcommittee at the OMG Dublin ORMSC meeting the week of September 22 1997.� The paper hope our proposals will lead to discussions, and, ultimately, proposes some areas for discussion that may lead to upgrades in these documents. OMG Object Management Architecture Reference Model (OMA-RM) and the containing OMA Guide, which is the central architectural handbook of OMG. Please send comments to Craig Thompson, thompson@objs.com, ASAP before September 22 1997. Status of this draft:� the current draft is not finished.� In particular, it leaves open slots for MCC projects on real-time, QoS, system management, and replication service to contribute paragraphs.� It allows for additional authors (Carol Burt?, DARPA ISO Architecture team?, NIIIP architects) who could add their experience.� It is open to improvement on any part but requests for input are especially solicited in the areas of dispatch mechanisms, interceptors, and extensions prior to the OMG Dublin meeting.� And of course corrections are solicited -- OMG specs cover a lot of territory and so does evolving practice -- some perceived problems may be non-problems so let us know about these too. Bunch of suggested changes by Bob to make the second draft. Ted's stuff on composition make the third draft More changes by Bob to make the fourth draft. ***FOR INTERNAL USE ONLY *** This document is a first draft and is expected to change based on inputs from OBJS, MCC and sponsors including MCC and DARPA sponsors.� Release is contingent on MCC paper release approval and DARPA/ARL paper release approval.��� Release approval is requested no later than September 22 1997 but earlier release to OMG will allow participants in discussions to have read the paper before the meeting. 1996 revision of OMA RM by Geoff Lewis at the Madrid OMG meeting � approved by the OMG Architecture Board. It removed examples of object services and common facilities, replacinged them with explicit reference to adopted CORBAservices and CORBAfacilities;, and added a paragraph on Domain Interfaces and three pages on Object Frameworks.� The latter describes a hierarchy of application, domain, common facility, and object service frameworks that are compositions (e.g., by interface inheritance or client requests) of application, domain, common facility, and object service objects. This included the adding a conceptual notion that higher level objects may call lower level objects (e.g., common facilities call object services).� It says that the specification of an Object Framework "defines such things as the structure, interfaces, types, operation sequencing, and qualities of service of the objects that make up the framework."� The 1996 resulting OMA-RM was just seven pages long. Discussion of the Object Management Architecture (http://www.omg.org/library/oma1.htm) Another version of the OMA-RM and some of the chapters in the OMA Guide was developed for the CORBA Academy and appears in online. It includes the 1996 RM and includes descriptions of adopted object services. What the OMA-RM does not explain The OMA-RM does not explain nor does it preclude a long list of desirable architectural extensions.� Some of these are presaged in the original OMA Guide "Overview" and "Technical Objectives" sections but are not yet realized in the OMA. They and are candidates for addition to these sections.� Possible Extensions to the OMA Candidate Extensions Summary architectural principles and properties (the -ilities) and, frameworks composability and componentware - containment model, binding time, packages, interceptors, extensions, guards, economic model scalability via federation performance guarantees and system management - real-time, quality of service, system management convergence with the competition - componentware, Java, web, DBMS, KBMS, mobile code, agent management architecture, RM-ODP, patterns Other extensions - semantics, object model extensions, domain interface architecture, needed interfaces Conclusions and Recommendations Architectural principles and properties (the -ilities) and, frameworks Architectural Principles. The OMA-RM does not explicitly mention the "architectural principles" that were first described in the   PRIVATE HREF="http://www.omg.org/docs/1992/92-08-01.ps"MACROBUTTON HtmlResAnchor Object Services Architecture and now appear in the RFP template. It should refer to these principles explicitly. The architectural principles should probably become a chapter or section in the OMA Guide. Architectural Properties. The OMA-RM does not currently say much about desirable architectural properties (beyond interoperability and security). The OMA is beginning to address quality of service, real-time, and composability. We discuss specific ilities in greater detail below. Interoperability, composability, scalability, evolvability, extensibility, tailorability, security, reliability, adaptability, survivability, affordability, maintainability, understandability, performance, quality of service, real-time, nomadicity. Architectural Principles The OMA-RM does not explicitly mention the "architectural principles" that were first described in the   PRIVATE HREF="http://www.omg.org/docs/1992/92-08-01.ps"MACROBUTTON HtmlResAnchor Object Services Architecture and now appear in the RFP template. It should refer to these principles explicitly. The architectural principles should probably become a chapter in the OMA Guide. Architectural Properties (-ilities) The OMA does not say much explicitly about how to achieve architectural -ilities.� One of the chief objectives of the OMA is interoperability but there is no discussion on interoperability in the OMA-RM.� The OMG OMA does address security and is beginning to address QoS, real-time, and composability. More on specific ilities below. <<what�s the="" purpose="" of="" this="" (frameworks)="" section??="">> Terminology. There has long been a question as to what the technical distinction is between object services and common facilities, even between platform and domain (e.g., is workflow Platform or Domain Technical CommitteePTC or DTC? <>).� Historically, such technical distinctions were mostly ignored and have mainly been treated as convenient intra-organizational divisions of labor.� Frameworks. But the 1996 OMA-RM section on frameworks is three pages long (where the Domain Interfaces section is one short paragraph). It describes an explicit hierarchy of application objects, domain objects, common facilities, and object services, and gives no concrete examples of object frameworks so they remain abstractprovides nary a single example of an object framework.gives no examples of object frameworks so they remain abstract.� Frameworks appear to be constellations of objects that operate together.� But most object services and common facilities define more than one object class.� So it is not really clear how common facilities and common facility frameworks would differ.� For instance, are OODBs, workflow systems, KBMS systems, repository management systems, and BOFs such frameworks or are they common facilities? The section on frameworks needs to be re-thought since at present frameworks are really a research area at OMG. Composability and componentware - containment model, binding time, packages, interceptors, extensions, guards, economic model From the beginning, high level goals of OMG have included reusability, interoperability, extensibility, and dynamic evolution.� Current specifications do not provide enough information to realize the desirable the goals of being able to mix-and-match and plug-and-play with alternate implementations of services or facilities.� Composing services with application objects. The interweaving of separate concerns is especially serious in the cases where the service requires insertion of functionality at the calling side of an interaction, as occurs with services such as encryption, authentication, and replication. To make services appear as componentware within an application, we need better and more structured ways of adding services while minimizing their impact on the application code. Often, service functions can be implicit in application method invocations. Frameworks can protect the application code from being intertwined with calls to service functions. However, it is not clear how to add (chain?) or control implicitly specified services.� Binding times for adding services are not specified nor is there any mechanism to control which users can add services dynamically. Service Interactions. According to the IEEE, an architecture is a collection of functions and interconnections.� Interconnections reveal the relationship between the functional components. Ironically, by mapping calling trees to a set of functions communicating over a single message dispatch bus, OMG has provided only the definition of functions and not the information about interconnections. we still have little experience connecting the services on the bus together to do useful work OMG users expect higher level OMG objects like facilities to be composed partly from lower level services and they want the ability to spin out stable internal components for independent reuse. Uses specification or Containment Model needed. Some sort of uses specification is needed to declaratively relate implementations to interfaces on which they depend. Alternatively, some sort of explicit containment graph is needed to relate a higher level component to components it contains or depends on. Hopefully, the CORBA Component RFP will address this. Binding Times.� The OMA-RM does not address how dynamic the binding is for adding new services to existing frameworks (though the old Technical Objectives chapter of the OMA Guide did mention Extensible and dynamic changes like adding new implementations, replacing implementations where the interface has not changed, replacing implementations where the interface is changed, and changing the location of implementations). Dynamic Dispatch, Interceptors and Extensions, Need for Guards.� OMA needs a generic mechanism for specifying these implicit service actions without expecting the application programmer to understand and manage all this implicit functionality. The interceptors above are just some of a large family of implicit (or explicit) side-effect extension behaviors that set up boundaries that need guards to enforce that the extensional behavior is not bypassed.� Others are: crossing intellectual property boundaries - license objects before use micropayment boundary - install payment and collection replication and consistency management - for availability and fault tolerance annotations - so comments and expertise from others can be added to a source object like a document derivation histories - so copied objects retain the source of the copy removing duplicate postings adding or filtering out advertisements (removing spam via keywords FREE, CASH, RICH, SALE, etc.) More Packaging Technology Needed.� Principled selection and decomposition into subcomponents can enable substitution and customization by developers other than the original designers.� But there are reasons to hide containment information as well: Who can install Interceptors?� If anyone can add or modify a service's interceptors, then there can be no guarantees that the objects are guarded by interceptors.�This implies that we need inviolate ways for application developers to package interceptors, controlling which can be added or removed and what information is available to each. And it must be understandable at a high enough level that it is easy to do and does not cause developer errors. In a way, instead of putting data objects into a database, one can think of the data objects as guarded by a set of extensional behaviors like persistence, security, replication, versioning, distribution. What was formerly a monolithic DBMS might become a collection of guards that form a sort of DBMS exoskeleton. The flexibility is in being able to add new services modularly to the list to create the kind of data store you want. A puzzle for OMG is how to represent the list of behaviors (before and after methods, a schedule, context variable, and so forth) to insure proper control. Roles.� Another architectural concept related to packaging not mentioned in the OMA Guide is roles. Different classes of developers might want to install different interceptors: the security group may want to insure that a certain security policy is followed the system management group may want to insure uniform system monitoring and may want a load balancing ability to move objects across distribution boundaries without affecting application semantics the configuration board may want to insure versioning a system administrator may want to insure that conversions occur to unpack compressed files In some cases, a developer wants to install a certain family of interceptors and then seal off the ability of anyone else to augment (that part of) the interceptor list.� (In fact, this corresponds to how we build stovepipe systems today as particular compositions of particular capabilities with little access to how to add other capabilities or customize or extend the ones that are in the system.) If not everyone can replace at will any part of an OMG architecture at any time, then the abstract notion of roles is needed to complement the packaging idea.� Roles might be global to an OMG system (e.g., CORBA vendor, developer, end-user) or local to an abstraction of the system (e.g., the system management role, the security administration role, the configuration management role, the DBA).� At present in the OMA there is no structural way to associate roles with responsibilities over parts of the architecture.� Roles appear to be related to packaging. Policies. If there are multiple implementations of services and variations on how the service can work then there also need to be policies that control the services� behavior. Some related issues: Footprint.�� Debugging and run-time fault resolution, finger pointing Complexity.�� Another problem with componentware is the same as with toolkits � too many interfaces are exposed. OMG provides a small forest of separable specifications. This has the benefits of conceptual isolation and potential reuse. However, it also has the drawback of complexity. Each application composes the services into the application in unique and idiosyncratic ways. Programmers are used to the complexity of subroutine and class libraries, and used to cursing the complexity of these libraries as they grow large. Distributed systems add the additional complication of requiring ilities to be implemented consistently, system-wide, throughout the application. It might make most sense if there are standard configurations of services and facilities (the analog of DBMS, KBMS, workflow, etc.) and interceptors dispatch to these (maybe that is what a common facility or a framework is, a named configuration?). The NIIIP Consortium uses such a mechanism, which it terms a virtual enterprise object � every ORB request is shunted through a VE gateway which governs a collection of common decisions made when the VE is constructed. Tailorability. How easy is it for a developer to tailor a system, framework, facility, or service developed by others to meet the developer�s needs. Given frameworks A and B with function f only available in B, how can users of framework A get this extra function f if they need it? Adaptability and Survivability. Can large systems developed with componentware gracefully degrade Multiple dispatch overloading mechanisms: are they all needed?� Interceptors, POA, and Trader Higher level Dynamic Dispatch Mechanisms than interceptors and POA.� Rules, filters, and before-and-after methods � Portability. How to state environmental constraints on components. Most legacy code encapsulated as components will be pinned to the environment it is compiled into. Java Decompilation. The developer role has self-interest in exposing only some interfaces. Visible and Invisible objects.� It is not clear how to control visibility of objects in the OMA. Profiles.� This notion may need to be revisited since the extensions that are community idiosyncratic directly lead to interoperability problems at the borders of a profile. Examples: ODMG, STEP, UML Economic Model. Even if it is possible to separately isolate components for reuse, there must be a marketplace for making them available. ActiveX and JavaBeans marketplace is an encouraging sign. Scalability and federation Scalability is a desirable property of componentware: we want to build larger systems from components, unrestricted by the particular size or internal organization of the components. Build-time componentware definitions might cast scalability as the ability to build larger systems or systems of systems from component parts. An example would be composition as described above in which a common facility might be defined from object services, for example, an OODB as some composition of naming, persistence, query, transactions, security, etc. An important variant to composition of parts to form a whole is the special case when the parts are similar.� We can define   PRIVATE HREF="http://www.objs.com/staging/federation.html" MACROBUTTON HtmlResAnchor federation to be the composition of like systems that operate together to form a higher level system.� When there was just a single LAN-based CORBA, OMG could choose to not spend to much emphasis on federation interfaces.� But with CORBA interoperability and Visigenics fanned out the the Netscape desktop, the number of machines connected to an ORB might go from 40 to 40 million.� No longer should we assume that there is a single name service, a single transaction service, a single query service, a single trader, ... in such an environment.� Minimally, we'd expect many instances of these services.� And we'd expect them to interoperate with others of their kind, so that name services federate, transactions federate, and so on.� Not only services but also facilities should federate so workflow, OODBs, simulations, etc. would intercommunicate with others of their own kind. To achieve scalability via federation, OMG must address several architectural issues: And we'd expect them to interoperate with others of their kind, so that name services federate, transactions federate, and so on.� Not only services but also facilities should federate so workflow, OODBs, simulations, etc. would intercommunicate with others of their own kind. In many cases, the result of a federation is recursively similar in interface to the base level services (e.g., a query service that has the same interface to child query services).� But the result of a federation might be a different abstraction, so that a collection of softball players make up a team and team behave differently than individual players in that teams enter tournaments. There are a number of architectural questions that can be considered about federations that OMG needs to be asking because, for OMG to scale, it will need to understand more about federation. In many cases, the result of a federation is recursively similar in interface to the base level services (e.g., a query service that has the same interface to child query services).� But the result of a federation might be a different abstraction, so that a collection of softball players make up a team and team behave differently than individual players. Decentralizing control there is the question of central versus decentralized control. tDefining which interfaces of the components are interfaces of the federation as a whole and enforcing the interfaces required to participate in a federation. E.g., DBMS and HLA examples. here is the question of what abstractions of a system are being abstracted for federation.� So DBMS systems might federate via obeying the XA transaction protocol or they might federate via some mediating schema or both.� The High Level Architecture is a federation architecture for simulations that abstracts out system time and event to allow new simulations to enter an HLA simulation by agreeing on the protocols that define these two area. services need policy interfaces to specify and later to negotiate and resolve semantic conflicts between confederates, there is the question of how to compose service into a federation when they implement the same service with different policies, e.g., no versioning and branching versioning, discretionary access control and mandatory access control. Given two services or frameworks that are alike in all ways except for some policy p that governs some service s, what can we say about how they interoperate modulo that policy? Taken together, with both composition and federation as ways of building complex systems from simpler ones, one can come back to the question of ilities and talk about end-to-end X or top-to-bottom X where X = security, QoS/bandwidth adaptive, real-time guarantees, optimization, maintainability, reliability, affordability, licenseability for reasonable cost, testability, understandability, seamlessness, evolvability, survivability, etc.� When a system, for instance, a communications network is a federation of similar subsystems, then we can talk about end-to-end guarantees.� When a systems is composed of parts, we can talk about top-to-bottom guarantees. Taken together, with both composition and federation as ways of building complex systems from simpler ones, one can come back to the question of ilities and talk about end-to-end X or� top-to-bottom X where X = security, QoS/bandwidth adaptive, real-time guarantees, optimization, maintainability, reliability, affordability, licenseability for reasonable cost, testability, understandability, seamlessness, evolvability, survivability, etc.� When a system, for instance, a communications network is a federation of similar subsystems, then we can talk about end-to-end guarantees.� When a systems is composed of parts, we can talk about top-to-bottom guarantees. Performance guarantees and system management - real-time, quality of service, system management It is hard to keep your promises if those promises depend on things you can't control. Real-time and QoS. Tradeoffs in performance and other quality measures like precision, accuracy, and reliability can potentially pervade many components in a system.� Real-time and Quality of Service both involve capturing weather, accuracy, and other metadata from trend data and current data in a system and providing guarantees on certain outcomes, e.g., that a certain class of user might receive some negotiated level of service.�� Much of the QoS literature focuses on networks providing QoS guarantees to applications.� Higher-level applications are said to be bandwidth-adaptive or QoS-aware if they can take special advantage of guarantees made by lower levels of the system to themselves perform better and possibly make further guarantees to their own customer applications. The way real-time and QoS impacts the OMA is that sSo far CORBA, CORBAservices, or CORBAfacilities are QoS- and bandwidth-insensitive.� OMG is already actively focusing on real-time and QoS via the active Real-time SIG and QoS Working Groups.� [Doug Stuart] real-time service extensions. [Bob Filman] queue management service for QoS System Management. one reason many large installations are slow to adopt CORBA-based technology is the lack of system management facilities. System management involves performance measurement, accounting, intrusion detection and security, failure analysis and debugging, and configuration management. [Ted Linden]� Monitoring, run-time configuration management, fault identification, isolation, and repair, prototype GUI distributed system control panel.� All for use within a multi-vendor environment.� Relationship to ongoing work elsewhere. Convergence with the competition - componentware, Java, web, DBMS, KBMS, mobile code, agent management architecture, RM-ODP, patterns Componentware ActiveX Java Web DBMS KBMS Mobile code Agent Patterns RM-ODP Distribution Transparencies Viewpoints the enterprise viewpoint contains the notion of a a community (a configuration of objects formed to meet an objective) and an X-federation (a community of X-domains), roles played by the system (defining permissions, obligations, prohibitions and behaviors), policy statements, a system and its environment the information viewpoint contains schemas, invariant predicates, and specification of allowable state changes the computational viewpoint, engineering viewpoint, and technology viewpoints - these contain notions like cluster, interceptor, binder, checkpoint, recovery, channel, consistency rules and conformance statements among many others. ODP Functions - categories of ODP functions include system management, coordination functions, repository functions, security functions, non-repudiation functions The OMG and RM-ODP architectures overlap.� In some ways, ODP may provide the broader conceptual framework and OMG the more enunciated framework architecture.� Some substantial conceptual mapping would have to be done to do this wholesale since object services, common facilities, and domain interfaces plus OMG architectural principles do not seem to map exactly into ODP concepts Other extensions - semantics, object model extensions, domain interface architecture, needed interfaces Views of the Architecture. We need some additional views of the OMA architecture, not just the software bus view. Other views might explain how services are interconnected, how ilities are inserted, how visibility and packaging is supported, dataflow, physical distribution, etc. This is in addition or complementary to possibly adopting ODP viewpoints. Semantics: there is already activity in OMG to address the need to say more about specifications than just their interface and an English explanation of their intended semantics. Object Model Extensions Templates - there is no IDL template or genericmacro facility and no macro facility. CDL or JDL - the JBOF CDL extended IDL with ODMG ODL which includes ODMG relationships (which differ from OMG Relationships Service), extensions for collections of instances of a class and keys, and some other additions.� Some modelers have found these extensions useful. Rules - Like relationships, rules could either be thought of as an extension to an object model or as a service.� There are several kinds of related rules systems (ECA Rules, before-and-after rules).� In the last year, the NIIIP consortium made a valiant but so far unsuccessful effort toward getting OMG interested in   PRIVATE HREF="ftp://ftp.omg.org/pub/docs/cf/96-07-01.doc"MACROBUTTON HtmlResAnchor rules. Domain Interface Architecture Domain Interfaces Architecture (DIA) to guide OMG in how to populate the DTC space. Provide guidance on domain scope.� The potential space is very large.� Other domain standards populate parts of that space (e.g., STEP). other potential areas like logistics, command and control, and crisis management Needed Services and Common Facilities Change Management Service.� Replication Service.� [Stu Barrett]� Rules Service.� Planning Service(s).� Scheduling Service(s).� Uncertainty, Precision. Other Services and Facilities. Caching Service, Indexing Service, Parsing Service, Event Logging Service, Search Engine Facility, Information Access Facility/Object Transfer Manipulation Facility, ODBMS, KBMS, Conclusion and Recommendations Conclusions OMG OMA-RM must continue to evolve rapidly to survive since it does not stand alone -- there are rival technologies like ODP, agents, Java, and DCOM. � OMG must develop convergence stories. The OMA-RM has historically been and continues to be useful "as is.".� The most conservative position is to change it as little as possible since it has served as a permissive guide to allow many architectural extensions to be layered on top as the entire body of OMA is populated.� to be layered on top as the entire body of OMA is populateThe original OMA-RM reflected a vision of the future.� Now most of that future is well in place. Its role may need to grow to explain more about the architecture. We recommend: Ccontinuinge the current practice of replacing references to abstract parts of the OMA architecture (e.g., object services in the 1990 OMA-RM) with concrete references to named adopted CORBAservices in the 1996 OMG-RM).� The concrete portions serve as a high level reminder of the current scope of the OMA.� We need to dDetermine how to splice in abstract elements of the architecture in order to serve as a scoping guide to OMG directions while stillbut somehow distinguishing what has been done from what is planned. Oonly a very few abstract extensions should be adopted into the body of the OMA-RM document itself.� These should identify some key architectural directions for the entire OMA.� Some additions to the OMA-RM we believe are needed are in the next revision are: Mmention the architectural principles.� Add a short section on architectural properties ((-ilities) and mention scalability, evolvability, survivability, real-time, QoS, and systems management. Aadd some supporting examples of object frameworks to show how they are different from (especially) common facilities (or drop the concept). Changes that need to be made to the OMA Guide Add a new chapter to the OMA Guide containing the architectural principles and properties. Add glossary terms to the "Glossary" chapter. Candidates for additional terms include: domain interface, encapsulation, skeleton, stub, framework, component, containment model, external environment, packaging, identify, granularity, interceptor, extension, policy, governs or owns, boundary, seamless or implicit, exoskeleton, architectural principles, -ility, isolation, property, scalability, survivability, real-time, quality of service (QoS), naming, transaction, trader, and concurrency. Also see   PRIVATE HREF="http://www.objs.com/survey/ComponentwareGlossary.htm" MACROBUTTON HtmlResAnchor Componentware Glossary. Add glossary terms to the "Glossary" chapter.� Here are some candidates but there are more: domain interface encapsulation skeleton, stub framework, component, containment model, external environment, packaging interceptor, extension, policy, governs or owns, boundary, seamless or implicit, exoskeleton architectural principles, -ility, isolation property, scalability, survivability, real-time, QoS naming, transaction, trader, concurrency Update the "Technical Objectives" chapter to modularly include: technical objectives on architectural principals and ilities component model and packaging scalability by composition and federation evolution real-time and QoS technical objectives on architectural principals and ilities (component model and packaging, scalability by composition and federation, evolution, real-time and QoS.) technical objectives for ORB, services and facilities like trader, language mappings, scripting language technical objective(s) on domain interfaces interoperability with industry standards including the Web, Java and COM/ActiveX Differentiate requirements that have been met from requirements that are so far unmet (like versioning). Kkeep the OMA Guide up to date (annually) and use it as a primary OMG architecture guide. Desirable Properties of Software Architectures � Object Services and Consulting, Inc. 1996. How open and extensible are OMG frameworks?� Who can add new services to a barebones repository that only supported persistence and concurrency?� Can the developer add queries, versioning (if we had a definition for versioning), replication (if ...), and/or rules (if ...)?� Can any end-user do this? What is needed to allow this form of openness? From the beginning, high level goals of OMG have included reusability, interoperability, extensibility, and dynamic evolution.� OMG developer customers have wanted the ability to assemble applications quickly from standard parts, and OMA framework users were seeking a sort of consistent semantics (like a common look and feel only more general than just pull-down menus) for how shared services would work when using the full suite of OMG specifications.� We have made good progress in the separable specifications but have said too little about composition of services and facilities.� Current specifications do not provide enough information to realize desirable goals of being able to mix-and-match or plug-and-play with alternate implementations of services or facilities.� It is not clear how to add or control implicitly specified services.� Binding times for adding services is not specified nor is there any framework to account for which users have the ability to add services dynamically. In meetings before the ORB bus architecture was adopted (way back in 1989 and early 1990), discussions occurred in which different people argued that, for instance, yes, versions and DBMS functionality were both needed but no one was satisfied with any particular block diagram or calling tree showing some services explicitly calling other services.� When a bus architecture and a set of services hanging from the bus was proposed, it seemed to be a good solution to allow separately specified services and defer issues of how services compose.� OMG has followed this course for the last eight years.� But we still have little experience connecting the services on the bus together to do useful work.� As an aside, IEEE defines an architecture as a collection of functions and interconnections.� By mapping calling trees to a collection of functions and a single message dispatch bus, we have not really provided the part of the architecture that accounts for the interconnections. One way this has manifested itself in OMG discussions was in the specification of CORBAservices.� There was a tendency to want to state that one service might depend on another but a hesitation in claiming this about service implementations, which might or might not have explicit dependencies.� Another manifestation is that, because IDL objects encapsulate their implementations, there is no declarative way to state that one depends on another without examining implementations.� On the positive side, this provides implementation independence for clients of interfaces.� On the negative side, there is no way to declare dependencies of implementations on interfaces and so provide a way to replace one implementation with another.�� A side effect is that a high level component like a BOF may have no way to say how it is composed of Object Services (if it is).� OMG users expect higher level OMG objects like facilities to be composed partly from lower level services and they want the ability to spin out stable internal components for independent reuse. Uses specification or Containment Model needed. Some sort of uses specification is needed to declaratively relate implementations to interfaces. Alternatively, some sort of explicit containment graph is needed to relate a higher level component to components it contains or depends on. Hopefully, the CORBA Component RFP will address this. Binding Times and Packaging.� The OMA-RM does not address how dynamic the binding time is for adding new services to existing frameworks (though the old Technical Objectives chapter of the OMA Guide did mention Extensible and dynamic changes like adding new implementations, replacing implementations where the interface has not changed, replacing implementations where the interface is changed, and changing the location of implementations. Dynamic Dispatch, Interceptors and Extensions, Guards.� Good news about the OMG bus architecture is that it promises flexibility.� If object A calls object B using the bus architecture, then the call may be transparently local or remote and furthermore the call can be intercepted or filtered by any number of implicit operations which can be executed on the client or the server or somewhere in between to insure that concurrency control is respected if B is a shared object, that B is versioned or not, that A has authorization to access B, that B is coerced to a form that A can accept, that replication occurs, etc.� There is a long list of these implicit actions. Other kinds of guards.� The interceptors above were just some of a large family of implicit (or explicit) side-effect extension behaviors that set up boundaries that need guards.� Others are: crossing intellectual property boundaries - license objects before use micropayment boundary - install payment and collection replication and consistency management - for availability and fault tolerance annotations - so comments expertise from others can be added to a source object like a document derivation histories - so copied objects retain the source of the copy removing duplicate postings adding or filtering out advertisements (removing spam via keywords FREE, CASH, RICH, SALE, etc.) More Packaging Technology Needed.� Principled selection and decomposition into subcomponents can enable substitution and customization by others than the original designers.� But there are reasons to hide containment information as well: Java Decompilation - Java bytecodes contain names of classes, methods, and fields and reverse compilers can reconstruct class definitions.� Companies worry how to preserve their investments in designs.� Better compiler technology can protect against decompilers by making reconstruction harder for third parties by mangling names or rearranging statements.� But the main point is, this is a case where the developer role has self-interest in exposing only some interfaces. Who can install Interceptors?� - if generic interceptors are used in applications, it must be that not just anyone anytime can install new interceptors.� An obvious case is the original use of interceptors in security.� Here interceptors trap accesses to allow modular checking for security.� It must be the case that interceptors guard objects and there can be no backdoor. But even with such interceptors, if just anyone can add or modify interceptors, then there can be no guarantees that the objects are guarded by interceptors.� Some objects are guarded by many interceptors and some are guarded by only some of them.� So there must be a way for some application developers can package in an inviolate way which ones should be turned on and off. And how to install new ones. And it must be understandable at a high enough level that it is easy to do and does not cause developer errors. In a way, instead of putting data objects into a database, one can think of the data objects as guarded by a set of extensional behaviors like persistence, security, replication, versioning, distribution. What was formerly a monolithic DBMS might become a collection of guards that form a sort of DBMS exoskeleton. The flexibility is in being able to add new services modularly to the list to create the kind of data store you want. A puzzle for OMG is how to represent the list of behaviors (before and after methods, a schedule, context variable, �?) to insure proper control. Roles.� Another architectural concept related to packaging not mentioned in the OMA Guide is roles. Different classes of developers might want to install different interceptors: the security group may want to insure a certain security policy is followed the system management group may want to insure uniform system monitoring and may want a load balancing ability to move objects across distribution boundaries without affecting application semantics the configuration board may want to insure versioning a system administrator may want to insure that conversions occur to unpack compressed files In some cases, a developer wants to install a certain family of interceptors and then seal off the ability of anyone else to augment (that part of) the interceptor list.� (In fact, this corresponds to how we build stovepipe systems today as particular compositions of particular capabilities with little access to how to add other capabilities or customize or extend the ones that are in the system.) If not everyone can replace at will any part of an OMG architecture at any time, then the abstract notion of roles is needed to complement the packaging idea.� Roles might be global to an OMG system (e.g., CORBA vendor, developer, end-user) or local to an abstraction of the system (e.g., the system management role, the security administration role, the configuration management role, the DBA).� At present in the OMA there is no structural way to associate roles with responsibilities over parts of the architecture.� Roles appear to be related to packaging. Some related issues: Footprint.�� At present, if applications or services are encapsulated and opaque and a user uses several OMG applications and they share common services used in their implementations, then there is no way to declare these dependencies and they may be loaded multiple times instead of once into an execution environment.� A containment model at least reduces this redundancy. The Java community has developed some approaches that help reduce this problem. Complexity.�� In that OMG provides a small forest of separable specifications, the benefit is conceptual isolation and potential reuse but a downside is complexity, the experience of a developer faced with a toolkit but no accompanying application.� Of course, subroutine and class libraries provide this same experience and are useful.� And applications based on OMG toolkits can result in systems as simple to use as conventional OO systems. Multiple dispatch overloading mechanisms - are they all needed.� Interceptors, POA, and Trader all provide a mechanism for implicitly calling some side-effect behavior. Trader appears to be separately useful but are both POA and interceptors needed? Higher level Dynamic Dispatch Mechanisms than interceptors and POA.� Rules, filters, and before-and-after methods might provide higher level means of specifying interceptors. Portability. Even assuming technical solutions for component isolation, the question remains how will OMG state environmental constraints on components. Components implemented by C++ may not port easily to other environments. Most legacy code encapsulated as components will be pinned to the environment it is compiled into. Only Java or other languages compiled with a virtual machine will have the portability requirements for components across a variety of platforms. Visibility and Profiles. The notions of visibility and profiles mentioned in the old OMA Guide Introduction seem related to packaging: Visible and Invisible objects.� Visible objects are identified and manipulated at the interface (of what?� a framework?).� Invisible objects are those whose behavior may affect behavior at the interface but are not directly identified or manipulated at the interface.� It is not clear how to control visibility of objects in the OMA. Profiles.� Also mentioned in the old OMA Guide are profiles, which are collections of OMG technology (object model capabilities, services and facilities) that can be extended for use by some technology community (e.g., OODBs) or domain community (e.g., CAD).� This notion may need to be revisited since the extensions that are community idiosyncratic directly lead to interoperability problems at the borders of a profile, e.g., as when ODMG-profile data might need to be distributed via CORBA.� Also, limits on expectations need to be understood better -- can STEP be viewed as an OMG profile just because there is a mapping from STEP to IDL?� Closer to home, if UML introduces 80+ semantically useful constructs that users begin to use widely to represent their problems, does that constitute a profile just because there is a mapping to IDL.� Users of the results of the mapping might need to be aware of the UML semantics as well as the details of the mapping to maintain their resulting OMG code. Economic Model. All of the considerations above are technical enablers to make it possible within the OMA to separately specify and control components. But it must be the case that an economic model for componentry exists as well. Even if it is possible to separately isolate components for reuse, there must be a marketplace for making them available. Fortunately, the ActiveX and JavaBeans market places are indicators that such a marketplace is possible. DRAFT -  DATE 09/11/9708/14/97 OBJS AND MCC INTERNAL DATA �����
�������/��=�Z��*�h
���

�
h


�
�

�
�

�
�

�
�

�
�

�
�

�
�

�
�.........)()() +48Ljmx���VXc*6lm�������#$'56YZ��
_i����Gceo����G Q k ��������������������������������������� A�EF�[�V� B�EF�[�V�V�n
A�EF���V� B�EF���V� A�EF���V� B�EF���V�V� B�EFݴ�n
A�EFݴ�U� B�EF�[�A�EFy�&U�cB�EFy�&U�cB�EFz�&U�cA�E
Frd�U�cA�E
Fqd�U�cU�c8k o x � � � � � � � � � � � �  � � � � � � _ o | � �   5 � � � � � � � � � � ��������������������������vmeA�EFʹ�V�cA�B�EFxd�V�cA�B�EF{&V�cA�E
F{&V�cA�E
F{&V�cA�EFsd�V�c A�EF̴� A�EF̴�U�A�EF���U�V� A�EF���U� A�EFʴ�U� A�EFɴ�U� A�EFf B�EFf A�EF��& B�EF��&V� A�EF:Tf A�EFTf A�EF9TfV� A�EF��& A�EF9Tf B�EF9Tf'� � � � � � �
    "%V\_mn���������;<P����������Ǿ����������w���nenene\neA�B�E Fzd�U�V�A�B�E F {&U�V�A�B�E F {&U�V�A�B�E F {&U�V�A�B�EF {&U�V�A�B�EF {&U�V�A�B�EFyd�U�V�A�B�EF {&U�V�A�B�EF {&U�V�A�E
F {&U�V�A�E
F {&U�V�^
A�E
F{&U�V�^
A�EFwd�V� A�E
F{&V�A�EFʹ�V�cA�B�EFxd�V�cA�E
F{&V�cA�EFTfV�cA�B�EF{&V�c"��������  /EGHMUrz���������������89wy���������������Իó��ó��ԡԐ���vn�vnA�EFд�U�V�A�B�EF {&U�V�A�EFδ�U�V�A�B�E F {&U�V�A�B�EF {&U�V�A�EFմ�U�V�A�B�EF {&U�V�A�B�E Fzd�U�V�A�EFӴ�U�V�A�EFԴ�U�V�A�EFϴ�U�V�A�B�E F {&U�V�A�E
F {&U�V�A�B�EF {&U�V�A�B�E F {&U�V�A�B�E F {&U�V�A�B�E Fzd�U�V�'yz����+EUVWXl���������|�����qr����������ƿ����������~vmv~v~v~d~[A�B�EF{&U�V�A�E
F{&U�V�n
A�EF�d�U�V�n
A�EF�d�U�V�A�E
F{&U�V� A�E
F{&V�A�EF{d�U�V�A�EFzd�U�V�A�E
F{&U�V�A�E
F{&U�V�A�E
F{&U�V�^
A�E
F {&U�V�^
A�EFwd�V� A�EFҴ�V�A�EFѴ�U�V�A�EFҴ�U�V�A�B�E F {&U�V�A�E
F {&U�V�A�EFд�U�V�A�EFд�U�V�n
"r�  *-@F���mpr�����#$ns}���� ~����7T�����} ~ � � � � ����������������������������������U�cn
A�EF��& B�EF��& A�EF��& B�EF��&U� A�EFf B�EFf A�EF��& B�EF��& A�EF��& B�EF��&V�A�EFִ�U�V�A�E
F{&U�V�A�E
F{&V�c A�E
F{&V�A�EFwd�U�V�A�B�EF�d�U�V�A�B�EF�d�U�V�2� � � � � !t!u!w!x!�!�!�!�!�!3"4"�"�"�"�"##M#_#a#j#p#}##�#�$.%/%1%2%k%l%�%�%�%H&m&n&�&���������������������������������}v A�EF�JFU� B�EF��& A�EF;TfU�A�EF��&V�^
bA�C�EF��&V�u
DA�C�EF��&V� A�EF��&V�u
DA�EF��&V� A�EF��& B�EF�JF B�EF�JF B�EF�JFV�n
V�^
bC�V� u
DC�V�V� u
DV�U�U�cA�EF��&U�cB�EF��&U�c,�&�&'*':'T'\'y'|'~'�'�'�'�'�'�'�'�'�'�'�'N(](b(s(�(�(�(�(�(�(�(�(�(�(�(�(\)])�)�)�)�)�)�)D*E*�*�*�*�*�*�*�����������������˺������������������� B�E
F{&n
A�B�EF{&b A�B�EF{& A�E
F{& B�E
F{&n
B�E
F{&V�U�A�B�EF{&U�A�B�EF{&U�bA�B�EF{&U�b A�EF��&U�A�EF�JFU�V� A�EF�JFU�A�EF�JFU�V� A�EF�JFU� A�EF��&U�4�*�* +++E+F+M+�,�,�,�,K-�-�-J.K.�.�.�.�.�.�.�.�.�.�.�.�./?/@/A/B/�/�/�/0$0(0�0�0�0�0i1j1s1y1�1�1F2H2I2M2Z2]2������������������������κ��ΧΧΧΧΧΠΚ�Κ��΍ B�EFDTf B�EFCTfn
B�EFCTf B�EFTfn
B�EF�c� B�EFNTf B�EFNTfU� B�EFTfU� B�EFTfV� B�EF�c� B�EFTfU�U�c A�EF�c�n
A�EF�c� A�EF�c� B�EF�c� A�B�EF {& A�B�EF{&7]2y2�2�2�2�2�2�2�2�2D3a3d3r3�3�3�3�34,4-4d4e4)5-5X5g5k5�5�5�5�5�56n6�6�6�6�6�6�6�6?7I7,8-8=8j8{8|8�8�8�8�8+9,90929�9�9�9�9�9�9:�:; <.<�<�<=#=$=%=�����������������������������������������������������������������EFUTfU� B�EFTfV�B�EFTfU�V� B�EFTfn
B�EFHTf B�EFGTfEFFTf B�EFFTf B�EFTfU� B�EFTfJ%=&=A=M=T=U=�=�=�=�=�=�=�=[>�>�>�>-?5?�?�?�?@�@�@�@AA$A{A�A�A�A�B�BEE�F�F@GAGIG�G�G�G�GHHHH<h��nh��zh��]h���h���h��i��i��i��i��i��;i��ui��vi��ai��li��ni���i���i���i�������������������������������������������������������������������������� b�e�f\tfn
�="" b�e�f\tf�="" b�e�f[tf�="" b�e�fztf�v��u��="" b�e�ftfu��="" b�e�f�c��="" b�e�ftfv��="" b�e�fvtf�="" b�e�ftfn
�="" b�e�ftf�="" b�e�futfe�i���j���j���j���j���j���j���j���j���j���j���l���l���l���m��n��fn���n���n���n��o��o��o��$o��%o��,o��2o��ko��yo��\o���o���o��p��<p��p���p��+q��hq��iq��xq���q���q�� r��="" r��="" r��(r��lr���r���r���r���r��is��js���s���s���t���t���t���t��u��u��!u����������������������������������������������������������������������c��="" u
d����c��u
d�����n
�="" a�e�f�jf�="" b�e�f�jfn
�="" b�e�f�jf�u�c�="" b�e�fitfu��="" b�e�fitf�="" b�e�ftfu��u��="" b�e�f]tfn
�="" b�e�f]tf�="" b�e�f\tf="!U��+U��,U���U���U��wW��xW���W���W���X���X���X���X���X���X���X���[��G\���\���\���]���]���]���]��^��^��^��b^��c^��d^���^���^���^���`���`���`���`���`���`���`���`���`���`���`���`���`���`���`��wa���a���a���a���a��;c��Hc��Jc��Zc���c���c��:d����������������������������ſ���˲��������������������������" a�e�f;kf�="" b�e�f;kf�="" b�e�fltf�="" b�e�f�jfn
�v��="" a�e�f:kf�="" b�e�f:kfn
�="" b�e�f:kf�="" b�e�f8kf�="" a�e�f8kf�="" b�e�f7kf�="" a�e�f7kf�="" a�e�f6kf�="" b�e�f6kf�="" b�e�f�jf�n
�u
d�����v�^
b;:d��;d���d���d���d���d��e��e��="" e��ie���e���e���e���e��^g��ig���g���g���g��h��h��(h��,h��h���h���h���h��(i��1i��6i��ii���j���j���j���j���k���k���k���l���l���l���l���l��(m��-m��lm��sm��em��pm��sm���m���m���m���m���m���m���m��n��n�������������������������������������ſ���������������������="" b�e�f][�n
�="" b�e�f\[��="" b�e�f^[��="" b�e�f][��="" b�e�f="" tf�="" b�e�fs[��="" a�e�f="" tfu��="" b�e�fy[��="" a�e�fy[��="" a�e�ftfv��="" a�e�ftf�u��="" b�e�f-[��u�c�n
��u�c�="" a�e�fakfv��="" a�e�fakf�="" a�e�f@kf�v��n
��:n��n��o���o���o���o���o���o���p��p��p��3p��5p��6p��@p���p���p���p���p��q��q��q��q��9q��pq���q���q���q���q���q���q���s���s��pt��qt���t���t���t���t��u��u��u��u��4u���v���v���v��6w��nw��ow��xw��ww��~w���w���w���w���w���w���x���x���y���y���y���y��3z��4z��nz��sz��tz��wz��tz��uz��vz�����������������������������������������������������������������������������="" b�e�f�[��^
b�c��="" u
d����c��u
d�����="" a�e�f�[��="" b�e�f�[��="" a�e�f�[�u��u��u�c�n
��n
�v�n
�="" a�e�f�[��v��c�u�c�="" tfhvz��xz���z���z���z���{���{���{��
|��|��l|���|��?}��_}��k}���}��
~��n~��o~��p~��q~������h��������������������="" ���������="" ���&���5���6���<���?���@�������€���������h���t���u���������������������������<���="���">�D�I�@�A�B�M���������������������������������������� A�EF�[� B�EF�[� B�EF�[� A�EF�[� B�EF�[�n
B�EF�[� A�EF�[�n
A�EF�[� B�EF�[� B�EF�[� A�EF�[�U�cU�c A�EF�[�ccU�V�n
V� A�EF�[�>M�h�����������������������G�H��������X�Y�s������������������ � ���d�f�ˆĈ���$�&�O�P�������ωЉ������������������������򼶼�������������������� A�EF�[� A�EF�[� A�EF�[� B�EF�[� A�EF�[� A�EF�[� A�EF�[� A�EF�[�^
bC� u
DC�u
D B�EF�[�EF�[� B�EF�[�n
A�EF�[�V� A�EF�[� B�EF�[�V�9��#�%�7�8�����܊ފߊ1�2�3�;�D��������������H���� ��0�4�_�n�r����`�s�����D�N�B�z�O�Z�]�f�����V�_�v��������������������ǿ������������������������������������ A�EFTfU�A�EFTfU�V� A�EFTfV� A�EFTf A�EFTf A�EF�[�c A�EF�JF A�EF�[�A�EF�[�U�c A�EF�[�V� A�EF�[� B�EF�[� B�EF�[� B�EF�[�n
B�EF�[� A�EF�[� A�EF�[� A�EF�[�6������_�|��������� ��A�I���(�.�����G�[�\�f�$�/�� �۵��������g������������Ƹ����i�|�>�H�c�l�q�y�)�8�������
��� ������6�9�:�7������������������������������������������������������������������u
A�E
F {&P,P, A�EF��&aA�B�EFod�au
DA�E
F {& A�E
F {& A�EFTfV� A�EFTfU� A�EFTfF+x��VWX�_�FGeG � � � �  WX��r��  ,-���������
[-��
[-��
[-��
[-��
[-����
[-��
[-��
[-��
[-��[-����������������������[-��
[-��
[-�
8x
xx
x
&�67T�7� � � � � �"�#�$H&m&n&�'�'�)K-�-K./B/70y2�24e4��
[-��
[-���[-��
[-��
[-��[-��
[-��
[-��
[-���[-��[-����������[-
�[-��[-��
[-��[-��[-��
[-��[-��
[-��  8x<p 8<<
88<8<<x<
8e4)5�6=8:[:�:�:G;�;�; <=�>A�A"B�B C}CEAG�GHHOH�L�MFN�NO�OPPIQ R)R�RKT�X�X�[-��[-��[-��[-��
[-��
[-��
[-��
[-��
[-��
[-��
[-��[-��[-��[-��[-��
[-��[-��
[-��
[-��[-��[-��[-��
[-��
[-��
[-�� [-��[-��
[-��
[-��[-��[-��
[-��
[-��[-��[-��
[-
��[-�� [-��
[-� 8x<� � (�X
Z�[G\�]�]^�^�`�b/e�g(h�h�h�kl�l�l�lno�o�o�o�o�o�o�o�o�o�o�����
[-������[-����
[-��
[-����
[-�������
[-��
[-��
[-��
[-��
[-��
[-��
[-��
[-��
[-�" 8< 4 8� x 8(<p�o�o�op6q�q�r3s�tu�v�v6wOw�w�xWzvzxzU{�{�{�{|"|9|R|l|?}_}k},~H�
[-��
[-��
[-���[-��[-��[-���[- �
[-
�[-����
[-���[-��[-��
[-����
[-��
[-��
[-���
[-��
[-��
[-��
[-��[-��
[-"
����<<�
 8x�  � 8x@ �  H4�h�<�@������������ ��f�Ĉ&�P�����Љ��%�8�ߊH�u�Nj1����������
[-��
[-��[-������������������[-��
[-��
[-��
[-��@  @ < @ << p <<<<@ <@ <<� <� <<p<<�<<�����������H�1� �0���B������!�p�ѡ�6�����_�w��(�۫(��&����G�\�$��������������������������������������8<8<<�<<<<<<<

<<
--
x#�۵��g��>�)�������7�8�9�:��������������
+<
8<8<<
<< 2
K`��Normal,Pa ,
@
, Heading 1,H1

�<U�c0k$*@
* Heading 2,H2 
�<U�c$*@
* Heading 3,H3 
�<U�c&@
& Heading 4,H4 
�<U�(@
( Heading 5,H5�<U�c(@
( Heading 6,H6�<U�c"A`���"Default Paragraph Font �O
 Address<<V�&�O

& Blockquoteh
h
<<�O�
CITEV��O�!
CODE]c:�O
2
:Definition Compact,DL COMPACTh
��<<.�O
B
.Definition List,DL�0�<<$�O�Q
$Definition Term,DT]c �O�a
Definition,DFNV�c,�O
, Directory,DIRh
@ ��O��
 Emphasis,EMV�6�O
6Horizontal Rule,HR��&�'�(�)�/�o��
 Hypertext,A^
b �O��
Keyboard,KBD]^cb0@
�
bList Bullet,ULF ��� 4�


h
�b1@
�
bList Number,OLF ��� 4
��
h
.X�O
XMenuF ��� 4�


h
���������\�O
�
\PRE WIDE@ 
�N1�%/���� ������� �#�&�)�,]c^�O
^Preformatted,PRE:  
-1�%) `� � �@�`�! %�(�+]c"�O��" RestartList!���O�! Sample,SAMP]"�O�1"Strikethrough,STRIKEW��O�A Strong,STRONGU� �O�Q Typewriter,TT]c �O�a Variable,VARV�]c*�O
*z-Bottom of Form'
&c �O�� z-HTML Tag ]^
bc(�O
( z-Top of Form)
(c @
� Header *��!
 @
� Footer +��!
)@�� Page Number,B@
�, Body Text -��]c@
� Footnote Text. &@�� Footnote Referenceh
*�O
* Reference1�`�<
�:�
��
����������
:�:�����
��

��
��
��
�����"6�Ik?z:�H
�
z
 ?Bk � �yr� �&�*]2%=�I!U:dnvzM����7�abcdefghijklmnopqrs�e4�X�oH���:�tuvwxyz{&UnknownCraig Thompson
Preferred Customer'Craig ThompsonPreferred CustomerfT'Craig ThompsonPreferred CustomerfT'Craig ThompsonPreferred Customer���'Craig ThompsonPreferred Customer���'Craig ThompsonPreferred Customer���'Craig ThompsonPreferred Customer���'Craig ThompsonPreferred Customer��� 'Craig ThompsonPreferred Customer��� 'Craig ThompsonPreferred Customer��� 'Craig ThompsonPreferred Customer��� 'Craig ThompsonPreferred Customer��� 'Craig ThompsonPreferred Customer���'Craig ThompsonPreferred Customer���'Craig ThompsonPreferred Customer&̕'Craig ThompsonPreferred Customer�[�'Craig ThompsonPreferred Customer&̔'Craig ThompsonPreferred Customer�c�'Craig ThompsonPreferred Customer�[�t�."�"�Q+R�vSw���:�3�
�3�3�3� B����Z OMAtomorrow composability Performance Convergence principles FederationRecommendationsK*�dlr����;�
K*�dlr����;�&
Q
e
p
?SBS�u�u����;�yCraig ThompsonD:\TEMP\OMG-OMA-NG.docCraig ThompsonD:\TEMP\OMG-OMA-NG.docCraig Thompson=D:\OBJS\Contracts-and-Projects\MCC OIP\OMG-OMA-NG-outline.docCraig Thompson=D:\OBJS\Contracts-and-Projects\MCC OIP\OMG-OMA-NG-outline.docCraig Thompson=D:\OBJS\Contracts-and-Projects\MCC OIP\OMG-OMA-NG-outline.docCraig Thompson=D:\OBJS\Contracts-and-Projects\MCC OIP\OMG-OMA-NG-outline.docCraig Thompson=D:\OBJS\Contracts-and-Projects\MCC OIP\OMG-OMA-NG-outline.docCraig Thompson+D:\OBJS\Ireland\9709-OMG-OMA-NG-outline.docCraig Thompson+D:\OBJS\Ireland\9709-OMG-OMA-NG-outline.docCraig Thompson$D:\OBJS\WORKSHOP\papers\paper017.doc�@HP LaserJet 4MVLPT1:HPPCL5MSHP LaserJet 4MVHP LaserJet 4MV
�@g



X

X

@MSUDNHP LaserJet 4MV�
;
d HP LaserJet 4MV
�@g



X

X

@MSUDNHP LaserJet 4MV�
;
d
�
#
#


#

i�
Times New Roman �
Symbol &�
Arial �
Tms Rmn5�
Courier New,
Bookman Old Style"
@��h
H�&H�&�&VћO�L
vX�[~
Y�OMG OMA-NG Green PaperxPreferred CustomerCraig Thompson
  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������Root EntryDocument1
��������
�F@�):��
��U;��
�WordDocument ���IȻI
����{

CompObjC:\MSOff���oD<@��\iE,@@
������������}���@��H��Hj(���SummaryInformation �@��b
��b�P(
����������b��P��b��b
X��b
���� ���� ��������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������
�� ���� �FMicrosoft Word Document MSWordDocWord.Document.6�9�q��
�����Oh��+'��0(
������x
�
�
�
�
�
�
�
 �OMG OMA-NG Green Paper
Preferred Customer
y Normal.dotCraig Thompson2DMicrosoft Word for Windows 95@@}x��
@(-��
@(-��
Vћ��
��՜.��+,��0�
HPx�� �� ��Object Services & Consulting�z
L
O OMG OMA-NG Green Paper</h��nh��zh��]h���h���h��i��i��i��i��i��;i��ui��vi��ai��li��ni���i���i���i��������������������������������������������������������������������������></what�s>