29 - Building Applications with Microsoft BackOffice

• Microsoft BackOffice as a platform for application implementation - Discover why BackOffice is a stable foundation upon which mission-critical applications can be built and deployed.

• How Microsoft BackOffice meets user demand for features and functionality - Learn how BackOffice services can be incorporated into applications you develop.

• How Microsoft BackOffice addresses the technical aspects of developing distributed applications - Relate the common technical problems of today to the world of BackOffice.

• How Microsoft BackOffice products work together to provide advanced functionality - See how BackOffice products work together as a unit to support application development.

The primary purpose of this book is to aid you in your Microsoft BackOffice implementation. To this end, the majority of the book focuses on "how to" install and administer the BackOffice products.

The primary purpose of this chapter is to aid information systems managers and administrators in understanding what BackOffice means to application development and deployment. Although it is beyond the scope of this book to provide an in-depth look at this topic, it is meaningful to examine some application scenarios. This serves to highlight some of the important aspects of BackOffice with respect to application implementation.

The best way to understand how BackOffice provides a foundation for application implementation is by way of example. In this chapter, you see how BackOffice is applied to real-world situations.

Before jumping into sample scenarios it is useful to take a brief tour of the predominant technical issues facing application developers today. The reason for this is twofold:

• To effectively develop applications with tools such as BackOffice, it is necessary to understand the underlying technologies.

• In some situations, applications are developed as a result of an available technology. Competitive pressures on businesses often lead to customer requests for services based on advanced technologies. In this case it is frequently common for a technology to drive an application requirement.

After exploring the underlying technical aspects of application implementation, you will see how BackOffice supports modern-day application development.

Technical Underpinnings

See "Understanding Client-Server," (Chapter 1)

The basic premise of client-server as a process model is sound - it allows and encourages the effective distribution of processes across the computing enterprise. As such, the client-server process model provides a solid basis for mission-critical applications.

One of the most common problems in information systems today is that tools, technology, and knowledge are just now catching up to the issues being addressed with the client-server process model. Microsoft BackOffice is an example of a product that enables the effective use of client-server as a process model for mission-critical application development and deployment.

Business conditions dictate a majority of the problems these tools and technologies must address. To understand the best way to apply them to the problems, it is necessary to gain some insight into the underlying technical issues. Some of the issues that currently receive the most attention include:

• Client-server process model

• Remote access

• Internet

• Electronic messaging

• Relational database management systems

• Distributed data

• Host connectivity

These issues comprise a short list of technical characteristics of modern-day applications. This list is not comprehensive. However, it does represent some of the most common issues associated with current application development.

Throughout this book, you have seen how BackOffice is based on these aspects of technology and how it addresses these needs. To better understand how BackOffice supports these concepts in application development, it is meaningful to examine each of these issues at a high-level from a developer's perspective.

Client-Server Process Model

In some ways, this makes it a self-fulfilling characteristic because many decision makers now state as an important requirement that the application be based upon the client-server process model. The reasons for its acceptance include:

• The client-server process model is truly a solid foundation upon which mission-critical applications can be built, even though it is just a step along the way to fully distributed computing.

• Investments in host-based solutions are reduced each year. These dollars are instead placed into platforms for solutions based on the client-server process model.

• The client-server process model holds the promise of leveraging the investment in computers, because it is designed to effectively utilize all the processors in the enterprise.

• A clear direction of the information systems industry is toward the client-server process model. Consequently, it is more inconvenient to obtain educational services or expert advice on anything other than the client-server process model.

• Industry vendors are investing heavily in products and tools based on the client-server process model. Because these vendors rely on the client-server process model, it becomes a characteristic of computing environments by the nature of the tools employed.

A result of all this is that client-server becomes the process model of choice for most systems being developed today. Some aspect of your information systems will soon, if not already, be based on the client-server process model.

Remote Access

Another need for remote access to data exists for those who normally work at a single location that is not near the main office. This is true for satellite offices, people who work at home (sometimes referred to as telecommuting), or those temporarily assigned to an off-site location.

