SSL(Secure Socket Layer)

What is SSL?
SSL is a protocol that provides privacy and integrity between two communicating applications using TCP/IP. The data going back and forth between client and server is encrypted using a symmetric algorithm.

A public-key algorithm (RSA) is used for the exchange of the encryption keys and for digital signatures. Public key cryptography defines an algorithm that uses two keys, each of which may be used to encrypt a message. If one key is used to encrypt a message, the other must be used to decrypt it. This makes it possible to receive secure messages by simply publishing one key (the public key) and keeping the other undisclosed (the private key).


Fig: Client/server authentication

Key file versus trust file

• The SSL implementation used by the WebSphere® Application Server stores personal certificates in an SSL key file and signer certificates in a trust file.
• A key file contains a collection of certificates, each one of which may be presented during an SSL connection initiation in order to prove identity.


• A trust file contains a collection of certificates that are considered trustworthy and against which the presented certificate will be matched during an SSL connection initiation in order to assure identity.
• A key store contains the personal certificates that can be used as the identity for the SSL end point referencing the key store. If more than one certificate is present, a certificate alias on the SSL configuration specifies one of the personal certificates. When an SSL connection is made (on either the client or the server side), certificates may be exchanged. The personal certificate referenced by the SSL configuration and stored in the key store is the certificate that will be used.
• A personal certificate represents the identity of the end point and contains a public and private key for signing/encrypting data.
• A trust store contains the signer certificates which this end point trusts when either making connections (from an outbound end point) or accepting connections (for an inbound end point).
• A signer certificate represents a certificate and public key associated with some personal certificate. The purpose of the signer certificate is to verify personal certificates. By accepting the signer certificate into an end point's trust store, you are allowing the owner of the private key to establish connections with this end point; that is, the signer certificate explicitly trusts connections made to or by the owner of the associated personal certificate. The signer certificate is typically made completely public by the owner of the personal certificate, but it's up to the receiving entity to determine if it is a trusted signer prior to adding it to the trust store.

Some of the security features provided by SSL are:

Data encryption to prevent the exposure of sensitive information while data flows across the wire.
Data signing to prevent unauthorized modification of data while data flows across the wire.
Client and server authentication to ensure that you talk to the appropriate person or machine.

JMX Architecture

Overview of JMX:

JMX is the Java standard for managing an application's resources. The management architecture defined by JMX is divided into three levels:

• The bottom level is management instrumentation. Each manageable resource is described by an interface that specifies the attributes it has, the operations it supports, and the notifications it sends. This resource is a managed bean (MBean).
  
• The middle level is the management agent. Each managed process contains a JMX agent that includes an MBean server, which provides a registry and access point for MBeans. Management clients must use the MBean server to access the registered MBeans.
  
• The top level of the architecture is identified, but undefined in the current level of the JMX specification. It is the distributed services level, and its role is to facilitate remote access to JMX agents. This task is accomplished through connectors, which provide a protocol-independent, location-transparent, client-side interface to the MBean server (for example, an RMI connector), or protocol adapters, which provide protocol-specific, server-side access to the MBean server (for example, an HTTP adapter).

Fig: JMX Architecture

Fig: Communication of AdminClient In Appl Server

Cell Structure in Network deployment package

SSL(Secure Socket Layer)

ScreenShots and Videos will be in the Next posts

SSL provides secure communications between the Internet web client and the Administrative server.

You must have a digital certificate, keystore file, and truststore file to fully implement SSL communications key store file is used to setup secure MQ channels to the message flow servertruststore: set SSl security for the websphere application server

digital certificates are issued by trusted parties called certificate authoritiesYou can create self signed certificate if you do not have a certificate issued by a CADigital certificate

A digital certificate reveals information about its owner, including their identity. During the initialization of an SSL connection, the server must present its certificate to the client for the client to determine the server identity.

Keystore file

The keystore file is a key database file that contains both public keys and private keys. Public keys are stored as signer certificates while private keys are stored in the personal certificates. The keys are used for a variety of purposes, including authentication and data integrity. You can use both the key management utility (iKeyman) and the keytool utility to create.

Truststore file

