JMS

You can configure a stand-alone JMS client and JMS nodes to communicate with service integration bus (SIBus) in WebSphere® Application Server Version 6 and Version 7.

1. Complete the following steps in WebSphere Application Server. For more information, see the WebSphere Application Server documentation.
   1. Create a messaging bus.
   2. Add a bus member.
   3. Restart the WebSphere Application Server server.
   4. Create a queue destination on the bus.
   5. Create a JMS queue on the default messaging provider.
   6. Create a Queue Connection Factory (QCF) on the default messaging provider.
      Ensure that the messaging provider URL is specified in the QCF definition, particularly if the JMS client and messaging bus are on different computers. The provider endpoint URL must have the following format:

      bus_member_host_name:7276:BootstrapBasicMessaging

      where 7276 is the default SIB endpoint address. Do not use 127.0.0.1 or localhost for the bus member host name.
2. Test the WebSphere Application Server configuration by using a stand-alone JMS client and completing the following steps.
   1. Put the following two JAR files in your class path: com.ibm.ws.sib.client.thin.jms_7.0.0.jar and com.ibm.ws.ejb.thinclient_7.0.0.jar.
      Copy these JAR files from the WebSphere Application Server Version 7 installation directory under the runtimes subdirectory. If you are using a non-IBM JRE, you also need the com.ibm.ws.orb_7.0.0.jar file.
   2. Ensure that the provider URL is set to iiop://WAS_server_host_name:boot_strap_port.
   3. Ensure that you specify the correct boot strap port.
   4. Ensure that the Queue Connection Factory and JMS Queue properties are set to the values defined in the WebSphere Application Server configuration.
   5. Compile the JMS client code.
   6. Run the JMS client with the following IBM® ORB debug parameters turned on.

      java -Dcom.ibm.CORBA.Debug=true -Dcom.ibm.CORBA.CommTrace=true -Dcom.ibm.CORBA.D ebug.Output=client.logJMS_Client_Class

      This command produces CORBA debug output in the client.log file in the same directory.
3. Complete the following steps in WebSphere Message Broker.
   1. Stop the broker.
   2. Create a directory (for example, c:\WebSphere_WAS_Client) and copy the following two JAR files from WebSphere Application Server Version 7 Thin Client for JMS.
      • com.ibm.ws.sib.client.thin.jms_7.0.0.jar
      • com.ibm.ws.ejb.thinclient_7.0.0.jar
      Alternatively, you can copy these files from the WebSphere Application Server installation directory WAS home/runtimes.
   3. Configure the JMS service in WebSphere Message Broker by using the mqsichangeproperties command. The JMS provider WebSphere_WAS_Client exists; therefore you can change the client JAR file path for that provider.

      mqsichangeproperties broker_name -c JMSProviders -o WebSphere_WAS_Client -n jarsURL -v WAS_thin_client_JAR_file_path

   4. Configure the JMSInput node as shown in the following example. For more information about these properties, see JMSInput node.
      • Specify the name of the JMS provider; for example, Client for WebSphere Application Server.
      • Specify the initial context factory; for example, com.ibm.websphere.naming.WsnInitialContextFactory.
      • Specify the location of the JNDI bindings in the format iiop://WAS_server_host_name:WAS_server_boot_strap_port.
      • Set the connection factory name to QCF.
   5. Ensure that the JMS connection has been established before the message flow starts by using the Windows Event Viewer.

Importent Definitions asked in interview

What is a ketstore?

A keystore is a database that contains private keys with their associated certificates. The keystore will be used for encrypting/signing something with your private key

What is A truststore ?

What is a Truststore contains certificates to trust like CA certs and remote server certs. Trust stores will be used mostly to authenticate remote servers etc.

What is root certificate?

a root certificate is either an unsigned public key certificate or a self-signed certificate that identifies the Root Certificate Authority (CA). Digital certificates are verified using a chain of trust. The trust anchor for the digital certificate is the Root Certificate Authority (CA).

A root certificate is the top-most certificate of the tree, the private key of which is used to “sign” other certificates. All certificates immediately below the root certificate inherit the trustworthiness of the root certificate. Certificates further down the tree also depend on the trustworthiness of the intermediates.

The root certificate is usually made trustworthy by some mechanism other than a certificate, such as by secure physical distribution. For example, some of the most well-known root certificates are distributed in the Internet browsers by their manufacturers. [From Wikipedia]

What is an intermediate certificate?

Trusted Root CA certificate can also be used to create another certificate, which in turn will then be used to issue SSL Certificates. So, an intermediate certificate is a subordinate certificate issued by the trusted root specifically to issue end-entity server certificates. The result is a certificate chain that begins at the trusted root CA, through the intermediate and ending with the SSL certificate issued to you. Such certificates are called chained root certificates. As the Intermediate Certificate is issued by the Trusted Root CA, any SSL Certificates issued by the Intermediate Certificate inherits the trust of the Trusted Root – effectively creating a certification chain of trust.

