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:
- The java classes for one or more enterprise beans.
- A single deployment descriptor, written in XML, which describes the characteristics
of each of the enterprise beans, such as:
- Transaction attributes
- Environment properties
- Security levels
- Application assembly information.
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 - 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).
- 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).
- 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.
- 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).
- 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.