A truststore file is a key database file that contains the public keys for target servers. The public key is stored as a signer certificate. If the target uses a self-signed certificate, extract the public certificate from the server keystore file. Add the extracted certificate into the truststore file as a signer certificate. For a commercial certificate authority (CA), the CA root certificate is added. The truststore file can be a more publicly accessible key database file that contains all the trusted certificates.

Start the IBM Key Management application c:\Program Files\IBM\gsk7\bin\gsk7ikm.exeNote: The JAVA_HOME variable must be set. The default location is C:\Program Files\WebSphere\AppServer\java.

For example:

set JAVA_HOME=C:\Program Files\WebSphere\AppServer\java
To Create a key file and self-signed certificate:

Select KeyDatabaseFile > New and enter the followingSelect KeyDatabaseFile > New and enter the following:

Table 1. KeyDatabaseFile values File Name HCNAdminServerKeyFile.jks Location WAS_HOME\etc\
Click OK.

Enter the Key File Password as defined in Table 1 table.
Click OK.

Under Key database content select Personal Certificates.

Click New self-signed.
Enter the following:
Table 2. Administrative server Key file properties Propery Value
Key Label HCN Admin
Common Name Administrative server host name
Example: hcnadmin.ibm.com

Organization Enter an organization name.
Validity Period Enter 7300 days, this is the maximum.
Country or Region Change if default not appropriate.

Create Trust File HCNAdminServerTrustFile.jks using the same values as in step 2. Place HCNAdminServerTrustFile.jks in WAS_HOME\etc.
Start IBM WebSphere Application Server Base V5.1.1 Administration Console.
Click Security > SSL > New Enter the following values:
Table 1. SSL Values Property Value

Alias HCNAdminSSLSettings Key File Name ${USER_INSTALL_ROOT}/etc/HCNAdminServerKeyFile.jks
Key File Password password
Trust File Name ${USER_INSTALL_ROOT}/etc/HCNAdminServerTrustFile.jks
Trust File Password password


