Communication Between Components

The manner in which we distribute our components and how they will be connected will affect the way we code our components, the interfaces we will create and the type of security we will implement (see later). If we were placing all of our components on one computer, then our components would communicate using COM. However, COM objects can communicate directly only if they are running in the same process space. Since we are placing our data and business services components on different machines, we will need to choose some other method of communication. The most common choices for connecting client and server components are Distributed COM (DCOM) and Remote Data Services (RDS).

With regard to our project, RDS is the perfect choice. For our web application, we can use RDS to make the connection between the server object and the client through a Microsoft Internet Information Server (IIS), using HTTP. RDS also supports DCOM, so for our order processing application this can be our means of communication across a local network.

OK, let's find out how this works.


RDS is a powerful technology that allows us to retrieve recordsets from remote databases and manipulate these databases in client-side script, in a way that minimizes network traffic. Using RDS, an entire set of data can be returned to the client. The client can then filter and manage the recordset without the server.

This is an ideal scenario for our E-commerce site. Let's think again about this application, which allows customers to view the products on a web site. Say a customer is browsing through one range of products and then decides to look at a completely different range. Without RDS, the browser would have to request new data, wait for a response from the server, receive the new data and then reload the page. With RDS, all of the data is on the client so the speed of the web application approaches that of more traditional desktop applications.

The data is held on the client in an ADOR Recordset object. This is a smaller, lightweight version of the full ADO Recordset object (it doesn't have the explicit Command and Connection objects). The ADOR Recordset object is designed for transmission over the relatively low-bandwidth connections of the Internet and so has a smaller footprint in memory. Our application won't require a constant data connection because the connection is severed without affecting the data. This is because RDS is very closely associated with ADO, which, as we know, provides disconnected recordsets.

How does all this work? Essentially, RDS works by making the connection between the server object and the client through a Microsoft Internet Information Server (IIS) web server. As we discussed earlier, COM objects cannot communicate directly if they are not running in the same process space, therefore there needs to be a mechanism by which they can communicate when they are running in different processes. A full description of how this comes about would include a detailed discussion of the RDS object model. This is beyond the scope of this book.

For a full description, I would refer you to Professional ADO RDS Programming with ASP,

ISBN 1861001649, published by Wrox Press.

However, we must briefly mention the RDS. DataSpace object. This object runs on the web client, creates COM objects on an IIS server and returns an object reference from the server to the web client application. These references are called proxies and are a bit like your television remote control. In a similar manner that you can press a button on your remote control to make something happen on your television, a client-side proxy object is the remote control that can be used to make something happen on a server side object across the Internet.

A proxy is an object that provides a pointer to another object in another process. The other object in the other process is known as a stub.

RDS will make a proxy of the Server object on the client. The proxy will look exactly like the Server object, that is, it will have the same public properties and methods as the Server object. As far as the client application is concerned, the Proxy object is identical to the Server object. The client will make requests to the Proxy object, and the RDS will pass this request to and from the Server object on the server. This is called marshalling.

Marshaling, through an IIS Web Server, is done using HyperText Transport Protocol (HTTP) - the standard Web protocol. The following diagram may help to explain how marshalling works:

How Marshaling Works

Object A

1.) Object A sends data to Object B proxy, which it believes to be Object B.


2.) Object B Proxy accepts the data, packages the data, addresses the package and send it to Object A Stub.

Object B Proxy



'ill III

Process 1

To Object B

Process 2



Object A Stub

3.) Object A Stub receives the package, unpacks the data and sends the data on to Object B.



Object B

4.) Object B receives the data and thinks it received the data directly from Object A.

Marshaling is the process that must occur when a proxy communicates with a stub. When they communicate with one another, the message must be packaged for transport across process boundaries. After the message is packaged, it is sent (copied) form the proxy to the stub. When the stub receives the message, it must be unpackaged and sent on to the server object. Marshaling does not include the instantiation or destruction of objects, but is the activity of passing data across process boundaries.

The connection to a Server object using RDS would look as follows:

The major advantage of this technique is that the client only has to be configured to have an Internet or an intranet connection. RDS using HTTP allows users to access the database on any client via an Internet connection. The connection to the server may be made through a Domain Server Name (DSN). Therefore, the client needs no knowledge of the server's actual address or, in fact, any information on the server whatsoever. This allows the DSN address to act as a gateway that may actually represent any number of actual Web Servers.

The really great thing about RDS is that as well as supporting HTTP - it also supports DCOM.

DCOM is a Microsoft technology that enables COM components to communicate with each other across a network. DCOM extends COM in a transparent fashion, such that any existing COM component can be remotely used without ever changing a single line of code (although it is important to remember that a COM component written without any consideration to DCOM specific issues, probably won't be efficient or scalable). DCOM is language neutral. This means that any language that can produce COM components can have these components run over DCOM. A very good introduction to DCOM can be found in the book VB COM, published by Wrox Press.

ADO disconnected recordsets are optimized for use with COM/DCOM so DCOM is the perfect means of communication between remote COM components on a local area network, without HTTP. This is a perfect solution for our order processing application!

DCOM can be difficult to configure when there are thousands of clients (such as for a web application) but is an excellent choice for Intranet or internal applications.

Below is a summary list of components required for an RDS project:

> Visual Basic ActiveX DLL: You can actually build your server components as a Visual Basic ActiveX DLL or as a Visual Basic IIS application. The ActiveX DLL will give you a greater degree of control over who can access your data over the Internet than an IIS application. IIS applications, though, give you more flexibility and perform better when there are dozens of forms.

> Microsoft Internet Information Server: This is required for RDS to connect to the server using the HTTP protocol and the Internet. This must be an NT 4.0 Web Server with the Option Pack installed (RDS is installed with the Option Pack by default).

> Database: A database for which there is an OLE DB provider.

> Client Machine: This computer must also be connected to the Internet - usually through an Internet service provider (ISP). To deploy the client application, use the Visual Basic Package and Deployment wizard, which will ensure that both ADO and RDS are installed on the client machine.

Effect of MTS

Finally, before we start creating our activity diagrams we need to consider how the use of MTS will affect the design of our components. Running our components in MTS will add some activities to our diagrams and we at least need to discuss these MTS activities. As we discussed previously, MTS offers two main advantages to our product:

> It provides scalability by managing object lifetimes.

> It provides support for transactions.

Was this article helpful?

0 0
365 Days Of Motivation

365 Days Of Motivation

Stop Wasting Time And Learn How To Stay Motivated. Finally! Discover How To Stop Your Mind From Wandering, And Upgrade Your Motivation. You Can Hack Your Motivation Levels, Allowing You To Take Your Life To The Next Level.

Get My Free Ebook

Post a comment