FOCUS: DISTRIBUTED COMPUTING

Common object request broker architecture (Corba) is becoming a hot topic in the embedded-communications arena. That is not surprising. Its key benefit to programmers is that it allows them to construct complex distributed object-based applications that offer near-universal interoperability among diverse programming languages and hardware architectures that are just as attractive in embedded systems as they are in the enterprise environment.

In addition, an increasing number of embedded devices interact with Corba-based enterprise systems, making it only natural for embedded systems to adopt the same coloration. Corba has made significant inroads in telecommunications, process control, industrial automation and defense electronics--all established playing fields for embedded systems.

But conformity with the enterprise computing world is not the only reason for embedded-systems developers to consider Corba. It is also an excellent platform for Internet connectivity and Web-based applications. Corba and its Internet Inter-ORB (object request broker) Protocol (IIOP) have proved to be a magnet for Java-language tool support as exemplified by the inclusion of a Corba ORB in Sun Microsystems' Java Development kit.

However, Corba has largely sneaked up on the embedded community without much consideration of how its enterprise baggage can be accommodated in embedded computing environments. Embedded developers opting for Corba in the design of their distributed-computing environments have had to transplant software designed for enterprise computing into their applications.

And, while it is possible to build network-connected embedded applications that contain enterprise-focused Corba technology, it soon becomes apparent that mainstream Corba makes no concessions to accommodate embedded systems. This is particularly true in the areas of memory required to support Corba software and the relationship between Corba and pre-emptive multitasking real-time operating systems (RTOS).

Over the last year, the object-management group (OMG)--the steward of the Corba standards--has taken two major steps to make Corba more embedded friendly. First, it has issued a specification for scaling down ORBs to better fit into more memory-constrained embedded environments: the minimum Corba standard. Second, OMG's Technical Committee is in the final stages of approving optional extensions to Corba standards that bring more clarity to the task of synchronizing ORB operations with those of software environments based on real-time operating systems.

Corba's capabilities and widespread acceptance have made it a mainstay of enterprise computing. However, enterprise computing environments significantly differ from typical embedded distributed computing environments. First, in the enterprise world memory resources are effectively unlimited. Embedded environments strive for minimal memory footprints to reduce cost, board space and opportunities for inefficient application execution and system failure.

Enterprise operating systems execute tasks on the basis of fairness, run to completion or data-throughput maximization. Embedded systems usually contain some kind of real-time operating system that executes tasks either according to priority or against a hard deadline. Higher-priority tasks can pre-empt lower priority tasks currently running on a processor. By contrast, an enterprise operating system could tell a high-priority task requesting resources to take a hike if it meant interrupting work in progress.

Basically, the OMG's work in making Corba a more-attractive option for embedded systems comes in two areas: specifications for memory-scalable ORBs and mechanisms to match ORBs and applications that use them to RTOS multitasking operations.

The minimum Corba specification describes a cut-down profile of the full Corba specification that remains sufficient for programming embedded systems. This profile concentrates on removing components of the Corba applications programming interface that are more-suited to enterprise systems.

Specifically, the minimum Corba spec removes dynamic invocation interface (DII), dynamic skeleton interface (DSI) and interface-repository (IR) features. Essentially, these interfaces support enterprise computing style run-time type checking that is typically used to support graphical user interface functions. Since embedded application developers set type information during application development, it was possible to remove DII and DSI without removing any meaningful Corba functionality from an embedded minimum Corba implementation.

However, minimum Corba offers only part of the solution for adapting Corba to embedded systems. It reduces the static memory requirement for implementing Corba, but it does not address run-time memory utilization efficiency--for example, the amount of memory required to create a Corba object in a running application. The OMG has left the matter of run-time memory allocation in real-time systems off the table, leaving embedded Corba software vendors and end users to develop their own solutions.

It is also true that OMG could have been more aggressive in stripping out more functions from standard Corba to create an even smaller footprint for embedded Corba environments. While embedded ultralight Corba implementations could still interoperate with similarly configured systems, they would have trouble acting as peers to fully configured Corba devices. OMG has decided that going too far in this asset-stripping process would degrade Corba's ability to guarantee universal behavior for Corba-compliant devices.

Also, since minimum Corba is only a subset of the existing Corba specification, it does nothing to address the other nonfunctional requirements of embedded real-time systems. These are addressed by the Real-Time Corba specification.

Although the minimum Corba standard represents a good start in adapting the technology to embedded-system memory spaces, it does not address the relationship of Corba to real-time computing. Non-real-time ORBs work reasonably well in real-time systems, but remain oblivious to what the RTOS is trying to accomplish. And there is the chance that an ORB's real-time cluelessness can compromise predictable scheduling or miss deadlines.

Clearly, it would be better if ORBs and RTOSes could work together as a team. Here the ORB would contain mechanisms that would more strongly link it to an RTOS' deadline--or priority-driven multitasking functions. A real-time-aware ORB would also contain facilities for better working relationships with other RTOS functions such as resource management and real-time-optimized communications protocol selection.

The recently completed Real-Time Corba extensions make major steps in this direction. These are optional extensions to the main Corba standards that can be employed in real-time computing environments. The extensions do not modify the main Corba standards but represent an agreed-upon approach to link standard Corba to the needs of real-time computing.