${USER_INSTALL_ROOT} expands to the WebSphere Application Server installation path on your machine. It is defined in the IBM WebSphere Application Server Administrative Console.
Click OK
Click Servers > Application Servers > server1 > Web Container > HTTP Transports
Click * next to SSL port 443
Select the ADMIN_SERVER_NAME/HCNAdminSSLSettings.
Click OK > Save > Save.
Restart WebSphere.
Test the Administrative server main page (https://ADMIN_SERVER_NAME/hcn/index.html).

Wsadmin CMD(ADMINCONTROL)

Example: Identifying running objects

In the WebSphere Application Server, MBeans represent running objects. You can interrogate the MBean server to see the objects it contains. Use the AdminControl object to interact with running MBeans.

• Use the queryNames command to see running MBean objects. For example:

$AdminControl queryNames *

This command returns a list of all MBean types. Depending on the server to which your scripting client attaches, this list can contain MBeans that run on different servers:

• If the client attaches to a stand-alone WebSphere Application Server, the list contains MBeans that run on that server.
• If the client attaches to a node agent, the list contains MBeans that run in the node agent and MBeans that run on all application servers on that node.
• If the client attaches to a deployment manager, the list contains MBeans that run in the deployment manager, all of the node agents communicating with that deployment manager, and all application servers on the nodes served by those node agents.

· The list that the queryNames command returns is a string representation of JMX ObjectName objects. For example:

WebSphere:cell=MyCell,name=TraceService,mbeanIdentifier=TraceService,
type=TraceService,node=MyNode,process=server1

This example represents a TraceServer object that runs in server1 on MyNode.

• The single queryNames argument represents the ObjectName object for which you are searching. The asterisk ("*") in the example means return all objects, but it is possible to be more specific. As shown in the example, ObjectName has two parts: a domain, and a list of key properties. For MBeans created by the WebSphere Application Server, the domain is WebSphere. If you do not specify a domain when you invoke queryNames, the scripting client assumes the domain is WebSphere. This means that the first example query above is equivalent to:

$AdminControl queryNames WebSphere:*

• WebSphere Application Server includes the following key properties for the ObjectName object:
• name
• type
• cell
• node
• process mbeanIdentifier

These key properties are common. There are other key properties that exist. You can use any of these key properties to narrow the scope of the queryNames command. For example:

$AdminControl queryNames WebSphere:type=Server,node=myNode,*

This example returns a list of all MBeans that represent server objects running the node myNode. The, * at the end of the ObjectName object is a JMX wildcard designation. For example, if you enter the following:

$AdminControl queryNames WebSphere:type=Server,node=myNode

you get an empty list back because the argument to queryNames is not a wildcard. There is no Server MBean running that has exactly these key properties and no others.

• If you want to see all the MBeans representing applications running on a particular node, invoke the following example:

$AdminControl queryNames WebSphere:type=Application,node=myNode,*

Example: Turning traces on and off in a server process with the wsadmin tool

The following example turns on tracing in a server process:

• Identify the object name for the TraceService MBean running in the process:

$AdminControl completeObjectName type=Server,name=server1,*

• Obtain the name of the object and set it to a variable:

set ts [$AdminControl completeObjectName type=TraceService,process=server1,*]

• Turn on traces for the server:

$AdminControl setAttribute $ts traceSpecification com.ibm.*=all=enabled

Example: Dumping threads in a server process

Use the AdminControl object to dump the Java threads of a running server.

• For example, in Jacl:

set jvm [$AdminControl completeObjectName type=JVM,process=server1,*]

$AdminControl invoke $jvm dumpThreads

This example produces a Java core file. You can use this file for problem determination.

Example: Starting a server using wsadmin

The following example starts an application server with the node specified.

• The following command starts server1 in mynode node:

$AdminControl startServer server1 mynode

Example output:

WASX7319I: The serverStartupSyncEnabled attribute is set to false. A startwill be attempted for server "server1" but the configuration information fornode "mynode" may not be current.WASX7262I: Start completed for server "server1" on node "mynode"

• The startServer command has several command syntax options. If you have Network Deployment installation, you have to use one of following:

$AdminControl startServer serverName nodeName

$AdminControl startServer serverName nodeName waitTime

• If you have an application server base installation, you can use the following syntax in addition to the previous syntax:

$AdminControl startServer serverName

$AdminControl startServer serverName waitTime


Example: Stopping a server using wsadmin

The following example stops an application server with the node specified.

• The following command stops server1 in node mynode.

$AdminControl stopServer server1 mynode

Example output:

WASX7337I: Invoked stop for server "server1" Waiting for stop completion.
WASX7264I: Stop completed for server "server1" on node "mynode"

• The stop command has serveral command syntaxes.

If you have Network Deployment installation, use the one of following command syntax:

$AdminControl stopServer serverName nodeName

$AdminControl stopServer serverName nodeName immediate

If you have application server base installation, you can use the following syntax, in addition to the previous syntax:

$AdminControl stopServer serverName

$AdminControl stopServer serverName immediate

Example: Querying the server state using the wsadmin tool

The following example queries the server state.

• Identify the server and assign it to the server variable.

set server [$AdminControl completeObjectName cell=mycell,node=mynode,name=server1,type=Server,*]

This command returns the server MBean that matches the partial object name string.

Example output:

WebSphere:cell=mycell,name=server1,mbeanIdentifier=server.xml#Server_1,
type=Server,node=mynode,process=server1,processType=ManagedProcess

• Query for the state attribute.

$AdminControl getAttribute $server state

The getAttribute command returns the value of a single attribute.

Example output:
STARTED

Example: Starting a listener port using wsadmin

The following example starts a listener port on an application server.

• Identify the listener port MBeans for the application server and assign it to the lPorts variable.

set lPorts [$AdminControl queryNames type=ListenerPort,cell=mycell,node=mynode,process=server1,*]

This command returns a list of listener port MBeans.

Example output: WebSphere:cell=mycell,name=ListenerPort,mbeanIdentifier=server.xml#ListenerPort_1,

type=ListenerPort,node=mynode,process=server1

WebSphere:cell=mycell,name=listenerPort,mbeanIdentifier=ListenerPort,type=server.xml#ListenerPort_2,

node=mynode,process=server1

• Start the listener port if it is not started with the following example:·

foreach lPort $lPorts

{ set state [$AdminControl getAttribute $lport started]

if {$state == "false"} {

$AdminControl invoke $lPort start

}

}

This piece of Jacl code loops through the listener port MBeans. For each listener port MBean, get the attribute value for the started attribute. If the attribute value is set to false, then start the listener port by invoking the start operation on the MBean.

Example: Testing data source connection using wsadmin

The following example tests a dataSource, to ensure a connection to the database.

• Identify the DataSourceCfgHelper MBean and assign it to the dshelper variable.

set dshelper [$AdminControl queryNames type=DataSourceCfgHelper,process=server1*]

Example output:

WebSphere:cell=mycell,name=DataSourceCfgHelper,mbeanIdentifier=DataSourceCfgHelper,

type=DataSourceCfgHelper,node=mynode,process=server1

• Test the connection.

$AdminControl invoke $dshelper testConnectionToDataSource "COM.ibm.db2.jdbc.DB2XADataSource dbuser1 dbpwd1 {{databaseName jtest1}} c:/sqllib/java12/db \"\" \"\""

This example command invokes the testConnectionToDataSource operation on the MBean, passing in the classname, userid, password, database name, JDBC driver class path, language, and country.

Example output:

DSRA8025I: Successfully connected to DataSource

Example: Starting an application using wsadmin

The following example starts an application:

• Identify the application manager MBean for the server where the application resides and assign it the appManager variable.

set appManager [$AdminControl queryNames cell=mycell,node=mynode,type=ApplicationManager,process=server1,*]

This command returns the application manager MBean.

Example output:

WebSphere:cell=mycell,name=ApplicationManager,mbeanIdentifier=ApplicationManager,

type=ApplicationManager,node=mynode,process=server1

• Start the application.

$AdminControl invoke $appManager startApplication myApplication

This command invokes the startApplication operation on the MBean, passing in the application name to start.

Example: Stopping running applications on a server using wsadmin

The following example stops all running applications on a server:

• Identify the application manager MBean for the server where the application resides, and assign it to the appManager variable.

set appManager [$AdminControl queryNames cell=mycell,node=mynode,type=ApplicationManager,process=server1,*]

This command returns the application manager MBean.

Example output: WebSphere:cell=mycell,name=ApplicationManager,mbeanIdentifier=ApplicationManager,

type=ApplicationManager,node=mynode,process=server1

• Query the running applications belonging to this server and assign the result to the apps variable.

set apps [$AdminControl queryNames cell=mycell,node=mynode,type=Application,process=server1,*]

This command returns a list of application MBeans.
Example output:

WebSphere:cell=mycell,name=adminconsole,mbeanIdentifier=deployment.xml#ApplicationDeployment_1,

type=Application,node=mynode,Server=server1,process=server1,J2EEName=adminconsole

WebSphere:cell=mycell,name=filetransfer,mbeanIdentifier=deployment.xml#ApplicationDeployment_1,

type=Application,node=mynode,Server=server1,process=server1,J2EEName=filetransfer

• Stop all the running applications.

foreach app $apps

{

set appName [$AdminControl getAttribute $app name]

$AdminControl invoke $appManager stopApplication $appName

}

This command stops all the running applications by invoking the stopApplication operation on the MBean, passing in the application name to stop.

Example: Querying application state using wsadmin

The following examples queries for the presence of Application MBean to find out whether the application is running.

$AdminControl completeObjectName type=Application,name=myApplication,*

If myApplication is running, then there should be an MBean created for it. Otherwise, the command returns nothing. If myApplication is running,
the following is the example output:

WebSphere:cell=mycell,name=myApplication,mbeanIdentifier=cells/mycell/applications/myApplication.ear/deployments/myApplication/deployment.xml#ApplicationDeployment_1,
type=Application,node=mynode,Server=dmgr,process=dmgr,J2EEName=myApplication

Example: Updating the Web server plug-in configuration files using wsadmin

This examples regenerates the web serer plugin configuration file.

• Identify the web server plugin configuraiton file generator MBean and assign it to the pluginGen variable.

EX:
set pluginGen [$AdminControl completeObjectName type=PluginCfgGenerator,*]

Example output:
WebSphere:cell=pongoNetwork,name=PluginCfgGenerator,
mbeanIdentifier=PluginCfgGenerator,type=PluginCfgGenerator,node=pongoManager,
process=dmgr

• Generate the updated plugin configuration file.

EX:

$AdminControl invoke $pluginGen generate "c:/WebSphere/DeploymentManager c:/WebSphere/DeploymentManager/config mycell null null plugin-cfg.xml"

This example command assumes a Windows system install. It invokes the generate operation on the MBean, passing in the install root directory, configuration root directory, cell name, node name, server name, and output file name. To pass in null as the value of an argument, enter null as given in the example. This is provided for operation that allows null as the value of its argument and processes null differently from an empty string. In this example, both node and server are set to null. The generate operation generates plugin configuration for all the nodes and servers resided in the cell. The output file plugin-cfg.xml is created in the config root directory.

You can modify this example command to generate plugin configuration for a particular node or server by specifying the node and server names.

Sample Wsadmin Commands

wasadmin
----------
wasadmin>$AdminConfig list servers
Wasadmin>$AdminApp install c:\plantsWebsphere
wasadmin>$AdminControl get port
Wasadmin>$Adminconfig save
wasadmin>$AdminControl trace com.ibm.*=all=enable
wasadmin>$AdminControl trace com.ibm.*=all=disable
wasadmin>$AdminControl stopServer server1
Wasadmin>$Admincontrol startServr server1
Listing installed application

wasadmin-ApplicationManagement
------------------------------------
$AdminApp listModules DefaultApplicatons -server
Export an enterprise application to a location of your choice$AdminApp export app1 c:/mystuff/exported.ear
$AdminApp exportDDL app1 c:/mystuff

wasadmin-Application configurations
-----------------------------------
$AdminConfig listTemplates JDBCProvider
$AdminConfig listTemplates JDBCProvider DB2


listing configations objects
--------------------------
$Adminconfig list server $AdminConfig attributes Node

wasadmin-$AdminTask createApplicationServer -interactive

Wsadmin Commands(ADMINAPP)

Example: Listing the modules in an installed application
Use the AdminApp object listModules command to list the modules in an installed application. For example, invoke the following command interactively in a script, or use wsadmin -c from an operating system command prompt:$AdminApp listModules DefaultApplication -server
This example produces the following output:wsadmin>$AdminApp listModules DefaultApplication -serverDefaultApplication#IncCMP11.jar+META-INF/ejb-jar.xml#WebSphere:cell=mycell,node=mynode,server=myserverDefaultApplication#DefaultWebApplication.war+WEB-INF/web.xml#WebSphere:cell=mycell,node=mynode,server=myserver

Example: Obtaining task information while installing applications
The installInteractive command of the AdminApp object prompts you through a series of tasks when you install an application. You are presented with the title of the task, a description of the task, and the current contents of the task that you can modify.
· Use the install command instead of the installInteractive command, provide updates for each task, but you must provide all of the information on the command line. The task name specifies each task and the information you need to update the task. You can treat the task information as a two-dimensional array of string data. For example:-taskname {{item1a item2a item3a} {item1b item2b item3b} ...}
This example is a linear representation of rows and columns, where {item1a item2a item3a} represents the first row, and each row for the task name has three columns.
The number and type of the columns in this list depend on the task you specify.
· Obtain information about the data needed for each task using the taskInfo command of the AdminApp object. For example, there is a task called MapWebModToVH used to map Web modules to virtual hosts. To specify this task as part of the option string on the command line, enter the following:-MapWebModToVH {{"JavaMail Sample WebApp" mtcomps.war,WEB-INF/web.xml default_host}}
Using the taskInfo command, you can see which of the items you can change for a task. Supply the columns for each row you modify, and the columns that you are not allowed to change must match one of the existing rows. In this case, taskInfo tells you that there are three items in each row, called webModule, uri, and virtualHost and the current column values for every row.
· Obtain help while creating complex installation commands, by using a feature of the installInteractive command. Install the application interactively once and specify the updates that you need. Then look for message WASX7278I in the output log for the wsadmin tool. You can cut and paste the data in this message into a script, and modify it. For example: · WASX7278I: Generated command line: install c:/websphere/appserver/installableapps/jmsample.ear {-BindJndiForEJBNonMessageBinding {{deplmtest.jar MailEJBObject deplmtest.jar,META-INF/ejb-jar.xml ejb/JMSampEJB1 }} -MapResRefToEJB {{deplmtest.jar MailEJBObject deplmtest.jar,META-INF/ejb-jar.xml mail/MailSession9 javax.mail.Session mail/DefaultMailSessionX } {"JavaMail Sample WebApp" mtcomps.war,WEB-INF/web.xml mail/MailSession9 javax.mail.Session mail/DefaultMailSessionY }} -MapWebModToVH {{"JavaMail Sample WebApp" mtcomps.war,WEB-INF/web.xml newhost }} -nopreCompileJSPs -novalidateApp -installed.ear.destination c:/mylocation -distributeApp -nouseMetaDataFromBinary}

Example: Identifying supported tasks and options for an Enterprise Archive file
The AdminApp object install command takes a set of options and tasks. The following examples use the AdminApp object to obtain a list of supported tasks and options for an Enterprise Archive (EAR) file:
· To identify supported options and tasks, use the AdminApp object options command:$AdminApp options c:/MyStuff/myapp1.ear
This command displays a list of tasks and options.
· To identify supported options only, use the following command:$AdminApp options
· To learn more about any of the tasks or options, use the AdminApp object help command. For example:$AdminApp help deployejb

Example: Configuring applications for session management using the wsadmin tool
You can use the AdminApp object to set configurations in an application. Some configuration settings are not available through the AdminApp object. This example uses the AdminConfig object to configure session manager for the application.
· Identify the deployment configuration object for the application and assign it to the deployment variable:set deployment [$AdminConfig getid /Deployment:myApp/]
Example output: myApp(cells/mycell/applications/myApp.ear/deployments/myApp:deployment.xml#Deployment_1)
· Retrieve the applicaton deployment and assign it to the appDeploy variable:set appDeploy [$AdminConfig showAttribute $deployment deployedObject]
Example output: (cells/mycell/applications/myApp.ear/deployments/myApp:deployment.xml#ApplicationDeployment_1)
· To obtain a list of attributes you can set for session manager, use the attributes command:$AdminConfig attributes SessionManager
Example output: "accessSessionOnTimeout Boolean""allowSerializedSessionAccess Boolean""context ServiceContext@""defaultCookieSettings Cookie""enable Boolean""enableCookies Boolean""enableProtocolSwitchRewriting Boolean""enableSSLTracking Boolean""enableSecurityIntegration Boolean""enableUrlRewriting Boolean""maxWaitTime Integer""properties Property(TypedProperty)*""sessionDRSPersistence DRSSettings""sessionDatabasePersistence SessionDatabasePersistence""sessionPersistenceMode ENUM(DATABASE, DATA_REPLICATION, NONE)""tuningParams TuningParams"
· Set up the attributes for the session manager:· set attr1 [list enableSecurityIntegration true]· set attr2 [list maxWaitTime 30]· set attr3 [list sessionPersistenceMode NONE]· set attrs [list $attr1 $attr2 $attr3]· set sessionMgr [list sessionManagement $attrs]
This example sets three top level attributes in the session manager. You can modify the example to set other attributes of session manager including the nested attributes in Cookie, DRSSettings, SessionDataPersistence, and TuningParms object types. To list the attributes for those object types, use the attribute command in AdminConfig object.
Example output: sessionManagement {{enableSecurityIntegration true} {maxWaitTime 30} {sessionPersistenceMode NONE}}
· Create the session manager for the application:$AdminConfig create ApplicationConfig $appDeploy [list $sessionMgr]
Example output: (cells/mycell/applications/myApp.ear/deployments/myApp:deployment.xml#ApplicationConfig_1)
· Save the changes with the following command:$AdminConfig save

Example: Configuring applications for session management in Web modules using the wsadmin tool
You can use the AdminApp object to set configurations in an application. Some configuration settings are not available through the AdminApp object. This example uses the AdminConfig object to configure session manager for Web module in the application.
· Identify the deployment configuration object for the application and assign it to the deployment variable:set deployment [$AdminConfig getid /Deployment:myApp/]
Example output: myApp(cells/mycell/applications/myApp.ear/deployments/myApp:deployment.xml#Deployment_1)
· Get all the modules in the application and assign it to the modules variable:· set appDeploy [$AdminConfig showAttribute $deployments deployedObject]set modules [lindex [$AdminConfig showAttribute $appDeploy modules] 0]
Example output: (cells/mycell/applications/myApp.ear/deployments/myApp:deployment.xml#WebModuleDeployment_1)(cells/mycell/applications/myApp.ear/deployments/myApp:deployment.xml#EJBModuleDeployment_1)(cells/mycell/applications/myApp.ear/deployments/myApp:deployment.xml#WebModuleDeployment_2)
· To obtain a list of attributes you can set for session manager, use the attributes command.:$AdminConfig attributes SessionManager
Example output: "accessSessionOnTimeout Boolean""allowSerializedSessionAccess Boolean""context ServiceContext@""defaultCookieSettings Cookie""enable Boolean""enableCookies Boolean""enableProtocolSwitchRewriting Boolean""enableSSLTracking Boolean""enableSecurityIntegration Boolean""enableUrlRewriting Boolean""maxWaitTime Integer""properties Property(TypedProperty)*""sessionDRSPersistence DRSSettings""sessionDatabasePersistence SessionDatabasePersistence""sessionPersistenceMode ENUM(DATABASE, DATA_REPLICATION, NONE)""tuningParams TuningParams"
· Set up the attributes for session manager:· set attr1 [list enableSecurityIntegration true]· set attr2 [list maxWaitTime 30]· set attr3 [list sessionPersistenceMode NONE]· set attr4 [list enabled true]· set attrs [list $attr1 $attr2 $attr3 $attr4]set sessionMgr [list sessionManagement $attrs]
This example sets four top level attributes in the session manager. You can modify the example to set other attributes in the seesion manager including the nested attributes in Cookie, DRSSettings, SessionDataPersistence, and TuningParms object types. To list the attributes for those object types, use the attribute command in AdminConfig object.
Example output: sessionManagement {{enableSecurityIntegration true} {maxWaitTime 30} {sessionPersistenceMode NONE} {enabled true}}
· Set up the attributes for Web module:· set nameAttr [list name myWebModuleConfig]· set descAttr [list description "Web Module config post create"]set webAttrs [list $nameAttr $descAttr $sessionMgr]
Example output: {name myWebModuleConfig} {description {Web Module config post create}} {sessionManagement {{enableSecurityIntegration true} {maxWaitTime 30} {sessionPersistenceMode NONE} {enabled true}}}
· Create the session manager for each Web module in the application:· foreach module $modules {· if ([regexp WebModuleDeployment $module] == 1} {· $AdminConfig create WebModuleConfig $module $webAttrs· }· }
You can modify this example to set other attributes of session manager in Web module configuration.
Example output: myWebModuleConfig(cells/mycell/applications/myApp.ear/deployments/myApp:deployment.xml#WebModuleConfiguration_1)
· Save the changes with the following command:$AdminConfig save

Example: Exporting applications using the wsadmin tool
Exporting applications enables you to back them up and preserve their binding information. You can export your applications before you update installed applications or before you migrate to a different version of the WebSphere Application Server product.
· Export an enterprise application to a location of your choice, for example: $AdminApp export app1 C:/mystuff/exported.ear
where app1 is the name of the application that will be exported and C:/mystuff/exported.ear is the name of the file where the exported application will be stored.
· Export Data Definition Language (DDL) files in the enterprise bean module of an application to a destination directory, for example:$AdminApp exportDDL app1 C:/mystuffwhere app1 is the name of the application whose DDL files will be exported and C:/mystuff is the name of the directory where the DDL files export from the application.

Example: Configuring a shared library for an application
You can use the AdminApp object to set certain configurations in the application. This example uses the AdminConfig object to configure a shared library for an application.
· Identify the shared library and assign it to the library variable.
· To create a new shared library, perform the following steps:
1. Idenitfy the node and assign it to a variable, for example:set node [$AdminConfig getid /Cell:mycell/Node:mynode/]

Example output:mynode(cells/mycell/nodes/mynode:node.xml#Node_1)
2. Create the shared library in the node, for example:set library [$AdminConfig create Library $node {{name mySharedLibrary} {classPath c:/mySharedLibraryClasspath}}]
Example output:MySharedLibrary(cells/mycell/nodes/mynode:libraries.xml#Library_1)
This example creates a new shared library in the node scope. You can modify it to use the cell or server scope.
· To use an existing shared library, issue the following command:set library [$AdminConfig getid /Library:mySharedLibrary/]
Example output:MySharedLibrary(cells/mycell/nodes/mynode:libraries.xml#Library_1)
· Identify the deployment configuration object for the application and assign it to the deployment variable:set deployment [$AdminConfig getid /Deployment:myApp/]

Example output: myApp(cells/mycell/applications/myApp.ear/deployments/myApp:deployment.xml#Deployment_1)
· Retrieve the applicaton deployment and assign it to the appDeploy variable:set appDeploy [$AdminConfig showAttribute $deployment deployedObject]
Example output: (cells/mycell/applications/myApp.ear/deployments/myApp:deployment.xml#ApplicationDeployment_1)
· Idenitfy the class loader in the application deployment and assign it to the classLoader variable:set classLoader [$AdminConfig showAttribute $appDeploy classloader]
Example output: (cells/mycell/applications/myApp.ear/deployments/myApp:deployment.xml#Classloader_1)
· Associate the shared library in the application through the class loader:$AdminConfig create LibraryRef $classLoader {{libraryName MyshareLibrary} {sharedClassloader true}}

Example output: (cells/mycell/applications/myApp.ear/deployments/myApp:deployment.xml#LibraryRef_1)
· Save the changes:$AdminConfig save

Service Integration Bus

· JMS clients are the programs or components, written in the JavaTM programming language,
that produce and consume messages.
· Messages are the objects that communicate information between JMS clients.
· Administered objects are preconfigured JMS objects created by an administrator for the use of
· Administrative tools allow you to bind destinations and connection factories into a Java
Naming and Directory InterfaceTM (JNDI) API namespace. A JMS client can then look up the
administered objects in the namespace and then establish a logical connection to the same
objects through the JMS provider. clients. The two kinds of administered objects are
destinations and connection factories

Point-to-Point Messaging Domain:

A point-to-point (PTP) product or application is built around the concept of message queues, senders, and receivers. Each message is addressed to a specific queue, and receiving clients extract messages from the queue(s) established to hold their messages. Queues retain all messages sent to them until the messages are consumed or until the messages expire

Publish/Subscribe Messaging Domain:

In a publish/subscribe (pub/sub) product or application, clients address messages to a topic. Publishers and subscribers are generally anonymous and may dynamically publish or subscribe to the content hierarchy. The system takes care of distributing the messages arriving from a topic's multiple publishers to its multiple subscribers. Topics retain messages only as long as it takes to distribute them to current subscribers.

connection factory:

A connection factory is the object a client uses to create a connection with a provider.

Destination:
A destination is the object a client uses to specify the target of messages it produces and the source of messages it consumes. In the PTP messaging domain, destinations are called queues,

Session:
A session is a single-threaded context for producing and consuming messages. You use sessions to create message producers, message consumers, and messages. Sessions serialize the execution of message listeners;

Message producer
A message producer is an object created by a session and is used for sending messages to a destination. The PTP form of a message producer implements the QueueSender interface. The pub/sub form implements the TopicPublisher interface.

Message consumer:

A message consumer is an object created by a session and is used for receiving messages sent to a destination. A message consumer allows a JMS client to register interest in a destination with a JMS provider. The JMS provider manages the delivery of messages from a destination to the registered consumers of the destination.
The PTP form of message consumer implements the QueueReceiver interface. The pub/sub form implements the TopicSubscriber interface.

Message listener:

A message listener is an object that acts as an asynchronous event handler for messages. This object implements the MessageListener interface, which contains one method, onMessage. In the onMessage method, you define the actions to be taken when a message arrives.
You register the message listener with a specific QueueReceiver or TopicSubscriber by using the setMessageListener method. For example, if you define a class named TopicListener that implements the MessageListener interface,

Messages:
The ultimate purpose of a JMS application is to produce and to consume messages that can then be used by other software applications. JMS messages have a basic format that is simple but highly flexible, allowing you to create messages that match formats used by non-JMS applications on heterogeneous platforms.

A JMS message has three parts:
· A header
· Properties (optional)
· A body (optional)

Message Headers:
A JMS message header contains a number of predefined fields that contain values that both clients and providers use to identify and to route messages. (Table: lists the JMS message header fields and indicates how their values are set.) For example, every message has a unique identifier, represented in the header field JMSMessageID. The value of another header field, JMSDestination, represents the queue or the topic to which the message is sent. Other fields include a timestamp and a priority level.

Message Bodies:
The JMS API defines five message body formats, also called message types, which allow you to send and to receive data in many different forms and provide compatibility with existing messaging formats.