Why to use intermediate certificates?

There are mainly two advantages.

1) Creating certificates directly from the CA root certificate increases the risk of root certificate compromise, and if the CA root certificate is compromised, the entire trust infrastructure built by the SSL provider will fail. The usage of intermediate certificates for issuing SSL certificates to end entities, therefore, provides an added level of security.

2) Intermediates also help by constraining the size of the Certificate Revocation List (CRL) associated with a certificate product. By periodically rolling over the intermediate CA that signs the end entity certificates CRL’s are kept to a minimum. Maintaining optimal CRL sizes ensures that customers have a smooth and seamless experience visiting SSL-secured websites while full security is maintained transparently to customers/end users.

What is in-bound and out-bound on the SSL settings in websphere?

Simply imagine the bus routes in your city. They are named north-bound/souuth-bound etc.. Based on the direction they travel.

In websphere inbound/outbound does the same. They specify the direction of the SSL connection. Inbound represents all server endpoints that receive connection. Outbound represents all the client side connections from the carious servers within the cell.

What is a WebSphere application server release means?

Simply it is a new version. Like 6.0, 6.1, 7.0, 8.0 etc. These releases include major new function, archictural changes etc..

What is a refresh pack?

A refresh pack includes minor new features and fixes. Say 6.0.1 is a refresh pack for 6.0 and 6.0.2 is a refresh pack for 6.0.1. Say now you are applying refresh pack 6.0.2, it includes all the fueatures and fixes in 6.0.1 plus fixpack and interm fixes published for 6.0.1.  So a refresh pack is cumulative.

What is a fix pack?

A fix pack is a package of fixes. Fixpacks install on top of refresh packs or on top of previous packs. For example your present software version is 6.1.0 and you are applying 6.1.0.23, this is called fixpack and will also be called as fixpack 23 for 6.1.0. After applying this fixpack23, your server version will be 6.1.0.23.

A fix pack uninstalls all interm fixes applied to the release since the lasr refresh pack or fixpack was installed. Therefore IBM suggests checking the list of delivered fixes to determine if an intermfix needs to be installed.
May not be correct but in other words, a fix pack is a package of fixes for a refresh pack.

What is fix/interim fix/Emergency fix etc..?

These are single fixes published to resolve/fix an product defect/known issue. The next release of fixpack will contain these interim/emergency fixes and you are expected to apply the new fix pack

Session Replication

What is session?
————————–
*  A Session is a series of requests to a servlet, originating from the same user at the same browser

How session works?
——————————
*  session ID Allows to keep track of individual users
*  Session ID generated on first request and send back to browser with first response.
*  Session ID then arrives with each subsequent request
*  Cookies, URL rewriting and SSL (if request is on HTTPS) are ways to track the session IDs


Distributed sessions
——————————
Session management can store session-related information in …
*  In application server memory (the default). This storage options is knows as in-memory sessions.
*  In a database. This storage option is known as database persistent sessions.
*  In another WebSphere Application Server instance. This storage option is known as memory-to-memory sessions.

*  Distributed sessions are essential for using HTTP sessions for the failover facility
*  Plug-in maintains Session affinity by sending requests with session ID to cluster member where that session has been previously created
*  On the failure of cluster member, plug-in routes requests to other members
*  When cluster member receives a request associated with a session ID that it currently does not have in memory, it can obtain the required session state by accessing the external store (database or memory-to-memory).

Memory-Memory replication
—————————————–
*  In Memory-to-Memory session replication, session data from owner server replicates (copies) in one or more other application server using Data Replication Service
=>Data Replication Service (DRS) is an internal WebSphere Application Server component that replicates data. You can configure DRS by creating a replication domain. Replication Domain can be created either manually from Environment page of admin console or automatically at cluster create time.
*  This requires creation of a data replication service instance in owner server that communicates to other data replication service instances in remote application servers
*  This can be achieved by creating a replication domain and configuring the session manager of cluster members to use memory-to-memory replication.

*  A server can run in one of the following three modes:
*  Client mode: server only sends copies of sessions it owns
*  Server mode: server only stores backup copies of other servers
*  Both mode: server sends copies of session it owns and acts as a backup table for sessions owned by other application server

*  Two different topologies are possible based on above three modes
*  Peer-to-Peer topology
*  Client/Server topology

=> Peer-to-Peer topology
*  Each server stores a session in it’s own memory and also stores sessions to, and retrieves from, other application servers.
*  Each application server acts as client by retrieving session from other servers and acts as server by providing sessions to other application servers

