Offered here is an overview of basic techniques and standards important to understanding some of the more theoretical elements of distributed intelligence techniques, focusing on the following three basic topics:

• fundamentals of the open standards interconnection (OSI) model—breaks down the seven-layer stack of the OSI model; the OSI structure forms a common mindset for understanding the specifics of the operations applicable to distribution activities
• primer on intelligent networking—provides the principles of intelligent networking activities, configuration, and interoperability
• primer on distributed processing techniques—provides a summary of existing approaches to process distribution models

Additional material exists for each of these topics, and these summaries are not intended to provide a full discourse on the concepts and practices of these components. The reader should consider the following as reference points to the remainder of the tutorial.

Fundamentals of the OSI Model

Distributed network intelligence is grounded in the OSI model. It is within this model that the necessary relationships between multiple hosts of the distributed network will be established. The OSI reference model defines a partitioning of network operability into seven layers where one or more protocols implement the functionality assigned to a given layer. Working from the bottom of the stack upward, the following layers are defined:

• physical layer—handles the transmission of raw bits
• data link layer—aggregates a stream of bits into a larger data unit called a frame
• network layer—performs routing among nodes within a packet-switched network
• transport layer—establishes a process-to-process channel
• session layer—creates and manages a name space used to link different transports considered part of a single application
• presentation layer—provides a common format of data exchange between different types of peers
• application layer—implements the functionality of the application

Each layer provides services to the layer above in the protocol stack and uses the service from the layer below. For messaging, each layer adds its own header to the message being passed on by the layer above it on the sender side. At the receiver side, each layer takes off the header from the message and passes the unbundled message to the layer above it.

Figure 2 gives the graphical representation for the OSI stack. Note that the model is replicated between disparate hosts. It is this replication that provides the framework for interoperability between compatible member hosts to execute in a distributed setting.

Figure 2. Diagram of the OSI Stack

The OSI model provides a framework from which to begin to define the basic capabilities of an interconnection solution and strategy. The layers of the OSI model establish a simple method of rationalizing communication theories between disparate computing elements. For distributed processing techniques, the OSI stack broadens the scope of basic interconnection and opens up the discussion to include how the interconnected elements may actually use and benefit from the connection mechanism at hand. Successful protocol agreements are achieved between distributed network elements through the use of the OSI model.

Primer on Intelligent Networking

The intelligent network (IN) relieves the telephone switching system’s burden of higher-level service introduction, management, and execution, allowing the switch to concentrate on the routing and management of calls. Introduced in the mid 1980s as a response to the demands of the regional Bell operating companies (RBOCs) for more rapid introduction of services and for relief of in-path call processing, the IN was initially defined as IN/1.

IN/1 Architecture

The initial services offered in the IN/1 architecture were 800-number translation (freephone) and calling-card processing. The architecture of IN/1 focused on implementing a standard set of triggers within a switch that, when invoked, would initiate an off-switch request to a new network element: the service control point (SCP). Management of the application residing upon the SCP was defined by another new network element, the service management system (SMS). Figure 3 shows the high-level topology of the IN/1 architecture.

Figure 3. Basic IN/1 Architecture Topology

With IN/1, service logic was removed from the switches themselves to be placed in application database servers or SCPs. The introduction of the SCP to the network fabric brought about the need to create supporting systems for creation, provisioning, deployment, and management of new services. Overall, the necessities of service manageability and maintenance combined with emerging computing capabilities brought about the need for distribution techniques. The limitation of the IN/1 architecture was seen in the diversity of service capabilities. Like the movement away from singular management environments, service as a whole moved toward more distributed settings.

AIN Architecture

Immediately following the IN/1 architecture came the need to abstract service development, deployment, and management even further. The construction of the AIN ensued. With the release of the AIN 0.1 architecture came the ability for multiple service providers to create and enable new services within the IN. The largest advantage to AIN over IN/1 is the ability to provide service independence.

Service independence was achieved through the creation of an entirely new set of triggers considered more generic than those implemented through IN/1. The triggers themselves apply to a range of application services rather than the limited 800/freephone services established within IN/1. AIN Release 1 defined a full set of requirements for trigger implementation. Contained within the AIN definitions are the following network elements (see Figure 4):

• an SMS capable of performing management, provisioning, and maintenance of multiple services at the same time
• SCPs that serve as application repositories complete with subscriber and provisioning databases; one SCP can host multiple applications through the establishment of a generic platform environment
• signaling transport points that route off-switch calls to the appropriate SCP
• service switching points with added intelligence that are capable of detecting AIN triggers for off-switch routing

