Deploying enterprise beans—overview

A desktop Java™ bean is developed, installed, and run on a workstation. An enterprise bean, however, which will run on a server, requires an additional stage, deployment, to prepare the bean for the runtime environment and install it into the EJB server.

Enterprise beans are produced by the bean provider and customized by the application assembler. The application assembler may use a tool such as the Assembly Toolkit (ATK) (described in the CICS® Operations and Utilities Guide) to customize the ejb-jar file. The customized ejb-jar file passed to the deployer contains:

Also required is CICS-specific information, such as resource definition requirements, in either resource definition online (RDO) format (for DFHCSDUP) or CICSPlex SM Business Application Services (BAS) format (for BATCHREP).

Here's an outline of the deployment process:1
  1. A deployment tool (such as the Assembly Toolkit (ATK), described in the CICS Operations and Utilities Guide) is used to transform the ejb-jar file into a deployable JAR file, suitable for deployment. The transformed file contains the XML deployment descriptor and enterprise bean classes from the ejb-jar file, plus additional classes generated in support of the EJB container. The transformed file is stored as a deployed JAR file on the hierarchical file system (HFS) used by z/OS®.
    It is recommended that you store the deployed JAR file in the CorbaServer's deployed JAR file directory (specified by the DJARDIR option of the CORBASERVER definition). The deployed JAR file directory is also known as the “pickup” directory. When CICS scans the pickup directory, it automatically creates and installs a definition of each new or updated deployed JAR file that it finds there. CICS scans the pickup directory:
    • Automatically, when the CORBASERVER definition is installed, or
    • When instructed to by means of an explicit EXEC CICS or CEMT PERFORM CORBASERVER SCAN command, or
    • When instructed to by the resource manager for enterprise beans (otherwise known as the RM for enterprise beans), which issues a PERFORM CORBASERVER SCAN command on your behalf. (The resource manager for enterprise beans is described in the CICS Operations and Utilities Guide).
  2. CICS resource definitions are required for:
    • The CorbaServer execution environment (CORBASERVER). (The same CORBASERVER definition will be installed on each CICS AOR in the logical EJB server.)
    • TCP/IP services (for IIOP). One or more TCPIPSERVICE definitions will be installed on each CICS region in the logical EJB server.
    • Request models, to associate client IIOP requests with CICS TRANSIDs (and thus to associate bean methods with sets of execution characteristics, covering such things as security, priority, and monitoring). Request models are only required if the default TRANSID, CIRP, is unsuitable. (You may want to segregate your IIOP workload by transaction ID, for example.)
      Note: You can use the CREA CICS-supplied transaction to display the transaction IDs associated with particular beans and bean-methods in the CorbaServer. You can change the transaction IDs, apply the changes, and save the changes to new REQUESTMODEL definitions.
    • Deployed JAR files (DJARs), each of which includes the HFS filename of a deployed JAR file. If you store your deployed JAR files in the CorbaServer's “pickup” directory, DJAR definitions are created and installed automatically when the CorbaServer is installed (or when a subsequent scan takes place).
    Note: Setting up a logical EJB server contains more information about these RDO definitions.
  3. Security definitions are added to the external security manager. These specify which roles can execute particular beans and methods, and which user IDs are associated with each role.
  4. The resource definitions are installed in CICS. Installing a DJAR definition causes CICS to:
    • Copy the deployed JAR file (and the classes it contains) to a “shelf” directory on HFS. The shelf directory is where CICS keeps copies of installed deployed JAR files.
    • Read the deployed JAR from the shelf, parse its XML deployment descriptor, and store the information it contains.
    Note: If you store your deployed JAR files in the CorbaServer's “pickup” directory, DJAR definitions are installed automatically when the CorbaServer is installed (or when a subsequent scan takes place).
  5. A reference to the home interface class of each deployed bean is published in an external namespace. The namespace is accessible to clients through JNDI.

    If you specify AUTOPUBLISH(YES) on the CORBASERVER definition, the contents of a deployed JAR file are automatically published to the namespace when the DJAR definition is successfully installed into the CorbaServer. Alternatively, you can issue a PERFORM CORBASERVER PUBLISH or PERFORM DJAR PUBLISH command.

Figure 1 shows the deployment process.

Figure 1. Deploying enterprise beans into a CICS EJB server. A deployment tool is used to perform code generation on the ejb-jar file containing the bean classes. The transformed file is stored as a deployed JAR file on HFS. An RDO definition of the deployed JAR file is created and installed in CICS, together with other definitions for TCP/IP services, request models, and the CorbaServer execution environment. Security definitions are created on the external security manager.
The picture shows a CICS EJB application server. Outside the server, a cloud represents enterprise bean development. The output of enterprise bean development is an ejb-jar file, which is passed to another cloud representing deployment. The output of deployment is a deployed JAR file in an HFS directory, some security definitions in an external security manager, and some CICS resource definitions in a CSD. The resource definitions are installed into CICS. When the DJAR definition is installed, CICS reads the deployed JAR file, parses it, and copies it to its shelf directory. A reference to the home interface of each enterprise bean is published in an external namespace.
1 This simplified description of the deployment process assumes that you're using RDO rather than BAS.