Designing Applications for Microsoft BackOffice

This whitepaper provides a brief technical overview of how to design applications which integrate in a client/server environment with the Microsoft BackOffice family of server applications. These guidelines have been carefully selected to ensure that the application you develop takes advantage of the great features provide by the Microsoft BackOffice server suite. Some of these guidelines are not required by your application in order to obtain the Designed for Microsoft BackOffice logo. However it is recommended that you seriously consider utilizing such features as in the future it is possible that the recommended features become requirements. These optional features are indicated via a *. Pointers to additional information such as the Microsoft Developer Network (MSDN), the BackOffice Software Development Kit (SDK) and the Win32® SDK are also provided so that you may quickly find in-depth information on each of these topics.

Common Application Considerations

Before even delving into creating your client/server application one needs to consider the important basics for any application regardless of where the application resides or which end, client or server, the application is targeted for. By utilizing these techniques an application is able to take maximum advantage of the operating system platform it is designed to run on. These techniques don't apply to just client or server based applications but to all applications in general. They have been provided to simply your job of creating an application and enabling your applications to take advantage of some of the powerful features provided. Chances are good that you will use some or all of these techniques in both your client and server based applications. Just like your application will have a core purpose, these techniques provide you with the basic functionality for which you can use the techniques mentioned allow your applications to become more scaleable, manageable and more robust. This is something which is required by all applications in distributed computing environments today.

Being Network Independent

Programming on top of an independent network transport allows the application to focus on the business application detail at hand without having to deal with the complexities of network data transfer. A client application can be designed to take advantage of standard, transport-independent interproccess communications interfaces. This helps ensure that the client and server application programs will be able to run on a wide variety of network platforms with little or no modification.

The Windows NT® operating system currently supports numerous sets of networking APIs that provide this transport independence: the Windows® Sockets interface, remote procedure call (RPC), named pipes and the Distributed Component Object Model (DCOM).

A named pipe is a one-way or two-way pipe for communicating between a server process and one or more client processes. Named pipes are implemented as a file system hence manipulation of named pipes occurs just as with reading and writing to file handles. As part of the file system they share common functionality, such as caching, with the other file systems. Additionally, processes on the local computer can use named pipes to communicate with one another without going through networking components. Remote access to named pipes as with all of the file systems, is provided through the network redirector. Working with named pipes is just like working with file I/O. You can use the same file I/O APIs and simply pass in named pipe handles. Named pipes also support impersonation, which allows a server to change its security identifier so that it matches the client's. Named pipes also give you the ability to perform asynchronous execution known as overlapped I/O. Overlapped operations make it possible for one pipe to read and write data simultaneously and for a single thread to perform simultaneous I/O operations on multiple pipe handles. This enables a single-threaded server process to handle communications with multiple client processes efficiently. Server processes can create named pipes by simply calling CreateNamedPipe while clients can connect to named pipes by using CreateFile or CallNamedPipe. Pipes can then by manipulated by using the usual Read, Write or ReadEx, WriteEx calls or PeekNamedPipe and TransactNamedPipe.

The Windows Sockets API defines a network programming interface for the Microsoft® Windows-based operating system on the "socket" paradigm popularized in the Berkeley Software Distribution (BSD) from the University of California at Berkeley. It encompasses both familiar Berkeley socket style routines and a set of Windows-specific extensions designed to allow the programmer to take advantage of the message-driven nature of Windows. Windows Sockets is intended to provide a single API to which application developers can program and multiple network software vendors can conform. Furthermore, in the context of a particular version of Microsoft Windows, it defines a binary interface such that an application written using the Windows Sockets API can work with a conformant protocol implementation from any network software vendor. This specification thus defines the library calls and associated semantics to which an application developer can program and which a network software vendor can implement. Windows Sockets provides functions which allow you to exchange data from a client to a server. Servers can register services within a name space. Functions are also provided to query the different protocols supported within the system as available services in the name space. The service registration and resolution functionality helps you write client server applications. Using this functionality, a service can register its existence with a name space (registration), and a client can find a service within a name space (resolution).

Microsoft® Remote Procedure Call (RPC) for the C and C++ programming languages is designed to help meet the needs of developers working on the next generation of software for the MS-DOS®, Microsoft Windows®, and Microsoft Windows NT™ family of operating systems.

Microsoft Remote Procedure Call (RPC) represents the convergence of three powerful programming models: the familiar model of developing C applications by writing procedures and libraries; the model that uses powerful computers as network servers to perform specific tasks for their clients; and the client-server model, in which the client usually manages the user interface while the server handles data storage, queries, and manipulation. When you write a client-server application, you must provide the layer of code that manages network communication. The advantage of using Microsoft RPC is that the RPC tools provide this layer for you. RPC nearly eliminates the need to write network-specific code, making it easier to develop distributed applications. Using the remote procedure call model, RPC tools manage many of the details relating to network protocols and communication. This allows you to focus on the details of the application rather than the details of the network. Microsoft RPC is an evolution of the procedural programming model familiar to all developers. Microsoft RPC allows a process running in one address space to make a procedure call that will be executed in another address space. The call looks like a standard local procedure call but is actually made to a stub that interacts with the run-time library and performs all the steps necessary to execute the call in the remote address space. As a tool for creating distributed applications, Microsoft RPC provides the following benefits:

The following items need to be performed when developing a client application to use RPC:

The following items need to be performed when developing a server application to use RPC:

For more information regarding Remote Procedure Call see the Win32 SDK/RPC.

The Component Object Model (COM) is designed to allow clients to communicate transparently with objects, regardless of where those objects are running - the same process, the same machine, or a different machine. This provides a single programming model for all types of objects, both object clients and object servers. From a client's point of view, all objects are accessed through interface pointers. COM does not specify how components are structured; it specifies how they interact. COM leaves the concern about the internal structure of a component to programming languages and development environments. Conversely, programming environments have no set standards for working with objects outside of the immediate application. C++, for example, works extremely well to manipulate objects inside an application, but has no support for working with objects outside the application. Generally, all other programming languages are the same in this regard. Therefore COM, through language-independent interfaces, picks up where programming languages leave off to provide the network-wide interoperability. Today COM provides the components needed to perform cross process communication within the same machine. Beginning with the Windows NT Operating System 4.0 there now exists the opportunity to create not just cross process components but also cross machine components, this is known as distributed COM (DCOM). DCOM naturally extends the programming model and constructs introduced by OLE 2.0 to work across the network, including:

Distributed COM further complements existing COM features with the security and scalability features required to build great distributed component software:

For more information on OLE/COM see the Win32 SDK OLE/OLE Programmer's Guide/Guide/The Component Object Model. For custom interfaces see the Win32 SDK OLE/OLE Programmer's Guide/Appendixes/OLE Custom Interfaces.

*Taking Advantage of the Windows 32-bit API