In all these situations, computer users require remote access to the organization's applications and data. Therefore, remote access becomes an important characteristic for application development.

Internet

• Communicate with everyone else on the Internet

• Publish information publicly to anyone on the Internet interested in viewing it

These two important aspects of the Internet reflect characteristics to be considered when developing an application.

The greatest concern regarding the use of the Internet for business transactions is security. Government, industry, and the worldwide academic community continue to work toward resolving security issues to the satisfaction of all. Although it is difficult to imagine that a perfect security scenario will ever exist, it is likely that an effective and durable security system will soon prevail.

As soon as the security concerns are quelled, opportunities to incorporate the Internet into application functionality will rapidly multiply. A wide variety of tools to support this type of development already exists. The Internet receives much attention and should be considered an important characteristic of modern-day application development.

See "Business Value of the Internet," (Chapter 9)

See "Security Plan for IIS," (Chapter 11)

Electronic Messaging

Organizations that rely on electronic communications are said to have an e-mail culture. This is an important attribute of many successful companies today; many companies that have achieved rapid growth rates in short time periods credit electronic messaging as one of the reasons for their success.

As e-mail has become more and more popular, organizations are beginning to utilize electronic messaging as one of the primary forms of communication. For this reason, electronic messaging is considered one of the characteristics of modern-day application development. With each new application, consideration should be given as to how the application will integrate with the organization's electronic messaging system.

See "Surveying Features in Microsoft Exchange Server," (Chapter 12)

Relational Database Management Systems

See "What Is a Relational Database Management System?," (Chapter 17)

Distributed Data

More likely, however, is that data from the remote user needs to be copied to a central location. It is also likely that data generated in a central location must be copied to one or more remote locations. Yet another scenario exists for remote users in which data is generated in both the remote locations and a central location. The act of combining this data in appropriately is challenging.

Two primary issues are associated with distributed data:

• Replication. In some situations, the same data must exist in multiple locations. When this need arises, it is important to define one of the locations as the place for data origination because this reduces the opportunity for data entry error due to double entry. The location of data origination can be assigned the responsibility of notifying other locations of a change to the data. The act of performing this notification and copying the data to other locations is referred to as data replication. Data replication is an important characteristic of modern-day application development that must be carefully planned and executed.

• Synchronization. Determining when and how to replicate data is only part of the problem. Another difficult aspect of managing distributed data is resolving conflicts. In a distributed data scenario, it is possible for two locations to change the same element of data during the same time frame. When the database manager then attempts to replicate the data to the other location, each location may lay claim to ownership of the data. However, only one change can be honored. The solution to this problem lies in how changes to the data are synchronized. Data synchronization is also a characteristic of applications in today's computing environment.

Of course, there are other problems associated with distributing data across multiple locations, and other scenarios exist in which distributing data is a requirement. For more information on managing distributed data in a BackOffice environment, see Chapter 20, "SQL Server Advanced Topics."

Host Connectivity

Legacy systems continue to dominate the information systems landscape because so many organizations rely on them for supporting business processes. Over time, these systems are being systematically replaced by solutions based on the client-server process model. In the meantime, however, a characteristic of application development today is the reliance on host-based data. Also, coexistence with legacy systems is an important concern, especially during migratory or transition periods.

Systems built upon the client-server process model often are dependent on data originating from a host-based application. Data travels between host-based applications and applications built using the client-server process model in two ways:

• Batch. Data that flows in this manner between these two application platforms is transmitted in bulk quantity at regularly scheduled intervals. Typically, batch transmissions amount to downloading a file from the host computer (or uploading a file to the host computer) and processing the file on the destination computer. As the data is processed, it is placed into the target database. This type of data exchange requires an occasional connection between the host computer and a server computer.

• Real-time. Data that flows in this manner between these two application platforms is transmitted as the applications operate. As soon as data changes in one system, it triggers a change in the other. This type of data flow requires a continuous connection between the host computer and a server computer. The applications must include processes that constantly await the arrival of new data and processes that send data as necessary. Because the flow of data in this situation is on-demand, the interface is referred to as real-time.

