Investigate the Component Object Model?

COMPATIBILITY: VISUAL BASIC 4, 5, 6

The Component Object Model (COM) is a general architecture for component software. This means that it is a standard, not an implementation. COM says this is how you should allow components to intercommunicate, but someone else (ActiveX) has to do it. ActiveX accomplishes the physical implementation of COM. Originally, ActiveX was called OLE (Object Linking and Embedding). ActiveX not only includes the OLE implementation of COM but also improves on the OLE implementation by extending capabilities to take advantage of the Internet. This is done in the form of ActiveX controls, as well as support for DCOM (Distributed Component Object Model), discussed in the “Distributed Component Object Model (DCOM)” section of this How-To.

Why is this important? So far, the discussion of client/server has shown the need for a design model that allows encapsulation of critical business logic away from the mire of database design and front-end code. An example of logic used to support the business could be a rule that prohibits orders for amounts of more than $500 to be placed without a manager’s approval. This business rule can now be implemented with code in a component that is centralized on its own server, which makes it easier to modify if necessary. If the rule changes to also allow supervisors to approve orders of more than $500, the change can be made much more easily and quickly to a centralized component of code rather than by redeploying a new executable to every desktop.

So the answer suggested here is to partition the business logic out of the front-end and back-end applications and into its own set of components. The question is, how are these components supposed to talk to each other? How are you going to install these components on a network where your client applications can use them as if they were running locally on their computers? OLE and the Component Object Model are the answer.

In creating the COM, Microsoft sought to solve these specific problems:

•Interoperability. How can developers create unique components that work seamlessly with other components regardless of who creates them?

•Versioning. When a component is being used by other components or applications, how can you alter or upgrade the component without affecting all the components and applications that use it?

•Language independence. How can components written in different languages still work together?

•Transparent cross-process interoperability. How can developers write components to run in-process or out-of-process (and eventually cross-network), using one simple programming model?

If you are using Visual Basic today, then you have no doubt experienced the benefits of COM. All the third-party controls, as well as Visual Basic itself, take advantage of standards set by COM and implemented through what are referred to as ActiveX technologies. What this means to you is that objects based on the Component Object Model—objects you can write in Visual Basic, C++, or some other language—have the capability to work together regardless of the language used to create them. Because all these components know how to work together, you can purchase components from others or build them yourself and reuse them at any time during the business-system life cycle.

In-Process and Out-of-Process Servers

A component, also referred to as a server, is either in-process, which means that its code executes in the same process space as the client application (this is a DLL), or out-of-process, which means that it runs in another process on the same machine or in another process on a remote machine (this is an .EXE file). From these scenarios you can see that three types of servers can be created: in-process, local, and remote. Both local and remote servers must be out-of-process.

As you create components you will need to choose the type of server, based on the requirements of implementation and deployment. Components can be of any size—from those that encapsulate a few functions to larger, very robust implementations of a company’s way of doing business. The powerful aspect of these component objects is that they look the same to client applications as well as to fellow components. The code used to access a component’s services is the same, regardless of whether the component is deployed as in-process, local, or remote.

Distributed Component Object Model (DCOM)

The Distributed Component Object Model (DCOM) was previously referred to as Network OLE. DCOM is a protocol that enables applications to make object-oriented remote procedure calls (RPC) in distributed computing environments (DCE). Using DCOM, an ActiveX component or any component that supports DCOM can communicate across multiple network transport protocols, including the Internet Hypertext Transport Protocol (HTTP). DCOM provides a framework for the following:

•Data marshaling between components

•Client- and server-negotiated security levels, based on the capabilities of distributed computing environments’ (DCEs) remote procedure calls (RPCs)

•Versioning of interfaces through the use of universally unique identifiers (UUIDs)

Comments

It is interesting to note that originally OLE was said to stand for Object Linking and Embedding. Microsoft backed off that definition and said that objects written to support the Component Object Model are collectively called component objects. Because OLE supports the Component Object Model, OLE objects are referred to as component objects. Now Microsoft refers to these component objects as ActiveX. ActiveX components have been extended to support DCOM.