We believe that ensuring there is a client that executes on standard desktop operating systems is important. With the release of Windows NT and Windows 95 as 32-bit operating systems there now exists the potential to create powerful 32-bit based client applications. The Win32 API provides a unified API on the Windows NT and Windows 95 operating systems allows gives the advantage of having a single set of source code that can be used on multiple platforms (X86, MIPS®, Alpha, PowerPC™). By taking advantage of the Win32 API, a client application can utilize features of the Win32 API. Some features are detailed below:

  1. To add performance objects and counters for your application, follow the basic steps in the list below:
  2. Design the object types and counters for the application.
  3. Set up the necessary performance monitoring entries in the Registry. This includes the following steps:
    • a. Create a Performance key in the application's Services node in the Registry. If you don't have such a node you must create one. Create it under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.
    • b. Create an .INI file containing the names and descriptions of the counter objects and counters.
    • c. Create an .H file containing the relative offsets at which the counter objects and counters will be installed in the Registry.
    • d. Use the lodctr utility with the .INI and .H files to install the information in the Registry. Lodctr succeeds only if a Performance key exists in the application's Services node.
    • e. Add Library, Open, Collect, and Close value entries to the application's Services node in the Registry. These entries specify the name of the application's performance DLL, and the names of the DLLs required functions. The Open and Close entries are optional.
  4. To your application, add functions and data structures for collecting and storing performance data, and a mechanism for communicating the data to the performance DLL.
  5. Create a performance DLL containing a set of exported functions that provide the link between the application and a performance monitoring application (such as Windows NT Performance Monitor).
  6. Modify the application's OEMSETUP.INF file to automate the Registry setup described in step 4.
For more information see Developing International Software for Windows 95 and Windows NT by Nadine Kano.

For more information on these topics see the Win32 SDK System Services.

Being Installable Via Systems Management Server

The application must be installable via Systems Management Server and provide the appropriate PDF and MIF files, supporting user interface-less installation, and support an Uninstall option. Applications that support Systems Management Server are easier for customers to deploy, manage, upgrade, and inventory.

A software Setup or installation program with Systems Management Server must support these items:

Providing a Package Definition File

A PDF follows the standard initialization file format. It is an ASCII text file containing keys (the key names are enclosed within square brackets). Key names can be separated by spaces. Each key contains one or more entries, where each entry follows the format: name = value1, value2, ... Values are separated by a comma and at least one space. A PDF has specific keys and entries that are used by the system to set the properties of a package.

Unattended Setup

The program must not require input from the user during the installation, removal, or maintenance of the application. Any information or options required by the Setup program should be supplied by command-line switches to the program, or should be provided in a configuration file that is read by the program at run time. Because multiple packages can be installed by Systems Management Server at one time, no individual package installation should force a restart as part of its installation program. To copy system files that may be in use, Setup programs typically construct a batch file containing operations that must be performed during a restart.

Providing for Uninstall

The setup program should also include a provision to support the removal of the application owned components, clean up environment settings and registry entries. This is to facilitate software upgrades, retirement, recalls, etc.. The setup program ideally would provide a switch or option as part of the setup procedure supporting Uninstall.

Report Status Back to Systems Management Server by Using a Status MIF

To report the status of a PCM application installation, a MIF file must be created in the Windows directory. The MIF file should be named appname.MIF, where appname is the name of the application. In fact, the PCM will pick up any file in the Windows directory with an extension of .MIF (and which was created-timestamped-after PCM began the installation) and send it back to Systems Management Server.


For more information see the BackOffice SDK Systems Management Server.

Creating Server Based Applications

Back in the days of mainframe programming users logged into mainframe computers from non-intelligent client terminals. The client terminals essentially an extension of the mainframe computer. It was as if people were in the same location as the mainframe and logging directly into it. They were logging directly into it but from afar. From here they ran programs on powerful mainframe computers which hosted many users simultaneously. The environment has changed in the face of today with the introduction of more powerful client workstations, each with it's own cpu, memory, storage devices and capable of doing more work, faster. Servers computers have begun to replace mainframes and clients are now being authenticated by servers for priveleged access. Programs are still being run, but now they are being run on the client workstations themselves. These programs may be split into multiple tiers. One tier of the application may reside on the server while another may reside on the client. There may be even yet another tier residing on an intermediary computer. More than likely these application tiers communicate with each other through some form of inter-process communication over a variety of network protocols. Client portions of an application may exchange data with a server portion or it may intiate some work to be done by the server portion.

In a world today where there are numerous network protocols being used, such as TCP/IP or IPX/SPX, making it difficult for an application developer to create an application which not only focuses on the actual task at hand but to also focus on manipulating the underlying network protocol. As a solution to this there have been various programming models and APIs developed for applications to use without having to understand the underlying network protocol.

Being in a networked environment where mutliple clients communicate with multiple servers creates the risk of unauthorized users attempting to access server functionality.

Running as a Windows NT Operating System Server Service

Services can be configured to run automatically at system boot time without user intervention and can execute at a different security level than the user. Services also allow administrators to use remote administration tools providing remote application management. Applications that are designed to run as a service may be more robust, scalable and more suitable for large scale enterprise deployment.

In the Microsoft Win32 application programming interface (API), a service is an executable object that is installed in a registry database maintained by the service control manager. The services database includes information that determines whether each installed service is started on demand or is started automatically when the system starts. The database can also contain logon and security information for a service so that a service can run even though no user is logged on. It also enables system administrators to customize security requirements for each service and thereby control access to the service. No more than one instance of a service can be running at a time. A server application running as a Windows NT service can do so using a unique service account for remote administration and control. For example, if a database application and a host connectivity application are both running on the same Windows NT Server system, these applications can run as services under separate service accounts. This helps ensure that only designated host connectivity administrators can administer the host connectivity server application, and that only database administrators can administer database server applications. An additional benefit of this configuration is that it makes it possible for oan administrator to control a group of services that work under a common user account. Running as a Windows NT service helps a server application impersonate a client while accessing objects on behalf of the client. This capability ensures that the server application can act on behalf of a client without requiring the server application to run with an inappropriately high privilege level. It also ensures that the server application will not be able to perform actions that would be denied the client directly. Services can be configured to start automatically, either when the server running Windows NT Server itself starts, or when the service is started by a dependent service that starts automatically. In either case, the service starts without human intervention, that is, without a user being required to log on and then explicitly start the service. By starting automatically, a server application implemented as a service is guaranteed to be available whenever needed so long as the Windows NT Server operating system is running. Moreover, related services can be started easily and, where appropriate, automatically. Finally, implementing a server application as a service allows the application to be installed and controlled using standard user and Win32 API's programming interfaces. Such a service can be started and stopped both locally and remotely, providing network administrators an easy and consistent way to control the service across the network.

Creating a Windows NT Service involves the following items:

For more information about creating a Windows NT Service see the Win32 SDK System Services/Services

Support Windows NT Operating System Unified Logon

Unified logon allows the client to logon one time to the system and utilize the security system of Windows NT to authenticate the user for network and application resources. Client applications submit requests to server side components which execute privileged functions and access restricted objects. One objective of the Windows NT security model is to ensure that the programs that a user runs have no more access to objects than the user does. When a program or process runs on the user's behalf, it is said to be running in the security context of that user. The security context controls what access the subject has to objects or system services. In general, when a subject calls an object service through a protected subsystem, the subject's token is used within the service to determine who made the call and to decide whether the caller has sufficient access authority to perform the requested action.

Windows NT allows one process to take on the security attributes of another through a technique called impersonation. For example, a server process typically impersonates a client process to complete a task involving objects to which the server does not normally have access. Impersonation is useful in a distributed computing environment when servers must pass client requests to other server processes or to the operating system. In this case, a server impersonates the client's security context. Other server processes can then handle the request as if it had been made by the original client. For example, a client makes a request to Server A. If Server A must query Server B to complete the request, Server A impersonates client security context and makes the request to Server B on behalf of the client. Server B uses the original client's security context, rather than the security identity for Server A, to determine whether to complete the task.