To accommodate either type of data flow, it is necessary to be able to connect server computers that store data with host computers. For this reason, host connectivity becomes an important characteristic of modern-day application development.

Programmatic Interfaces

The second way BackOffice incorporates these technologies into applications is via programmatic interfaces. Such interfaces, normally referred to as application programming interfaces (APIs), are simply a means by which an application developer can access the same services available to users and administrators. Often, the available APIs provide access to additional functionality.

As developers work on applications, they frequently encounter situations in which their application requires the services of another application. If the other application provides a programmatic interface such as an API, the developer can "invoke" the service from within his or her application's source code. Although other types of programmatic interfaces available, this is the most popular method and is fully supported by Microsoft as a part of BackOffice.

The programmatic interfaces needed to develop applications in a BackOffice environment are normally built by Microsoft along with the BackOffice product. However, the API is not normally provided in the product package. Instead, the APIs are bundled in developer tool kits and assorted technical CDs available from Microsoft.

The APIs important to BackOffice application developers are delivered as extensions to Microsoft's Windows programming interface, Win32. This API is a 32-bit programming interface for developing applications on Windows 95 or Windows NT. As such, it is the broadest API available from Microsoft and is used to develop each of the actual BackOffice products.

To understand how developers interact with BackOffice services, it is necessary to be introduced to the available programmatic interfaces. Microsoft provides the following interfaces for BackOffice application developers:

• Win32 API (Win32)

• Internet Server API (ISAPI)

• Messaging API (MAPI)

• Open Database Connectivity API (ODBC)

• System Network Architecture API (SNAPI)

Other programmatic interfaces are available from Microsoft and third-party providers for more specific services. Examples include Microsoft's Telephony API (TAPI) and their recently introduced Speech API (SAPI). You should stay abreast of API availability from Microsoft and other vendors because this is one of the most important ways to take advantage of server application services to improve the functionality of applications developed by your organization.

Figure 29.1 shows how some of the available APIs line up with the individual BackOffice products. Each BackOffice product has at least one programmatic interface, as shown in figure 29.1. Not shown is a programmatic interface for SMS. Although a limited interface is available, it is not yet widely used in application development and, therefore, will not be covered herein.

Fig. 29.1 - Each Microsoft BackOffice product is supported by an underlying programmatic interface.

A brief description of each API follows.

Win32

Win32 contains several categories of programming interfaces. At the root of Win32 is the windows management capabilities of the base operating system. This includes all the windows control and user interface functions. Win32 is available in C and C++ versions. However, it is far more convenient to utilize component libraries based on Win32 such as Microsoft Foundation Classes, which is delivered with Visual C++ instead of Win32 itself.

ISAPI

The demand for external applications arises out of the need to respond to user actions and choices. As Internet users view information presented to them by a WWW site, it is possible the next information presented should be different depending on the choices made by the user or the path taken. In this way, it is desirable to create what is known as a dynamic WWW page.

Dynamic WWW pages today are created by execution of a CGI application. This application prepares the subsequent content for the viewer based on the information received from the user. CGI applications, however, are a crude way in which to invoke external applications. They typically have to be loaded into memory each time they are invoked and are prone to performance difficulties.

The Internet Server API (ISAPI) offers an alternative way to develop CGI applications. Instead of developing stand-alone executables, using the CGI approach an application developer can now build an external application for execution by a WWW server using ISAPI. ISAPI allows the applications to be developed in C or C++ and prepares the application as a DLL. Because DLLs have more flexibility in the way the load, they offer many advantages over the CGI approach.

See "The Information Superhighway," (Chapter 9)

See "Using CGI," (Chapter 11)

See "WWW Publishing," (Chapter 11)

MAPI

MAPI allows application developers to incorporate messaging services directly into applications. It is possible, from within an application, to automatically generate e-mail messages and send them to appropriate addresses. It can be of great convenience to users to have their applications automatically create and send messages with information from the application. MAPI can also be used to receive messages and manage e-mail.

ODBC

