| DCOM Explained by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98

Previous | Table of Contents | Next

### Context Bridging

Context bridging is the ability to transfer messages between network protocols transparently. The important point about context bridging is the complete transparency of the service—the service not only passes the message on between software products but also handles the transfer between network stacks.

DCOM supports TCP/IP, UDP (which is used internally between Windows NT machines), IPX/SPX, and NetBIOS network protocols. Appletalk support is planned—may even be available by the time you read this book (with the release of DCOM on the Macintosh). Microsoft uses the connectionless UDP subset of TCP/IP to improve performance—by using UDP low-level acknowledgement, packages can be merged with actual data and pinging messages.

DCOM supports context bridging between all the protocols it supports. Three-way bridging is also possible, in addition to the normal two-way bridging. In addition to the normal support provided by DCOM, the use of Cedar adds additional support for the IBM LU6.2 protocol. Cedar uses standard communication protocols (LU 6.2) for communicating between the computer running Windows NT Server and the mainframe TP Monitor. This time, however, as we saw in the last chapter, Microsoft SNA server 3 is used as the bridging software to handle the protocol exchange.

### Broadcasting and Multicasting

The default communication approach supported by DCOM is what is termed one-to-one or point-to-point communication. In DCOM’s one-to-one communication approach the developer uses an invocation of a method. This form of conversation is termed request/reply—a client requests that a method is invoked and a reply is expected.

So called one-way communication where the client sends a request but no reply is expected is not supported by DCOM. This contrasts with CORBA, for example, which does support one-way communication. Even though this style of communication is called one-to-one, a client can communicate with one or more components. Similarly, a component can receive requests from more than one client.

But the request/reply, one-to-one form of addressing is not the only approach that DCOM supports.

What if the client, for example, wanted to send details of an event, but wanted the servers to register their interest in the event? In this case, the client should not need to know all the addresses of the servers that had registered an interest; all it should need to know is that it was supplying an event as opposed to a request.

This type of communication is called broadcasting (all servers on the network receive the event) or multicasting (only those servers registering an interest get to know of the event). DCOM supports broadcasting and multicasting using a special form of interface called the Outgoing or Event Interface.

Where a normal interface is used, the interface is used for incoming calls to methods in a class—the client calls methods via the interface using a request for the method invocation. If the Outgoing or Event Interface is used, the server/class can inform clients of an event via this outgoing interface. If a server has this interface, it is called a connectable object.

Figure 9.4 The outgoing interface

A client that uses the outgoing interface on an object is called a sink, and a special process is implemented within the client to handle incoming calls. From the sink’s perspective, the interfaces appear to be incoming and the sink listens through them.

Interfaces in this case are composed of a series of “functions,” which are actually events, notifications, or requests.

Events and notifications are used to tell the client that something has happened and no reply is expected (one way). A request is used to tell the client something, but a response is expected (two way). A class (connectable object) can distribute event details to multiple client sinks, and those client sinks can be connected to any number of outgoing interfaces—in other words, listen for multiple events.

Figure 9.5 A client can be connected to multiple outgoing interfaces

The mechanism used to handle registration within the component is called a “connection point.” The connection point allows callers to connect a sink to the connectable object, to disconnect the sink, or to enumerate existing connections.

Connection points are subobjects of the connectable object that are owned by it but that are separate. The reason Microsoft has used this approach is to avoid “reference counting” problems (see Triggers). The sinks connect and disconnect themselves from the outgoing Interfaces, so the component itself does not need to know which clients have registered an interest in knowing about an event.

By connecting themselves to the Interface, the client is effectively registering an interest in all events in the interface. But since a component can have multiple interfaces, it is possible (where a component can generate multiple events) to split up the events into groups and allocate each group to a different interface. In this way the clients need only be informed of the events in which they are interested.

What does all this mean in practice? It means that a component can either “broadcast” or “multicast” details of an event to all the clients interested in the event without needing to know the name or address of those clients. This is a useful feature because it means new clients can be added or old clients removed without needing to alter the component generating the event.

So, a component could be written that monitored the stock value of a share, for example, and once it had reached a certain value any client interested in this event could be informed. Perhaps one type of client was connected to customers owning the share, another type was connected to stockbrokers, another to the actual owners of the company with the share, and so on. All these could register an interest and then write their own processes to act on the information. This technology has also come to be known as publish and subscribe because one component publishes the information and many others subscribe to receive details about it.

In effect, this form of communication is similar to (but not the same as) the CORBA events channel approach. The difference is that CORBA uses an intermediate memory-based store or disk-based store to hold the events before it sends them off to the clients. Microsoft’s events are directly communicated to clients; there is no “holding store” where they are temporarily held.

Previous | Table of Contents | Next