ActiveX is a physical implementation of the Component Object Model that provides the foundation for the creation of components which can encapsulate logic and be distributed to operate in-process, local, or remote. Visual Basic 6 has been extended to enable the creation of ActiveX servers. Visual Basic’s capability to create components in the form of ActiveX DLLs (in-process servers) and ActiveX EXEs (local or remote servers) makes three-tier client/server applications easier to create than ever before.

Using Visual Basic, you can create applications that are partitioned into several separate physical components. Those components can then be placed transparently on any machine within your network, as well as across the Internet, and they can talk to each other. The following section introduces you to the service model, which suggests a logical rather than a physical way of viewing how applications should be partitioned into components.

COMPLEXITY
INTERMEDIATE

1.5How do I…Discover the service model?

COMPATIBILITY: VISUAL BASIC 4, 5, 6

The service model is a logical way to group the components you create. Although this model is not language specific, this book discusses the service model and how it is implemented by using what is available in Visual Basic 6. The service model is based on the concept that every tier is a collection of components that provide a common type of service either to each other or to components in the tier immediately adjacent.

The following three types of services are used in the creation of business solutions:

•User services

•Business services

•Data services

Each of these types correlates to a tier in a three-tier client/server architecture. Figure 1.7 shows physical components (DLLs, EXEs, database triggers, and database-stored procedures) grouped logically into the three service types. Note that DLL components and EXE components can be used to encapsulate logic in any tier. In fact, the only objects that are not in every tier are triggers and stored procedures because they are database specific.


Figure 1.7Physical components grouped logically within the services tiers

Figure 1.7 also shows a very important benefit of using components, which is the ability to make a component’s services available to more than a single application. Notice that the shaded areas overlap where components are used by both application 1 and application 2. Reuse is a powerful aspect of the service model. The following basic rules for intercomponent communication must be followed in the service model:

•Components can request services from fellow components in their current tier and any tier below or above a component’s tier.

•Requests cannot skip tiers. User services components cannot communicate directly with components in the data services tier and vice versa.

Often the service model is referred to as a layered approach. The typical use of the term layer refers to a process in which one layer must speak to the next layer and move from top to bottom and then back up. This does not correctly describe the way components communicate within the service model because a component can interact with other components in the same layer as well as those above and below it. The service model is meant to help you decide how to partition application logic into physical components, but it does not deal with the actual physical deployment of the software components. By understanding the three service tiers, you can begin to make decisions about which application logic you should encapsulate within a single component as well as within the various tiers. The following sections discuss the different types of services defined in the service model.

User Services

Components in the user services tier provide the visual interface that a client will use to view information and data. Components in this layer are responsible for contacting and requesting services from other components in the user services tier or in the business services tier. It is important to note that even though a component resides in the user services tier, one of the services provided to a user is the ability to perform business functions. User services play a role in doing business. Even though the business logic may be encapsulated in components of the business services tier, the user services component enables the user to have access to the whole process.

User services are normally, but not always, contained in the user application. A user service such as common company dialog boxes could be compiled into a DLL and made available locally on a client’s machine. Perhaps you want to implement a standard set of error messages, but you don’t want to deploy it to every machine. You could take that user service, compile it into an ActiveX EXE, and deploy it remotely on a shared server so that everyone could use it.

WARNING:
If the Error message component is placed on a central server, it should only contain text string error messages and should not display a dialog box. If a remote ActiveX server displays a dialog box, it appears on the server rather than on the user’s workstation. Refer to Chapter 6, “Business Objects,” for more information on this topic

Business Services

Because user services cannot directly contact the data services tier, it is the responsibility of the business services components to serve as bridges to alternative tiers. Business components provide business services that complete business tasks such as verifying that a customer is not over his or her credit limit. Rather than implementing business rules through a series of triggers and stored procedures, business components provide the service of implementing formal procedures and defined business rules. So why go through all the trouble of encapsulating the business logic in a business component or set of components? For robust, reusable, maintainable applications.

Business services components also serve to buffer the user from direct interaction with the database. The business tasks that will be executed by business services components, such as entering a patient record or printing a provider list, should be defined by the application’s requirements. One overwhelming reason to partition out business services into components is the knowledge that business rules have the highest probability for change and, in turn, have the highest probability for requiring the rewriting and redeployment of an application.