The basic premise of ODBC is simple: to provide a consistent manner in which to access data in databases that support ODBC. Because most of the popular database vendors provide ODBC support (in addition to their own access methods), it is important to know what ODBC provides. It allows application developers to access databases using common SQL commands. The major categories of ODBC functions include:

• Connecting to a data source

• Obtaining information about the ODBC driver and a data source

• Setting retrieval options

• Preparing SQL requests

• Submitting SQL requests

• Retrieving results and information about the results

• Obtaining information about the data source's system tables

• Terminating a statement or a connection

Applications that support ODBC are assured of having a common interface to a variety of data sources, including databases managed by database management products from other vendors. This is an important characteristic of any application developed in today's information systems.

SNAPI

It is also nice to be able to gain access to host information from within applications developed in the BackOffice environment. To this end, Microsoft provides a System Network Architecture API (SNAPI). With SNAPI, applications can access host information in a variety of ways. Included in SNAPI are interfaces for the following:

• Advanced Program-to-Program Communications (APPC)

• Common Programming Interface for Communications (CPI-C)

• Logical Unit Application (LUA)

• Common Service Verb (CSV)

• High Level Language API (HLLAPI)

All these APIs are included with SNA Server with the exception of HLLAPI, which is available from third-party vendors.

Business Issues

Now that you have been adequately introduced to the technical issues, it is time to learn how typical applications rely upon them. To demonstrate how these technologies can be incorporated into applications, it is helpful to see how they apply to common business problems. Most applications developed today possess one or more of the following business issues:

• Geographically separate locations

• Mainframe transaction systems

• Management reporting

• Remote employees

• Remote customers

• Information publishing

For each of these business issues, you see which technologies are appropriate to apply toward their resolution. Following each explanation, you learn how BackOffice addresses the business issues with the respective technologies and supporting programmatic interfaces.

Geographically Separate Locations

Computers connected within the same physical location are usually connected to the local area network (LAN). In a LAN, all computers are connected to the same physical cabling system. As the distance between computers grows, it is necessary to utilize other means (for example, long-distance carriers, microwave, or satellites) to attach computers to the network. The concept of connecting computers to the same network over vast distances is known as wide area networking (WAN).

Regardless of the number of geographically separate locations your organization has, it likely has one location that is considered the central location, or headquarters. At this location, the WAN is administered, and the majority of network services are provided.

From a technology perspective, BackOffice accommodates this type of networking scenario for two reasons (see fig. 29.2):

• It is based on the client-server process model.

• It has the capability to manage distributed data.

Fig. 29.2 - The client-server process model and distributed data capabilities are the BackOffice technical underpinnings that allow it to support geographically separate locations.

From a developer's point of view, support for geographically separate locations is accommodated through the Win32 and ODBC APIs (see fig. 29.3). With Win32, a developer can build applications that operate on a LAN or WAN or over a remote connection to the network. Applications can be developed to achieve optimal performance depending on the connection type. ODBC database access is transparent regardless of the user location or connection type.

Fig. 29.3 - Win32 and ODBC are among the most important APIs needed to support geographically separate locations.

It should be noted, however, that BackOffice supports geographically separate locations in other ways, as well. In those situations where performance suffers due to the availability of bandwidth, it is appropriate to contemplate supporting remote users with a message-based approach. As such, MAPI may also be an important interface to consider when supporting multiple, remote locations. The message-based approach offers other advantages in that it is more resilient when links are frequently dropped and more flexible when access is available only at certain times.

Several BackOffice products are necessary to fully support geographically separate locations (see fig. 29.4). At a minimum, Windows NT Server is needed to play the role of the network operating system. The remote access service of Windows NT Server can also be used to connect remote users, whether they be internal users such as remote employees or external users such as customers, to the network. Although this is not the only means available to support geographically separate locations, it provides a convenient means for doing so because it is automatically included with Windows NT Server and is easy to use.

SQL Server can be used to build and manage production databases (transaction systems) as well as data warehouses (reporting databases). Again, these databases can be accessed from any client PC on the WAN provided that appropriate privileges have been granted. SMS can be used to administer the entire network including those client PCs connected to remote LANs.

