Chapter 8: Services, Packages and Request Handlers

This chapter describes service, package and request handler objects, the relationships between them and what you can do with them.

Introduction

Service objects, implementation package objects and request handler objects work together to enable service-based business functionality to be provided. A service object for a business service (as opposed to a system service) must have exactly one request handler and one implementation package associated with it. It can have one or more service listeners associated with it.

For all three kinds of objects, your responsibilities as administrator include:

Creating Services Manually

When you deploy a service using the Interface Mapping Toolkit, all the objects required are created automatically, complete with their relationships. However, if you add services manually to an enterprise server, you need to create the objects for them and their relationships in a certain order, as follows:

  1. Add the implementation package to the enterprise server
  2. Add one or more service listeners
  3. Add the service, and associate the listener or listeners, implementation package and request handler with it

Additions, Updates and Deletions

You can add services and implementation packages to an enterprise server, and update and delete them whether or not the enterprise server is running.

If the enterprise server is running (that is, if it has the status "Started") when you are adding services and packages, the changes are immediately reflected in the enterprise server. As long as the service is not currently responding to a client request, any updates are also accepted and take immediate effect.

You cannot delete a service, package or request handler if the resources are in use by a client request. You cannot delete a package if it is associated with a service, whether or not the service is running. If a service has operations, you can delete a service and all its operations and packages in one step, or you can delete individual operations and packages.

When you delete services, packages and request handlers, you are deleting objects in the Directory Server repository, not physical files. Every time a developer deploys a service using the Deploy tool or the imtkmake command, a new directory is created in the enterprise server's deploy directory to hold all the deployed files. If a developer redeploys a service that has already been deployed, the old deployment directory is no longer referenced, since the old service and package objects will have been deleted. You might want to delete old deployment directories from time to time.

If an enterprise server is running and you add, edit or delete resources, administration messages are sent to the enterprise server console indicating the success or otherwise of your changes.

It is possible for the Directory Server repository to become out-of-step with a live enterprise server if the Directory Server accepts updates that Enterprise Server rejects. If this happens you should stop the server and restart it to enable it to pick up the updates.

Services

A service provides access to specific business functionality.

Services that have been deployed using the Interface Mapping Toolkit always contain one or more operations. For example, if you work through the interface mapping tutorials in your Getting Started book, you create a service wmapserv with four operations, Add, Read, Next and Delete. The Enterprise Server documentation uses the term "service with operations" for services of this type.

A service that you create within Enterprise Server can contain one or more operations, depending on the name you give the service and which request handler is associated with it (if any). If you create a service with no request handler associated with it or if the name you use does not contain a valid separator, the service and the operation are one and the same. The Enterprise Server documentation uses the term "simple service" for services of this type. System services such as the Deploy service of the default enterprise server ESDEMO are simple services.

Service names can be of two forms, depending on whether or not the service contains any operations. The two forms are:

The Services Table

You can see the information held in the repository for services by clicking Details against Services in the table of servers on the Home page. The services table is shown in Figure 8-1.

Services Table

Figure 8-1: Services Table

The information is as follows:

Service display flters control how much service information you can see. These appear at the top of the services table. There are four service display filters:

Except for Service, each has three options

For example, to see service details for services of class 1, choose Some in Service Display Filters Class; to see only services that do not have a request handler associated with them, choose None in Service Display Filters Handler; to see all services choose All in all three filters that have options and leave Service blank. Use all the filters in combination to achieve the maximum control over the level of detail you see.

When you first see the Services table, all the filters that have options are set to All and the Service filter is blank.

Configuration Information

You can use the Configuration Information field on the Add Service and Edit Service pages for configuration data specific to services. The only Configuration Information settings for services are for deployment services, the special services with Service Class “MF Deployment” which are used by the Interface Mapping Toolkit to deploy Web Services and J2EE EJBs.

The [MF client] settings provide configuration for MFCC when it is creating the deployment request.

The [destination] settings are used by mfdepinst when it creates service and package objects in the Directory Server while installing a deployment package (.car file). Note that these settings are only used when deployment is done via MFCS, using the IMTK or another deployment client. If you run mfdepinst manually from the command line to install a .car file, it is not invoked for a particular deployment service, so it has no deployment service configuration to consult.

[MF client]
scheme=protocol
URL=virtual-directory-name-1/mfdeploy.exe/virtual-directory-name-2
accept=request-data-type
[destination]
listener=listener-name
server=server-name
scheme

Specifies the protocol to use for the request.

Syntax:
scheme=protocol
Parameters:
protocolSet to “http”
Properties:
Default: None.
URL

Sets the base path portion of the request URL.

Syntax:
URL=virtual-directory-name-1/mfdeploy.exe/virtual-directory-name-2
Parameters:
virtual-directory-name-1/Must correspond to a virtual directory in the listener’s configuration which is mapped to the directory containing mfdeploy.exe
virtual-directory-name-2Must correspond to a virtual directory where the new deployment directory will be created. (This directory must contain an .mfdeploy file.)
Properties:
Default: /cgi/mfdeploy.exe/uploads
Comments:

You can have multiple deployment services under a single Web listener, directing deployment packages to different locations, by creating additional virtual directories in the listener’s configuration and specifying the appropriate directory here. For more information see the section Deployment Services and Listeners in the chapter Configuration.

accept

Tells MFCC what kind of request data this service accepts.

Syntax:
accept=request-data-type
Parameters:
request-data-typeSet to “application/x-zip-compressed”
Properties:
Default: None
listener

Specifies the name of the listener which will own the new services. By default this is “Web Services”. You can set this value if you want to deploy services to a listener with a different name.

Syntax:
listener=listener-name
Properties:
Default: Web Services
Comments:

You can set this value if you want to deploy services to a listener with a different name.

server

Specifies the name of the server which will own the new services and packages. By default this is the server that the deployment service belongs to. You can set this value so that an enterprise server accepts deployment requests for services that will be deployed to a different enterprise server on the same system.

Syntax:
server=server-name
Properties:
Default: The server that the deployment service belongs to.
Comments:

You can set this value so that an enterprise server accepts deployment requests for services that will be deployed to a different enterprise server on the same system.

What You Can Do

If you have Modify permission level or higher you can:

If you have Add/Delete permission level or higher you can also:

How to...

Implementation Packages

An implementation package defines the application that provides the business functionality.

The Packages Table

You can see the information held in the repository for packages by clicking Details against Packages in the table of servers on the Home page. The packages table is shown in Figure 8-2.

Packages Table

Figure 8-2: Packages Table

The information is as follows:

What You Can Do

If you have Modify permission level or higher you can:

If you have Add/Delete permission level or higher you can also:

Outside Enterprise Server Administration, you can delete old deployment directories.

How to...

Request Handlers

A request handler is software 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. The following request handlers are provided with Enterprise Server:

The Request Handlers Table

You can see the information held in the repository for request handlers by clicking Details against Request Handlers in the table of servers on the Home page. The request handlers table is shown in Figure 8-3.

Request Handlers Table

Figure 8-3: Request Handlers Table

The information is as follows:

What You Can Do

If you have Modify permission level or higher you can:

If you have Add/Delete permission level or higher you can also:

How to...


Copyright © 2006 Micro Focus (IP) Ltd. All rights reserved.