Using named pipes a server process uses the ImpersonateNamedPipeClient function to assume the security token of the client process connected to the specified pipe instance. This function can be useful in determining whether to grant the request of a client process. For example, a named pipe server can provide access to a database or file system to which the server process has privileged access. When a client process makes a request from the server, the client typically has some lesser level of security access. By assuming the security token of the client, the server can attempt to access the protected database. The system then grants or denies the server's access, based on the security level of the client. When the server is finished, it uses the RevertToSelf function to restore its original security token.

Remote procedure calls require that the server call RpcImpersonateClient to overwrite the security for the server thread with the client security context. RpcRevertToSelf restores the security context defined for the server thread. When binding, the client can specify quality-of-service information about security that specifies how the server can impersonate the client. For example, one of the settings allows the client to specify that the server is not allowed to impersonate it.

Windows NT 3.51 introduces another set of APIs used for impersonation. The LogonUser function attempts to perform a user logon operation. You specify the user with a user name and domain, and authenticate the user with a clear-text password. If the function succeeds, you receive a handle to a token that represents the logged-on user. You can then use this token handle to impersonate the specified user, or to create a process running in the context of the specified user. Using this security token one may call the ImpersonateLoggedOnUser function, which lets the calling thread impersonate a user. Also using this security token one may call the CreateProcessAsUser function which creates a new process and its primary thread. The new process then executes a specified executable file. The CreateProcessAsUser function behaves just like the CreateProcess function, with one important difference: the created process runs in a context in which the system sees the user represented by the security token as if that user had logged on to the system and then called the CreateProcess function.

The process occurs as follows:

For more information see the Win32 SDK and query for "impersonation".

*Support OLE Automation

OLE Automation is a technology that lets software packages expose their unique features to scripting tools and other applications. OLE Automation uses the OLE Component Object Model (COM). Using OLE Automation, you can:

The objects an application or programming tool exposes are called OLE Automation objects. Applications and programming tools that access those objects are called OLE Automation controllers. Applications and other software packages define and expose objects, which can be acted upon by OLE Automation controllers. Type information describes the exposed objects, and can be used by OLE Automation controllers at either compile time or run time.

OLE Automation controllers can access objects in three ways:

use the IDispatch interface

for compatibility with existing OLE Automation controllers who access objects only through IDispatch.

use virtual function table (VTBL) binding

faster than both ID binding and late binding because access is direct; no calls are made through IDispatch.

use dual interfaces (combination of IDispatch and VTBL binding)

Binding can take place at compile time through the VTBL interface, or at run time through IDispatch.

OLE Automation controllers that can use the VTBL interface may benefit from improved performance.

Existing OLE Automation controllers that use the IDispatch interface will continue to work.

The VTBL interface is easier to call from C++.

Dual interfaces are required for compatibility with the Visual Basic® programming system object support features.


In order to expose objects within your application as OLE Automation objects you need to consider doing the following:

Use UUIDGEN (in the Win32 SDK) to generate class ids (CLSID) for your class and interface ids (IID) for your interfaces.

Initialize OLE, use CoInitialize

Register the class factories of your exposed objects, use CoRegisterClassObject

Register the active object, use RegisterActiveObject

Implement your exposed objects, implement IClassFactory, IUnknown, IDispatch, any other methods

Implement methods and properties

Revoke the class factories and your object, use RevokeActiveObject

Uninitialize OLE, use CoUninitialize

Create an object description (.ODL) file that describes the properties and methods of the exposed objects, and use MkTypLib to compile the .ODL file into a type library.

Create a registration (.REG) file for your application.

For more information on OLE Automation see the Win32 SDK/OLE/OLE Automation or the OLE Automation Programmer's Reference by Microsoft Press.

*Support Remote Administration

Supporting remote administration allows for single seat administration of multiple servers within an enterprise. Even though servers within an organization may be spread throughout the world it is possible to architect applications to administer remote services running on remote servers. In order to create server applications which can be administrated remotely you should consider the following:

Utilize the registry to store configuration parameters. This way you can use tools such as regedt32.exe from a remote location to configure a server.

Use event logging to audit actions, failures, errors, etc. This way you can use the Event Viewer from a remote machine to view the local machine's event log.

Create a separate UI client portion which communicates to a server portion via RPC.

Support delayed connections. When applications must communicate over a network take into consideration that the communication might occur over slow WAN links. For example, using Server Manager for Windows NT Server you can initiate Low Speed Connections so that the client application isn't bottlenecked by enumerating all the servers and workstations in a particular domain. An application may decide to offload time consuming functions to the server side and have a service perform these functions and return the data to the client. Also batched requests may be another consideration.

*Supporting Long Filenames and the Universal Naming Convention

Long Filenames

Windows NT and Windows 95 now offer the use of long filenames. These filenames go beyond the old restriction of 8.3 filename length.

To determine which file system your application is currently running under, an application makes a call to the GetVolumeInformation function. This function returns information about the current volume, such as the maximum length of filenames. Once you have called this function, you can use the value returned as the maximum file length within your application and dynamically allocate a buffer for your filenames and for paths. This is preferable to using static buffers for filenames and paths.

The following are general guidelines that apply to all file systems supported within the Windows operating system. An application that follows these guidelines can create valid names for files and directories regardless of the file system in use.

Universal Naming Convention

Supporting Universal Naming Convention (UNC) paths when dealing with file names is another way for an application to work seamlessly in a network environment. UNC paths allow logical connections to network devices without the need to specifically reference a network drive letter. The system will be able to locate the network server and path with the UNC name even over a modem connection. The Universal Naming Convention is a naming convention for describing network servers and share points on those servers. UNC names start with two backslashes followed by the server name. All other fields in the name are separated by a single backslash. A typical UNC name would appear as:

\\server\share\subdirectory\filename

Not all of the components of the UNC name need to be present with each command; only the share component is required. For example, dir \\server\share can be used to obtain a directory listing of the root of the specified share.

Integrating with Microsoft Exchange Server

Messaging Client-Server and Groupware Applications

Server applications extend the basic functionality of Microsoft Exchange Server. They can be used to provide a broad range of services, from mail gateways and voicemail to document management, content indexing, and electronic newspapers. Server applications communicate with Microsoft Exchange Server components through MAPI. This communication includes actions such as using the address book, accessing information stores (including public folders), and transferring messages. Functions are provided for communicating with Microsoft Exchange Server. Some of these functions extend MAPI functionality, some enhance debugging capabilities, and others add completely new functionality. Most server applications are either mailbox agents or gateways. As such, a server application is represented in the Microsoft Exchange Server directory as either a Mailbox-Agent or a Mailbox-Gateway object. One way the application can modify its own directory object, as well as the directory objects of recipients or other applications, is by integration with the Microsoft Exchange Server Administrator Program.

A server application that has its own mailbox within Microsoft Exchange Server is a mailbox agent. A typical mailbox agent uses its mailbox to communicate with mail users, gather processing requests, and distribute results. A server application can use mailboxes in three ways:

A gateway is an interface that connects electronic messaging systems that have different message and address formats. In its simplest form, it receives a mail message, translates it from one messaging system's format to another, maps addresses between the two systems, then delivers the translated message. The benefit to users is that messages transferred by the gateway appear to come directly from the originating mail system. A gateway can translate messages between mail systems within a single organization or between an organization and an outside mail system.