Fig. 29.4 - Together, Windows NT Server, SQL Server, and Systems Management Server provide the necessary support for geographically separate locations.

Figure 29.5 represents a typical BackOffice wide area network. See Chapter 8, "Using TCP/IP with Windows NT Server," for complete coverage of Windows NT Server as a network operating system for a wide area network. This basic network forms the foundation upon which applications can be developed and deployed.

Fig. 29.5 - Geographically separate locations are connected as a "network of networks" via a wide area network.

Based on sound technologies, BackOffice provides the capability to support geographically separate locations. This is an important consideration when designing your enterprise network and applications upon which the organization will operate. Regardless of whether you have multiple locations today, you may eventually need to connect to the outside world or allow customers access to your world. For these reasons, it is important to understand how BackOffice supports geographically separate locations.

See "Building Your Network," (Chapter 3)

See "Using a LAN or WAN," (Chapter 4)

See "Understanding Dial-Up Access to BackOffice," (Chapter 4)

Mainframe Transaction Systems

Although this sounds like a simple suggestion, in the real world it is difficult to draw such a clear line between the two process models. In many organizations, host-based transaction systems are the cornerstone of business operations. For years the strength of mainframe and minicomputers has been their capability to process large numbers of transactions in a short period of time. This has led to the proliferation of transaction-oriented systems on mainframes and minicomputers.

BackOffice and similar approaches from other vendors now provide an alternative that permits the successful development and implementation of mission-critical applications based on the client-server process model. New development tools and development methodologies exist that support this approach to application development and render the mainframe tools seemingly obsolete and inflexible.

Nevertheless, it is common to see new applications based on the client-server process model be developed in and around existing mainframe transaction systems. Even though the eventual goal may be to replace the mainframe computers with a client-server computing environment, the transition may take place over several years (sometimes over five to ten years).

These long transitions lead to the need for PCs on networks to gain access to mainframe applications and data. This concept is commonly referred to as host connectivity. BackOffice provides this important capability (see fig. 29.6).

Fig. 29.6 - The host connectivity capability provided with BackOffice supports application interfaces to mainframe transaction systems.

The major distinction between mainframe systems and applications based on the client-server process model is that mainframe transaction systems typically process large amounts of data in batches at a time; whereas systems rooted in the client-server process model, typically process smaller units of data in response to a request. Because these requests are often referred to as "messages," client-server is said to be message-based.

As developers move from mainframe-based experiences to client-server design and development, this is the most difficult part of the transition. Adjusting application design scenarios from batch-oriented solutions to message-based solutions is a challenge overcome only by those who take the time to learn the fundamentals of the client-server process model.

Because Microsoft recognizes that these different types of application scenarios must coexist in today's computing environments, they have provided application developers with a means to support both. The SNAPI programmatic interface (see fig. 29.7) provides access to IBM mainframe and minicomputer applications and data from a BackOffice environment.

Fig. 29.7 - SNAPI is the programmatic interface that allows BackOffice applications to access mainframe transaction systems.

The SNAPI programmatic interface gains access to host systems via the BackOffice product SNA Server (see fig. 29.8). This product also allows users on client PCs located throughout the enterprise network to run mainframe applications, provided that they are configured with the appropriate client software. Figure 29.9 shows the role SNA Server plays in the enterprise network.

Fig. 29.8 - SNA Server is the BackOffice product that supports access to mainframe transaction systems.

Fig. 29.9 - IBM mainframe and minicomputers are connected to BackOffice networks via SNA Server.

SNA Server is the BackOffice component that provides host connectivity to mainframe transaction systems. This is an important part of application development today and for many years to come. SNA Server addresses this need from both a user's perspective and a developer's perspective.

See "Understanding Client-Server," (Chapter 1)

Management Reporting

Herein lies the dilemma facing information system professionals today. How can more and better information be delivered in the shortest time possible? The cornerstone of the solution to this problem is a relational database management system (RDBMS). BackOffice provides this important piece to the puzzle (see fig. 29.10)

Fig. 29.10 - The capabilities of a relational database management system provide the technical underpinnings necessary to support sophisticated and flexible management reporting.

