2.1 Introduction

2.2 Review of Distributed Computing Concepts

2.2.1 Remote Procedure Call

2.3 Natural Access Architectural Model

2.3.1 Managed Resource

2.3.2 Service Implementation

2.3.3 Service API

2.3.4 Service SPI

2.3.5 Service Manager

2.3.6 Dispatcher

2.4 Dispatcher Functionality

2.4.1 Communications

2.4.2 Built-In Dispatcher Services

Service Setup

Command Processing

Event Handling

Error Handling

Parameter Management

Tracing

2.5 Summary

2.1 Introduction

This chapter describes the Natural Access programming environment from a service writer's perspective. Included is a discussion of the internal architecture of Natural Access and an overview of each of the Natural Access components.

The Natural Access internal architecture is based on the client/server model of distributed computing. Before describing the Natural Access internal architectural model, the following sections briefly review distributed processing concepts and implementation strategies.

2.2 Review of Distributed Computing Concepts

Distributed computing refers to two or more processes (which can be located on different computers) that interact with each other over a communications channel in order to accomplish some computing task. The client/server model is a popular model for implementing distributed computing. In this model, two different sets of code, known as the client and the server, are produced. These parts are typically located on different computers within a network, although they may exist within different processes on the same computer, or even within different libraries within the same process.

The client makes a request over a communications channel and waits for a reply. The server waits for incoming requests, processes the request, and returns a response. In this model of computing (shown in Figure 6), the server is responsible for coordinating and providing access to a resource on behalf of one or more clients. The resources controlled by a server can be any computing resource such as a database, a physical device, or even another server process.

Figure 6. Client Server Model

Writing an application that works in the raw client/server environment requires detailed knowledge of interprocess and network communications mechanisms. This means that a large portion of implementing applications in this environment deals with communications details rather than with server implementation details.

2.2.1 Remote Procedure Call

Remote Procedure Call (RPC) is a way of implementing the communications between the client and server in the client/server model. The main strength of RPC is that the details of using interprocess and network communications mechanisms are hidden.

Using RPC, the client makes a procedure call which looks like a local call from the client's perspective. The procedure call is translated into a message and sent to the server using the RPC specific communications protocol. Once the server receives the request, it is translated back to a procedure call and the appropriate server procedure is executed. Responses are returned in a similar fashion.

RPCs are actually implemented via stubs and an RPC runtime library as shown in Figure 7. Stubs contain functions which map simple local procedure calls into a series of RPC function calls. RPC function calls are the communication interface implementing the RPC protocol and also specify how the messages are constructed and exchanged.

Figure 7. Remote Procedure Call (RPC)

Both client and server communicate via stubs; one for the client and one for the server. The client stub calls RPC library procedures to:

1. Package (marshal) the arguments and ID of the call into a message

2. Find the server

3. Transmit the message to the server via the RPC runtime library

4. Wait for the response from the server

5. Return the response to the caller

The server stub calls RPC library procedures to:

1. Receive the incoming message from the RPC runtime library

2. Unpack (unmarshal) the arguments and procedure id

3. Invoke (perform an upcall to) the appropriate server procedure

4. Marshal the results

5. Send a response back to the client

In the client/server and RPC environments, the term service is used to describe both the remote procedure call and remote procedure implementation components of the server. These parts are also called the service interface and service implementation components, respectively. The service interface component is typically packaged as a library to be linked into a client application. Similarly, the service implementation component is packaged as a separate library to be linked into a server process (a daemon). Note that both components (both libraries) could be linked into the same application - effectively making one process operate as both client and server.

As described earlier, the internal architecture of Natural Access is based on the client/server model. The internal implementation strategy of Natural Access is loosely based on RPC. The outcome is a highly efficient, distributable infrastructure for telephony services. The following sections introduce the Natural Access architecture and describe its components.

2.3 Natural Access Architectural Model

Figure 8 illustrates the components in the Natural Access architecture. In each of the following sections, the components of the Natural Access architecture are explained and identified with the analogous components of the RPC model.

Figure 8. Natural Access Architectural Model

2.3.1 Managed Resource

Natural Access provides an environment for an application to interact with a managed resource such as a telephony board.

Figure 9. Managed Resource

The Natural Access application corresponds to an RPC client. The managed resource corresponds to a managed resource in RPC.

2.3.2 Service Implementation

The service implementation provides the underlying (detailed) logic to interact with the managed resource.

Figure 10. Service Implementation

A Natural Access service implementation corresponds to an RPC service implementation.

2.3.3 Service API

In order to access the managed resource via the service implementation, a Natural Access application makes calls on a well-defined API. The service API is the set of function calls, including arguments and managed parameters, return values, and asynchronous events, that define the work that is performed by the service.

The service API acts as a "contract" specifying what a client can expect and what an implementation must provide.

Figure 11. Service API

The service API corresponds to the list of remote procedure calls in RPC.

2.3.4 Service SPI

The service SPI (Service Provider Interface) converts the API call into a message that is suitable for transmission to the service implementation.

Services communicate with other services by calling their SPI functions (as opposed to using their high level API).

.

Figure 12. Service SPI

The service SPI corresponds to the RPC client side stub.

2.3.5 Service Manager

