InfoCenter Home >
6: Administer applications >
6.6: Tools and resources quick reference >
6.6.0: About user assistance >
6.6.0.2: Command line administration >
6.6.0.2.2: WebSphere Control Program (wscp) >
6.6.0.2.2.4: Example wscp commands, procedures, and scripts >
6.6.0.2.2.4.8: Creating an enterprise application

6.6.0.2.2.4.8: Creating an enterprise application

This section discusses the wscp operations for deploying enterprise applications and modules.

  • Administering enterprise applications describes how to install, start, and stop enterprise applications by using the wscp EnterpriseApp operations.

  • Administering modules describes how to install, start, and stop modules by using the wscp Module operations. Modules can be deployed independently of the enterprise applications into which they are packaged.

Administering enterprise applications

An enterprise application is a collection of resources (such as XML files, enterprise beans, servlets, HTML files, and JSP files) that work together to perform a business function. An application server, combined with a Web server, makes the enterprise application available to users. Enterprise applications are installed and configured as a single unit.

The wscp EnterpriseApp commands allow you to perform various operations on enterprise applications, including the following tasks:

  • Install an enterprise application from an enterprise archive (EAR) file. In addition to installing the application, you can optionally specify the default application server on which its modules run, assign security roles, specify JNDI mappings, and specify data sources for enterprise beans.

  • Start and stop instances of an enterprise application.

  • List the modules that compose an enterprise application.

  • List the nodes onto which an enterprise application is deployed.

The wscp EnterpriseApp install operation installs an enterprise application from an EAR file. The syntax of this operation is:

EnterpriseApp install nodeName earFileName [other options]

where:

  • nodeName -- The fully-qualified name of the WebSphere Application Server node onto which the application is being installed.

  • earFileName-- The full path name of the EAR file containing the application.

  • other options-- Represents the following enterprise application attributes that can optionally be set at installation:

    • -defappserver appServName-- Installs all modules are installed on the specified application server. Specify the fully-qualified name of the application server onto which the enterprise application is installed, such as /Node:DS1/ApplicationServer:DSServ/.
      Note:
      You can specify either this option or the -moduleappservers option, but not both.

    • -moduleappservers {moduleName appServName}-- Allows enterprise application modules to be installed on different application servers. You must specify a Tcl list of module URI-application server pairs, including the fully-qualified name of the application server (for example, {shoppingCart.JAR /Node:DS1/ApplicationServer:DSAux/}).
      Note:
      You can specify either this option or the -defappserver option, but not both.

    • -appname applicationName -- The name of the enterprise application.

    • -userroles {roleName userName}-- Defines J2EE security role to user mappings. Specify a Tcl list of role name and user name pairs, such as {{Manager Mary}}.

    • -grouproles {roleName groupName}-- Defines J2EE security role to user group mappings. Specify a Tcl list of role name and group name pairs, such as {{Manager AdminGroup}}.

    • -specialroles {roleName specialGroupName}-- Defines J2EE security role to special group mappings. (Special groups are the predefined user groups Everyone and AllAuthenticatedUsers.) Specify a Tcl list of role name and special group name pairs, such as {{Manager Everyone}}.

    • -runasroles {roleName identity password}-- Defines the security roles and execution identities that enterprise bean methods run under in the enterprise application. A password must also be specified, for example {Manager Mary marypwd}.

    • -resourcereferences resourceRefName Specifies how module resource references are mapped to JNDI names. The type of mapping depends on the type of module, but the mapping is always specified as a Tcl list of resource reference-JNDI name pairs.

      • Enterprise bean resource references are mapped as { module_URI::bean_name::resource_ref_name JNDIName}

      • Web archive (WAR) resource references are mapped as {module_URI::resource_ref_name}. The references in WAR modules do not require bean names.

    • -ejbnames {module_URI::bean_name JNDIName}-- Specifies the JNDI names for enterprise beans as a Tcl list of pairs, where module_URI is the name of the JAR file containing the enterprise bean module. This option is only valid for JAR modules.

    • -modvirtualhosts {module_URI virtual_host_name}-- Specifies the virtual host mapping for a WAR modules as a Tcl list of pairs, where module_URI is the name of the WAR file containing the web archive module. Enter the virtual host alias for virtual_host_name (such as default_host) not the fully-qualified wscp virtual host name (such as /VirtualHost:default_host/)

    • -ejbreferences--Specifies the JNDI names for enterprise bean references. The type of mapping depends on the type of module, but the mapping is always specified as a Tcl list of enterprise bean reference-JNDI name pairs.

      • Enterprise bean references are of the form { module_URI::bean_name::ejb_ref_name JNDIName}

      • Web archive references are of the form {module_URI::ejb_ref_name}. The references in WAR modules do not require bean names.

    • -ejbdatasources {module_URI JNDI_name}--Sets the JNDI name of the default data source for JAR files as a Tcl list of pairs, where module_URI is the name of the JAR file. This option is only valid for JAR files.

    • -cmpdatasources {module_URI::bean_name JNDIName}--Specifies the data source for entity beans with container-managed persistence (CMP) as a Tcl list of pairs, where module_URI is the name of the JAR file.

    • -redeploy--Forces the archive to be installed, regardless of whether it has been deployed before.

    • -dbname name --Specifies the name of the enterprise application database. It can only be used when an enterprise application is first installed or when an application is reinstalled using the -redeploy option.

    • -schemaname schema -- Specifies the database schema to be used in the enterprise application database. It can only be used when an enterprise application is first installed or when an application is reinstalled using the -redeploy option.

    • -dbtype type -- Specifies the type of application database, where type is one of the following supported databases:

      • DB2UDBWIN_V72

      • DB2UDBOS390_V6

      • DB2UDBAS400_V4R5

      • INFORMIX_V92

      • MSSQLSERVER_V7

      • ORACLE_V8

      • SQL92

      • SQL99

      • SYBASE_V1192

      • MYSQL_V323
      It can only be used when an enterprise application is first installed or when an application is reinstalled using the -redeploy option.