*  This is the default configuration and each application server can:
*  Host the Web Application leveraging the HTTP Session
*  Send Changes to the HTTP Session that it owns
*  Receive backup copies of the HTTP session from all of the other servers in the cluster

=>Steps to configure
1. Create replication domain
configure request timeout, encryption and number of replicas
2. go to Servers ->Application servers -> First Cluster member -> Sessionmanagement -> Distributed environment settings -> Memoryto-memory replication
3. Select the replication domain created in first step
4. Select “Both Client and Server” as replication mode
5. Click Ok and Save to master configuration
6.  Repeat above steps for all the cluster members
7. Once done, restart the cluster

=>Advantages
*  No additional processes and products are required to avoid a single point of failure.
*  Reduce the time and cost required to configure and maintain additional processes or products
=>Disadvantages
*  It can consume large amounts of memory with many users. This can cause a performance impact
*  Does not provide stable configuration for cluster with only 2 members, because of two way replication?

=>Client/Server topology
*  Application Servers act as either a replication Client or a Server
*  Replication servers store sessions in there own memory and provide session info to clients.
*  Dedicated replication servers just store session but do not respond to users’ requests
*  Client application servers send session information to replication servers and retrieve as needed. Clients respond to user requests
*  Application servers configured as Server can not host any applications. They act as pure data store for backup sessions and receive updates from Clients
*  Backup data is isolated into a separate JVM
*  Client replicas will contain only local session data
*  Application servers configured as Servers must be started before starting Clients

=>Steps to configure
1. Create replication domain
configure request timeout, encryption and number of replicas
2. go to Servers ->Application servers -> First Cluster member -> Sessionmanagement -> Distributed environment settings -> Memoryto-memory replication
3. configure cluster1 members as client
4. configure cluster2 members as Server
5. start cluster2 first and then cluster1

=>Advantages
*  Clearly distinguishes the role of client and server.
*  Reduces the consumption of memory on each application server
*  Better performance
*  Allows recycle of a backup server without affecting the servers running applications
*  Better choice if your hardware varies across the cluster
=>Disadvantages
*  Additional application servers have to be configured and maintained over and above those that interact with the user
*  Need multiple replication servers to avoid a single point of failure

Deployment of application through WSADMIN

Now let us learn how to install, start/stop and update or deployment tasks of applications using WSADMIN on to clusters and single servers.

Deploying Applications

You can install the application in batch mode, using the install command, or you can install the application in interactive mode using the installinteractive command. Interactive mode prompts you through a series of tasks to provide information.All the options available to use are listed here in the IBM documentation.

note: words in bold are command or options and in italic are your inputs

To find out the options available to install the EAR file, run:

AdminApp.options()

Installing EAR application:

Using Batch Mode:

If you are deploying on single servers….make sure that server is running before you execute the commands.

AdminApp.install(‘/home/joseph/applications/SampleApp.ear’, ‘[-server test_server1]‘)

If you are deploying it in network deployment/ Clusters, you must connect to WSADMIN of deployment manager.

AdminApp.install(‘/home/joseph/applications/SampleApp.ear’, ‘[-cluster sample_cluster]‘)

Using Interactive Mode:

AdminApp.installInteractive(‘/home/joseph/applications/SampleApp.ear’)

now it will take you through a series of questions before finishing the deployment.

After the deployment is done, you need to perform two more steps

step1. Save the changes by issuing

AdminConfig.save()

step2. Synchronize the changes across all nodes by using

Sync1 = AdminControl.completeObjectName(‘type=NodeSync,node=myNodeName,*’)

and then

AdminControl.invoke(Sync1, ‘sync’)

step2 is required only for network deployment models.

Starting Applications

this involves two steps.
step1: getting the handler of the application, means .. locating where the application is running. To do this we use a variable and use querynames option on admincontrol object

appHandle= AdminControl.queryNames ‘cell=SampleCell,node=virt_node1,type=ApplicationManager,process=test_server1,*’)
print appHandle

then you will get an output like the one below

WebSphere:cell=SampleCell,name=ApplicationManager,mbeanIdentifier=ApplicationManager,type=ApplicationManager,node=virt_node1,process=test_server1

step2: Now we execute the command to start the application

AdminControl.invoke(appHandle, ‘startApplication’, ‘Dynamic Cache Monitor’)

You can do both steps at once by using the below format

AdminControl.invoke(‘WebSphere:name=ApplicationManager,process=test_server1,node=virt_node1,type=ApplicationManager,mbeanIdentifier=ApplicationManager,cell=SampleCell, ‘startApplication‘, ‘["Dynamic Cache Monitor"]‘, ‘[java.lang.String]‘)

