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.
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.
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.
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.
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.
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.