A Microsoft Exchange Server gateway is a client application of the Messaging Application Programming Interface (MAPI). This means that it uses MAPI interfaces, methods, and properties to communicate with Microsoft Exchange Server. A gateway is also a server application for Microsoft Exchange Server; as such, it should be implemented as a service of Microsoft Windows NT Server. A gateway should be integrated with:

Integrating with SQL Serverä

Use Open Data Services

Microsoft Open Data Services (ODS) provides a server-based application programming interface (API). The API consists of C functions and macros used for creating two types of server applications: applications that are initialized as Open Data Services servers and that support user connections and user queries, and applications called extended stored procedures that are added directly to SQL Server and accessed by making procedure calls to SQL Server. Applications created with Open Data Services can interact with SQL Server database clients, with SQL Server database servers, and with any other elements of a network environment that you define.

This interaction allows you to create powerful applications that can:

Integrating with the Internet Information Server

Using the Internet Server API (ISAPI)

ISAPI for Windows NT can be used to write applications that Web users can activate by filling out an HTML form or clicking a link in an HTML page on your Web server. The remote application can then take the user-supplied information and do almost anything with it that can be programmed, and then return the results in an HTML page or post the information in a database.

ISAPI can be used to create applications that run as DLLs on your Web server. If you have used Common Gateway Interface (CGI) scripts before, you will find that the ISAPI applications have much better performance because your applications are loaded into memory at server run-time. They require less overhead because each request does not start a separate process. A client uses ISAPI extensions just like executing CGI applications, but instead of than referencing them as "http://scripts/cgi.exe?Param1+Param2", a client would use "http://scripts/isapi.dll?Param1+Param2". Because ISAPI applications and filters are implemented as DLLs they are inherently single process and can support thread pooling whereby the Internet Information Server will call out to the extension DLL. DLLs are also require much less overhead for instantiation compared to a process. Also function calls are direct and involve no process transition or intermediate steps. Multiple extension DLLs can be loaded and called simultaneously. ISAPI extension DLLs are essentially "in-process" CGI applications.

Creating ISAPI extensions involve the following:

  1. Export and implement GetExtensionVersion. This provides the initial entry point from the IIS into your extension and is used to provide the version and description of your extension.
  2. Export and implement HttpExtensionProc. This is the main entry point into functionality for your extension. It is equivalent to main() in a CGI application. It is called once per request and called be called simultaneously from multiple threads. For this reason your extension DLL must be thread safe.
  3. Utilize the EXTENSION_CONTROL_BLOCK data structure. The ECB contains data about the client request as well as providing four callback functions which your extension can use. These callback functions are as follows: ReadClient is used to obtain data from the client's HTTP request.

    WriteClient is used to send data to the HTTP client from a buffer.

    GetServerVariable is used to obtain information about the client connection or the server itself.

    ServerSupportFunction provides some general purpose functions as well as HTTP Server specific functions. The basic functions include client URL redirection, sending another URLs data back, and sending back detailed header information.

ISAPI extensions can also be combined with the Internet Database Connector to create highly interactive sites.

Another feature of ISAPI allows pre-processing of requests and post-processing of responses, permitting site-specific handling of HyperText Transport Protocol (HTTP) requests and responses. ISAPI filters can be used for applications such as customized authentication, access, compression, encryption, logging or client request analysis.

Creating ISAPI filters involve the following:

  1. Export and implement GetFilterVersion. GetFilterVersion gets called with a HTTP_FILTER_VERSION structure which your filter must fill in with version information, events which your filter requests, and the priority level. ISAPI filters should register only required events since extraneous events can have a significant impact on the performance and scalability of the server. The priority level is used to assign a call order for you filter with respect to other filters for the same events.
  2. Export and implement HttpFilterProc. This represents the main entry point into the filter. Your filter will typically switch on the notification type. For notification specific functionality there are several other data structures which allow you to process raw data, pre-process headers, perform authentication, obtain URL maps and perform logging.
  3. Use the HTTP_FILTER_CONTEXT structure which contains context information associated with the HTTP request. Also contained in the HTTP_FILTER_CONTEXT structure are callback functions. These callback functions are as follows: GetServerVariable is used to obtain information about the client connection or the server itself.

    ServerSupportFunction provides some general purpose functions as well as HTTP Server specific functions. The basic functions include . . .

    AddResponseHeaders is used to supply extra header information in response to HTTP requests.

    WriteClient is used to send data to the HTTP client from a buffer.

    AllocMem is a function used to allocate memory upon request completion all memory allocated with this function is automatically freed.

Register the filter under HKEY_LOCAL_MACHINE\ System\ CurrentControlSet\ Services\ W3Svc\ Parameters\ Filter DLLs. This value is a comma-separated list and your filter should be added to the end of the list.

Creating Client Applications for Microsoft BackOffice

In order to develop client applications which communicate with a component in the Microsoft BackOffice suite you should take advantage of the rich set of functionality exposed by APIs specific to each component. If you are developing your own client/server components then you may choose to expose APIs that expose functionality in the same manner as the BackOffice components. Methods can range from using one of the interprocess communication methods mentioned above. The following sections describe the APIs associated with each Microsoft BackOffice component and the functionality which it provides.

SNA Client

Use WOSA APIs (WinAPPC, WinCPI-C, WinRUI, WinSLI) or use FMI

In order to provide one common set of APIs to port applications from various operating systems to Windows NT and Windows version 3.X, a Windows SNA specificationstandard was created. As a direct result of this work, the Windows APPC, Windows CPI-C and Windows LUA specificationsstandards were developed. All of the Windows SNA specificationsstandards have provided a set of extensions that allow for asynchronous communication. Asynchronous call completion returns the initial call immediately so the application can continue with other processes. A program that issues a call and does not regain control until the operation completes is not able to perform any other operations. This type of operation, referred to as blocking, is not suited to a server application designed to handle multiple requests from many clients.

Programs written to use Windows APPC can exchange data with programs written to use other implementations of APPC that adhere to the SNA LU 6.2 architecture. Windows APPC adds to this functionality by providing a set of extensions for asynchronous communication in addition to the full complement of APPC features.

Windows CPI-C is compliant with CPI-C version 1.2 which allows applications developed using the CPI-C Systems Application Architecture API to establish a conversation in order to exchange data and control information flow between two programs. Support for automatic parameter conversion, communicating with non-CPI-C program, local/remote transparency as well as X/Open CPI-C support for nonblocking calls, the ability to accept multiple conversations, support for data conversion (beyond parameters) and support for security parameters. Windows CPI-C further adds to this functionality by providing a set of extensions for asynchronous communication in addition to the full complement of supported features in CPI-C version 1.2 (with the exception of resource recovery).

The conventional Logical Unit Application programming interface (LUA) is an application programming interface (API) that allows you to write LUA applications to communicate with host applications. The Windows LUA interface is provided at the request/response unit (RU) and session levels, allowing programmable control over the Systems Network Architecture (SNA) messages sent between your communications software and the host. It can be used to communicate with any of the logical unit (LU) types 0, 1, 2, or 3 at the host; it is up to the application to send the appropriate SNA messages as required by the host. For example, you can use LUA to write a 3270 emulation program that communicates with a host 3270 application. By design, LUA is asynchronous and uses semaphores for notification messages. While semaphores work extremely well for the Windows NT and OS/2® operating systems, the Windows enhancements built into Windows LUA also allows for asynchronous support for Windows version 3.x applications in the LUA interface. Windows LUA provides the following entry-points for both RUI and SLI verbs: RUI, SLI, WinRUI, and WinSLI. WinRUI and WinSLI provide asynchronous message notification for all Windows-based RUI and SLI verbs while RUI and SLI provide support for event notification. Applications based on Windows version 3.X use WinRUI and WinSLI for asynchronous message notification.