To view a complete list of enterprise application attributes, use the EnterpriseApp attributes command. See Querying (displaying) attributes for more information on displaying object attributes.

The following command example shows how to install an enterprise application. The node under which the application runs is DS1; the default application server under which its modules are installed is DSserv; and the security role mappings assign all authenticated users to the Client role and the site administrator to the Administrator role.

wscp> EnterpriseApp install /Node:DS1/ C:/drugstore/DrugStoreApp.ear
-defappserver /Node:DS1/ApplicationServer:DSserv/
-userroles {{Administrator SiteAdmin} {Supervisor Mary}} -specialroles {Client AllAuthenticatedUsers}

The following command example starts an instance of the DrugStore enterprise application, then waits 60 seconds to see if it really started. If the application does not start within this time period, the EnterpriseApp start operation is assumed to have failed.

wscp> EnterpriseApp start /EnterpriseApp:DrugStore/ -wait 60

The following command example stops an instance of the DrugStore enterprise application:

wscp> EnterpriseApp stop /EnterpriseApp:DrugStore/

The following command example lists the modules that comprise an enterprise application:

wscp> EnterpriseApp listmodules /EnterpriseApp:DrugStore/
/Node:DS1/ApplicationServer:DSserv/Module:ShoppingCart/
/Node:DS1/ApplicationServer:DSserv/Module:StoreFront/
/Node:DS1/ApplicationServer:DSserv/Module:Accounts/
/Node:DS2/ApplicationServer:DSserv/Module:InventoryMgr/

The following command example lists the nodes onto which an enterprise application is deployed:

wscp> EnterpriseApp listnodes /EnterpriseApp:DrugStore/
/Node:DS1/ /Node:DS2/