Many types of reporting requirements must be fulfilled. Some reports are produced and delivered on a regular schedule. Some reports are generated daily, weekly, monthly, or on some other regularly scheduled interval. These reports typically are generated automatically by applications built for this purpose.

From a developer's perspective, these reports are written as a part of the application. In the client-server process model, these reports can be written on the client side or the server side. There exists a multitude of tools for creating these reports from Microsoft and other vendors, as well.

Often, management desires an answer to a question more quickly than a developer can prepare a report. In such cases, it is necessary for managers and staff to be able to access the enterprise information. These impromptu requests for information are referred to as ad-hoc queries.

Regardless of whether the information desired comes from a preprepared report or is the result of an ad-hoc query, these results are only possible if a consistent, convenient access to the information is provided. BackOffice supports such an interface to the RDBMS through the Open Database Connectivity (ODBC) programmatic interface (see fig. 29.11).

Fig. 29.11 - ODBC is the programmatic interface that forms the foundation of end-user reporting tools.

Application developers can use ODBC to gain access to data managed by SQL Server for the purpose of preparing reports. Reporting tools are also developed with the capability to access SQL Server data using ODBC. More important, ODBC is a database interface supported by other RDBMS vendors, such as Sybase and Oracle. This allows reports and reporting tools built upon the ODBC programmatic interface to access other databases as well.

The product that provides the foundation for management reporting in a BackOffice environment is SQL Server (see fig. 29.12). Combined with reporting and query tools for client PCs, BackOffice permits organizations to fulfill the regularly scheduled reporting requirements as well as respond to the immediate need for information through ad-hoc queries.

Fig. 29.12 - Combined with client PC reporting and query tools, SQL Server is the BackOffice product that supports management reporting.

Figure 29.13 depicts how multiple instances of SQL Server can be used. It also shows that SQL Server can be used for multiple purposes. Production databases typically contain the high-volume transaction data necessary to support mission-critical applications. Data for reporting purposes and to support ad-hoc queries is stored in data warehouses.

Fig. 29.13 - SQL Server can be used to build management reporting databases (data warehouses) as well as enterprise transaction databases (production databases).

The need for information drives the information systems industry today. BackOffice addresses this need by incorporating a relational database management system and providing convenient access to it for application developers and users.

See "Online Transaction Processing and Online Analytical Processing," (Chapter 17)

Remote Employees

One approach is to load their PCs with data as they are in the office and connected to the network. This tends to be a restrictive way to resolve this issue because it sometimes requires frequent visits to the office, although this is often the only way to gain acceptable performance. Moreover, it may be that the information is too voluminous for a portable PC; not to mention that data may change while the traveler is away from the office. This may result in an inappropriate decision being made.

Who needs this information while away from the office? Clearly, the most popular example today is field sales personnel. These individuals spend the significant portion of their days calling on customers at the customer sites. While engaged with customers, much information is needed to facilitate customer service and be the most competitive in a sales environment.

In addition to field sales personnel, many organizations employ people who work from home. Although this trend has not yet achieved widespread acceptance, it is gaining in popularity. Many part-time employees currently work from home on a temporary basis, and many full-time employees anticipate they will in the years to come.

What does all this mean to application developers? Most importantly, it means that applications must be developed to behave well in a remote computing environment. It also means that the organization's network must provide remote access capabilities. BackOffice provides the technical foundation upon which these types of applications can be developed because it is based upon the client-server process model and incorporates remote access capabilities (see fig. 29.14).

Fig. 29.14 - The client-server process model and remote access capabilities are the BackOffice technical underpinnings that allow it to support remote employees.

BackOffice provides a comprehensive set of programmatic interfaces for developing applications in a remote usage environment. The programmatic interface provided by Microsoft for this purpose is Win32 (see fig. 29.15). This API includes capabilities to control access to the network from remote PCs, the capability to execute processes in the office (remote procedure calls) to reduce the amount of data transmitted, the capability to reduce bandwidth requirements through message-passing interfaces such as MAPI (included within Win32), and the important capability to build applications based on the client-server process model due to the availability in Win32 of a network protocol interface such as TCP/IP.