Business rules are defined as policies that control the flow of business tasks. An example of a business rule might be a procedure that applies a late charge to a person’s bill if payment is not received by a certain date. It is very common for business rules to change more frequently than the tasks they support. For this reason, business rules are excellent targets for encapsulation into components, thus separating the business logic from the application logic itself. The advantage here is that if the policy for applying late charges changes to include the stipulation that they cannot be sent to relatives of the boss, then you will need to change the logic in your shared business component only, rather than in every client application.

Data Services

Data services involve all the typical data chores, including the retrieval and modification of data as well as the full range of other database-related tasks. The key to data services is that the rules of business are not implemented here. Although a data service component is responsible for managing and satisfying the requests submitted by a business component, or even a fellow data services component, implementing the rules of business is not a responsibility.

Data services can be implemented as objects in a particular database management system (DBMS) in the form of triggers or stored procedures. Alternatively, the data services could provide access to heterogeneous data sources on multiple platforms on any number of servers or mainframes. A properly implemented data services tier should allow changes to take place in the data services tier and related data sources without affecting the services being provided to business services components.

Comments

The service model is a logical—not a physical—view of working with components and application partitioning. Sometimes physical deployment of components might parallel the component’s tier assignments, but this is neither necessary nor desired. In Figure 1.8, components in the service model have been mapped to one of three physical locations. They can reside on the client, on a network server (typically a business server), or on a second network server (typically a database engine server).


Figure 1.8Simple physical deployment of components on a network

Figure 1.8 helps to illustrate the following key points with regard to the service model and physical deployment:

•Triggers and stored procedures from the data services tier must be deployed in the database back end. The reason is that these objects are direct implementations of the database engine and are stored within the database itself. This is shown by the direct mapping of the stored procedures and triggers symbols within the data services tier to the database server.

•To share a single common source of services, a component must be an out-of-process remote Automation Server (ActiveX EXE) and be deployed on a central server so that everyone can access it. In Figure 1.8, an ActiveX EXE within the user services tier is mapped to the business server so that multiple users can access it.

•Not all business logic is best deployed remotely. Due to performance considerations, an in-process DLL provides better performance than an ActiveX EXE and might be a wiser choice. In Figure 1.8, a DLL in the business services tier represents this type of scenario. DLLs generally cannot be utilized remotely, so the business services DLL must be deployed to the user’s workstation rather than to the business server.

One final comment about the idea of dual personality is that dual personality is a powerful aspect of components that affects their design. Any component can be both a client and a server. Consider a situation in which you design a business services component to calculate book royalties. The royalty calculation is a service that the Visual Basic component provides to any requester. To create the calculation, the business component must have information about the author’s contract with the publisher. Your business services component becomes a client of services rather than a server as it requests contract information from a data services component. In this example, the royalty component is acting not only as a server of royalty information but also as a client of data services. This is a much more powerful implementation than the typical and more rigid client/server relationship in which a client can’t be a server, and vice versa. In the next section you will review three physical deployment scenarios available for client/server applications that utilize a three-tier client/server architecture.

COMPLEXITY
ADVANCED

1.6How do I…Understand client/server deployments using components?

COMPATIBILITY: VISUAL BASIC 4, 5, 6

The service model encourages the creation of components that encapsulate common reusable functionality in a physical package—the ActiveX DLL or ActiveX EXE. VB6 makes possible also the creation of ActiveX controls in the form of OCXs, as well as the creation of ActiveX documents which are applications that live inside a browser. Compiled into these physical formats, these pieces can be deployed on a practically infinite number of topologies. Before you review deployment options, you should understand the characteristics of the ActiveX DLL and ActiveX EXE. Both are ActiveX component objects and share a common interface based on the standards defined by the Component Object Model.

When considering which is the proper container for a particular component, you should consider the following about these two physical component implementations. A DLL is an in-process server. In-process refers to the fact that the DLL operates in the same process space as the application using it. Because a DLL is operating in the same process, it loads much more quickly than an EXE would. Additionally, a DLL cannot be deployed remotely, at least not without a trick or two. The trick being referred to here is that a DLL can be deployed remotely if the DLL is parented by an EXE component. The EXE would instantiate the DLL on the remote machine and provide an interface to the DLL’s methods and properties. This process is referred to as containment. The parent component marshals requests between a client and the DLL.