Connecting the User and Business Service Layers | Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit

In multi-layer application design, each layer must be able to communicate with its neighbors. Thus, the user service layer and business service layer must be able to pass control to each other, as well as pass information and data. Objects can be used within a user service layer as well as within the business service layer. Additionally, many mistakenly think the UI and user service layer are the only portions of an application that can affect the desktop computer. Often business objects are distributed to the desktop client computers along with the user service layer.

Making Business Objects Available to Client Computers

Components must be properly configured for object creation to work. To start with, developers must either provide a CLSID and the remote server name in a call to CoCreateInstanceEx to create the object or install some information in the client computer's registry. To access components using Visual Basic and most scripting languages, this information would include the object's ProgID, CLSID, and RemoteServerName registry entries.

NOTE
For business objects running in MTS environments, the easiest way to provide this information is to run the client install program on each client computer. (For additional information on MTS see Chapter 8.) The client install program also takes care of installing and registering any type libraries or proxy/stub DLLs required to use vtable-binding or late-binding to access components during development.

The <OBJECT> tag is used on a Web page to automatically download the client install program, using the Internet Component Download service. The <OBJECT> tag CODEBASE parameter points the browser to the location of the program. To automatically install required remote component registry entries from a Web page using Internet Component Download, the <OBJECT> tag must be used to create the object; script code cannot download and install component information.

In addition to the general registration process for Internet components, code safety issues must be considered when using ActiveX controls or business objects from Web pages. Internet Component Download install programs should be digitally signed. Depending on the users' particular browser settings, a browser may prevent unsigned install programs from being downloaded. The digital signature lets browsers determine the install program's origin, and detect whether or not the install program has been violated.

NOTE
The Platform SDK contains information about, as well as tools for, creating signed packages for download. Some development tools, such as Visual Basic, also provide packaging and deployment tools used for signing packages.

ActiveX Components should be marked as:

Safe for scripting Users are notified that client-side scripts won't use the application's components to harm user computers or obtain unauthorized information.

Safe for initializing Users are notified that the Web page's controls will not harm the user's computer.

The easiest way to perform this action for both scripting and initializing is to add the following subkeys to the registry under a component's CLSID:

 Implemented Categories\{7DD95801-9882-11CF-9FA9-00AA006C42C4} Implemented Categories\{7DD95802-9882-11CF-9FA9-00AA006C42C4}

If components aren't marked as safe for scripting and initializing, a browser can't create objects or make method calls to objects, depending on individual browser settings.

Accessing Business Objects in Native Applications

For native Win32 applications, the mechanics of accessing remote business objects with DCOM really aren't much different from those for accessing any other COM component. (We discuss DCOM is further detail in Chapter 8.) Developers simply call CoCreateInstance, CoCreateInstanceEx, or the equivalent object creation mechanism provided by the development language being used. After a DCOM-based object is created, method calls can be made as usual.

NOTE
The object context's CreateInstance method should be used only to create MTS-hosted objects from within the MTS environment. CreateInstance should not be used to create remote business objects from applications running on users' computers. Such applications are base clients, running outside the MTS environment.

Native client applications should acquire and hold interface pointers to MTS-based business objects rather than recreate objects each time they are needed, largely to avoid the expense of locating remote servers and establishing communication sessions between computers. Typically, an application creates objects during its initialization, or when a specific portion of the application is first accessed.

Interface pointers returned from object creation should be stored in application variables for future use. These pointers don't need to be released until the application in which they are stored shuts down, unless the application receives a communication error during a method call. Such a communication error could indicate that the remote server computer is unavailable. Releasing and reacquiring the interface pointers allows the application to take advantage of MTS fail-over support on the server.

Accessing Business Objects in Web-Based Applications

COM objects can be created on a Web page using:

The HTML <OBJECT> tag Objects are created during page rendering. This technique is normally used for visual objects, such as ActiveX controls.

Script code Objects are created only when the script is executed.

These two methods of creating COM objects work for both client-side and remote COM objects. Client-side script code is used to call methods on objects, regardless of how the objects were created. The script code provides access to the methods and properties exposed by the objects' IDispatch interfaces.

When using the <OBJECT> tag, the business object's ClassID can be specified and given an ID so that the object can be accessed from client-side script code. The following <OBJECT> tag can be used to create an instance of a component:

 <OBJECT ID="objCustomer"    CLASSID="clsid:6FED8869-EAC5-11D1-80F4-00C04FD61196"> </OBJECT>

