Configuring the Crystal Enterprise Architecture for Your Network Environment

Chapter 24, "Crystal Enterprise Architecture," introduced the components that make up the Crystal Enterprise architecture. However, before looking at how Crystal Enterprise can be configured to support the implementation of the firewall types described previously, it is necessary to review the architecture of Crystal Enterprise, concentrating on how the components that make up the complete product architecture communicate with each other. In fact, the mechanism employed to support server communications has a significant bearing on how Crystal Enterprise can be deployed with one or multiple firewalls.

Additionally, more detail needs to be provided about the relationship between the WC, the Web server, and the Web Component Server. This will be done in a later section; first, you will examine the core of Crystal Enterprise server communicationthe Framework.

Reviewing the Framework

From your investigation of the Crystal Enterprise architecture in previous chapters, you know that at the core of Crystal Enterprise is a communication layer called the Crystal Enterprise Framework. The Framework is made up of a collection of services, which provides a series of Business Intelligencerelated functions implemented by one or more Crystal Enterprise services. It is, effectively, a CORBA bus integrating Enterprise information management facilities (Security, Deployment, Administration, and so on) with the CORBA 2 Open Standard services (Naming, Trading, Event, and so on). Common Object Request Broker Architecture (CORBA) is an architecture and specification for creating, distributing, and managing distributed program objects in a network. It allows programs in different locations to communicate in a network through an "interface broker."

Although CORBA is at the core of the Framework, it is hidden from Crystal Enterprise administrators and developers (and, therefore, does not form part of the discussion of administration in Chapter 27, "Administering and Configuring Crystal Enterprise"). No configuration needs be done with CORBA that would be done differently from any other TCP/IP application. Some definition of port numbers is all that is required as far as Framework Administration is concerned.

However, for the purpose of using firewalls one concept about CORBA needs to be understoodthe IOR. The IOR (Interoperable Object Reference) is a unique identifier for an object and contains information about the CORBA object itself. For example, the Report Job Server appears to other CORBA clients using the Framework as an object that is available for those clients to use. Each time a server in the Framework requires the use of another server object, it requests information about that object. This information comes in the form of an IOR. The IOR includes the IP address and port to be used for returning messagescritical when working with firewalls.

To summarize, Crystal Enterprise uses CORBA for intra-server communication. Administrators and developers are not exposed to the technology, nor are they required to work with it; however, it can become important in terms of firewall configuration.

Crystal Enterprise and TCP/IP Communication

With standard TCP/IP communications, two servers that communicate with each other do so over a single point-to-point connection. The use of CORBA in the Crystal Enterprise Framework, however, lends a slightly different flavor. In an environment where many requests are to be served, traffic on a particular port can be overwhelming and slow the operations of the serverleading, obviously, to performance problems. Crystal Enterprise avoids this by listening on one port and sending on others. Within the Crystal Enterprise environment, therefore, communication consists of the opening and closing of multiple ports for a single request/service interaction. In Crystal Enterprise server-to-server communication, after the initial connection is complete, communication stops on this channel. Instead, another channel is established to send data back and forth, leaving the server that is listening on a given port free to service the next connection request quickly and efficiently.

Understanding Web Connector and Web Component Server Communication

The gateways to the Crystal Enterprise information delivery environment are either the Web Component Server (WCS) in the COM environment, the Java application server in the Java environment, or the .NET application server in the .NET environment. These communicate via the CE-SDK to the Crystal Enterprise Framework. Because there are multiple configurations available with Crystal Enterprise depending on the platform and technologies used in each organization, a brief exploration clarifies the remainder of this chapter.

Three main types of configuration are possible at the application level of the Crystal Enterprise Architecture: the COM configuration, Java configuration, and .NET configuration. Note that all of these configurations could be connected to one Crystal Enterprise installation, allowing a diverse organization to leverage existing technology to write applications against one installation of Crystal Enterprise.

NOTE

Crystal Enterprise supports three implementations of its SDK simultaneously. That means one implementation can support communication from Java, .NET, and COM environments at the same time. This enables organizations to leverage their inherent skill-sets when developing with Crystal Enterprise and also facilitates ongoing system availability through enterprise development standards changes (for example, moving from a COM-based shop to a J2EE-based organization).

The COM environment is common on Windows platforms and uses the Crystal Enterprise COM SDK, CSP or ASP pages, a Crystal Enterprise WCS, and a Crystal Enterprise Web Connector (WC) installed on the Web server. In this configuration two possible levels of communication are possible: the WC communicates with the WCS over TCP/IP, which in turn communicates with the Crystal Enterprise Framework; or ASP pages use the COM SDK, which communicates directly with the Framework.

The Java configuration installs by default in Unix environments, or can be installed when working with a Java Application Server in a Windows environment. Instead of a WC and WCS, the Java configuration uses a Crystal Enterprise Web Component Adapter (WCA) installed on the Application Server, and no WC or WCS. The Crystal Enterprise Java SDK also installs on the Application Server and causes the Application Server (for example, IBM's WebSphere or BEA's WebLogic) to communicate directly with the Crystal Enterprise Framework via TCP/IP.

The .NET environment uses .NET assemblies, which in turn directly communicate with the Framework via TCP/IP. In the .NET configuration no WCS, WC, or WCA are installed.

The remainder of this chapter discusses the COM configuration because it is the most complex. This discussion can easily be applied to the Java and .NET environments by considering that any IP and port configuration applied to the WCS should be applied to the initialization files for the Java Application Server. In .NET deployments, all port configurations are made within the various services as the Framework does not make outbound calls to the .NET server (in other words, IIS). The basic concepts for these alternate configurations, however, are the same.

The configuration for the WCA in the Java environment is done via modification of the file web.xml. This file can be found in Unix environments in the WEB-INF subdirectory of the webcompadapter.war file stored in the crystal_root/enterprise/JavaSDK/applications directory on Unix, or X:Program FilesCommon FilesCrystal Decisions2.5jarsJavaSDKapplications on Windows. In this file you can set context parameters by entering XML such as

viewrpt.groupTreeGenerate

true

This chapter will deal primarily with setting IP addresses and ports, and so will involve setting the following two context parameters in the web.xml file:

• connection.cms sets the name and port number of the CMS. Equivalent to setting command-line argument -requestport for the WCS.
• connection.listeningPort defines the default ports that the WCA applets are running on. Equivalent to setting command-line argument port for the WCS.

Thus, in any discussions in the remainder of this chapter, treat the Java Application Server and WCA together as equivalent to the WC in terms of network settings. Also, because the WCA carries out functions of the WCS, remember that no WCS will be installed.

For a detailed review of the application layer, p. 522

If operating in a Java or .NET environment, you can draw a parallel between the WC and the application server. Because the application server communicates with the Framework, you will need to configure support for the application server to "talk" to the Framework the same way that you would configure the WC to "talk" to the WCS.