Figure 1-1: Enterprise Server Architecture
This chapter introduces Enterprise Server.
Enterprise Server provides an execution environment for COBOL application programs. This execution environment is known as an enterprise server. In this book and associated documentation, the term enterprise server means the execution environment, while the term Enterprise Server refers to the product.
Within an enterprise server, COBOL applications run in response to service requests issued by several different client types. The Interface Mapping Toolkit, part of your COBOL development system, allows you to take existing COBOL applications and expose them as services. These COBOL services can then be invoked by clients as Web Services or through a J2EE connector or through COM.
A COBOL program that implements a service is a program that reads in a parameter block, processes it and returns a results block. The interface to the service is exposed by means of a service definition. Not all COBOL applications are suitable for exposing as services. For advice, see the chapter Preparing Applications for Enterprise Server in your Interface Mapping Toolkit book.
Enterprise servers provide session and state management for COBOL applications, as well as optionally interfacing with external resource managers to coordinate resource updates.
An enterprise server provides a pool of pre-initialized service execution processes, within which COBOL applications are executed. As the COBOL applications run within their own address spaces, they are isolated from other programs executed within the enterprise server. Multiple execution processes enable concurrent processing of COBOL programs responding to client request messages.
When you install Enterprise Server, one enterprise server is automatically set up for you. You can then create further enterprise servers.
You need licenses to run an enterprise server. For more information see Deployment Licensing .
The only prerequisite is TCP/IP communications software running on all client and server machines.
An enterprise server has a number of components. Figure 1-1 shows a high-level view of the enterprise server architecture.
Figure 1-1: Enterprise Server Architecture
An enterprise server consists of some processes and an area used for inter-process communication.
The processes include a console daemon, server manager and communications process. These processes provide the following functionality:
All types of requests use TCP/IP as the underlying communications mechanism.
An enterprise server is created with one communications process, but you can add more to improve reliability and fault tolerance.
An enterprise server is created with two service execution processes. A service execution process is, as the name implies, the process that actually executes the COBOL program that handles the client request. You can add more service execution processes.
The inter-process communication area consists of a shared memory area that contains definitions of all the services that are available within the enterprise server. These definitions come from the Directory Server, which is shown in Figure 1-1. It sits outside the enterprise server, because it can contain information for many enterprise servers. The inter-process communication area is also used to pass requests and responses between the enterprise server processes.
The COBOL application providing a service runs inside a service execution process. An enterprise server can have a number of service execution processes. When you start a server, they all become available to process client requests. When a service execution process has finished processing a request, it becomes available again, to process another request.
The processing of a request proceeds as follows:
Figure 1-2 shows the components of a service execution process.
Figure 1-2: Components of a Service Execution Process
The transaction management component manages transactions for container-managed services, that is, it coordinates COMMITs and ROLLBACKs. The resource manager interface handles requests for resources such as database and file access. For more information about transaction management and resource managers see the section Resource Management
The Directory Server is a process that maintains a collection of information that defines services and other related components. The components that the Directory Server handles are known as objects. The Directory Server stores information about objects in its repository. The Directory Server maintains information about:
When you deploy a COBOL application as a service using the Interface Mapping Toolkit, much of this information is created automatically. An administrator can edit the information to respond to changing needs.
The server object is the top level object in the Directory Server. The other objects cannot exist independently of a server. Figure 1-3 shows an enterprise server with two services. Arrows between two objects indicate an association. If you set up a server with one or more services manually, instead of deploying from your COBOL development system, you first create all the objects, and then you build the relationships between them.
Figure 1-3: Objects in an Enterprise Server
By default the Directory Server runs on the same machine as your enterprise servers.
The Directory Server stores information about two types of server object:
For more information about servers, see the chapter Servers.
A service object defines a service. A service provides access to specific business functionality for clients.
A service can contain a number of operations. For example, a calculator program might do addition, subtraction, multiplication and division. Each of those tasks is an operation within the calculator service that a client can use if it understands the interface to the functionality.
In addition to the services that you deploy to an enterprise server, an enterprise server can have one or more system services. The default enterprise server has two system services:
If you want to deploy to an enterprise server other than the default server, ESDEMO, it must have a deployment service.
A service must have at least one service listener. A service that provides business functionality must have exactly one request handler and one implementation package associated with it. (System services do not require handlers or packages.)
For more information about services, see the chapter Services, Packages and Request Handlers.
A communications process object defines a communication process, as introduced and explained in the section Enterprise Server Architecture. Communications processes own service listeners. When you add a new enterprise server, it is created with one communications process, containing listeners for the two system services. You then add further listeners as required to deal with the expected workload of the enterprise server. Once you have the process defined as you want, you can create additional communications processes by copying the existing one. The advantages of having more than one communications process are:
For more information about communications processes, see the chapter Communications Processes and Service Listeners.
A service listener object contains a network address that accepts incoming client requests on behalf of services. A service can have multiple listeners, and a listener can accept client requests on behalf of multiple services.
Each service listener is associated with a connector. This is software that contains the logic for processing the type of requests the listener will handle.
Enterprise Server comes with several connectors, including:
For more information about service listeners, see the chapter Communications Process and Service Listeners and the section Deployment Services and Listeners in the chapter Configuration.
A request handler object defines a request handler. A request handler is a program that receives a client request for access to the service, and translates the request into a form that the application providing the business functionality can understand. After the application has completed its task, the request handler translates the output from the application into a form that the client can understand, then passes the output to the client, via the communications process.
We provide request handlers for the SOAP protocol and for the Micro Focus binary protocol. You can customize the request handler provided for the SOAP protocol using user exits.
For more information about request handlers, see the chapter Services, Packages and Request Handlers.
An implementation package object contains information about the COBOL application that provides the service. A package is associated with an interface definition table (IDT), which contains the information that allows a client request to be mapped onto a COBOL program interface.
For more information about implementation packages, see the chapter Services, Packages and Request Handlers.
An XA Resource object contains information about an XA-compliant database manager required to provide database access to one or more container-managed services. .
For more information about XA resources see the section Resource Management in this chapter and the section Resource Managers in the chapter Configuration.
A COBOL application providing a service that uses external resources, such as databases and files, can manage its own resources or let the application container manage them. A service that manages its own resources is known as application-managed, while a service that does not manage its own resources is known as container-managed.
If a service updates files through Fileshare, you must specify the name and location of an fhredir.cfg file for the enterprise server in which the service runs. For more information see the section Fileshare in the chapter Configuration.
If an application running as a service uses databases and files but does not contain any transactional logic, it can let the application container manage its resources.
The application container must know in advance what resource managers will be required. You define resources not by service, but by enterprise server. You can only define resource managers that are XA-compliant.
When an enterprise server and its service execution processes start up, the enterprise server manager opens connections to all the resources that might be needed by the services that run in that server. When a container-managed service is invoked, the enterprise server manager performs all file and database actions that it requires.
The application container manages databases by issuing XA commands.
The application container decides whether to commit or roll back resources using information supplied when the service was created and deployed in your COBOL development system. However, if there is an error in the application container itself, resources are always rolled back.
A service must manage its own resources if:
A service in which the application accesses files in a non-transactional way (that is, it does not includes COMMITs and ROLLBACKs), should be application managed.
A transactional application-managed service must contain all the transactional logic it needs, that is, it must complete with all resources either committed or rolled back.
Application-managed services are executed in a similar way to applications in a conventional execution environment such as Net Express, Server Express or Micro Focus Server. One of the main differences is that the process is not terminated at the end of execution of the service.
You can mix container-managed and application-managed services in the same enterprise server, but in these circumstances it is even more important that the application-managed services complete with all resources either committed or rolled back. This is because when the application container commits or rolls back resources on behalf of a container-managed application, it commits or rolls back all outstanding updates, including any outstanding from application-managed services that ran previously.
J2EE clients run in a J2EE application server such as IBM WebSphere or BEA WebLogic. When a service is processing requests from a J2EE client, the J2EE application server can be a transaction manager coordinating updates to all the resources involved in a transaction. In this situation, the enterprise server behaves like a resource manager and responds to commit and rollback requests from the J2EE application server, whether the COBOL service is container-managed or application-managed.
After a COBOL program has been mapped using the Interface Mapping Toolkit, it needs to be deployed to an enterprise server. During the development process the developer deploys the interface using the Deploy tool, which is part of the Toolkit. This tool not only automatically deploys the interface to an enterprise server, it also packages all the files required to deploy a service to a COBOL archive file (.car file). Typically, once the service is ready to be run in a production environment, deployment becomes your responsibility. You deploy the interface from the .car file created when the Deploy tool was last used.
If the service has been mapped as an EJB interface, there are some extra tasks to perform:
For more information about deployment from the .car file and deploying EJBs and resource adapters see the chapter Deploying Interfaces. For more information about deploying interfaces automatically using the Interface Mapping Toolkit, see the section Deploy Tool in the chapter Interface Mapping Toolkit in your Interface Mapping Toolkit book.
You can configure and administer Enterprise Server using the Enterprise Server Administration tool. This allows you to view and change information about the enterprise servers managed by the Directory Server. You access Enterprise Server Administration from a Web browser.
Once you have configured Enterprise Server, you can use Enterprise Server commands for some administrative tasks, as an alternative to using the Web interface. For more information about the command-line interface see the chapter Servers.
Administration activities can be divided into two categories: occasional and day-to-day. Once your enterprise servers are fully defined, with their services, service listeners, request handlers and implementation packages, there should not be much to do on a day-to-day level. If developers are deploying direct to Enterprise Server using the interface mapping toolkit, the necessary object definitions are created automatically.
Occasional tasks include:
Day-to-day tasks include:
Before you can start using Enterprise Server, you need to configure the Directory Server and your enterprise servers. For more information about configuration see the chapter Configuration.
To find out about deploying mapped interfaces to an enterprise server and about the extra tasks required to deploy a service mapped as an EJB, see the chapter Deploying Interfaces.
To find out about the Web interface to the Directory Server, start at the chapter Introduction to Enterprise Server Administration. To learn about ESMAC, a set of administration facilities that are only available for started enterprise servers, see the chapter Administering Servers Using ESMAC.
To learn more about the objects that the Directory Server administers, see the chapters Servers, Communications Processes and Service Listeners and Services, Packages and Request Handlers.
For advice on troubleshooting problems see the chapter Troubleshooting.
To find out how to customize the Micro Focus request handlers, see the chapter User Exits for Request Handlers.
Copyright © 2008 Micro Focus (IP) Ltd. All rights reserved.