APPC is an application programming interface (API) that allows peer-to-peer communications in a Systems Network Architecture (SNA) environment. By using APPC, programs distributed across a network can work together-communicating with each other and exchanging data-to accomplish a single processing task. A processing task can query a remote database, copy a remote file, send or receive electronic mail, and so on.

In order to provide one common API to port applications from various operating systems to Windows NT and Windows version 3.x, a Windows SNA standard was created. As a direct result of this work, Windows APPC was developed.

Programs written to use this implementation of APPC can exchange data with programs written to use other implementations of APPC that adhere to the SNA LU 6.2 architecture.

Asynchronous call completion returns the initial call immediately so the application can continue with other processes. A program that issues a call and does not regain control until the operation completes is not able to perform any other operations. This type of operation, referred to as blocking, is not suited to a server application designed to handle multiple requests from many clients.

SNA Server uses the RegisterWindowsMessage for asynchronous support. With "WinAsyncAPPC" as the input string, you pass a Windows handle by which you will be notified of verb completion. You then issue your verb, and once it completes, a message is posted to the Windows handle that you passed, notifying you that the verb is complete.

With the exception of asynchronous RECEIVE_AND_WAIT and RECEIVE_AND_POST, which can issue certain other verbs while pending, a conversation can have only one incomplete operation at any time.

CPI-C is a Systems Application Architecture (SAA) adherent application programming interface (API) that allows peer-to-peer communications among programs in a Systems Network Architecture (SNA) environment. (An API is a facility that provides information and services to programs.)

Through CPI-C, programs distributed across a network can work together - communicating with each other and exchanging data - to accomplish a single processing task, such as querying a remote database, copying a remote file, or sending or receiving electronic mail.

These programs communicate as peers, on an equal (rather than hierarchical) basis. Together, programs distributed across a local or wide area network perform distributed processing.

In order to provide one common API to port applications from various operating environments to Windows NT and Windows version 3.x, a Windows SNA standard was created. As a direct result of this work, Windows CPI-C was developed. The CPI-C calls and information presented in this guide represent an evolving Windows CPI-C that is composed of CPI-C version 1.2 and a set of Windows extensions that allow for multiple applications and asynchronous call completion.

CPI-C version 1.0 was first introduced to provide a means by which two applications could speak and listen to each other; in other words, to have a conversation. A conversation is the logical connection between two programs that allows the program to communicate with each other. Programs using CPI-C converse with each other by making program calls. These calls are used to establish the full characteristics of the conversation, to exchange data, and to control the information flow between the two programs.

CPI-C version 1.1 was extended to include four new areas of function: support for resource recovery (not supported in Windows CPI-C), automatic parameter conversion, support for communicating with non - CPI-C programs, and local/remote transparency. Built upon CPI-C version 1.1, X/Open CPI-C provided support for nonblocking calls, the ability to accept multiple conversations, support for data conversion (beyond parameters), and support for security parameters.

CPI-C version 1.2 consolidated CPI-C version 1.1 and X/Open CPI-C by providing function in all the areas described above. Windows CPI-C further adds to this functionality by providing a set of extensions for asynchronous communication in addition to the full complement of supported features in CPI-C version 1.2 (with the exception of resource recovery).

Asynchronous call completion returns the initial call immediately so the application can continue with other processes. A program that issues a call and does not regain control until the operation completes is not able to perform any other operations. This type of operation, referred to as blocking, is not suited to a server application designed to handle multiple requests from many clients. In particular, Windows CPI-C support related to asynchronous communications includes the following calls and extensions:

Set_Processing_Mode

Specify_Windows_Handle

Wait_For_Conversation

WinCPICSetBlockingHook

WinCPICIsBlocking

WinCPICUnhookBlockingHook

Asynchronous support is appended to the Set_Processing_Mode call and allows you to be notified of call completion on a Windows handle. Through RegisterWindowsMessage with "WinAsyncCPIC" as the string, you pass a Windows handle by which you are notified of call completion. You then make your call, and once it completes, a message is posted to the Windows handle that you passed, notifying you that the call is complete.

With the exception of an asynchronous Receive call that can issue certain other calls while pending, a conversation can have only one incomplete operation at any time. For more information on using an asynchronous Receive call, see "Using Asynchronous Call Completion" later in this chapter. In the case of an incomplete operation, the program can issue Wait_For_Conversation to test for its completion or Cancel_Conversation to end the conversation and the incomplete operation.

The only Windows extensions required for Windows CPI-C are for initialization (WinCPICStartup) and termination (WinCPICleanup) purposes. Depending on your application, other Windows extensions may be useful to you, but they are not required.

The conventional Logical Unit Application programming interface (LUA) is an application programming interface (API) that allows you to write LUA applications to communicate with host applications.

The interface is provided at the request/response unit (RU) and session levels, allowing programmable control over the Systems Network Architecture (SNA) messages sent between your communications software and the host. It can be used to communicate with any of the logical unit (LU) types 0, 1, 2, or 3 at the host; it is up to the application to send the appropriate SNA messages as required by the host.

For example, you can use LUA to write a 3270 emulation program that communicates with a host 3270 application.

In order to provide one common API to port applications from various operating environments to Windows NT and Windows version 3.x, a Windows SNA standard was created. As a direct result of this work, Windows LUA was developed. The LUA verbs (both Request Unit Interface [RUI] and Session Level Interface [SLI]), routines, and information presented in this guide represent an evolving Windows LUA that is based on IBM ES for OS/2 version 1.0 and includes a set of Windows enhancements.

Asynchronous verb completion returns the initial verb immediately so the application can continue with other processes. A program that issues a verb and does not regain control until the operation completes is not able to perform any other operations. This type of operation, referred to as blocking, is not suited to a server application designed to handle multiple requests from many clients.

By design, LUA is asynchronous and uses semaphores for notification messages. While semaphores work extremely well for the Windows NT and OS/2 systems, the Windows enhancements built into Windows LUA also allows for asynchronous support for Windows version 3.x applications in the LUA interface. Windows LUA provides the following entry-points for both RUI and SLI verbs: RUI, SLI, WinRUI, and WinSLI. WinRUI and WinSLI provide asynchronous message notification for all Windows-based RUI and SLI verbs while RUI and SLI provide support for event notification. Windows version 3.x applications use WinRUI and WinSLI for asynchronous message notification.

Asynchronous support allows you to be notified of verb completion on a Windows handle. Through RegisterWindowsMessage with "WinRUI" or "WinSLI" as the string, you pass a Windows handle by which you are notified of verb completion. You then make your call and once it completes, a message is posted to the Windows handle that you passed, notifying you that the verb is complete.

The only Windows extensions required for Windows LUA are for initialization (WinRUIStartup or WinSLIStartup) and termination (WinRUICleanup or WinSLICleanup) purposes. Depending on your application, other Windows extension may be useful to you, but they are not required.

