A client/server bulletin system
Previous examples only work in a single machine. Assume that, instead, we want to serve the bulletin board publicly at news.com so that anyone can write a client program to access it. Here is one of the many ways to implement this. First, we publish the abstract bulletin board definition — i.e., the Msg struct and the IBulletin interface types — at api.org. The Board object at news.com then implements the abstract definition. The Client class is programmed against the abstract definition, and bound dynamically to the imop:news.com/pub.Board object only at runtime. The beauty of the design is that the Client class can use any remote object that implements the same imop:api.org/service.IBulletin interface without modification.
This OO paradigm is what most programmers accustomed to, but it is rather difficult to achieve in a distributed system with current technologies. The problem is their inability to establish a public interface definition, such as imop:api.org/service.IBulletin, that can be systematically obtained. For example, Java RMI need to have interface definitions available at compile time, but how and where to get them is undefined. To create a RMI client taking to a remote service with a, say, Java "service.IBulletin" interface, one must somehow obtain that interface class file at compile time. Java RMI does not help us with that. This makes the client and server tightly coupled due to the obscure whereabout of this essential interface. CORBA IDL files have the same problem. Newer technologies such as Web Services do not have the concept of an abstract interface, whereas RESTful services do not have machine-processable definitions at all. Neither can support the OO architecture shown above easily.
The Global Program Grid decouples clients and servers, in terms of their development, by making all data types publicly and uniquely available. An IMOP UTL can unambiguously locate a type definition regardless where it is referenced, just like a HTTP URL can unambiguously locate a document. For instance, the imop:api.org/service.IBulletin UTL clearly indicates that its definition may be obtained through IMOP from the host api.org. Anyone performs the IMOP reflection operation will get the latest authoritative copy of its definition.
Note that one should treat the entire UTL as a type's name, rather than just the /service.IBulletin part. That is, imop:aa.com/foo and imop:bb.com/foo are not a type /foo served by two different hosts, but are considered two different types.
imop : api.org /service.IBulletin ^^^^ ^^^^^^^ ^^^^^^^^^^^^^^^^^^ The imop type scheme Authority Local name location
The UTL format for user-defined IMOP data types