Figure 4. IN/1 Network Elements

The emerged capabilities and requirements of the AIN model for an SCP are natural for distributed environments. Generic platform environments, which host a range of services and are combined with multiple entry points for management and provisioning, form the groundwork that distributed systems provide. Distribution of intelligence in the IN network targets the keeper of the system’s value-added purposes. The SCP holds the keys to the services of the IN, and it is here that distribution realizes the maximum value.

Primer on Distributed Processing Techniques

Distributed processing is more of a computer science concept than it is a telecommunications technique. Nevertheless, the broadening of intelligence in the telecommunications environment encompasses the theories and principles of distributed processing. An information management and control activity, distributed processing involves the separation of work between computers that are linked through a common communications network. Methods of implementing distributed processing run the gamut between simple segmentation of workload between member computer element to cooperative tasking of computer elements to achieve a singular goal. Common practices for implementing distributed processing take the form of client/server and distributed object architectures.

Client/Server Model

The client/server architecture arose during the 1980s as an alternative to centralized, mainframe computer architectures, although the client/server model can be applied to a single machine. In client/server methods, a client is identified as a requester of services and a server is identified as a provider of services. Negotiation between the client and the server is achieved through a message interface chosen by both the client and the server components. With client/server techniques, flexibility, interoperability, and scalability become both byproducts of the implementation and requirements for improving the implementation. To this end, client/server techniques are implemented in two-tier and three-tier settings with variations applied to the three-tier methods for the inclusion of message-servers (also called transport protocol [TP] monitors), application servers, and object request brokers (ORBs). Each of the transitional configurations for client/server methods brings about capabilities that build upon the previous method (see Figure 5).

• Basic two-tier client/server implements simple request-reply actions in which the requester typically takes the form of an established graphical interface while the more powerful server actually implements the request and fashions a reply to the client/requester.
• Three-tier expands upon the limitations of two-tier architectures (typically sizing, processing overhead, and reliability) by implementing a logical middle tier that enacts message queuing. Maintained logically in both the applications of the client and the server, message queues are established to allow asynchronous operation on the client’s part during the processing of the transaction by the server.
• Transaction monitoring enhances the three-tier architecture by implementing higher orders of logic within the transactions themselves. This logic implements larger queuing methods that allow further abstraction of the asynchronous operations of the clients while at the same time performing redundancy operations that guarantee the safety of the in-flight transaction.

Figure 5. Two- and Three-Tier Client/Server Models

In ORBs, client/server architectures take on the evolving role of distributed objects.

Distributed Objects

Distributed objects is the application of object technology to client/server systems (see Figure 6). The architecture makes two distinctive presumptions: one, that the participating machinery in the architecture is capable of assuming and encapsulating the functions of an agreed set of common primitives known as common object services and, two, that the capabilities of object-oriented principles are available to the requesters of those services. The latter of these presumptions places the newly created services on equal footing with the basic primitives, which allows for larger and larger classes of services to be developed and integrated into the overall architecture’s topology.

Figure 6. Distributed Objects

The application of distributed objects depends on the existence of a common set of services that is readily available to all participants in the system. These services are defined to be available through an interface known as an object request broker (ORB). The ORB allows other objects to make local or remote requests to other objects in the system. Primitive services available within the confines of the ORB are similarly available to local or remote requests at the same time as they cooperatively interact to provide the request/reply service. The Object Management Group (OMG) has been instrumental in defining the components contained within an ORB. These components are the founding elements of the common object request broker architecture (CORBA).

Basic CORBA Architecture

In this topology, the following elements may be found (see Figure 7):

• an ORB that CORBA defines as the object bus, which allows objects in the overall system to perform request/reply actions to other objects in the system
• the common object services, which provide system-level objects that allow the bus to interact with the system upon which it resides
• management facilities, which refer to applications that are used by the application objects; the objects within this facility are generic to the overall system
• application objects, which are the specific elements that provide value-added work to the system

Figure 7. CORBA ORB Architecture

One can find client/server techniques embedded within the distributed object topology. The important distinction made between client/server and distributed objects is established with the commonality that exists between member systems of a distributed object framework. While client/server relies upon either an agreed message interface or a mediation element such as a TP monitor, distributed objects rely on the existence of a common architecture from which an established mediation device may be constructed. Distributed objects is an open architecture providing participation, development, and rapid deployment of solutions.