The service manager is a set of well-known, Natural Access-specified functions (known as binding functions) to be implemented on a per-service basis.

Among other things, the service manager implements binding functions to start up and shut down the service implementations, and functions to perform upcalls to service implementation functions.

Figure 13. Service Manager

The service manager corresponds to RPC server side stubs and a portion of the RPC runtime library having to do with upcall processing.

2.3.6 Dispatcher

The dispatcher provides the communications channel between the service interface and the service implementation components. The dispatcher also provides a set of built-in services addressing common, system-level programming needs.

Figure 14. Dispatcher Functionality

The dispatcher services are called via dispatcher functions (disp functions). The service manager binding functions interact with corresponding dispatcher built-in services.

Some dispatcher services are also available to the application and can be accessed via an associated Natural Access API call. For example, the Natural Access function ctaSetParmByName calls the dispatcher function dispSetParmByName.

2.4 Dispatcher Functionality

The dispatcher is responsible for providing functionality for:

• Communications

• Built-in services

2.4.1 Communications

The dispatcher provides and maintains a communications path between the SPI and the service manager. By using dispatcher functions, details of network programming are hidden from the service developer.

Figure 15. Dispatcher Communications

The Natural Access dispatcher corresponds to portions of the RPC runtime library having to do with low level IPC and network communications.

2.4.2 Built-In Dispatcher Services

The dispatcher built-in services include the following:

Figure 16. Dispatcher Built-In Services

Service Setup

When setting up a Natural Access application, services and service managers are registered and initialized by calling dispatcher functions. These dispatcher functions declare the version numbers, compatibility levels, and binding function addresses for the service.

Command Processing

When an application calls a service API function, a command buffer is passed to the dispatcher. The dispatcher invokes the appropriate service manager binding function which, in turn, performs an upcall to the corresponding service implementation function.

Event Handling

Conceptually, an event service is a mechanism that allows:

• Event producers to publish their events in a well-known location.

• Event consumers to register their interest in certain events and, when those events are published, to retrieve them.

An event service does not impose a restriction the types of event information that can be published nor does it inform the consumer as to the contents of an event. The content of an event is completely determined and documented by the producer of the event.

However, an event service defines the transport structure to encapsulate the raw event published by the producer and retrieved by the consumer. By doing so, the mechanics of sending an event from the producer to the consumer are greatly simplified since the event service is trafficking in only one common data structure.

The dispatcher includes a built-in service to provide streamlined event service functionality. The built-in dispatcher event service:

• Defines a generic event structure for transport of events between Natural Access services and Natural Access applications. This generic event structure encapsulates raw event data produced by a service.

• Provides the ability for a Natural Access service to define and publish events to a specific consumer (either another Natural Access service or a Natural Access application).

• Provides the ability for a Natural Access service to process an incoming event.

• Provides the ability for a managed resource to publish raw (unencapsulated) event data to a specific Natural Access service.

• Provides the ability for a Natural Access service to process an incoming raw event from a managed resource via a specific callback function.

Error Handling

Natural Access handles errors in API calls by calling an error handler. The default error handler simply returns the error as the function return value. An application may override error handling by registering its own error handler with Natural Access. Internal errors in services or service managers are sent to the trace log if tracing is enabled.

Parameter Management

Each service has a defined set of parameters that allow dynamic modification of service behavior. These parameters are specified by each service, but are managed by the dispatcher. Each context maintains the parameter values for each service opened on the context. There are also global defaults for service parameters that may be either shared between processes or held locally in process memory. Parameter default values are copied from the global defaults to a context when it is created. Natural Access parameter functions can be used by an application to modify either the parameter values in a specific context or the global default parameter values.

Service APIs support the passing of structures for parameter values. Parameters passed in API calls modify the behavior of the function but do not modify the default parameter values stored in the context.

Each service has a set of standard parameters that all conforming service implementations must expose. Natural Access also provides the capability for services to define extension parameters. Currently, Natural Access services do not define any extension parameters.

Tracing

To facilitate debugging of both services and applications, Natural Access provides a built-in dispatcher service to log warning, error, and informational messages to a central location. These messages are referred to as trace records. The trace records can then be viewed via the ctdaemon utility. Refer to the Natural Access Developer's Reference Manual for more information on how to use ctdaemon.

There are a variety of trace record categories that are supported by the dispatcher built-in tracing service. For some of these categories, the Natural Access dispatcher automatically generates the trace records. The remaining trace record categories are service-specific. For service-specific trace records, each Natural Access service must associate corresponding trace records and explicitly generate them.

The dispatcher also provides a mechanism (a tracemask) to identify which trace record categories are active. If the trace record category is active, the associated trace records are generated and logged.

2.5 Summary

The Natural Access architectural model is based on the RPC implementation strategy of the client/server model. Rather than using RPC directly, Natural Access was developed to address the following additional requirements beyond what is specified by RPC:

• Event handling
  RPC is a request/reply paradigm. The service can only respond to requests from a client. Natural Access also requires the ability for a service to generate unsolicited events and send them to clients.

• Built-in services
  RPC does not provide an infrastructure of "system-level" services such as parameter management. Natural Access requires a rich infrastructure of built-in services.

• Efficiency
  Access to Natural Access services must be very efficient with very little overhead in processing a message from the service interface to the service implementation.