The exact script code used to create objects depends on the scripting language used. In VBScript, the CreateObject function is called, as shown here:

 <SCRIPT LANGUAGE="VBScript">    Dim objCustomer    Set objCustomer = CreateObject("bus_CustomerC.Customer") Do other program logic.    Set objCustomer = Nothing </SCRIPT>

In JScript, the ActiveXObject object is used, as shown here:

 <SCRIPT LANGUAGE="JScript">    var objCustomer;    objCustomer = new ActiveXObject("bus_CustomerC.Customer"); Do other program logic.    objCustomer = ""; </SCRIPT>

After the object is created, the object methods can be accessed through script code, using the object ID as the variable's name, as shown in the following example:

 <SCRIPT LANGUAGE="VBScript">    Dim rsCustomer    Set rsCustomer = objCustomer.GetByEmail("someone@microsoft.com") </SCRIPT>

Accessing Remote Objects Using RDS

Another option for accessing remote objects from client computers is to use RDS to call objects via DCOM or HTTP. RDS can be helpful for accessing remote objects from Web pages. However, like most scripting languages used in Web page development, it can access methods only on an IDispatch interface exposed by a set of components.

To use business objects with RDS over DCOM, they must be marked as safe for scripting and initializing, as described earlier. The client computer needs only a registry entry mapping the component's ProgID to its CLSID.

To use business objects with RDS over HTTP, their ProgIDs must be added to the ADCLaunch registry key on the server computer, as follows:

 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ADCLaunch

The RDS.Dataspace object is used to invoke business objects. The following code fragment shows how a Web page could create a remote object and call its GetByEmail method using RDS over HTTP:

 <SCRIPT LANGUAGE="VBScript">    Dim rdsds, objCustomer, rsCustomer    Set rdsds = CreateObject("RDS.Dataspace")    Set objCustomer = rdsds.CreateObject("bus_CustomerC.Customer", _                                         "http://webservername")    Set rsCustomer = objCustomer.GetByEmail("someone@microsoft.com") </SCRIPT>

The DataSpace CreateObject method generates a client-side proxy that calls methods on an object using IDispatch over DCOM or HTTP. One parameter specifies the ProgID of the object to be created. Another parameter specifies the object's server name. This parameter controls whether the object is called over DCOM or HTTP. If the server name is specified using the form \\machineName, DCOM is used. However, if the server name is specified using the form http://machineName, HTTP is used. HTTP over the Secure Sockets Layer (HTTPS) is also supported.

NOTE
For more information about using RDS, including sample code, refer to the Microsoft Data Access SDK documentation included in the Platform SDK. The white paper Remote Data Service in MDAC 2.0 by Kamaljit Bath is another excellent source of information; this white paper is available from the MSDN Web site at http://msdn.microsoft.com.

Using Data Binding

RDS can also be used to return disconnected ADO Recordset objects to client computers. In Internet Explorer 4.0 and later versions, DHTML data binding can be used to connect these Recordset objects to HTML elements on Web pages in development. Using data binding and client-side scripting allows users to browse through the Recordset objects without reconnecting directly to the to the Web server to retrieve additional records.

The data-binding support in Internet Explorer 4.x and later versions is not specific to any particular type of data. Internet Explorer will bind to any type of data for which there is a data source object (DSO). The DSO is responsible for transporting data between client and server computers, manipulating the data, and providing an object model for script access. The DHTML attributes DATASRC, DATAFLD, DATAFORMATAS, and DATAPAGESIZE are used to determine data origin, data fields bound to particular HTML elements, treatment of data as text or otherwise, and the number of records to be displayed on a page.

The RDS.DataControl object is a DSO for OLE DB Rowset objects and ADO Recordset objects. The RDS.DataControl object supports both two-tier and three-tier models of data access. In the two-tier model, data source information is embedded in the Web page, and each client gets its own connection to this data source. In the three-tier model, business objects are used to return a disconnected Recordset to the client, which is in turn attached to a DataControl object.

Visual Studio 6.0 supports data binding to ADO Recordset objects. Developers can use the ADO Data Control object to establish a connection between data-bound controls and a Recordset object. First, an ADO Data Control object is created. This object's Recordset property is then set to a Recordset object returned from business objects. The DataSource property of each data-bound control on a form or in a dialog box is set to the ADO Data Control object. The Recordset object can also be attached directly to each data-bound control using the DataSource property.