Position Paper: A NIIIP Architecture Perspective

Art Goldschmidt
NIIIP System Architect

National Industrial Information Infrastructure Protocols, NIIIP, is a consortium of more than a dozen organizations. Visit our home page at http://www.niiip.org. The views expressed are those of the author and are not an official position of the NIIIP consortium or any of its members.


"Wireless mobile communications in the near future will make it possible for one to communicate with any mobile device anywhere in the world [1]." "Weaving a web of trust" between "people, commuters, and organizations" sharing is now envisioned[2]. The computing paradigm itself is turning from the Turing machine to "interactions between objects" [3] ; from Shannon's information coding to neural nets, semiotics and semantics; and from the shared database to the "local ontology" a of set of objects accessible through "mediators[4]." What kind of infrastructure can address all of these requirements?

When several organizations, each with their own heterogeneous data, processes, and people, each operating behind firewalls, form a "virtual enterprise" to meet some goal, collections of objects must inter-operate both among themselves and with other virtual enterprises, as envisioned in the above references.

The complexity of virtual enterprises is such that its objects cannot inter-act directly, but must communicate through intermediate control frameworks. Frameworks themselves are such a complex assemblage of subsystems , susceptible to "viruses" and exhibiting "intelligent behavior", that one wonders if they'll end up needing analogues of the same the functional sub-systems as those provided by animate systems (e.g. nervous, immune, endocrine, digestive, reproductive, etc.).

An open question for the NIIIP project, in developing its protocols for enabling the Virtual Enterprise (VE), was how many of such sub-systems would be needed? (And yes, the NIIIP architecture does support the merging of two complex object "virtual enterprises" to produce a third VE, with each of the original two retaining their own identities. Should OMG have an RFP out on "merging" of communities of objects?)

From the perspective of the NIIIP Architecture experience, much of the functionality in OMG's OMA, CORBA, and CORBA Services are useful building blocks. But some modifications , as outlined in the following four positions, would require changes to the OMG OMA, and require a different approach to composing legacy and object system services to meet tomorrow's requirements.

1. Object Services such as Security and Transaction should not be bound to a particular ORB.

The problem is that if these kind of services are tied to the transport bus of the particular object system that initiates the object request, then any VE control structure that was implemented elsewhere in some foreign object system, fails to be exercised. One object system may need to get system level services, such as security and transactions, from an entirely foreign system than that which originated the request. These services might be implemented as CORBA, DCOM, DCE, Java , or other object system services .

What needs to be architected within each of kind of object system is a mechanism and protocol to pass control to a designated "middle-ware" component not necessarily implemented in the same object system as that which initiated the request.

An example of such a protocol might be for the CORBA ORB to examine the "principal object" parameter of an object request, and using it as a key to a look-up table within its own ORB, to obtain the "inter-operable object request", IOR, of some middle-ware services "object" to which to pass the initial object request. That middle-ware services environment, upon completion of its subsystem pre-processing, might dispatch the original request back to the originating ORB (e.g. object system), or to some other system. In either case, that system returns control back to the middle-ware object for post-processing, which then returns control back to the originating requester.

Other object systems would also need to establish a similar service inter-operation protocol.

2. Object Services should be composed to support a "work" environment.

In traditional work environments, such as on IBM main-frame computers, the unit of work is either the "job" or the "transaction." A job has one or more "steps". Each step executes a program, with zero or more input and output data files. A transaction is a unit of work that modifies a database, such that the entire set of modifications can be committed or aborted as a unit

In both traditional environments, exits are architected that allow other middle-ware to mediate the data and control flow. The job environment has exits for accounting routines and result code testing at the end of each step. The database environment allows for "stored procedures" that can execute, before, after, or during the execution of the underlying original request.

A "business object framework, a BOF, that uses CORBA services should be composed to address the requirements of complex workflows within VE environment of heterogeneous resources.

3. The BOF should be structured in multiple layers, rather than as objects inter-acting through a single "universal" ORB.

This position follows from the previous two positions: 1.) the middle-ware services are not tied to a particular ORB ; 2) the request must go through the middle-ware; 3.) a protocol, customized via "exits" to the needs of the VE, must be obeyed to manage the work; and 4.) the VE protocols must invoke standardized interfaces that can be used to wrap the heterogeneous "implementation repositories" and "commercial off the shelf" (COTS) products that provide the desired service.

Therefore five layers are needed: a client layer to initiate object requests; a gateway layer to provide a targets for the VE specific middle-ware; a protocol layer to enforce the rules of behavior of the VE; a interface layer to wrap the services of the COTS products; and a service layer to actually invoke a method activation upon the requested object or wrapper object.

4. The future requires an infrastructure that is "goal-oriented", and supports interactions between people, objects, and organizations, using heterogeneous interfaces and protocols, i.e. a Virtual Enterprise infrastructure.

Within the five layers defined above, the NIIIP architecture provides an example of the kinds of constructs and protocols for managing complex work that might be needed. As shown in the following figure, it's infrastructure doesn't make the ORB a center point, but rather four "gateway servers" at the second layer, to which all human, software, or external event requests from the first layer are directed.

These four gateways mediate the flows between clients of various "real organizations", doing work behind their own firewalls. The VE Registry locates VE resources, like an OMG Naming Service, but with an LDAP interface and additional VE "bootstrap" creation and termination functionality.

The VE Knowledge Base acts like a BOF and an Internet MIB (Managed Information Base), functioning as an active database. All objects used by the VE are dually represented in the VE's Knowledge Base. It may be physically distributed, and even have portions of itself cached on client desktops.

The VE Event Channel, using the CORBA Event Service and IIOP, routes asynchronous requests between multiple VEs that share common resources. For example, lock or unlock events are posted between VEs through sets of event channels that subscribe to some of each others events.

The VE Server provides intermediate storage and other services.

The twelve system protocol, illustrated in the third layer, make sequences of calls to interface objects in the fourth layer. These objects wrap the implementation systems in the fifth layer. In the fourth layer, NIIIP has adopted interfaces from OMG and STEP communities and has defined some of its own, while waiting for OMG services such as the BOF and PDM to mature.

It is only in the fifth layer, that an ORB, with its Interface and Implementation Repository "plumbing" occurs. Conceptually, in this scheme, the ORB is at the same level a database or procedural application.

[1] Likourezos, George, "Prolog to Application of Antenna Arrays to Mobile Communications," Proceedings of the IEEE, Vol., 85, No. 7, p. 1029.

[2] Khare, Rohit, Rifkin Adam, " Weaving a Web of Trust", World Wide Web Journal, Vol. 2, No. 3, p.77.

[3] Wegner, Peter, "Why Interaction Is More Powerful Than Algorithm", Communications of the ACM, Vol.40, No.5, pp. 81-91.

[4] Wiederhold, Gio, "Mediators in the Architecture of Future Information Systems", IEEE Computer, Mar 1992.