The Function Management Interface provides applications with direct access to SNA data flows and information about SNA control flows by means of status messages, while shielding them from the full complexities of SNA protocol handling. It is particularly suited to the requirements of applications emulating 3270-type controllers. The FMI is defined in terms of the messages that are sent across the interface. Note that this is logically distinct from the definition of the DL-BASE/DMOD interface, which defines the mechanism for sending messages between two components in SNA Server (for example between the local node and the 3270 emulator). The FMI is used by LU types 0, 1, 2, and 3, but not by LU type 6.2. It provides access to the SSCP-LU session as well as the main PLU-SLU session (see section 3.1.1 below for more information on these sessions). An application can use the FMI to access multiple sessions, and hence multiple LUs, simultaneously. The 3270 emulator on the client communicates over the LAN with the local node on the server machine by exchanging messages. The content and format of the messages is defined by the FMI.

For detailed information about each API set see the BackOffice SDK SNA book.

Use SNA Server client APIs (support SNA Server user record)

Vendors who want to create applications which integrate a 3270 emulator with SNA Server should utilize the 3270 Emulator Interfaces Specification. This specification defines the initialization, message passing and termination procedures required for 3270 emulator and SNA Server communication.

See the BackOffice SDK Microsoft SNA Server/3270 Interface Emulator Specification for more information.

Use SNA Server compatibility APIs for IBMâ PC Support or Client Access/400

SNA Server 2.11 adds support for the EHNAPPC application programming interface (API) which is the Windows-based APPC API supported by IBM's PC Support and Client Access/400 (CA/400) products. IBM has presented EHNAPPC API to its independent software vendor (ISV) community as the way to write Windows-based applications that integrate with the AS/400®. There are estimated to be more than 60 applications that utilize this API as a way to connect to the AS/400® data and applications. These ISV applications will work unchanged with SNA Server 2.11.

For additional information about the EHNAPPC API, see "IBM AS/400, Client Access/400 for Windows 3.1, API and Technical Reference, Version 3" (SC413531-00).

Use ODBC/DRDA Drivers to access Host Data

Many applications use the Open Database Connectivity (ODBC) programming interface to access local and server-based databases, while distributed databases on IBM hosts are usually managed through the Distributed Relational Database Architecture (DRDA) protocol defined by IBM.

SNA Server version 2.11 includes the StarSQL ODBC/DRDA drivers for Windows-based and Windows NT-based clients. With these drivers, applications designed to use the ODBC interface and Structured Query Language (SQL) can access databases located on IBM hosts that use the DRDA protocol to manage distributed data, without requiring a host-based database gateway. These drivers allow ODBC-enabled applications (such as Microsoft® Excel and Microsoft® Access) to query, create, delete, and update tables in the following host databases:

Use AFTP for File Transfer

The APPC File Transfer Protocol (AFTP) application programming interface (API) is a set of C routines that provides APPC file transfer capabilities. This API makes file transfer programming easier by allowing you to access routines that will interact with any AFTP server.

APIs are provided for creating or destroying an AFTP connection object, establishing a connection to the AFTP server, querying connection characteristics, transferring files, specifying file transfer characteristics, querying file transfer characteristics, listing files on the AFTP server, listing files on the AFTP client, performing directory manipulation, performing file manipulation, querying system information, generating message strings, and controlling trace information.

Messaging Client

Use MAPI for send and post OR use OLE/Messaging and/or OLE/Scheduling

The Messaging Application Programming Interface (MAPI) is a messaging architecture that enables multiple applications to interact with multiple messaging systems seamlessly across a variety of hardware platforms. The interfaces are used to create and access diverse messaging applications and messaging systems, offering a uniform yet separate environment for development and use and providing true independence for both. MAPI client applications are divided into three categories:

Messaging-aware applications

A messaging-aware application does not require the services of a messaging system, but includes messaging options as an additional feature. For example, a word processing application can add a "Send" command to its File menu, enabling the user to send a document to another user.

Messaging-enabled applications

A messaging-enabled application requires the services of a messaging system and typically runs on a network or an on-line service. An example of a messaging-enabled application is Microsoft Mail.

Messaging-based workgroup applications

A more advanced client application is the messaging-based workgroup, or workflow, application. The workgroup application requires full access to a wide range of messaging system services, including storage, addressing, and transport services. These applications are designed to operate over a network without users having to manage the applications' network interaction. Examples of such applications include work flow automation programs and bulletin board services.


MAPI supports each of these types of client applications by providing in its subsystem different levels of programming interfaces. This multi-level programming interface is described in the following section.

Most client applications will use one client API - either OLE Messaging, Simple MAPI, CMC or Extended MAPI. However, some clients will want to take advantage of what more than one client API has to offer. These clients will want to use Extended MAPI for some tasks and a simpler API for others. The MAPI architecture allows client applications to do this fairly easily by providing several API functions for converting between the environments.

For instance to send a message you need to consider doing the following:

Posting messages and documents to folders (as opposed to sending messages) is a common action performed by client applications. For example, a client application may post information to a public folder so that its associated server application can read the information. To post information, the application uses standard MAPI techniques and follows this sequence shown below.

To post information to a folder

For information pertaining to MAPI see the Win32 SDK Win32 Extensions/Messaging Application Programming Interface (MAPI). For information regarding integration with Microsoft Exchange Server see the BackOffice SDK Microsoft Exchange Server.

The Microsoft OLE Messaging Library exposes messaging objects for use by tools supporting OLE automation, such as those applications created in the Microsoft Visual Basic® programming system and the Microsoft Visual C++® development system applications. The messaging library lets you quickly and easily add to your Visual Basic application the ability to send and receive mail messages and to interact with folders and address books. You can create programmable messaging objects, then use their properties and methods to meet the needs of your application. When you combine messaging objects with other programmable objects exposed by Microsoft Access, Microsoft Excel, and Microsoft Word, you can build custom applications that, for example, would allow your users to extract information from a database, copy it to a spreadsheet for analysis, then create a report and mail the report to several people. With these powerful building blocks, you can quickly build custom applications that cover your entire line-of-business needs. The Microsoft OLE Messaging Library does not represent a new messaging model but rather an additional interface to the Microsoft Messaging API (MAPI) model.

For more information about OLE Messaging see the Win32 SDK under \mstools\samples\mapi\olemsg\olemsg.hlp.

OLE Scheduling defines programmable objects that can be used to extend the capabilities of Schedule+. OLE Scheduling is based on the capabilities of OLE Automation. OLE Automation enables you to create instances of programmable scheduling objects. Once you've created the new objects, you can reference them with tools that support OLE Automation, such as Microsoft Visual Basic and Microsoft Visual C++.

For additional information regarding OLE Scheduling see the BackOffice SDK Microsoft Exchange Server/Microsoft Schedule+ Programmer's Guide.

Public Folders

For most purposes, applications access public folders the same way they access private folders in private mailboxes - through MAPI. Subject to access restrictions, an application can browse the folders and items in the public store, read items, delete items, modify items, search for items, and create new public folders in the public folder hierarchy. All this is done using MAPI interfaces.

Public folders are distinguished by several unique characteristics. Users can send messages to them because they are addressable objects. They include a property that allows administrators or programmers to control access to their contents. They have an additional property that specifies one or more rules that execute when certain message events occur. Furthermore, each public folder in the information store has a corresponding object in the Microsoft Exchange Server directory.

To develop applications for public folders, you will use one or more of the following interfaces:

For more information about programming with folders using MAPI, see the MAPI Programmer's Guide and the MAPI Programmer's Reference. For more information about the Microsoft Exchange Server directory access functions, see Directory Operations.

Using Custom Forms for Applications

