PDF of this tutorialA core competency of distributed systems and therefore distributed intelligence is the ability to relate tasking to the capabilities of the member nodes in the system. To this end, heterogeneous environments establish the best possible methods for applying intelligence toward a distributed system. In heterogeneous environments, tasking methods applied to the most appropriate container for the actions to be performed in the overall system are found. Distributed intelligence in heterogeneous models allows the system designer to accomplish the following tasks:
- retain use of legacy elements and systems
- isolate usage of member computing elements
- brand computing elements to perform best-fitting tasks
- establish rules for functionality creep beyond designated computing elements
- coordinate system behavior rules to overload escalation and abatement actions
Using the client/server model for interaction, combined with the OSI stack as a requirement template for determining interactive behavior, one may begin to define the interoperability model between heterogeneous platforms, which accomplish the following:
- provide identification of the makeup of the member nodes or sets of nodes
- establish a matrix of attributes to be applied to each member node
- abstract the attributes to collections of nodes
- identify the principal connectivity method between nodes
- establish a common set of interactive primitives or messaging components between nodes
- broadcast the attribute matrix to member nodes (note: The system is alive.)
- establish an agreed manager of the system; voting ensues
Now that the system is operable as a singularity, rules for reacting to changes in the system may be implemented either at the voted manager or within the confines of the member nodes. One has essentially established heterogeneous attributes as the common environment between the members of the system. Once the attributes are received and the method of system management (voting or otherwise) is established, each system can act independently to detect state changes and can then react corporately based on the rules for behavior dictated by the management scheme.
Growth Models
Change determines the behavior in distributed intelligent systems. One of the most predominant elements of change appears in system growth. For systems in which retention and preservation of assets is a key factor, growth most certainly brings about heterogeneous computing environments. Applying the principles of establishing best behavior for the appropriate elements in a heterogeneous setting, system designers become unburdened by the inclusion of legacy components in an evolving architecture. All that is needed is a redefinition and redeployment of the attribute and behavior matrix to the system. One must remove some of the functionality applied to the legacy node and distribute it to newly added members of the total system. The legacy environment is retained and continues to contribute to the activity of the overall solution.
Tying Solutions to Architecture
Several well-established solutions exist for enabling heterogeneous architectures. Those covered here are distributed computing environment (DCE), CORBA, and component object module (COM).
DCE
DCE performs fundamental request/reply interaction between systems containing DCE components. This interaction is made possible through a remote procedure call vehicle that is considered a fundamental middleware piece of the DCE. DCE source code is available from the Open Group, and vendors wishing to implement DCE on their systems incorporate this source code into their platforms. DCE itself contains several middleware services which, once converted, reside atop a specific operating system. Once available, the services interact to provide transportability of service to other computing systems that have adopted the DCE standard. These services include the following (see Figure 8):
- remote procedure calls, which enable client/server-like interaction with procedures on other systems as if they were local to the calling system
- directory naming capabilities, which provide a simple naming convention for file structures applied across the member nodes
- time synchronization services, which establish a single clock value across the member nodes
- distributed file access
- authentication and security methods for resource accessibility
DCE also provides multithreading services and relative platform independence for application developers.
CORBA
The OMG offers CORBA as an infrastructure for establishing distributed components. CORBA comes in the form of interface specifications written in an independent interface definition language (IDL), which imposes no implementation mandates for operating systems or programming languages. As a result of this neutrality, components coded to the CORBA IDL must perform discovery of other components at run-time. As a benefit of this discovery operation, a CORBA system (as a totality) is both dynamic and self-defining. Through extending the capabilities of the components in the system, the rediscovery of the system results in a dynamic redefinition of the attributes of the system. This redefinition can then become the impetus for enabled behavior modification of the node elements in the system (see Figure 9).
As discussed in the introductory sections, CORBA requires the presence of the ORB. The ORB provides the vehicle for performing invocations of local and remote CORBA objects. Unlike an RPC, an ORB invocation is not a simple function call. Rather, it is a more granular invocation of an object method associated with a specific instant of data. RPCs do not bring the capability of object-oriented technology to the distributed medium. Contained within the specifics of the ORB are the following 11 object services of CORBA:
- concurrency
- events
- externalization
- license
- life cycle
- naming
- persistency
- properties
- query
- relationships
- transactions
The environments possible with the cooperation of these services combined with basic object-oriented methods for inheritance and container manipulation provide application developers and system designers with the tools necessary to create behavior-specific open middleware solutions. Through IDL, definitions of a heterogeneous system’s attributes can begin with a nugget of information and be expanded through discovery, inheritance, and redefinition to adhere to the changing characteristics of the living system.
COM
COM is a Microsoft offering that provides support to objects communicating with other objects residing on different computing elements in the same manner that they would communicate and interact within a single element. Like a CORBA IDL, COM enables interaction through the specification of an interface to acting objects. Through COM, object interfaces are instantiated and uniquely identified through an element known as a global unique identifier (GUID). The element is a generated 128-bit value, which essentially guarantees uniqueness amongst other interface GUIDs on the local system or connected remote systems.
Distributed COM
Distributed COM (DCOM) is simply an extension of the COM model (see Figure 10). In essence, DCOM enables the distribution of COM capabilities to other computing elements. With COM, it is easier to think of component interaction in terms of interprocess communication. Where the destination component resides upon a separate machine, DCOM acts to augment the interprocess communication with a network protocol. The result is an abstraction of the interaction to the end-user where remote objects are referenced in the same manner as local objects. This abstraction is particularly useful in growth scenarios where current coding schemes are protected from the addition of computing elements and the distribution of COM objects to those new elements.
Figure 10. DCOM Interaction Topology
Interaction between components on different machines is managed through a midlevel DCOM network protocol that uses any of the following low-level transport protocols:
- transmission control protocol (TCP)/Internet protocol (IP)
- user datagram protocol (UDP)
- Internet packet exchange (IPX)/sequenced packet exchange (SPX)
- network basic input/output system (NetBIOS)
Whether connection-oriented or connectionless, DCOM implements a security framework for the low-level protocol. Connection management is maintained through collaborated reference counts against objects in use combined with a pinging scenario between computing elements. The DCOM protocol is based on DCE’s RPC model, particularly in the area of converting data structures used in the communication path to data packets across the network.
Certainly, DCOM is an environment available to Microsoft Windows products (Windows 95, Windows 98, and Windows NT). Various UNIX platforms are capable of implementing DCOM as a result of cooperative development activities between Microsoft and UNIX software vendors. In addition, several packages exist that integrate the elements of DCOM and CORBA through the use of an established bridge that performs conversion and mediation between the two.
The Sum of the Parts
As seen in the examples of growth models, heterogeneous environments serve the greater whole of the system by exploiting the best capabilities of the member nodes within the system. In legacy settings, exploitation is complemented through the reuse of contributory computing elements through refinement of their responsibilities in the system. The penalty paid for the heterogeneous collaboration of these elements is found in the necessary common elements that must exist between these elements. Whether DCE/RPC, CORBA, COM/DCOM, or a proprietary message-oriented-middleware (MOM) technique, processing power is reduced to some extent on member elements in the system to accommodate object and resource location transparency. Refining the needs of the system so that the most efficient method for object independence can be achieved dulls the loss of processing power for the computing elements but may eventually detract from the overall health and growth pattern of the system.
So which system is best? For the field of intelligent networking, one must look at the specifications and requirements. Intelligent networking is far different from on-line transaction processing (OLTP), but many of the methods in intelligent networking find their roots in OLTP systems. In the same vein, intelligent networking also finds basis in relational database management systems (RDBMS). The specifications of intelligent networking are too abstract to be a subject for this tutorial, but for determining heterogeneous topologies, a simple statement would be that the speedy processing of the in-flight transaction must be verified, augmented, and returned by the system while under the continued oversight of independent collaborating management processes. An object model serves these needs.
