The Basics of Configured Components
Exposing system services through configurable attributes is very different from exposing system services through a set of functions in a traditional API. In the older API-based model, you must write code to tell the system what services you want and how you want to use them. When you want to modify the manner in which an application uses a system service, you must modify code and recompile and redistribute the application. Moreover, Visual Basic programmers are often at a disadvantage because their language makes it impossible or impractical to call upon several system services exposed by the C-based Win32 API. The new way in which COM+ and declarative attributes expose system services is more flexible and makes your work easier.
Working with declarative attributes offers two primary benefits. First, you don't have to write as much code. You indicate your requirements by configuring attributes at design time and letting COM+ do the work for you at runtime. The second benefit is that you can configure attributes after an application has been put into production. You don't have to modify any code or recompile your application when you want to change the way you use a system service. This is really convenient when you make hardware changes to your application's physical deployment and you need to change a database connection string or tune a middle-tier application to take advantage of a more powerful computer.
COM+ Applications
In COM+, every configured component needs a home. The programming model defines an abstraction known as a COM+ application. Each COM+ application defines a set of configurable attributes that tells the system such things as where to activate objects and how to set up security. Every component that carries declarative attributes must belong to exactly one COM+ application. You can think of a COM+ application as a set of one or more configured components set up to run on a specific computer. In addition to its own attributes, a configured component also inherits a set of attributes from its hosting application. As you'll see later, COM+ also tracks configured attributes for interfaces and methods.
MOVING FROM MTS
What's in a Name?
MTS uses the term package in the same way that COM+ uses the term application.
In Chapter 3, I talked about the confusion surrounding the term component. Some people use the term to refer to a concrete class, while others use it to refer to a physical server file such as an ActiveX DLL. Still others go as far as to use component interchangeably with object. Because the term component has several possible meanings, you often must read between the lines to interpret how it's being used. In this book, I use the term to refer to a concrete class identified by a specific CLSID. More specifically, in terms of COM+ development using Visual Basic, a component is a MultiUse class compiled into an ActiveX DLL. This view is consistent with COM+ because each COM+ application contains a Components collection, which holds a set of concrete classes. However, you still have to stay on your toes. The COM+ documentation in MSDN often uses the term component to describe a physical server file as opposed to a concrete class. So much for consistency.
The COM+ registration database (RegDB)
When you create a new COM+ application, the system creates a new profile for it in a system catalog called the COM+ registration database (RegDB). This catalog holds attribute settings for applications, components, interfaces, and methods. The details of storing and accessing data in RegDB are abstracted away behind a system-supplied component called the Catalog Manager, as shown in Figure 6-1. The Catalog Manager generates a new GUID (known as an Application ID or AppID) to identify each application.
There are two common ways to create and administer a COM+ application. You can do it manually by using a built-in utility called the Component Services administrative tool. You can also do it programmatically by writing administrative scripts or full-blown Visual Basic applications against a set of system-supplied components known as the Component Services Administration (COMAdmin) Library. Both administrative techniques leverage the Catalog Manager to do their work.
Figure 6-1 The COM+ Catalog Manager handles reading and writing configuration information to RegDB and the Windows Registry.
A component is considered a configured component once it's been added to a COM+ application. As you saw in Chapter 3, earlier versions of COM relied on Registry keys to hold configuration information about type libraries, CLSIDs, ProgIDs, and IIDs. COM+ relies on these same Registry keys in addition to other attribute settings stored in RegDB. For various reasons, the COM+ team decided to avoid changing the traditional way that COM configuration information is stored. They also decided that keeping duplicate settings in RegDB was a bad idea. This means that configured components have configuration information both inside and outside RegDB.
MOVING FROM MTS
Configured Components and MTS
The term configured component wasn't really formalized until the emergence of COM+. However, you should think of a component that's installed in an MTS package as a configured component. It's really the same thing. MTS components are like COM+ components in that they have declarative attributes.
The concept of a standard catalog manager is very valuable. Component registration is easier and more foolproof because administrators and developers are never responsible for writing to or reading from the Registry or RegDB. You don't have to be concerned about how registration data is physically stored in RegDB. Moreover, the Catalog Manager is a COM+ component that supports remote activation. An administrator can easily create a COM+ application and configure components on remote machines using scripts or the Component Services administrative tool. This means that COM+ provides a built-in scheme for network management.
This is important because an administrator can configure many production servers from a single desktop computer. It's also fairly easy to move a component from one computer to another when an application requires changes to its physical deployment. This is often the case when a company adds additional computers to an application to achieve higher levels of throughput, fault tolerance, or security. In the early days of COM, configuring servers was much tougher because it typically required visiting each computer involved.
Configured vs. nonconfigured components
In addition to configured components, you'll also encounter an older type of component that doesn't have COM+ attributes—the nonconfigured component. Nonconfigured components are not installed in COM+ applications. Instead, they're registered in a manner consistent with earlier versions of COM. For example, you should register an in-process DLL containing nonconfigured components by using REGSVR32.EXE. Note that nonconfigured components can't take advantage of COM+ services. They can, however, run in environments other than MTS and COM+.
If you're authoring component code for an application based on COM+, you'll generally produce configured components. This approach allows you to take advantage of various platform services. When you write your code, you're also likely to encounter nonconfigured components. For instance, ADO is a library made up of nonconfigured components. ADO objects can run in an application based on COM+, but they can also run in applications based on earlier versions of COM.
You should note that Visual Basic knows almost nothing about COM+ administration. When you build an ActiveX DLL, the Visual Basic IDE builds in traditional self-registration code and calls REGSVR32.EXE. In other words, after you build an ActiveX DLL on a Windows 2000 computer, your MultiUse classes are set up as nonconfigured components. You must explicitly add your classes to a COM+ application to turn them into configured components.
Creating and Deploying Configured Components
One of the main reasons that so many companies use Visual Basic to write middleware is that it's easy to create components for a COM+ application. All you need to do is create a simple ActiveX DLL with one or more MultiUse classes. You add a few public methods, implement them, and build the DLL. It's that easy.
Before we get started, I'd like to throw out a few recommendations for creating configured components:
- Be careful when using the New operator.
- Don't change the DLL's threading model to single-threaded.
- Don't use public variables in .BAS modules.
- Don't hold database connections open across method calls.
Now you know what not to do, but it'll take a little longer for me to tell you why. I'll attempt to explain the reasoning behind these recommendations over the next few chapters.
The easiest way to create a new COM+ application and add the components from a DLL is to use the Component Services administrative tool, which is shown in Figure 6-2. If you're not familiar with this tool, look at the platform SDK documentation in MSDN and search for Creating and Configuring COM+ Applications. This section walks you through the steps of COM+ administration. It can also get you started writing administrative scripts and applications with the COMAdmin Library.
Figure 6-2 You should learn how to create COM+ applications and configure components with the Component Services administrative tool.
Also note that the COM+ Administration Reference in the platform SDK documentation briefly explains each configurable attribute. The topic titled Applications Collection lists each application attribute. The topic titled Components Collection lists each component attribute. I recommend that you take some time to become familiar with these resources.
When you create a new COM+ application with the Component Services administrative tool, a wizard asks you to set the application's identity property. In a production application, this property should be assigned a special user account dedicated to running middle-tier objects. However, while you're writing and testing your components, the default setting of Interactive User is the easiest and most common choice.
When you add a component to a COM+ application, it gets a new set of attributes. Each attribute is given a default value at creation time. You should review the component attributes list in MSDN to see what all the default values are. In certain cases, they won't be what you're looking for and you'll have to do a little extra work to set things up properly.
You can't predefine any of these configurable attributes (with the exception of transaction support) from within the Visual Basic IDE. You must add your components to a COM+ application and then configure them at deployment time. You can make these adjustments programmatically or by hand using the Component Services administrative tool. Future versions of Microsoft development tools and COM+ are likely to allow you to configure component attributes at design time, but they aren't quite that elegant yet.
In addition to properly configuring your component and application attributes, you must also write code that interacts with the COM+ runtime. To do this, you must reference the COM+ Services Type Library in your ActiveX DLL projects, as shown in Figure 6-3. This type library is crammed full of definitions for the components, interfaces, UDTs, and enumerations that are defined by COM+.
Figure 6-3 The COM+ Services Type Library contains several interface and enumeration definitions that you'll use when you interact with the COM+ runtime.
In most cases, the DLLs you create for the middle tier will contain configured components because configured components can take advantage of COM+ services. However, configured components also carry a dependency on the COM+ runtime. When a component is written against the COM+ Services Type Library and relies on configured attributes, it can't be run in other environments.
In some less common scenarios, you might want to create components that don't have a dependency on the COM+ runtime. This might be the case, for example, if you have a component that calculates sales tax or validates user input and you want to use the component on desktop computers running Windows 95 in addition to using it in a COM+ application. If you avoid dependencies on COM+ attributes and the COM+ Services Type Library, you can run your classes as either configured components or nonconfigured components. Just realize that nonconfigured components can't take advantage of most COM+ services.
You might be wondering: Is it me, or is all this computer theory getting a bit fuzzy? Let's look at an example of creating a component that makes use of a few configurable attribute settings. This example will show you how to put all this theory to work.
Using an object constructor string
Each configured component has a configurable object constructor string. You can use the constructor string for any purpose, but in this example I'll use it to hold an OLE-DB database connection string. The two important configurable attributes in this example are ConstructionEnabled and ConstructorString. Note that you can configure these two attributes in the Component Services administrative tool on the Activation tab of the component's Properties dialog box.
When the SCM creates an object from a configured component that has been assigned a declarative constructor string, the COM+ runtime calls into the object and provides an opportunity to load the string value from RegDB.
Let's walk through the details of how the COM+ runtime interacts with the new object. During object creation, the SCM looks to see whether the component's ConstructionEnabled attribute is turned on. If it is, the SCM performs a QueryInterface on the new object to obtain a reference to an interface named IObjectConstruct. As long as your component implements this interface, the COM+ runtime calls the Construct method and passes a reference to a constructor object. Examine the following code:
Implements COMSVCSLib.IObjectConstruct Private MyConnectionString As String Private Sub IObjectConstruct_Construct(ByVal pCtorObj As Object) Dim cs As IObjectConstructString Set cs = pCtorObj MyConnectionString = cs.ConstructString End Sub |
As you can see, this custom implementation of the Construct method loads the object constructor string into a module-level variable named MyConnectionString. Note that the reference passed by the pCtorObj parameter is cast to the IObjectConstructString interface. This interface exposes a single property, ConstructString, which makes it possible to obtain the configured value from RegDB and store it in a module-level variable. After the object has been created, the constructor string is available to any other method implementation in the class.
The most valuable aspect of using a constructor string is that the actual string value doesn't get compiled into the DLL. The administrator can easily reconfigure the connection string using the Component Services administrative tool. If the database's connection information changes, you don't have to modify any code. This example demonstrates how COM+ lets you do more work declaratively, which lessens the need for programming and recompiling. This example also shows you how to implement an interface that's defined in the COM+ Services Type Library.
Library Applications vs. Server Applications
Chapter 3 discussed how the SCM activates objects from an in-process server such as an ActiveX DLL. However, earlier versions of the SCM are unaware of the extended attributes made available by COM+. The COM+ team rewrote the SCM for Windows 2000 to examine the activation setting behind a configured component's application. This activation setting tells the SCM where and how to activate objects.
Every COM+ application must be configured as either a library application or a server application. The distinction between these two activation settings is quite simple. Take a look at Figure 6-4. Objects created from library application components are activated and run in the process of their creator. Objects created from server application components are activated in their own surrogate process. Furthermore, clients can activate objects from local server applications as well as from remote server applications running across the network. The ability to deploy a component in any one of these deployment scenarios without modifications or recompilation is known as location transparency.
Figure 6-4 COM+ provides location transparency. Components can be reconfigured to run in-process, locally, or across the network without requiring changes to code or recompilation.
Out-of-Process Activation
Each server application runs in a separate instance of the surrogate container application DLLHOST.EXE. When a client creates an object from a component in a server application, the SCM locates the appropriate instance of DLLHOST.EXE. If the server application process isn't already running, the SCM launches it before creating the object. This scheme allows COM+ to start applications on an on-demand basis.
MOVING FROM MTS
The Name of the Container Application Has Changed
In MTS, the surrogate container application is MTX.EXE instead of DLLHOST.EXE.
MOVING FROM MTS
You Don't Need the Refresh Components Command Anymore
In both COM and COM+, the CLSID key for a component in an ActiveX DLL must have an InProcServer32 subkey pointing to the server's path. When you build a Visual Basic ActiveX DLL, the compiler automatically builds in self-registration code. Once the DLL has been built, it is registered with the utility REGSVR32.EXE.
The SCM uses information in the CLSID key when it needs to create an object. However, the SCM in Windows NT 4 doesn't know how to properly create an MTS object using configured attributes. MTS requires CLSIDs to be configured differently from the way COM and COM+ do. The MTS team had to devise a way to steal activation requests from the SCM.
When you add a component to an MTS package, the Catalog Manager changes entries under the CLSID key to redirect activation requests to the MTS runtime. A component in an MTS library package requires an InProcServer32 key pointing to MTXEX.DLL. A component in an MTS server package requires a LocalServer32 key pointing to the container application MTX.EXE.
This gets pretty confusing. With Windows NT 4, you can register a CLSID in three different ways: the original COM way and two MTS ways. To make matters worse, the self-registration code built into a Visual Basic DLL knows only the COM way to register a CLSID. If you call REGSVR32.EXE on a Visual Basic DLL after it's been installed in an MTS package, the CLSID entries get messed up.
Many programmers have gotten into trouble when building and testing DLLs on an MTS machine because Visual Basic always calls REGSVR32.EXE at the successful completion of every build. There's nothing you can do to suppress this behavior in the Visual Basic IDE. Things don't work correctly when you try to test an MTS component that's been reconfigured as a standard COM component.
To solve the problem, MTS offers a Refresh Components command. When you run this command on an MTS package, the MTS Catalog Manager simply looks through the Registry and makes sure that each CLSID is configured in the proper MTS way instead of the COM way. There's also a Visual Basic add-on that automatically calls upon the MTS Catalog Manager to refresh MTS components whenever the associated ActiveX DLL server is rebuilt.
In COM+, the CLSIDs from an ActiveX DLL are always registered in a manner consistent with the original version of COM. There's always an InProcServer32 key that holds the path to your DLL. This is true for both configured and nonconfigured components. Configured components differ from nonconfigured components only in that they have additional information about their attributes and activation requirements in RegDB. The good news in COM+ is that you don't have to worry about using the Refresh Components command, as you did in MTS.
Once the SCM locates the process of the target server application, it forwards the request for the new object. However, as you'll remember from Chapter 3, the code that actually creates objects lives in the class factories in your DLLs. When a server application is launched, the COM+ runtime loads all its associated DLLs in order to register each class factory. Once the class factory for the requested CLSID has been loaded, the server application can successfully create the object.
The server application uses a class factory to create the object, and it returns an object reference to the SCM. The reference is then forwarded to the client. After a successful out-of-process activation, the client is really holding on to a proxy that wraps an RPC-based connection to the object.
By default, the process for a server application remains loaded in memory for three minutes after the last object has been released. However, you can configure this time interval on the Advanced tab of a server application's Properties dialog box in the Component Services administrative tool. (You can also configure a server application to run indefinitely or to shut down immediately after the last object has been released.)
In addition to letting you control when a process is shut down, COM+ also supports prelaunching a server application. Prelaunching an application provides an optimization because the first client doesn't have to wait while the server process is launched. As with most other administrative chores, you can prelaunch a server application manually or programmatically.
Remote Activation
Activating an object in a remote server application is more complex than in-process or local activation because it requires the participation and coordination of the SCM on two different computers. When the client-side SCM determines that a client wants to activate an object from a component that lives at a different network address, it forwards the activation request to the SCM on the server computer. The server-side SCM is responsible for creating the requested object and returning a reference.
When the server-side SCM receives an activation request from a client across the network, it performs a standard out-of-process activation from the server application that holds the requested CLSID. After all, from the perspective of the server computer, the activation is performed locally. Once the object has been created, a reference is passed from the server application to the server-side SCM, then to the client-side SCM, and finally back to the client. As with a local out-of-process activation, the client is connected to the object across a proxy/stub pair.
Note that client computers don't have to be running Windows 2000. They require only a version of Windows that has Distributed COM (DCOM). Computers running Windows NT 4 and Windows 98 are already DCOM-compliant. If you want to run client applications on computers running Windows 95, you must install the required DCOM software by downloading the appropriate installation files from Microsoft's Web site (www.microsoft.com/com/resources/downloads.asp).
As you learned in Chapter 3, software created with Visual Basic relies on the universal marshaler to build proxies and stubs. The universal marshaler must create a proxy on the client computer by inspecting the appropriate interface definition in a type library. This means that a copy of the type library must be copied to and registered on every client computer. A client computer must also have information about IIDs, CLSIDs, and ProgIDs.
You can configure any client-side computer running a DCOM-enabled version of Windows to redirect activation to a remote computer on a CLSID-by-CLSID basis. The SCM redirects an activation request when it determines that a CLSID has an associated AppID with a valid network address.
You'll probably never be required to add these client-side Registry entries by hand, but here's how you'd do it. First, add an AppID key with a RemoteServerName named value, as shown in Figure 6-5. Second, set the RemoteServerName value to an IP address, a Domain Name System (DNS) address, or a NETBIOS name. Finally, add an AppID named value to the Registry key for each CLSID to associate it with the remote server name. When everything is set up correctly, the client-side SCM redirects every activation request for any of the CLSIDs to the remote server computer. That is how things worked with DCOM prior to Windows 2000. Windows 2000 stores the AppID in the same way (in the Registry), but it stores CLSID and ProgID information in RegDB instead of in the Registry.
Figure 6-5 A CLSID configured for remote activation must have an AppID with a valid RemoteServerName value. The CLSID should not have an InProcServer subkey or a LocalServer32 subkey.
If you configure a CLSID for remote activation using an AppID, it's important that the CLSID key not have an InProcServer32 or a LocalServer32 subkey. The client-side SCM redirects activation to a remote computer only if both the InProcServer32 and LocalServer32 values are absent. Some programmers and users have gotten in trouble by registering the DLL on the client machine and unknowingly adding the InProcServer32 subkey. In this case, the SCM performs a local in-process activation instead of calling across the network to create the object.
You should keep one more thing in mind about remote activation. You don't have to rely on the RemoteServerName value for selecting a target server. Instead, you can select the address of a remote computer programmatically using Visual Basic's CreateObject function. Visual Basic 6 added a second optional parameter to CreateObject that accepts the name of a remote server. This parameter always overrides the RemoteServerName value in the Registry. As in the case of the RemoteServerName value, the parameter can be an IP address, a DNS address, or a NETBIOS name.
Application Proxies
A few paragraphs back, I said that you'll probably never have to add client-side configuration information by hand because COM+ allows you to create a client-side setup program that automatically copies type libraries and writes all the required configuration information. This client-side setup program is known as an application proxy.
You can build an application proxy by running the Export command from the Component Services administrative tool. When you choose the Export command to create an application proxy, COM+ generates an .MSI file (a Windows Installer file). Note that the setup program runs differently on Windows 2000 computers than it does on computers running other DCOM-enabled version of Windows. On Windows 2000 computers, it writes entries for the CLSID and ProgID to RegDB and it writes type library and IID entries to the Registry. RegDB doesn't exist on earlier versions of Windows, so the setup program adds all entries to the Registry.
You'll notice a new application in the COM+ Applications folder in the Component Services administrative tool after an application proxy has been installed on a Windows 2000 computer. Every Windows 2000 computer has an Applications collection that contains application proxies in addition to server applications and library applications. The difference is that an application proxy holds the CLSIDs for a set of components that live on another machine.
You should note several more important issues concerning application proxies. First, you can explicitly set the remote server name that gets built into the application proxy. If you don't explicitly set this value, COM+ simply uses the computer on which the application proxy is built. If you want the application proxy to point to a different computer, you should change the remote server name using the Component Services administrative tool before building the application proxy. You can adjust the remote server name value on the Options tab of the My Computer Properties dialog box.
A second issue is that your client computers might require an updated version of the Windows Installer in order to install an application proxy. Windows NT, Windows 98, and Windows 95 all require updated versions. If you receive an error while installing an application proxy, you can find the required update in the Platform SDK for Windows 2000. Once you install the most recent version of the Windows Installer, the application proxy should be installed without any problems.
The third issue is that you should be sure that all the relevant type libraries have been added to the server application before the application proxy is built. Be sure to add components to a server application using the Install command rather than the Import command. The Install command adds the type libraries embedded in your ActiveX DLLs, while the Import command doesn't. If you've built any custom type libraries using IDL and the MIDL compiler, you should also add them to the server application before building the application proxy. This can be a bit tricky the first time you do it because the Component Services administrative tool only allows you to install a .TLB file in a server application at the same time that you install components from a DLL.
The fourth and final issue has to do with a bug that prevents you from building application proxies in certain situations. The client computers need type libraries but they don't need the DLLs that hold your configured components. When you select the Remote Server Files option in an ActiveX DLL project, the Visual Basic IDE builds a stand-alone .TLB file in addition to the type library that it builds into the DLL. You can add a stand-alone TLB file to a server application when you add the components from the DLL. The motivation for doing this is to prevent the application proxy from copying the entire DLL to each client computer.
However, there's a problem. If you add the .TLB file to a server application in addition to the DLL, COM+ can't build the application proxy because of an incompatibility between COM+ and Visual Basic-generated type libraries. This bug can be frustrating because things work correctly under MTS but they don't under COM+. I have no information about when this bug will be addressed.
What are the implications of this bug? If you rely on application proxies to set up client-side computers, you must copy all your DLLs to the client computers. This can present a security hole if your DLL contains sensitive passwords. A user could bypass your security scheme by installing the DLL in a local server application and executing a method.
One workaround is to move all your passwords out of your compiled DLLs and into declarative constructor strings. A second workaround is to avoid using COM+ application proxies when you configure client computers. Instead, you can copy type libraries and write all the required configuration information to client computers using another technique. Visual Basic provides an alternative technique for setting up client computers using .VBR files and the CLIREG32.EXE utility.
Distributed Garbage Collection
What happens if a client application crashes while holding an outstanding reference to an object in a remote server application? The object must have a way to determine that its client application has expired. You saw in Chapter 4 that a client can discover when an object has died by inspecting HRESULTs. However, an object needs a little more assistance to determine whether the client has passed away.
COM provides an infrastructure for distributed garbage collection that allows the server-side computer to determine when a client with an outstanding object reference has died. When the server-side computer discovers that a client has died, it informs the object by calling Release. This means that a remote object is automatically released from memory if its client crashes. The need for garbage collection is extremely important in distributed applications that are meant to stay running for long periods of time.
COM's mechanism for distributed garbage collection is based on the client machine pinging the server machine with a notification that says, "I'm still alive." The client pings the server every two minutes. If the server doesn't hear from the client for six minutes (three missed pings), the server informs the object that the client has died.
The ping algorithm has been optimized to avoid excessive network traffic. Pings aren't sent for individual interface references or for individual objects. Instead, the client computer transmits a single machinewide ping to the server with information about every connection between the two machines. Note that each ping doesn't transmit all the information about every outstanding interface reference. Instead, it transmits the information about what has changed since the last ping. This "delta" algorithm significantly reduces what needs to be transmitted across the network.
Partitioning a Distributed Application
You should notice that each server application is associated with exactly one process per computer. Objects created from components in the same server application run in the same process and can therefore share process-specific resources. Objects created from different server applications run in separate processes and can't share process-specific resources.
So, how do you decide between using server applications and library applications? And if you decide to use server applications, how many should you create? Should you add five components to the same server application or add each component to its own server application? You can choose from several approaches, each of which comes with trade-offs in performance, fault tolerance, and security.
The main advantage to using a library application is that it provides better performance because it eliminates or decreases the need for cross-process calls. However, library applications do not support remote activation. The client application must be running on the local computer in order to activate an object from a library application.
Each server application adds another process and therefore another level of fault tolerance. You can think of each server application as its own fault-isolation domain. An object that crashes can take down all the objects in the same server application. However, a crash in one process doesn't necessarily affect objects running in other processes.
To provide an additional level of fault tolerance, each COM+ process has a failfast policy. If the COM+ runtime detects that something unusually bad has happened when it's running a method implementation, it assumes that the entire process has become corrupt. This triggers COM+ to terminate the entire process. The failfast policy is also triggered whenever a component raises a Win32 error or a C++ exception. However, you can't trigger the failfast policy by raising a Visual Basic error with Err.Raise. Visual Basic errors (which, as you know, are really COM exceptions) propagate to the caller without any problem. Note that COM+ writes an error message to the Windows event log whenever it terminates a process with the failfast policy.
While you can add all your components to a single server application, you also have the option of spreading out your components across several server applications. The trade-off is that calls across process boundaries take significantly longer than in-process calls. If you decide to use multiple server applications spread out across multiple computers, it's possible to distribute the processing load across more processors. The obvious trade-off to this approach is that calls across computer boundaries are even more expensive than local cross-process calls.
So, when would you want to use a library application? Two scenarios are common. In the first scenario, you have a utility component that you want to share between two or more server applications. If you add the utility component to a library application, an object running in any server application can create an in-process object from the utility component. You can thus share a component across several server applications while eliminating expensive cross-process calls.
In the second scenario, you use a library application to create objects in a hosting application other than DLLHOST.EXE. For example, let's say you're deploying a component for use in a Web application and the client is an ASP page running in the IIS Web server process INETINFO.EXE. If you configure the component in a library application, your objects will be created in the Web server process instead of in an instance of DLLHOST.EXE, as shown in Figure 6-6. You'll experience better performance because you eliminated the need for cross-process calls. However, fault tolerance won't be as good as it could be. Your component can potentially crash the entire Web server process.
Figure 6-6 In a Web application based on ASP pages, library applications generally offer better performance because they eliminate the need for cross-process calls. Server applications provide better fault tolerance as well as the ability to run components on a separate computer.
EAN: 2147483647
Pages: 70