Several Tcl scripts for installing enterprise applications are available. Each installs one of the sample applications provided with WebSphere Application Server.

  • t1.tcl installs jmsample.ear

  • t2.tcl installs perfServletApp.ear

  • t3.tcl installs sampleApp.ear

  • t4.tcl installs Samples.ear

  • t5.tcl installs ServletCacheMonitor.ear

  • t6.tcl installs soapsamples.ear

  • t7.tcl installs TradeSample.ear

The following example shows the script t1, which is used to install the sample enterprise application jmsample.

set mynode xxxx

set instdir i:/WebSphere/AppServer/installableApps/

set earfile jmsample.ear

set appname "MailSampleApp"

set sname "Default Server"

set mailth "AHost"

set mailSessName "DefaultMailSession"

set vhostName "default_host"



# create prerequiste objects

#

# first, the MailSession

set mailtransportattr [list MailTransportHost $mailth]

set attributelist [list $mailtransportattr]



MailSession create /MailSession:$mailSessName/ -attribute $attributelist



# next, the virtual host

set aliaslist [list *:80 *:9080]

set aliasattr [list AliasList $aliaslist]

set attributelist [list $aliasattr]



VirtualHost create /VirtualHost:$vhostName/ -attribute $attributelist



# Now install the application

#

#     construct -modvirtualhosts option

set modhost1 [list mtcomps.war $vhostName]

set modhosts  [list $modhost1]



#     construct -resourcereferences option

set resref1 [list mtcomps.war::mail/MailSession9 mail/$mailSessName]

set resref2 [list deplmtest.jar::MailEJBObject::mail/MailSession9 mail/$mailSessName]

set resrefs [list $resref1 $resref2]





EnterpriseApp install /Node:$mynode/ $instdir$earfile -appname $appname -defappserver /Node:$mynode/ApplicationServer:$sname/ -modvirtualhosts $modhosts -resourcereferences $resrefs

This script (and the others listed in this section) is available in 6.6.0.2.2.5: Sample Tcl procedures and scripts.


Administering modules

The resources that compose an enterprise application are grouped according to function into modules. Enterprise applications can contain three types of modules:

  • Enterprise JavaBeans (EJB) modules, which contain Java class files for enterprise beans, Java class files for functionality that is not included with the J2EE platform, and an EJB deployment descriptor.

  • Web modules, which contain Java class files for servlets and applets; JSP files and their helper classes; static HTML, sound, image, video, and other content files; and a Web deployment descriptor.

  • Application client modules, which contain the Java classes that implement the client and an application deployment descriptor.

The wscp Module operations allow you to deploy modules independently from enterprise applications. Application client and EJB modules are installed from Java archive (JAR) files; Web modules are installed from Web archive (WAR) files. When you install a module, wscp actually generates a simple EAR file with the specified JAR or WAR file as its only module. It then installs the EAR file. You can optionally assign such things as security roles, specify JNDI mappings, and specify data sources for enterprise beans.

The wscp Module install operation installs an enterprise application module. The syntax of this operation is:

Module install nodeName module_name-moduleappservers module_URI appServName [other options]