Fig. 29.15 - The Win32 programmatic interface is necessary to build applications for use by remote employees.

All these capabilities are built directly into Windows NT Server (see fig. 29.16). Developers have access to each of these interfaces, and many others, in application development. Microsoft also uses these interfaces to develop such products as the Exchange Server client software. This is a good example of client software that is optimized to operate in a remote environment. Any applications built today should consider to what extent remote operation should be supported.

Fig. 29.16 - The remote access service of Windows NT Server is sufficient for supporting remote employees.

Figure 29.17 depicts how remote employees such as field salespeople connect to the network. They can connect either to the central LAN or a remote LAN - wherever a Windows NT Server exists with the remote access service enabled. See Chapter 7, "Implementing the Remote Access Service (RAS)," for a complete description of how to implement this capability.

Fig. 29.17 - Remote employees connect to the network via Windows NT Server remote access service.

Remote access to information is quickly becoming one of the most important aspects of modern-day application development. It is important that you understand this need and how BackOffice addresses it. It is imperative that you design your applications with remote access in mind. This absolutely means that the amount of data transmitted to and from the client PC must be minimized, and the client-server process model must be fully exploited.

See "Understanding Network Protocols," (Chapter 4)

Remote Customers

To the uninitiated, supporting remote customers may appear to be the same as supporting remote employees. This is true with one major exception - security. Employees demand access to internal information to make decisions about their work. Customers, on the other hand, must be restricted to the information pertinent to the specific transaction at hand.

To allow customers access to your enterprise network, you must, just as for remote employees, base application development on the client-server process mode and the remote access capabilities of BackOffice. In addition, it is important, in some situations, to give customers access to information via the Internet (see fig. 29.18).

Fig. 29.18 - The client-server process model, the remote access service of Windows NT Server, and the Internet together form the technical underpinnings necessary to support remote customers in a BackOffice environment.

Just as with remote employees, applications built to support remote customers must be based on Win32. Additional interfaces for security must also be exploited within the Win32 programmatic interface. Also, because the Internet represents another possibility for accommodating customer access, it may be necessary to incorporate ISAPI into application development (see fig. 29.19).

Fig. 29.19 - Win32 and ISAPI are the programmatic interfaces necessary to build applications for remote customers.

Windows NT Server and Internet Information Server are the BackOffice products that support remote customer access to your enterprise network (see fig. 29.20). Although the Internet is not yet considered a secure enough environment for some transactions (such as financial transactions), it is a reasonable means by which to deliver nonsensitive information to customers. Moreover, much progress is being made by the Internet community toward putting in place security measures suitable for confidential transactions. For this reason, it is important to evaluate the Internet as a possibility for fulfilling customer information demands.

Fig. 29.20 - Windows NT Server and Internet Information Server are the BackOffice products necessary to support remote customers.

Figure 29.21 depicts the manner in which remote customers can connect to the organization. If customers connect via the Internet, they can do so through any Internet service provider using their favorite Internet browser (although it is possible that you may create your Internet information optimized to work best with a given browser). Customers connecting via the remote access service of Windows NT Server must execute applications that you provide and are optimized to operate on remote PCs.

Fig. 29.21 - Remote customers connect to the enterprise either through the remote access service of Windows NT Server or through the Internet via the Internet Information Server.

The capability to connect customers and other interested parties to your network may soon, if not already, be important to your organization. When you are confident that all appropriate security measures are in place, this capability can yield strategic benefits or competitive advantages. BackOffice provides a thorough means by which to support remote customer access.

Information Publishing

Through the Internet, you now have the capability to publish information electronically that is available to the entire Internet community. As the Internet community becomes more closely aligned with the global community, the capability to publish information electronically becomes more important.

The Internet, combined with electronic messaging and the capability to send files to anyone on the Internet, form the technical foundation upon which information publishing can take place in today's world (see fig. 29.22). The great news for information publishers is that the same technologies and tools can be applied to internally published information as to externally published information. In fact, this idea is so prevalent that internal LANs and WANs are now commonly referred to as intranets, as a takeoff on the word Internet.

