To register a custom business object
One of the most important features of Remote Data Service is data caching on the client. It reduces the number of requests for data between the client-side application components and the database server, which improves both the actual performance and the userÆs perceived performance of the application.
There are three ways to pass a Recordset back from your server to the client with RDS. You can:
This section explains how to pass Recordset objects using any of these methods, and it also contains information on:
You can open a disconnected Recordset by setting the RDSIE3.DataControl object's Connect, Server, and SQL properties.
The following code shows how to set these properties at design time:
<OBJECT CLASSID="clsid:BD96C556-65A3-11D0-983A-00C04FC29E33" ID="ADC1"> <PARAM NAME="SQL" VALUE="Select * from Products"> <PARAM NAME="Connect" VALUE="DSN=AdvWorks;"> <PARAM NAME="Server" VALUE="http://SalesWeb/"> </OBJECT>
Callingthe Refresh method after setting these properties on the RDSIE3.DataControl automatically calls the RDSServer.DataFactory object "behind the scenes," and Remote Data Service returns a Recordset object to the client. You don't have to actually write any code to use the RDSServer.DataFactory, but if you do want to do this, see "Getting a Recordset with the RDSServer.DataFactory Object."
Remote Data Service contains a server-side business object (ActiveX DLL) called RDSServer.DataFactory that sends commands to a data source and passes the results back across the Internet or an intranet for you. RDSServer.DataFactory is the default ActiveX DLL that you can use to provide live data on your Web page with little programming.
The following example shows how to call the RDSServer.DataFactory object from a VBScript Web page. You use the RDSIE3.DataSpace object on the client to instantiate the RDSServer.DataFactory object on the server.
<HTML>
<HEAD></HEAD>
<BODY>
<!ùRDSIE3.DataControl -->
<OBJECT classid="clsid:BD96C556-65A3-11D0-983A-00C04FC29E33" ID=ADC1>
</OBJECT>
<!-- RDSIE3.DataSpace -->
<OBJECT ID="ADS1" WIDTH=1 HEIGHT=1
CLASSID="CLSID:BD96C556-65A3-11D0-983A-00C04FC29E36">
</OBJECT>
.
.
.
<SCRIPT LANGUAGE="VBScript">
Option Explicit
Sub Window_OnLoad()
Dim ADF1, myRS
Set ADF1 = ADS1.CreateObject("RDSServer.DataFactory", _
"http://<%=Request.ServerVariables("SERVER_NAME")%>")
Set myRS = _
ADF1.Query("DSN=pubs;UID=sa;PWD=permission;", _
"Select * From Authors")
' Assign the returned recordset to SourceRecordset.
ADC1.SourceRecordset = myRS
End Sub
</SCRIPT>
</BODY>
</HTML>
If you use the RDSServer.DataFactory object on your Internet Web server, remember that doing so creates a potential security risk. External users who obtain valid data source name (DSN), user ID, and password information could write pages to send any query to that data source. If you want more restricted access to a data source, one option is to unregister and delete the RDSServer.DataFactory object (msadcf.dll), and instead use custom business objects with hard-coded queries. The next section describes how to do this.
If you don't want to use the RDSServer.DataFactory object to pass Recordset objects back to the client, you can create your own custom business object that will run on the server. The DLL(dynamic-link library) can be any generic Automation object created with Visual Basic®, Visual C++®,and so forth, or a server-side HTML page with Active Server Pages scripting code. Clients and Web front-end applications call the business objects to perform a particular function, and those middle-tier business objects in turn can communicate with back-end databases.
The custom DLLs could also contain methods that aren't provided by the simple RDSServer.DataFactory ActiveX DLL. These methods don't have to be related to data access ù they could just encompass a business rule.
This section contains information on:
The followingclient VBScript code performs the same action as the previous RDSServer.DataFactory code, except that it uses a custom business object. You still use the RDSIE3.DataSpace object on the client to instantiate the business object (in this case, MyCustomBusinessObject) on the server.
<HTML>
<HEAD></HEAD>
<BODY>
<!ùRDSIE3.DataControl -->
<OBJECT classid="clsid:BD96C556-65A3-11D0-983A-00C04FC29E33" ID=ADC1>
</OBJECT>
<!ùRDSIE3.DataSpace -->
<OBJECT ID="ADS1" WIDTH=1 HEIGHT=1
CLASSID="CLSID:BD96C556-65A3-11D0-983A-00C04FC29E36">
</OBJECT>
.
.
.
<SCRIPT LANGUAGE="VBScript">
Option Explicit
Sub GetRecords()
Dim objMyCustomBusinessObject, myRS
Set objMyCustomBusinessObject = _
ADS1.CreateObject("MyCustomBusinessObject", _
"http://<%=Request.ServerVariables("SERVER_NAME")%>")
' Assume MyCustomBusinessObject has a method called
' GetData that takes connection string and SQL
' parameters.
Set myRS = _
objCustomBusinessObject.GetData _
("DSN=pubs;UID=sa;PWD=permission;", _
"Select * From Authors")
' Assign the returned recordset to SourceRecordset.
ADC1.SourceRecordset = myRS
End Sub
</SCRIPT>
</BODY>
</HTML>
Assuming you use Visual Basic to create the MyCustomBusinessObject ActiveX DLL that is located on the middle tier, the code in the GetData method of the MyCustomBusinessObject class could look something like this. Notice that you can use ActiveXÖ Data Objects (ADO) directly.
' Returns an ADO resultset.
Public Function GetData(szCnStr As String, szSQL _
As String) As Object
Dim cn As New ADODB.Connection
Dim rs As New ADODB.Recordset
cn.Open szCnStr
' The ADODB.Recordset should generate Recordset
' objects that can be disconnected and later
' reconnected to process batch updates.
rs.CursorLocation = adUseClientBatch
' Using the Unspecified parameters, an ADO/R
' recordset is returned.
rs.Open szSQL, cn, _
adOpenUnspecified, adLockUnspecified, _
adCmdUnspecified
Set GetData = rs
End Function
Tips
Always place one simple method in your server component to test for minimum functionality before attempting to pass Recordset objects back.
Build a simple client application to test your server component before deploying and testing it with Internet Explorer.
It is easier to develop your application on a local test Web server. You will need to copy and register the .dll on the test server after each compile.
The DSN passed to your business object will need to be a System DSN on your server. If it doesn't exist or is set up improperly, your component will fail. It is a good idea to test the DSN on the server with another ODBC application such as MSQuery to make sure the DSN is set up properly.
Method names on custom business objects cannot exceed 255 characters. This allows compatibility across all RDS-supported protocols (HTTP, HTTPS, DCOM, andrunning in-process).
If you used Visual Basic to create a custom business object that uses early binding with the ADOR 1.0 type library, you should rebuild you custom business object to use the ADOR 1.5 type library.
To successfully launch a custom business object (DLL or EXE) through the Web server, the business object's ProgID must be entered into the registry as explained in this procedure. This RDS feature protects the security of your Web server by running only sanctioned executables. The default business object, RDSServer.DataFactory, is already fully registered.
To register a custom business object
To help ensure a secure Internet environment, you need to mark any business objects instantiated with the RDSIE3.DataSpace object's CreateObject method as "safe for scripting." You need to ensure they are marked as such in the License area of the system registry before they can be used in DCOM.
To manually mark your business object as safe for scripting, create a text file with a .reg extension that contains the following text shown in capitals. The following two numbers enable the safe-for-scripting feature:
[HKEY_CLASSES_ROOT\CLSID\<MyActiveXGUID>\Implemented Categories\{7DD95801-9882-11CF-9FA9-00AA006C42C4}]
[HKEY_CLASSES_ROOT\CLSID\<MyActiveXGUID>\Implemented Categories\{7DD95802-9882-11CF-9FA9-00AA006C42C4}]
where <MyActiveXGUID> is the hexadecimal GUID number of your business object. Save it and merge it into your registry by using the Registry Editor or double-clicking directly the .reg file in the Windows Explorer.
Business objects created in Visual Basic® 5.0 can be automatically marked as "safe for scripting" with the Application Setup Wizard.
To mark business objects safe for scripting in Visual Basic 5.0:
"RegisterServer=yes" and the [AddSafeToScript] section.See Also The ActiveX SDK Web page at http://www.microsoft.com/intdev/sdk/ contains more information about this standard and how to implement it. The safe-for-scripting information is under the Signing/Marking Controls topic (signmark.htm).
Password Authentication
RDS 1.1 can communicate with an IIS Web server running in any one of the three Password Authentication modes: Anonymous, Basic, or NT Challenge/Response. These settings define how a Web server controls access through it, such as requiring that a client computer have explicit access privileges on the NT Web server.
Custom business objects need to ensure that the client side can map their program name (ProgId) to an identifier (CLSID) that can be used over DCOM. For this reason, the ProgID of the DCOM object must be in the client side registry and map to the class ID of the server-side business object. For the other supported protocols (HTTP, HTTPS, and in-process), this isn't necessary.
For example, if you expose a server-side business object called MyBObj with a specific class ID, for instance, "{00112233-4455-6677-8899-00AABBCCDDEE}", you should make sure the following entries are added to the client-side registry:
[HKEY_CLASSES_ROOT]
\MyBObj
\Clsid
(Default) "{00112233-4455-6677-8899-00AABBCCDDEE}"
When a client-side component invokes a server-side component, there are a number of ways that you can use to send the request. These include:
When the client-side component and the server-side component reside on different computers (that is, you will use the HTTP, HTTPS, or DCOM protocol), a client-side proxy must be created for each server-side business object stub to ensure proper marshaling. How the proxy is created depends on which protocol you are using.
If you use the HTTP or HTTPS protocol, client-side components can't access remote server-side components directly. Therefore, Remote Data Service provides a proxy creation method (CreateObject) on the client side. A business object proxy is created for every server-side business object invoked from the client side. This RDS mechanism takes care of packaging and receiving remote application parts. This means that you don't have to write a lot of code to use custom business objects over HTTP or HTTPS.
Business object proxies are Automation objects and can be called from within Visual Basic® and Visual C++® applications, or any application that enables ActiveXÖ technology. No type checking is done on the client side, instead RDS assumes that each method supports a variable number of variant arguments. An instance of the business object is created on the server-side only when the first method call is made, so no round trip is made just to instantiate the object.
When you use HTTP, the business object proxy packages and unpackages the parameters it sends and receives in MIME format. Each argument is packaged into a separate MIME subpart. The proxy can handle all Automation data types and ADODB.Recordset and ADOR.Recordset objects. The proxy translates the method invocation into HTTP Post format, which it passes to the Advanced Data ISAPI DLL (ADISAPI) on the Web server.
You can also implement Remote Data Service applications on an intranet without using HTTP. If the client-side and server-side components are on different computers, you can use DCOM to marshal the interfaces and method arguments across the network. When you do this, the business object proxies and ADISAPI components are replaced, respectively, by COM proxies and stubs.
If your client-side and server-side components reside on the same computer, they can access each other directly. There is no need for a proxy-stub mechanism.
To improve the speed with which you open Recordset objects and establish connections, use:
If you're using an ODBC data source, you can use the Connection Pooling option in Internet Information Server (IIS) 3.0 to achieve high performance handling of client load. Connection Pooling is a resource manager for connections, maintaining the open state on frequently used connections.
To enable Connection Pooling, refer to the Internet Information Server documentation.
Please note that enabling Connection Pooling may subject the Web server to other restrictions, as noted in the Microsoft Internet Information Server documentation.
Microsoft SQL Server ù Performance and Stability with Connection Pooling
To ensure connection pooling is stable and provides additional performance gains, you must configureMicrosoft SQL Server to use the TCP/IP Socket network library.
To do this, you need to:
Configuring the SQL Server Computer to Use TCP/IP Sockets
On the SQL Server computer, run the SQL Server Setup program so that interactions with the data source use the TCP/IP Socket network library.
To specify the TCP/IP Socket network library on the SQL Server computer
Configuring the Web Server to Use TCP/IP Sockets
There are two options for configuring the Web server to use TCP/IP Sockets. What you do depends on whether:
û or û
If all SQL Servers are accessed from the Web server, you need to run the SQL Server Client Configuration Utility on the Web server computer. The following steps change the default network library for all SQL Server connections made from this IIS Web server to use the TCP/IP Sockets network library.
To configure the Web server (all SQL Servers)
If a specific SQL Server is accessed from a Web server, you need to run the SQL Server Client Configuration Utility on the Web server computer. To change the network library for a specific SQL Server connection, on the Web server computer, configure the SQL Server Client software as follows.
To configure the Web server (a specific SQL Server)
In a three-tiered environment, clients can share database connections if you use Microsoft Transaction Server on the middle tier. You can use the RDSServer.DataFactory object or create an ActiveX component DLL that can set up ODBC connections for clients to share; the sharing mechanism comes into play when you run the RDSServer.DataFactory or custom business object in the Transaction Server run-time environment. Instead of using thousands of database connections, you could get away with hundreds, still supporting thousands of clients. This is a feature of the ODBC resource dispenser in Microsoft Transaction Server.
See Also For more information about using Transaction Server, see "Running Business Objects in Transaction Server" or visit the Transaction Server Web site (http://www.microsoft.com/transaction/).
Business objects can be executable files (.exe) or dynamic-link libraries (.dll). The configuration you use to run the business object depends on whether the object is a .dll or .exe file:
By running the RDSServer.DataFactory object or your custom business object in the MTS run-time environment, you can also boost your performance and scalability by using the MTS resource dispenser. Because these business objects call ADO, which indirectly calls ODBC, you can take advantage of the MTS ODBC resource dispenser.
Resource dispensers automatically pool and recycle resources. Therefore, when RDSServer.DataFactory or your custom business object releases a database connection, the connection is returned to a pool. When a method is called to create a connection again, it requests the same database connection. Instead of creating a new connection, the ODBC resource dispenser recycles the pooled connection, which saves time and server resources.
Note When business objects on the middle tier are implemented as Microsoft Transaction Server components (using GetObjectContext, SetComplete, and SetAbort), they can use Transaction Server context objects to maintain their state across multiple client calls. This scenario is possible with DCOM, which is typically implemented between trusted clients and servers (an intranet). In this case, the RDSIE3.DataSpace object and CreateObject method on the client side are replaced by the transaction context object and CreateInstance method (provided by the ITransactionContext interface), implemented by Microsoft Transaction Server.
The following steps outline how to enable a business object DLL to use both DCOM and Internet Information Server (HTTP) via Microsoft Transaction Server.
You will use the Transaction Server Explorer to create a package and add the DLL into this package. This makes the DLL accessible through DCOM, but it removes the accessibility through IIS. (If you check in the registry for the DLL, the Inproc key is now empty; setting the Activation attribute, explained later in this topic, adds a value in the Inproc key.)
-or-
Import the RDSServer.DataFactory object into the package.
To make the DLL accessible through DCOM and IIS on the same computer you must set the component's Activation attribute in the Microsoft Transaction Server Explorer. After you set the attribute to In the creator's process, you will notice that an Inproc server key in the registry has been added that points to a Microsoft Transaction Server surrogate DLL.
See Also For more information about Transaction Server and how to perform these steps, visit the Transaction Server Web site at http://www.microsoft.com/transaction/ or refer to theMicrosoft Transaction Server documentation.