where:

  • nodeName -- The fully-qualified name of the WebSphere Application Server node onto which the module is being installed.

  • module_name-- The full path name of the file containing the module.

  • -moduleappservers {module_URI appServName}-- Specifies the application server onto which a modules is installed. Specify the file name of the JAR or WAR file and the fully-qualified name of the application server, such as {shoppingCart.JAR /Node:DS1/ApplicationServer:DSAux/}.

  • other options-- Represents the following module attributes that can optionally be set at installation:

    • --contextroot contextroot--The context root for a WAR file.

    • -appname applicationName -- The name of the enterprise application to which the module belongs.

    • -userroles {roleName userName}-- Defines J2EE security role to user mappings. Specify a Tcl list of role name and user name pairs, such as {{Manager Mary}}.

    • -grouproles {roleName groupName}-- Defines J2EE security role to user group mappings. Specify a Tcl list of role name and group name pairs, such as {{Manager AdminGroup}}.

    • -specialroles {roleName specialGroupName}-- Defines J2EE security role to special group mappings. (Special groups are the predefined user groups Everyone and AllAuthenticatedUsers.) Specify a Tcl list of role name and special group name pairs, such as {{Manager Everyone}}.

    • -runasroles {roleName identity password}-- Defines the security roles and execution identities that enterprise bean methods run under in the enterprise application. A password must also be specified, for example {Manager Mary marypwd}.

    • -resourcereferences resourceRefName Specifies how module resource references are mapped to JNDI names. The type of mapping depends on the type of module, but the mapping is always specified as a Tcl list of resource reference-JNDI name pairs.

      • Enterprise bean resource references are mapped as { module_URI::bean_name::resource_ref_name JNDIName}

      • Web archive (WAR) resource references are mapped as {module_URI::resource_ref_name}. The references in WAR modules do not require bean names.

    • -ejbnames {module_URI::bean_name JNDIName}-- Specifies the JNDI names for enterprise beans as a Tcl list of pairs, where module_URI is the name of the JAR file containing the enterprise bean module. This option is only valid for JAR modules.

    • -ejbreferences--Specifies the JNDI names for enterprise bean references. The type of mapping depends on the type of module, but the mapping is always specified as a Tcl list of enterprise bean reference-JNDI name pairs.

      • Enterprise bean references are of the form { module_URI::bean_name::ejb_ref_name JNDIName}

      • Web archive references are of the form {module_URI::ejb_ref_name}. The references in WAR modules do not require bean names.

    • -ejbdatasources {module_URI JNDI_name}--Sets the JNDI name of the default data source for JAR files as a Tcl list of pairs, where module_URI is the name of the JAR file. This option is only valid for JAR files.

    • -cmpdatasources {module_URI::bean_name JNDIName}--Specifies the data source for entity beans with container-managed persistence (CMP) as a Tcl list of pairs, where module_URI is the name of the JAR file.

    • -dbname name --Specifies the name of the database.

    • -schemaname schema -- Specifies the database schema to be used.

    • -dbtype type -- Specifies the type of database, where type is one of the following supported databases:

      • DB2UDBWIN_V72

      • DB2UDBOS390_V6

      • DB2UDBAS400_V4R5

      • INFORMIX_V92

      • MSSQLSERVER_V7

      • ORACLE_V8

      • SQL92

      • SQL99

      • SYBASE_V1192

      • MYSQL_V323

  • -defappserver appServName-- Installs all modules are installed on the specified application server. Specify the fully-qualified name of the application server onto which the enterprise application is installed, such as /Node:DS1/ApplicationServer:DSServ/.
    Note:
    You can specify either this option or the -moduleappservers option, but not both.

  • -moduleappservers {moduleName appServName}-- Allows enterprise application modules to be installed on different application servers. You must specify a Tcl list of module URI-application server pairs, including the fully-qualified name of the application server (for example, {shoppingCart.JAR /Node:DS1/ApplicationServer:DSAux/}).
    Note:
    You can specify either this option or the -defappserver option, but not both.

  • -appname applicationName -- The name of the enterprise application.

To view a complete list of enterprise application attributes, use the EnterpriseApp attributes command. See Querying (displaying) attributes for more information on displaying object attributes.

The following command example shows how to install a Web module. The module type and active module type are web; the relative URI of the WAR file containing the module is storefront.war; the context root is /WebApp.

wscp> Module install /Node:DS1/ C:/storefront.war -contextroot /WebApp
Go to previous article: 6.6.0.2.2.4.7: Creating and installing drivers and data sources Go to next article: 6.6.0.2.2.4.10: Configuring server groups and clones

 

 
Go to previous article: 6.6.0.2.2.4.7: Creating and installing drivers and data sources Go to next article: 6.6.0.2.2.4.10: Configuring server groups and clones