Fig. 29.22 - The Internet and electronic messaging provide the technical underpinnings necessary to support external and internal information publishing.

To support application development in this environment, Microsoft provides the ISAPI and MAPI programmatic interfaces (see fig. 29.23). Applications can be designed with Internet integration built in and automatic messaging capabilities. A popular example of how messaging can be incorporated into an application is seen in Microsoft Word. After a document is prepared in Microsoft Word, it can be automatically e-mailed to another individual on the BackOffice network simply by choosing File, Send from the menu.

Fig. 29.23 - ISAPI and MAPI are the programmatic interfaces used to build applications in support of both external and internal publishing.

This example illustrates only the simplest form of electronic messaging. As seen in Chapter 12, "Understanding Exchange Server," many other capabilities included with Exchange Server are available. Maintaining document libraries, facilitating document routing, automatic routing of forms, bulletin boards, news flashes, and discussion forums are other examples of how BackOffice supports information publishing with Internet Information Server and Exchange Server (see fig. 29.24).

Fig. 29.24 - Internet Information Server and Exchange Server are the BackOffice products that best support information publishing activities.

Figure 29.25 depicts how customers access published information by browsing the Internet and using Exchange Server. Security for the Internet is provided by third-party products known as Internet firewalls. These products restrict access only to the information you want to make available to the outside world.

Fig. 29.25 - Customers gain access to published information using any Internet browser or the Exchange Server client.

One of the primary purposes for implementing BackOffice in your organization is to facilitate the seamless flow of meaningful information to the client PCs within the organization. The information publishing capabilities of BackOffice make it well suited for this purpose as well as for publishing public information on the Internet.

See "Intranet," (Chapter 3)

See "Business Value of the Internet," (Chapter 9)

See "Security for Your Internet Server," (Chapter 11)

Entire Microsoft BackOffice Solution

Fig. 29.26 - BackOffice provides a thorough coverage of the most important technical underpinnings of modern-day information systems.

These technical underpinnings are further supported through programmatic interfaces. Figure 29.27 shows, all together, which programmatic interfaces are needed to support the various business issues. You have learned how these APIs are important to application developers and what they mean to them. More important, as a manager or an administrator, you have gained insight of BackOffice from an application developer's perspective.

Fig. 29.27 - Each BackOffice product is supported by a programmatic interface so that developers may incorporate BackOffice services into their applications.

The BackOffice products are designed to work as a unit toward resolving today's business issues. Figure 29.28 shows each BackOffice product and the role it plays in addressing these concerns. Through the scenarios presented earlier in this chapter, you learned that each individual product is built upon a solid technical foundation while fully exploiting the most current technologies.

Fig. 29.28 - Together, the BackOffice products satisfy the prevailing business issues.

Finally, bringing all the BackOffice products together in a single enterprise network is shown in figure 29.29. If you were to overlay the diagrams in all the figures in this chapter, you would find that they exactly match figure 29.29.

Fig. 29.29 - An organization can use BackOffice to fulfill the vast majority of its connectivity and user service needs.

By bringing all this together in building blocks, the intent is to demonstrate how BackOffice can be used as a platform upon which mission-critical applications can be built and deployed. Many organizations have already achieved success in so doing, and many more are engaging in BackOffice-based application development each day.

From Here...

Looking ahead, Microsoft has stated publicly their intention is to continue the development of the BackOffice family of applications. You are encouraged to keep apace with Microsoft BackOffice product information and published materials; significant advances are anticipated in the months and years to come.

• For a practical approach to security, see Chapter 28, "Implementing Real-World Security."

• To see why SQL Server is a sophisticated tool for developing modern-day applications, see Chapter 20, "SQL Server Advanced Topics."

• To see how Exchange Server supports today's applications, see Chapter 16, "Exchange Server Advanced Topics."

• To review the foundation upon which Microsoft BackOffice is built, see Chapter 2, "Characteristics of Microsoft BackOffice."

Table of Contents

28 - Implementing Real-World Security

30 - Proactive Network Administration