One of the key techniques used to obtain the predictability required for real-time is the assignment of priorities to tasks running in the system. The RTOS schedules task execution according to their priority, with a high-priority task able to preempt a lower-priority task. For example, in a hypothetical passenger aircraft flight-control system, the "Avoid rapidly approaching tall mountain" task will preempt the "Remind cabin crew to collect headsets" task. Most multitasking enterprise-computing operating systems wouldn't do this. In a typical run-to-completion tasking model, the flight attendants would die in a fiery cataclysm with their arms full of headsets.

Priority assignments

Fortunately for the flying public, real-time Corba extensions add a priority model that allows different priorities to be assigned to application activities. This priority assignment can be passed with Corba invocations, so that a given priority can be honored throughout a distributed activity.

Real-time Corba uses priority mapping to allow the standard Corba priority model to be mapped to the priority scheme of the particular RTOS where the Real-Time ORB is running. The Corba-to-RTOS priority mapping is user controllable, allowing for customization and optimization of the priority assignment scheme.

Real-Time Corba's single priority model provides a way to build globally scheduled systems composed of elements running on different RTOSes running on systems remotely located from each other. This also opens the door to the use of advanced scheduling techniques such as off-line scheduling tools, to prepare systems that can be verifiably scheduled.

Another critical technique in the design and implementation of embedded real-time systems is the precise control of resource utilization. Preemptive multitasking imposes tight control over a real-time system's microprocessor resource, but other elements--especially memory--require vigilance to maintain predictability in a resource-constrained environment.

By partitioning the system and rationing the amount of resources used by any one system component, engineers can insulate system elements from disturbances generated by other parts of an application. This protects critical components from resource starvation by less critical components, helping to maintain predictable system behavior.

The Real-Time Corba extensions allow programmer control of thread and memory resources through use of a thread-pool facility. In Real-Time Corba ORBs, Portable Object Adapters (POAs) are associated with a particular thread pool. The thread pool can be sized to control the maximum number of threads that objects created by a POA can use. This allows for control of the number of calls that an object can handle concurrently and the total number of threads that Corba subsystem will use.

The thread pool also makes it possible to set the stack size and idle-time priority of threads. Configuring idle-time priority increases predictability by reducing the likelihood that the thread priority needs to be changed to handle an incoming request. That way, it reduces average call latency.

Controlling memory

Real-Time Corba extensions also manage memory resources through a request buffer facility that lets programmers specify the amount of memory that can be used to store Corba requests. The amount of available memory can be controlled either in absolute terms or by specifying the number of requests that will be handled.

Embedded real-time systems usually require correct configuration of the network-transport protocols used for remote communication. This goes as far as using specialized or custom real-time-oriented protocols, such as RTP or a proprietary real-time protocol--not normally encountered in general-purpose computing.

Real-Time Corba provides interfaces for run-time selection and configuration of communications protocols used by a Real-Time ORB. The interface allows for protocol configuration down to the level of an individual Corba object using a protocol, if the protocol supports configuration at the individual object level. Providing a configurable protocol interface recognizes the fact that no single real-time protocol has yet emerged as an industry standard. The protocol configuration facility lets engineers keep their options open and powder dry.

The common-object request broker architecture, or Corba, is a set of industry standards for distributed object-based computing that's designed to facilitate reliable, platform-independent execution of object-oriented software in wide- and local-area network environments. The key element of Corba technology is the object-request broker (ORB), which acts as a "software bus" managing access to and from objects in an application, linking them to other objects, monitoring their function, tracking their location and managing communications with other ORBs.

The ORB is not an operating system but rather a form of middleware under the control of an application's operating system-Unix, Windows NT, Linux, VxWorks. Corba objects are application software modules typically written in C++ or Java. They can represent application code, text, graphics, audio, control parameters, algorithm inputs and so on.

Basically, the ORB is the main mechanism for simplifying the development of Corba-standard applications. The simplification is a result of three properties: location independence and platform and language interoperability. Location independence means that an ORB treats all objects it is aware of as local objects, even if they exist on remote systems. Platform interoperability means that objects created on one hardware/software computing platform (for example, those generated on a Pentium-based Windows NT system) can run on any other Corba-equipped platform.

Language interoperability means that objects written in one language can interact with applications written in another, thanks to Corba's interface-definition language. IDL is a contractual language that defines the interfaces to objects, but not their implementations. Objects themselves can be written in any common language (C, C++, Java) and still work on non-native systems thanks to Corba's IDL facility.

Corba also includes mechanisms for communication among objects across a network. The general inter-ORB protocol (GIOP) specifies message formats and data representations that ensure object interoperability among ORBs. The inter-ORB protocol (IIOP) defines the specific details for using GIOP over TCP/IP.

These properties of Corba give software engineers a powerful set of tools for building distributed, client-server applications. Corba offers a universally understood framework to remotely control objects resident on other systems, regardless of their hardware-software architecture. Corba makes it possible to harvest the software-reuse benefits of object-orient computing and to create applications that can run on heterogeneous platform and language environments.
-- Ken Black and Jon Currey,
of Highlander Communications LC

~~~~~~~~

By Ken Black, President and Jon Currey, Senior Embedded Corba Engineer Highlander Communications LC Lakeland, Fla.