Custom forms are an important part of many applications that run in the Microsoft Exchange Server environment. When you develop forms-based applications for Microsoft Exchange Server, you'll use the MAPI forms interfaces. These interfaces give you the ability to define custom forms, install them in forms registries, and supply them to Microsoft Exchange Server users.

Any MAPI-compliant forms application can run in the Microsoft Exchange Server environment. However, two considerations must be kept in mind when developing forms-based applications in a Microsoft Exchange Server environment:

In MAPI, a forms registry is any storage area where you can install and access forms definitions. Microsoft Exchange Server builds upon and extends the MAPI forms model. It provides a special forms registry called the organization forms registry that can be used as a master forms repository for the entire organization. The main advantage of the organization forms registry is that it can be accessed from anywhere in the organization (subject to access rights). The organization forms registry resides in the public store as a hidden folder and is replicated throughout the organization to facilitate access to forms.

*Extending the Microsoft Exchange Client

The basic Microsoft Exchange Client is included in the Windows 95 operating system as the core mail client in the system. When drivers are loaded that set up the Windows 95 client to communicate with a Microsoft Exchange Server system, functionality specific to Microsoft Exchange Server clients is added to the Microsoft Exchange Client by making use of the client's extensibility interfaces.

Using client extensions to expose application-specific functionality is usually appropriate when one or more of the following conditions is satisfied:

SQL Server Client

Use ODBC, DB-Libraryä, or Embedded SQLä

Developers can write applications for SQL Server by programming with DB-Library for C, the C-language version of the communication library for SQL Server or with DB-Library for Visual Basic, the Visual Basic version of the communication library for SQL Server. DB-Library for C is an application programming interface (API) that consists of C functions and macros that allow an application to interact with SQL Server. Included are functions that send Transact-SQL® statements to SQL Server and functions that process the results of those statements. Other functions handle errors and convert data.

DB-Library for C offers a rich set of functions for:

Information about DB-Library can be found in the BackOffice SDK, Microsoft SQL Server Programmer's Toolkit.

These functions allow the application developer extremely fine-grained control of data flow back and forth between the client and the server. DB-Library supports multiple environments. C programmers can choose from among:

A multithreaded dynamic-link library (DLL) for the Windows NT operating system

Medium and large model static-link libraries for MS-DOS for both Microsoft and Borland® compilers

A DLL for the Windows operating system

In addition to DB-Library, SQL Server supports the Microsoft Open Database Connectivity (ODBC) call-level API. ODBC enables applications for Windows, Windows NT, and Windows 95 to access multiple data sources, including a wide range of relational databases and local indexed sequential access method (ISAM) data. In most cases, DB-Library and ODBC are equally capable of creating SQL Server client applications. ODBC enables applications to access more data sources. DB-Library provides equivalent functionality in multiple client environments, including the MS-DOS® operating system. In addition, DB-Library provides specialized support for SQL Server, such as bulk copy, two-phase commit, and text operations.

Information about ODBC can be found on MSDN Product Documentation/SDKs/Open Database Connectivity (ODBC) SDK 2.10.

Embedded SQL allows programmers to place SQL statements into programs written in a standard programming language, which is termed the host language. SQL statements are delimited with specific starting and ending statements defined by the host language. The resulting program contains source code from two languages — SQL and the host language. When compiling a program with embedded SQL statements, a precompiler translates the SQL statements into equivalent host language source code. After precompiling, the host language compiler compiles the resulting source code. The Embedded SQL approach, using programming statements similar to Transact-SQL, is more concise than the function-call approach and is tightly coupled to the existing database structure. Because the SQL statements are directly included in the source code, Embedded SQL programs are usually special-purpose applications. Embedded SQL is well suited for environments where the programmer is also in control of the database structure. However, it is less flexible for environments where the database structure is changing or is not known in advance.

For more information about Embedded SQL see MSDN Product Documentation/SDKs/Embedded SQL for C 4.22.

Use Stored Procedures, Triggers and Cursors

Stored Procedures

You can refine your applications by using stored procedures, compiled collections of SQL statements and control-of-flow language that execute very quickly. For example, you can use stored procedures called triggers to define business processes. Stored procedures greatly enhance the power, efficiency, and flexibility of SQL Server, and dramatically improve the performance of SQL statements and batches.

Stored procedures can:

Stored procedures on other SQL Servers to which the client process is not directly connected to can be executed if the remote server has been set up to allow remote logins. You can write triggers on your local SQL Server that execute procedures on a remote server whenever certain events (inserts, updates, or deletes) occur locally. Stored procedures differ from ordinary SQL statements and from batches of SQL statements in that they are pre-parsed and pre-normalized. The first time you run a procedure, the SQL Server query processor analyzes it and prepares internal, normalized structure for the procedure that is stored in a system table. The first time the procedure is run when the SQL Server is started, the procedure is then brought into memory and fully compiled (but it does not need to be re-parsed or "sequenced" since this was done when the procedure was created). The fully compiled plan then stays in memory (unless other memory needs force it out so that the next request for execution (whether by the same or a different client) can be processed without any plan compilation overhead.

Stored procedures return a status value that indicates that they completed successfully or states the reasons for failure. Stored procedures can also return information to the caller through return parameters. Remote procedure calls (stored procedures run on a remote SQL Server) also return both types of information. You can create stored procedures using the CREATE PROCEDURE statement.

Triggers

A trigger is a special kind of stored procedure that goes into effect when you modify data in a specified table. Triggers are often created to enforce business rule consistency among logically related data in different tables.

An advantage of triggers is that they are automatic - they work no matter what caused the data modification - a clerk's entry or an application action. Each trigger is specific to one or more of the data modification operations UPDATE, INSERT, or DELETE. The trigger is executed once per SQL statement; it "fires" immediately after the data modification statements are completed. The trigger and the statement that fires it are treated as a single transaction that can be rolled back from within the trigger. If a severe error is detected, the entire transaction automatically rolls back.

Triggers are useful in these ways:

Unlike CHECK constraints, triggers can reference columns in other tables. For example, a trigger can roll back updates that attempt to increase a book's price by more than 1 percent of its advance, might be checked with a SELECT to another table.

You can create a trigger using the CREATE TRIGGER statement.

Cursors

Server cursors allow individual row operations to be performed on a given results set or on the entire set. In SQL Server 6.0, ANSI SQL cursors are server based. In earlier releases, cursors were provided only through the DB-Library and Open Database Connectivity (ODBC) cursor APIs.

The addition of cursors to the server provides an efficient way for single-row operations to occur within a given results set. ANSI SQL cursors support only single-row cursors. Each fetch will return only one row from the results set. Server cursors enhance the general use of relational databases by allowing row-level operations when set-oriented operations are impractical. In relational systems, set operations are preferred; cursors provide a powerful complement to set operations. Using cursors, multiple operations can be performed row by row against a results set with or without returning to the original table. In other words, cursors conceptually return a results set based on tables within the database(s). For example, a cursor can be generated to include a list of all user-defined table names within a database. After the cursor has been opened, movement (fetching) through the results set can include multiple operations against each table by passing each table name as a variable. Cursors are extremely powerful when combined with stored procedures and the EXECUTE statement (to dynamically build strings).

SQL Server provides two interfaces for cursor functions. When using cursors in Transact-SQL batches or stored procedures, ANSI-standard SQL syntax has been added for declaring, opening, and fetching from cursors as well as positioned updates and deletes. When using cursors from a DB-Library or ODBC program, the SQL Server 6.0 client libraries transparently call built-in server functions to handle cursors more efficiently.

Use SQL Distributed Management Objects for Administration

SQL Distributed Management Objects (SQL-DMO) are 32-bit Component Object Model (COM) objects for the Microsoft Windows 95 and Windows NT operating systems. The SQL-DMO objects are OLE Automation Compatible. The SQL-DMO object model includes objects, properties, methods, and collections that are used to write programs that can administer multiple SQL Server-based servers distributed across a network. SQL-DMO programs can range from simple Visual Basic scripts to complex C++ applications. SQL-DMO is the foundation of SQL Enterprise Manager. Using SQL-DMO you can access objects such as SQL Server devices, logins, language, remote servers, configuration, and security. As well you can manage application environment such as backup and permissions, databases, indexes, tables, stored procedures and triggers.

Use Integrated Security

Integrated security integrates SQL Server login security with Windows NT security. This allows a network user to log in to a SQL Server without supplying a separate login ID or password. Users can maintain one login ID and password for both Windows NT and SQL Server.

Integrated security lets SQL Server applications take advantage of Windows NT security features, including encrypted passwords, password aging, domain-wide user accounts, and Windows-based user administration. (For more information about these features, see your documentation for Windows NT.)

SQL Server achieves login security integration with Windows NT by using the Windows NT security attributes of a network user to control login access to SQL Server. A user's network security attributes are established at network login time and are validated by Windows NT through a sophisticated password encryption mechanism. When a network user tries to connect to SQL Server, SQL Server uses Windows NT - based facilities to determine with certainty the validated network username of the client. SQL Server then permits or denies login access based on that network username alone, without requiring a separate login name and password to be sent in the client connection request.

Login security integration operates over network protocols that support authenticated connections between clients and servers. Such connections are referred to as trusted connections.

Trusted connections include multi-protocol and named pipes sessions from other Windows NT - based workstations, from Windows for Workgroups - based clients, from Windows 95-based clients, and from Microsoft LAN Manager clients running under the Microsoft Windows or MS-DOS operating system. Using the multi-protocol Net-Library, trusted connections can also be made over the NWLink IPX/SPX protocol from Windows 3.1 clients using Novell® software. (In this case, the user will be prompted for a Windows NT username and password at SQL Server connect time.) Other network protocols do not support authenticated connections, so clients on these protocols must be handled according to SQL Server standard security.

When a user of integrated security logs in to SQL Server over a trusted connection, the user is mapped to a SQL Server login ID, to a default SQL Server login ID (usually called guest), or if the user has administrative privileges to SA.

Once the login process is complete, all other SQL Server security checks are handled as usual. Access to individual SQL Server tables, for example, is managed through the permissions granted within a SQL Server database.

If multiple SQL Server computers participate in a domain managed by a machine running Windows NT Server, a single network login for each user is sufficient to enable access for all of the SQL Server-based servers. For users defined on other domains, SQL Server provides map characters to map the domain name and username to a SQL Server login ID (for example, salesdomain_Chris). These map characters also provide a way to map Windows NT usernames that are not valid SQL Server login IDs to valid SQL Server login IDs.

The recommended way to implement SQL Server security integration is to create two or more locally defined Windows NT groups and then provide the users of those groups with access to SQL Server. The two recommended Windows NT groups are:

A SQLUsers group, to be assigned user privileges

A SQLAdmins group, to be assigned system administrator privileges. (Note that when SQL Server is set up with integrated security, the Administrators group on the local computer is automatically mapped to the sa login ID. This can be disabled if you prefer.)

You can use the DBSETLSECURE command to request a secure, or trusted connection to SQL Server. SQL Server will then use integrated login security to establish connections made via dbopen. Any login ID or password supplied by DBSETLUSER, or DBSETLPWD is ignored. With ODBC you can use the SqlSetConnection API and the SQL_INTEGRATED_SECURITY option to have SQL Server use integrated security.

Systems Management Server Client

Access Systems Management Server Database using Systems Management Server APIs or ODBC

In an Systems Management Server system, a primary site's site database stores the inventory and configuration information for itself and the sites below it in the site hierarchy. Using the Systems Management Server API, your application can access this information. The Systems Management Server API enables your application to retrieve, add, and remove data in the Systems Management Server database. Using the Systems Management Server API, you can access the Sites, Inventoried Objects, Packages, Jobs, Queries, Machine Groups and Site Groups following objects in an Systems Management Server database.: The Systems Management Server API represents all Systems Management Server objects in terms of containers, folders, and scalars. This paradigm provides a standard interface to all types of objects. You can use the Systems Management Server API to view the existing packages and jobs within an Systems Management Server database as well as to create new packages and jobs.

For more information about the Systems Management Server APIs the BackOffice SDK Systems Management Server/Microsoft Systems Management Server API.

The inventory and configuration information is stored in multiple tables in order to store the data efficiently. However, this efficient design can make it difficult to view the computer inventory directly from other applications. The inventory for each computer is stored in the MachineDataTable. However, the specific inventory data (such as group names, attribute names, and the values for groups and attributes) is stored in other tables. The MachineDataTable has keyed pointers to these other tables. The Systems Management ServerVIEW program creates views that resolve these keyed pointers so that you can view the computer inventory easily with other applications. With the Systems Management ServerVIEW program, you can create database views on a site database. Using the Microsoft Desktop ODBC Database Driver, you can use these views in other applications (such as Microsoft Word for Windows) to view the computer inventory and generate reports.

Systems Management ServerVIEW is provided with the Microsoft Systems Management Server product.

For more information about Systems Management ServerVIEW see the BackOffice SDK Systems Management Server/Systems Management ServerVIEW Samples.

Extend data in the database by providing a MIF file

To add or maintain items in an Systems Management Server database, the Systems Management Server system uses data in the Management Information Format (MIF). For example, computer inventory, events, package locations, job status, and user groups are all reported to the Systems Management Server database as MIF files. Using the ASCII text files with the MIF format, you can also add, update, or delete custom objects and groups from the Systems Management Server database. You can add objects with new architectures (for example, printers or hardware routers) or add new types of objects of existing architectures (for example, a new computer to the Personal Computer architecture). In general, the Systems Management Server system can use any MIF file that complies with version 4.5 of the Desktop Management Interface (DMI) specification. However, Systems Management Server treats some aspects of the MIF syntax in a way that is unique to Systems Management Server. The full DMI 4.5 syntax is accepted by the Systems Management Server MIF parser; however, some fields are not used.

For more information see the BackOffice SDK Systems Management Server/Extending the Inventory.

Internet Information Server Clients

Support HTTP keep alive

Support NT challenge response

The information contained in this document represents the current view of Microsoft Corporation on the issues discusssed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the data of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

© 1996 Microsoft Corporation. All rights reserved.

Microsoft, Win32, Windows, Visual Basic, Visual C++, Windows NT and MS-DOS are registered trademarks and BackOffice, the BackOffice logo are trademarks of the Microsoft Corporation.

IBM, AS/400, OS/2 and OS/400 are registered trademarks and SQL/DS and PowerPC are trademarks of International Business Machines Corporation. MIPS is a registered trademark of MIPS Technologies, Inc. Novell is a registered trademark of Novell, Inc. Transact-SQl is a registered trademark and DB-Library and Embedded SQL are trademarks of Sybase, Inc. Unicode is a registered trademark of Unicode, Inc.