This paper presents an overview of the general architectural features needed to build, deploy, and manage large-scale distributed object systems. These features will be described in the conceptual framework of an "enterprise object model" which is defined as the set of assumptions and tools used implement the object system. The object oriented software industry actually presents a variety of architectural object models that together provide important capabilities, yet may have somewhat contradictory goals. Expersoft merges these different goals to provide customers the best tools and infrastructure for building and deploying enterprise systems that achieve standards compliance and also maximum performance and manageability. One of the major outgrowths of Expersoft's experience with large scale distributed C++ systems is that it understands what the large scale object system requires for manageability and performance.
Different object models arise from different requirements. OLE/COM provides interfaces for popular existing desktop suites and applications; Smalltalk provides a superior object-oriented application environment; C++ provides a means for object-oriented systems, infrastructures and component-building. Important new standards like CORBA IDL provide a language neutral and location-neutral messaging interface for component integration. Expersoft's ORB provides the communications backbone with which these different object models can co-exist within one enterprise system. Some of the types of object model communication models employed in the enterprise model are:
A message bus for CORBA component objects and servers. Components can be individual large-grained objects, collaborating groups of objects, or existing non-object oriented monolithic applications wrapped with CORBA interfaces. Also called Business Objects and Frameworks, these building blocks employ object-oriented mechanisms like inheritance and polymorphism to provide higher level applications logic.
Fabricating the CORBA components out of smaller, individual objects that cooperate to form components. These individual objects may perform business rules and support logic such as GUIs, etc. Since they form the "plumbing" for components, they frequently have more stringent performance characteristics, such as asynchronous mess ages and event handlers. Frequently written in an object oriented language like C++ or Smalltalk.
Assembling and coordinating ("scripting") the CORBA components into desktop-centric applications. This involves connecting OLE/COM components and enterprise component (CORBA) objects. Scripting tools at this layer would also make use of tools such as Visual Basic to allow non-programmers and power users to build the final stages of the user applications.
The CORBA IDL specification is not an implementation model, but rather an interface and services model. It is language-neutral and leaves maximum flexibility for underlying implementation details. In fact, recent attempts by some ORB vendors to build enterprises using CORBA IDL as the low-level implementation model have resulted in performance and integration issues that have forced the customer to provide expensive, proprietary extensions to the CORBA-based ORB. This problem could be avoided by using CORBA IDL for distributed component interfaces rather than for individual C++/Smalltalk distributed objects. Following is a discussion about the goals of CORBA and other object models.
Goals of CORBA - Component Integration
Goal #1 - Integration
A component in CORBA is intended to behave like an object or object server to a client application, even though it may or may not actually be written in an object-oriented language like C++. This component "encapsulation" of an application is done by representing it with the Interface Definition Language, or IDL, and hiding the actual details of the application, and its location, from the client. In particular, the CORBA object model provides a strong separation of "interface" from "implementation". CORBA is oriented to the component subsystem, or server, level rather than the individual object level. The CORBA IDL is not pure OO technology; while it does support interface inheritance, it is more a tool for encapsulating things to make them look like objects to a client. Bindings to convert IDL to languages like C++, Smalltalk, C (all of which are already standardized), COBOL, ADA, and more, mean that an organization can describe application objects and services with a well l-known IDL interface and provide this interface specification enterprise-wide to software developers using many different implementation languages. The CORBA IDL component is intended to serve as an interface specification or "contract" between departments, corporations, larger applications, or entities in a system that will be smaller in number and larger in size so that they provide adequate performance with a synchronous or deferred synchronous (also called polling) architecture. In other words, IDL provides a standard client/server interface: a client program requests a server for information, waits until the information is obtained, and continues on to the next activity. Goal #2 - Environment Independence
CORBA is not only language-neutral (it's intended to support C++, C, etc.) it is also fairly object-model-neutral as well. What this means is that even though it is an Object Request Broker (ORB) model, this model is flexible enough that it allows non-object-oriented modules and applications to fit into the ORB mechanism. Non-object-oriented pieces can exchange data with each other and with object sub-systems as well. Given that not all the components in an enterprise may be object-oriented, CORBA IDL must provide descriptive features that are not tied to any language or object model. The purpose of the ORB is actually pretty narrow in terms of enterprise application functionality: to provide an interface to remote object components, and to provide a "router" between local and remote objects and components. CORBA doesn't go beyond this base ORB functionality for a reason - it is envisioned that there will be many special-purpose ORBs for a variety of application needs ranging from light-weight embedded requirements to full-service corporate infrastructures. This least common denominator does have a cost, however, in that it can't directly exploit the features of native object-oriented languages that can enhance functionality or performance. For example, IDL interfaces don't currently provide for the transmission of full objects between components, there are no C++ like pointers, n o event callbacks for asynchronous behavior, no broadcasting/multicasting of objects to multiple receivers, etc., since these are features that are not common to all languages that need access to the ORB. But they are needed functionality, and so have to b e provided at some level in order to build a working system. Discussing the low-level enablers and services of distributed object systems leads naturally to the following discussion about the strengths of a more generic object model for full enterprise capable applications. Goals of a Language-specific OO system (such as C++)
For the discussion about a more general language-based object-oriented model for enterprise systems, PowerBroker Extended C++ would be a good starting point. PowerBroker provides C++-centric tools for building the "plumbing" or lower-level "implementation" of what the CORBA model describes at the higher-level component "interface". The main difference between this extended C++ toolkit and the CORBA model is that the former allows for the direct manipulation of objects as remote method call arguments and callbacks. Extended C++ behaves like, and uses the same idioms as, non-distributed C++. CORBA, on the other hand is a more "loose" object model that minimizes dependencies on OO languages, so that it's main goal of the encapsulation of existing large-grain applications is easier to achieve, in a multi-language environment. With a C++ model, objects be individually distributed, as well as being used as parts of larger-grained distributed components. Individual objects can of course come in all sizes, but they have the more flexible communication styles that enable them to be used in much larger numbers for more effective scaling and event-driven real-time notification. Goal #1 - Asynchronous Message-based Communications
The design features for object systems are already well-understood: inheritance, encapsulation, and polymorphism. These 3 characteristics of objects provide the central design benefit of objects, namely, reusability. Another factor in reusability is a communications model using a message-based architecture. Messaging is a light-weight communications paradigm (a "send and continue until notified" approach) which allows for an object to be available for further requests and activities instead of being tied up blocked waiting for a server to return a result. With asynchronous messaging, the client can simply be notified when the results are ready instead of waiting, or repeatedly polling, for data. The benefits of asynchronous messaging are quite evident in a large network with many objects, since the overhead from the synchronous blocking, and for client-side polling, can be quite high. Goal #2 - Event-driven Capabilities for Response & Manageability
Other characteristics that full distributed object systems have (that must be implemented in the server side of the ORB) are centered around object-level deployment and management features. In a multi-platform networked environment, systems need to transparently migrate and transport objects around the network so that client-level services can be provided independent of location. Also, migration permits services to be load-balanced or failed-over to another system, transparently to the client. Another feature is event-driven response capabilities: manageable object t systems are able to respond to "events" which are basically messages coming from outside the system or control loop. These events can range from networks going down, to inventory objects suddenly running low on an item in stock. The system needs to be able to respond to events like this, asynchronously, and in a controlled manner. To summarize the difference in communications requirements between component-level and individual object level, it can be stated that the latter require light-weight inter-object communications that allow objects to "send and continue", to send the message and then continue on with other activities until they are notified when the request is ready. Events and messages are part-and-parcel of object systems, especially distributed object systems with all the complexities of network behavior. Object systems are fundamentally different from synchronous "call and wait" client/server programs in this regard, and the application of RPC-style call-and-wait communications will bog down a system with numerous objects. Issues in CORBA-Compliant Systems: Merging Object Models
The key to building standards-compliant distributed object systems is to use the features of the different object models where they are most appropriate, based on business requirements. Specifically, the enterprise object-oriented application should be driven by lower-level object models for the implementation details, with CORBA IDL used for interface specifications between components. There are at times a language mis-match between the CORBA and OO-language models, given that CORBA is for integration with existing client/server and legacy applications and that native approaches (like Smalltalk/C++) are for low-level modeling of application support and system support objects. Both models are important, and both models must be managed and merged for enterprise object systems. Issue #1 - Implementing a Message-based Architectures
One example is the need for a low-level interobject communications approach that works well inside components as well as between them; a feature that Expersoft refers to as true asynchronous method invocations. Expersoft provides a very easy-to-use asynchronous method call mechanism that provides good scalability for numerous low-level object communications. The mis-application of component-level IDL communication models to individual object-level communications leads to the following kinds of performance and maintainability issues:
Client-side threads The individual object has an over-reliance on IDL's synchronous approach. With synchronous method invocation as the only calling style, client code needs to propagate threads (threads attempt to build async behavior on top of sync calls) to other intermediate software packages as well. The client has to maintain and manage threads, in addition to its own applications functionality. Threads are powerful enablers for concurrency on the server side, where they provide transparent scalability to many clients, but should not be the primary means of concurrency for the client side, where they increase the coding burden, and make integration more difficult with add-on packages since they must support threads as well.
Interobject Network-coupling The object messaging/event paradigm is somewhat compromised by the component synchronous/deferred synchronous approach, if used for too many low-level objects. When a client object connects to another object which in turn connects to another object, what results is a "stacking" effect in which the intermediate object is blocked and unavailable to other potential clients as well. This stacking increases behavioral coupling between objects and in fact reduces availability (reusability) for other potential clients. This could be avoided by allowing heavily-used intermediate objects to send messages on, and then continue with their own control loop in order to service other object requests. This ability for objects to send and continue is one example of what Expersoft calls asynchronous method invocation. There have been attempts by other ORB vendors get around these problems with low-level, inter-object synchronous communications, but the work-arounds are not optimal for a variety of reasons:
One strategy is to simulate asynchronous callbacks with IDL "oneway" function calls to set up a double oneway connection between the client object and the server object, each managing the connection to each other. Unfortunately, now the server is no longer independent of the client and has to be aware of client side behavior, and especially if it has to manage connections to more than one client - which is generally the case. A better solution would be to allow the client to set up a callback so that it could be notified when the server data is ready, since the client and server are de-coupled time-wise and more independent of each other. This latter approach is frequently needed for numerous objects and is an example of asynchronous method invocation.
Another makes us of the Dynamic Invocation Interface "deferred synchronous" method invocation style which is useful for component clients to poll for data from a server, if they know that the waiting period will be too long for a synchronous wait. The usefulness of a polling approach which works for a few large processes is, just like the synchronous calling style, dependent on how many clients will be doing it over the network. The disadvantage of polling is twofold: it may clog the network if done too much, and also it still requires the client to go back and check for data, wasting time managing the information transaction instead of saving its CPU cycles for more useful work. Here again, Extended C++'s asynchronous callbacks permit the client to be notified, and hence interrupted, only when n its data is ready. This is very effective for large numbers of distributed objects in large networks.
Another approach being used to deal with synchronous calls over a network involves the use of "Smart Proxies" which is a caching scheme to duplicate the remote object server into local memory. Essentially this tactic replicates the data from the remote e object into a local object, transparently to the client, to provide better performance since now communication doesn't actually have to go over the network itself. Of course, now an additional copy of each remote server has to be placed into local memory, and additional connections now exist between server and smart proxy as well as between client and server/proxy. This creates additional overhead. Interestingly enough, Expersoft's distributed object class extensions make it easier to build these smart proxies, but note t hat smart proxies are un-necessary with asynchronous messaging anyway; after all, the whole point of distributed objects is to be able to communicate with remote objects in an effective manner. Issue #2 Event Management
The need for component objects to have an event management interface is well-recognized by the CORBA standards developers, and the CORBAservices Events interface has been defined. This will provide standard IDL-based APIs for access to send and receive applications events by client objects. The area of event-handlers is a major feature of Expersoft`s existing product set, with robust, mature event handlers for disconnect/connect events, read input events, and object-level creation events. Expersoft will leverage its existing event-services to be among the first to comply with the CORBA specification. However, event management at the object-level has some gaps in the CORBA model and so must be filled in at the implementation layer. While CORBAservices standards do exist for the Event interface, they are more oriented towards application events. System-related events such as network outages are more implementation-dependent, and Expersoft's mature system event handlers provide a strong head start. Issue #3 Transporting and Migration of Objects
Since the CORBA IDL model has to be OO-language independent, any object movement over the wire needs to convert objects to "flat" records, or opaque byte streams, and back to objects again at the receiving end. This feature must be used with care in CORBA , since there could be 2 performance hits: one in that this conversion needs to be done, and another in that there would need to be 2 sets of "objects" that would need to be maintained - one that is used in an actual object-oriented component, and one that t the true object would be converted to in order to be shipped over the network. A better solution to this conversion process would be to provide different access levels in one unified mechanism so that CORBA and the native object interface could map to a single object transportation engine without a performance penalty. Summary - Expersoft Provides A Better Way to Merge Object Models
One way to summarize what's been said so far is that a distributed enterprise object model needs to contain an ORB, rather than merely be an ORB. The ORB needs to be integrated within an adequate enterprise object models. Simply stretching the ORB interface model into an implementation model causes significant performance and manageability problems. The enterprise object model itself needs to leverage actual experience and expertise in building systems for vertical applications. Expersoft has already built large scale object systems for these specific industries: financial, manufacturing, telecom, and other leading-edge users of OO technology. This experience has given Expersoft deep insight into the architectural features to provide for the optimal performance and management t hooks that would underly the CORBA high-level interfaces. Expersoft has identified the common object model features of the production systems mentioned above and also required by several other distributed object systems on the market, including our own C++ model, CORBA, OLE/COM, and Smalltalk to name some of them. These common model features have been incorporated into Expersoft's 3rd generation ORB product. The ORB has been modularized to support both the different object models and also to support modular configuration of the engine to either include, or exclude, specific services and features as needed by the application. Feature - PowerBroker's Object Model Neutral ORB
A major feature of the PowerBroker ORB will an "object model neutral" design that will provide adequate interobject communication and transportation capabilities to a variety of object systems: CORBA, C++-centric, Smalltalk, and OLE/COM. This will provide a much cleaner way to merge object models to meet specific application requirements. For example, CORBA C++ builders who need to provide IDL public interfaces to remote clients for an encapsulated database application, and C++-oriented developers who need to write a high-performance, asynchronous peer-to-peer server application, actually have different communications requirements even though both groups are coding in C++. The PowerBroker ORB underneath can provide optimal performance for both applications since it uses an object model neutral approach. In the same way, the engine provides these features for Smalltalk and OLE/COM users, legacy integration, non-OO applications, non-OO middleware like high-performance message busses, etc. Feature - Supports All Communications Models
Since PowerBroker includes the full CORBA 2.0 development environment, plus CORBAservices, plus Expersoft's important extensions, the system allows the building and management of event-driven object systems, including application events and systems events. A key differentiator between Expersoft and ORB-centric vendors is that Expersoft provides all the major interobject communications models: synchronous, deferred synchronous (polling), and true asynchronous (with callbacks). Expersoft will provide these at the low-level interobject layer and also at the CORBA IDL layer, with special extensions to IDL that provide the asynchronous capability to CORBA developers that need it. This will allow CORBA C++ and Smalltalk developers to use Synchronous or Polling for straight forward (such as local memory) interobject invocations and also provide asynchronous IDL calls for: large numbers of components, components that need to wait for longer periods for results, and for asynchronous decoupling between dissimilar software components (such as the attachment of GUI front-ends to batch-oriented mainframe systems). Feature - A Complete CORBA 2.0 Environment
A complete CORBA 2.0 environment will be provided for C++ and Smalltalk developers. The CORBA 2.0 compilers (for static and dynamic interface between client and server) will contain integrated repositories for industry standard C++ and Smalltalk ParcPlace/VisualWorks component building. Several of the CORBAservices and extended Expersoft object services will be provided so that 3rd party software packages (including other ORBs) can make use of Expersofts object deployment and management services, including transportation/migration of objects, event management, persistence, and communications services. Glossary:
Object Component: 1) A group of collaborating objects 2) A discrete repackaged application that provides a large-grained piece of business application functionality.
Object Implementation: The code executed for an object or a component, Extended C++: Uses C++ idioms and mechanisms to build a distributed version of C++ that works like the regular non-distributed C++ language.
ORB: Object Request Broker.
Object systems: A system used to model/simulate: attributes, behavior, and communications of objects
摘自 Sun Microsystems, Inc本文地址：http://com.8s8s.com/it/it18404.htm