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 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.
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.
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.
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.
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:
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.
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.
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.
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).
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.
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
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10797429/viewspace-101488/，如需转载，请注明出处，否则将追究法律责任。