Stopping Application

The steps are same as starting the application except ‘startApplication’ should be renamed to ‘stopApplication’

But, if you want to stop all applications running on a server… after executing step1 of above
Step2: you need to first get the list of applications

# get line separator
import java.lang.System as sys
lineSeparator = sys.getProperty(‘line.separator’)
apps_list = AdminControl.queryNames(‘cell=SampleCell,node=virt_node1,type=Application,process=test_server1,*’).split(lineSeparator)
print apps_list

Step3: now we need to create a loop to stop the applications one by one

for app in apps_list:
appName = AdminControl.getAttribute(app, ‘name’)
AdminControl.invoke(appHandle, ‘stopApplication’, appName)

Updating Application

We have different options to update applications, like, full update, module update, single file update etc…Similar to the install, we do have both batch mode and interactive mode for updating [update and updateinteractive]. All the options available to use are listed here in the IBM documentation.

updating entire application
AdminApp.update(‘SampleApp’, ‘app’, ‘[-operation update -contents /home/joseph/applications/SampleAppv2.ear ]‘)

Adding a new module to EJB
AdminApp.update(‘SampleApp’, ‘modulefile’, ‘[-operation addupdate -contents /home/joseph/applications/Increment.jar -contenturi Increment.jar -nodeployejb
-BindJndiForEJBNonMessageBinding [["Increment Enterprise Java Bean" Increment Increment.jar,META-INF/ejb-jar.xml Inc]]]’)

Updating Single file
AdminApp.update(‘SampleApp’, ‘file’, ‘[-operation update -contents /home/joseph/applications/my.xml -contenturi SampleApp/my.xml]‘)

TIP: Use the taskInfo command of the AdminApp object to obtain information about the data that is needed for your application.

for example, you want to know what options you need to supply for mapping modules to servers…use the following taskinfo command

AdminApp taskInfo <ear file> MapModulesToServers




TO VIEW JVM settings:

w to enable the verbose gc logging on Websphere Application server

Wednesday, June 19, 2013, 5:41 AM

Posted By: Akhilesh

Hi Everyone,

Execute the following steps to enable the verbose:gc logging in your setup. Or you can use some steps to check the current status of your Java Virtual Machine configuration by using wsadmin tool 

1.Launch the wsadmin. Run these commands in a command prompt window:

:/IBM/WebSphere/AppServer/profiles/AppSrv01/bin

:/IBM/WebSphere/AppServer/profiles/AppSrv01/bin $ ./wsadmin.sh

This output will appear after running the command:

WASX7209I: Connected Node DefaultNode ?process "server1" by SOAP connector Process Type UnManagedProcess

wsadmin>

2. Set the server environment.

wsadmin>set server1 [$AdminConfig getid /Cell:mycell/Node:mynode/Server:server1/]

server1(cells/DefaultNode/nodes/DefaultNode/servers/server1|server.xml#Server_1214551833906)

3.Get the definition of JVM.

wsadmin>set jvm [$AdminConfig list JavaVirtualMachine $server1]

(cells/DefaultNode/nodes/DefaultNode/servers/server1|server.xml#JavaVirtualMachine_1214551833937)

4.Check the current JVM setting.

wsadmin>$AdminConfig show $jvm

{bootClasspath {}}

{classpath {}}

{debugArgs "-Djava.compiler=NONE -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket.server=y,suspend=n,address=7777"}

{debugMode false}

{disableJIT false}

{genericJvmArguments {}}

{hprofArguments {}}

{initialHeapSize 128}

{maximumHeapSize 256}

{runHProf false}

{systemProperties {}}

{verboseModeClass false}

{verboseModeGarbageCollection false}

{verboseModeJNI false}

5.Set the verboseModeGarbageCollection variable to true.

wsadmin>$AdminConfig modify $jvm {{verboseModeGarbageCollection true}}

6.Check the changed JVM setting.

wsadmin>$AdminConfig show $jvm

{bootClasspath {}}

{classpath {}}

{debugArgs "-Djava.compiler=NONE -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=7777"}

{debugMode false}

{disableJIT false}

{genericJvmArguments {}}

{hprofArguments {}}

{initialHeapSize 128}

{maximumHeapSize 256}

{runHProf false}

{systemProperties {}}

{verboseModeClass false}

{verboseModeGarbageCollection true}

{verboseModeJNI false}

7.Save the JVM setting.

wsadmin>$AdminConfig save

8.Close the wsadmin console.

wsadmin>quit

9.Restart the Windows service IBM WebSphere Application Server.

10.Check the verbose:gc logs. By Default, the verbose:gc logs are located here:

/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1 $ cat native_stdout.log

/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1 $ cat native_stderr.log