WebSphere Application Server Terminology 6.1.a.b 6.1 : major version a is feature pack b is fix pack versioninfo.sh -maintenancePackages versioninfo.

sh -help installationverification utility (IVU) IVT : install verfication test domain name server (DNS) WebSphere Relational Resource Adapter (WRRA) Java EE Connection Architecture (JCA) enterprise information system (EIS) container-managed persistence (CMP) BMP : bean managed persistence BMP Lightweight Third-Party Authentication (LTPA) Common Secure Interoperability Version 2 (CSIv2) Security Authentication Service (SAS) Security WebSphere Common Configuration Model (WCCM) WebSphere Security Domains (WSD) trust association interceptor (TAI) Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) JAAS (Java Authentication and Authorization Service) external third party JACC (Java Authorization Contract for Containers) There attributes needed to create an ssl configurations: * A key store * Default client certificate alias * Default server certificate alias * Trust store * The handshake protocol * The ciphers needed during handshake * Supporting client authentication or not In SSL handshake purpose of trustStore is to verify credentials and purpose of k eyStore is to provide credential. keyStore in Java stores private key and certificates corresponding to there publ ic keys and require if you are SSL Server or SSL requires client authentication. TrustStore stores certificates from third party, your Java application communica te or certificates signed by CA(certificate authorities like Verisign, Thawte, G eotrust or GoDaddy) which can be used to identify third party. TrustManager determines whether remote connection should be trusted or not i.e. whether remote party is who it claims to and KeyManager decides which authentica tion credentials should be sent to the remote host for authentication during SSL handshake. keyStore in Java stores private key and certificates corresponding to there publ ic keys and require if you are SSL Server or SSL requires client authentication. TrustStore stores certificates from third party, your Java application communic ate or certificates signed by CA(certificate authorities like Verisign, Thawte,

Geotrust or GoDaddy) which can be used to identify third party. 1)First and major difference between trustStore and keyStore is that trustStore is used by TrustManager and keyStore is used by KeyManager class in Java. KeyMan ager and TrustManager performs different job in Java, TrustManager determines wh ether remote connection should be trusted or not i.e. whether remote party is wh o it claims to and KeyManager decides which authentication credentials should be sent to the remote host for authentication during SSL handshake. if you are an SSL Server you will use private key during key exchange algorithm and send certi ficates corresponding to your public keys to client, this certificate is acquire d from keyStore. On SSL client side, if its written in Java, it will use certifi cates stored in trustStore to verify identity of Server. SSL certificates are mo st commonly comes as .cer file which is added into keyStore or trustStore by usi ng any key management utility e.g. keytool. See my post How to add certificates into trustStore for step by step guide on adding certificates into keyStore or t rustStore in Java. 2) Another difference between trustStore and keyStore in rather simple terms is that keyStore contains private keys and required only if you are running a Serve r in SSL connection or you have enabled client authentication on server side. On the other hand trustStore stores public key or certificates from CA (Certificat e Authorities) which is used to trust remote party or SSL connection. 3)One more difference between trustStore vs KeyStore is that we use -Djavax.net. ssl.keyStore to specify path for keyStore and -Djavax.net.ssl.trustStore to spec ify path for trustStore in Java. 4) Another difference between trustStore and keyStore is that, If you store your personal certificate along with signer certificate in trustStore, you can use same file as both trustStore and keyStore. By the way its good idea to separate personal certificate and signer certificates in keyStore and trustStore for bett er management. 5) One more API level difference between keyStore and trustStore is that passwo rd of keyStore is provided using -Djavax.net.ssl.keyStorePassword and password o f trustStore is provided using -Djavax.net.ssl.trustStorePassword. That s all on difference between trustStore and keyStore in Java. You can still us e same file as trustStore and keyStore in Java to avoid maintaining two separate files, but its good idea to segregate public keys and private keys in two diffe rent files, its more verbose and self explanatory that which one holds CA certif icates to trust server and which contains client's private keys.

many Web server plug-in properties, such as RefreshInterval, LogLevel, and the Edge Side Include (ESI) processor properties, only can be updated manually. Those values must be maintai ned through each iteration. Personal certificates contain a private key and a public key. You can extract th e public key, called the signer certificate, to a file, then import the certificate into another keys tore. The client requires the signer portion of a personal certificate for Security Socket Layer (SSL)

communication LoadBalanceWeight (zero or one attribute for each Server) Specifies the weight associated with this server when the plug-in does weighted Round Robin load balancing. The starting value for a server can be any integer between 0 and 20. However, zero should be specified only for a server that is shut down. The LoadBalanceWeight for each server is decremented for each request processed by that server. After the weight for a particular server in a server cluster reaches zer o, only requests with session affinity are routed to that server. When all servers in the cluster reac h a weight of zero, the weights for all servers in the cluster are reset, and the algorithm starts o ver. When a server is shut down, it is recommended that you set the weight for that s erver to zero. The plug-in can then reset the weights of the servers that are still running, an d maintain proper load balancing. The bootstrap, extensions, and CLASSPATH class loaders created by the Java virtua l machine The bootstrap class loader uses the boot class path (typically classes in jre/li b) to find and load classes. The extensions class loader uses the system property java.ext. dirs (typically jre/lib/ext) to find and load classes. The CLASSPATH class loader use s the CLASSPATH environment variable to find and load classes. The extensions class loader uses a ws.ext.dirs system property to determine the path that is used to load classes Each class loader is a child of the previous class loader. That is, the applicat ion module class loaders are children of the WebSphere extensions class loader, which is a child of the CLASSPATH Java class loader. Whenever a class needs to be loaded, the class load er usually delegates the request to its parent class loader. If none of the parent class lo aders can find the class, the original class loader attempts to load the class. Requests can only g o to a parent class loader; they cannot go to a child class loader. If the WebSphere extension s class loader is requested to find a class in a Java EE module, it cannot go to the applicatio n module class loader to find that class and a ClassNotFoundException error occurs. After a cla ss is loaded by a class loader, any new classes that it tries to load reuse the same class loade r or go up the precedence list until the class is found. Class-loader modes : parent first parent last Parent first

Also known as Classes loaded with parent class loader first. The Parent first class-loader mode causes the class loader to delegate the loadi ng of classes to its parent class loader before attempting to load the class from its local cl ass path. This value is the default for the class-loader policy and for standard JVM class load ers. Parent last Also known as Classes loaded with local class loader first or Application first. The Parent last class-loader mode causes the class loader to attempt to load cla sses from its local class path before delegating the class loading to its parent. Using this p olicy, an application class loader can override and provide its own version of a class tha t exists in the parent class loader. application class-loader policy single multiple If the application class-loader policy of an application server is Single, the s erverlevel mode value defines the mode for an application class loader. * If the application class-loader policy of an application server is Multiple, t he application-level mode value defines the mode for an application class loader. * If the WAR class-loader policy of an application is Module, the module-level m ode value defines the mode for a WAR class loader. When Java 2 Security is enabled and if an application requires more Java 2 secur ity permissions than are granted in the default policy, then the application might fail to run p roperly until the required permissions are granted in either the app.policy file or the was.policy file of the application. Select which authentication mechanism is active when security is enabled from th e Authentication mechanisms and expiration menu. In this release of WebSphere Appl ication Server, the authentication mechanism choices include LTPA and Kerberos. In previous releases of WebSphere Application Server, when a user enabled global security, both administrative and application security were enabled. In WebSphere Applicat ion Server Version 6.1, the previous notion of global security is split into administrative security and application security, each of which you can enable separately. As a result of this split, WebSphere Application Server clients must know whethe r application security is disabled at the target server. Administrative security is enabled, b y default. Application security is disabled, by default. To enable application security, you must enabl e administrative security. Application security is in effect only when administrative security is enabled.

When the Use Java 2 security to restrict application access to local resources o ption is enabled and if an application requires more Java 2 security permissions than are granted in the default policy, the application might fail to run properly until the required permission s are granted in either the app.policy file or the was.policy file of the application. Java 2 security Java 2 security provides a policy-based, fine-grain access control mechanism that increases overall system integrity by checking for permissions before allowing access to c ertain protected system resources. Java 2 security guards access to system resources such as file I/O, sockets, and properties. Java 2 Platform, Enterprise Edition (J2EE) security guards acces s to Web resources such as servlets, JavaServer Pages (JSP) files and Enterprise JavaBean s (EJB) methods. You must separately enable administrative security, and application security. Because of this split Application security can be in effect only when administrative security is enabled. When you switch user registries, the admin-authz.xml file should be cleared of e xisting administrative ids and application names Use the User account repository menu to specify the repository that is active wh en security is enabled. You can configure settings for one of the following user repositories: Configuring the Lightweight Third Party Authentication mechanism. Import and export the LTPA keys for cross-cell single Sign-on (SSO) b etween cells. If automating the creation of a SSL Configuration it may be needed to create som e of the attribute values needed like the key store, trust store, key manager, and trust managers. You can modify or a create a new SSL configuration. This action protects the integrity of the messages sent across the Internet. The prod uct provides a centralized location to configure SSL configurations that the various WebSphere Application Server features that use SSL can utilize, including the LDAP registry, Web conta iner and the RMI/IIOP authentication protocol (CSIv2) For any transports that use the new network input/output channel chains, includi ng HTTP and Java Message Service (JMS), you can modify the SSL configuration repertoire alia ses in the following locations for each server: * Click Server > Application server > server_name. Under Communications, click P orts. Locate a transport chain where SSL is enabled and click View associated transpor

ts. Click transport_channel_name. Under Transport Channels, click SSL Inbound Channe l (SSL_2). * Click System administration > Deployment manager. Under Additional properties, click Ports. Locate a transport chain where SSL is enabled and click View associated transports. Click transport_channel_name. Under Transport Channels, click SSL Inbound Channel (SSL_2). * Click System administration > Node agents > node_agent _name. Under Additional properties, click Ports. Locate a transport chain where SSL is enabled and click View associated transports. Click transport_channel_name. Under Transport Channels, c lick SSL Inbound Channel (SSL_2). For the Object Request Broker (ORB) SSL transports, you can modify the SSL confi guration repertoire aliases in the following locations. These configurations are for the server-level for WebSphere Application Server and WebSphere Application Server Express and the ce ll level for WebSphere Application Server Network Deployment. * Click Security > Global security. Under RMI/IIOP security, click CSIv2 inbound communications. * Click Security > Global security. Under RMI/IIOP security, click CSIv2 outboun d communications.

Signer exchange When you configure an SSL connection, you can exchange signers to establish trus t in a personal certificate for a specific entity. Signer exchange enables you to extra ct the X.509 certificate from the peer keystore and add it into the truststore of another ent ity so that the two peer entities can connect. The signer certificate also can originate from a CA a s a root signer certificate or a chained certificate's root signer certificate or an intermediat e signer certificate. You can also extract a signer certificate directly from a self-signed certificat e, which is the X.509 certificate with the public key SSL configurations An SSL configuration comprises a set of configuration attributes that you can as sociate with an endpoint or set of endpoints in the WebSphere Application Server topology. The S SL configuration enables you to create an SSLContext object, which is the fundament al JSSE object that the server uses to obtain SSL socket factories. You can manage the f ollowing configuration attributes: * An alias for the SSLContext object * A handshake protocol version * A keystore reference * A truststore reference

* A key manager * One or more trust managers * A security level selection of a cipher suite grouping or a specific cipher sui te list * A certificate alias choice for client and server connections in federated repositories : user id should be unique resource scoping : application level > server scope > cluster scope > node scope >cell scope An administrator cannot map users and groups to the administrator roles. roles operator Administrator deployer configurator Adminsecuritymanager auditor

The message listener service, listener ports, and listeners for any message-driv en beans that you want to deploy against listener ports. For WebSphere Application Server Version 7 and later, listener ports are depreca ted. Therefore you should plan to migrate your WebSphere MQ message-driven bean deployment configurations from using listener ports to using activation specifications. For silent installations, modify the sample response files supplied, response.ba se.txt for base and response.nd.txt for network deployment. Then issue the following command to perform the silent insta llation: ./install.sh options myresponsefile.txt silent Silent creation of profiles a response file which should be customized: DMGR response.pct.NDdmgrProfile.txt Application Server response.pct.NDStandaloneProfile.txt Custom response.pct.NDmanagedProfile.txt The following terms describe elements in WebSphere Application Server configurat ions: cell The administrative domain that a Deployment Manager manages. A cell is a logical grouping of nodes that enables common administative activities in a WebSphere A pplication Server distributed environment. A cell can have one or many clusters. node A node is a logical group of one or more application servers on a physical compu ter. The node name is unique within the cell. A node name usually is identical t o the host name for the computer. That is, a node usually corresponds to a physi cal computer system with a distinct IP address. application server The application server is the primary component of WebSphere. The server runs a Java virtual machine, providing the runtime environment for the application's co de. The application server provides containers that specialize in enabling the e xecution of specific Java application components. Network Deployment Manager The administrative process used to provide a centralized management view and con

trol for all elements in a WebSphere Application Server distributed cell, includ ing the management of clusters. The Network Deployment Manager is responsible fo r the contents of the repositories on each of the nodes. The Network Deployment Manager manages this through communication with node agent processes on each nod e of the cell. node agent A node agent manages all managed processes on a WebSphere Application Server on a node by communicating with the Network Deployment Manager to coordinate and sy nchronize the configuration. A node agent performs management operations on beha lf of the Network Deployment Manager. The node agent represents the node in the management cell. Node agents are installed with WebSphere Application Server bas e, but are not required until the node is added to a cell in a Network Deploymen t environment. cluster A logical grouping of one or more functionally identical application server proc esses. A cluster provides ease of deployment, configuration, workload balancing, and fallback redundancy. A cluster is a collection of servers working together as a single system to ensure that mission-critical applications and resources re main available to clients. Clusters provide scalability. For more information, refer to additional document ation that customer support may provide that describes vertical and horizontal c lustering in the WebSphere Application Server distributed environment. cluster member An instance of a WebSphere Application Server in a cluster. WebSphere Web Server plug-in The WebSphere Web Server plug-in is a component installed onto an HTTP server to take incoming requests and transport them to the appropriate Web container in a cluster. The behavior of the plug-in is governed by the plugin-cfg.xml file. Th e plug-in allows the Web server to communicate requests for dynamic content, suc h as servlets, to the application server. Application Server Tool (AST) Kit, WebSphere Rapid Deployment (WRD), terminology LSD: location service daeoman DRS: domain replication service WLM : workload management HA : high availability NA : node agent DM : deployment manager ejb : WS : web service ORB : object resource borker SAS : Secure Association Service (ibm properitory ) JACC: the Java Authorization Contract with Containers J2EE standard CSIv2 authentication protocol RAID : redundant array of independent disks NAS : Network Attached Storage SAN : storage area network NFS : network file system Install Shield for Multiplatforms (ISMP) Centralized Installation Manager (CIM). customized installation package (CIP) and an integrated installation package (II P) ifcli command : installation factory command line interface Enterprise JavaBeans(EJB) . Java Naming and Directory Interface (JNDI) Object Management Group (OMG) (CosNaming) Interoperable Naming Service

Common Object Request Broker(CORBA). vpd.properties networkaddress.cache.ttl 0=never cache -1=cache forever RAID technology and standards The Storage Networking Industry Association(SNIA) has established the Common RAID Disk Data Format (DDF) specification. HA : process availability / data availability active/active automatic/mutual takeover or active/standby takeover We have a firewall cluster, LDAP cluster, WebSphere server cluster, and database cluster. In system failover, clustering software monitors the health of the net work, hardware, and software process, detects and communicates any fault, and automatically fails ov er the service and associated resources to a healthy host. Therefore, you can co ntinue the service before you repair the failed system. As we discussed before, as MTTR approaches zero, A increases toward 100%. System failover can also be used for planned software and hardware maintenance and upgrades. Disaster recovery. This applies to maintaining systems in different sites. When the primary site becomes unavailable due to disasters, the backup site can becom e operational within a reasonable time. This can be done manually through regular data backups, or automatically by geographical clustering software. Recovery Point Objective (RPO) : The point in time to which data is restored an d/or systems are recovered after an outage. Recovery Time Objective (RTO) : The period of time within which systems, applica tions, or functions must be recovered after an outage. RTO includes the time req uired for: assessment, execution and verification. RTO may be enumerated in busi ness time Recovery Time Objective (RTO) - How much time can pass before the failed compone nt must be up and running? Recovery Point Objective (RPO) - How much data loss is affordable? The RPO sets the interval for which no data backup can be provided. If no data loss can be afford ed, the RPO would be zero. stop-the-world (STW) in garbage collection MTTR : mean time to recover transport buffer size for data replication service : 10 mb default session manager : 1000 session in first cache : by default JSESSIONID storage nfs/san/nas raid business continuity disaster recovery ITIL proxy and reversee proxy server edge component application infrastructure architecture

The main difference between Java 2, JAAS, and J2EE Security is how the security

is enforced. Java 2 Security is enforced by the JVM and by the server with the permissions sp ecified in policy files. JAAS Security is enforced programmatically from within an application. J2EE Security is enforcable by the J2EE application server or programmatically f rom within an application. CSIv2 is the authentication protocol, used by EJB and EJB client over RMI/IIOP. J2EE 1.4 Security Features Java 2 Security - Access to System Resources Enforces access control, based on the location of the code and who signed it. N ot based on the principal. Defined in a set of Policy files. Enforced at runtime. Authorization is performed using J2EE security roles. Security roles are applie d to the Web and EJB application components (EJB methods or Web URI's). Binding users and groups to J2EE security roles is usually done at application install time. JAAS Security - Authentication and Authorization Enforce access control based on the current Principal or Subject. Defined in Application Code. Enforced Programmatically. Used for any type of Java Code - Stand-alone application, Applet, EJB, Servlet. J2EE Security Roles - Authorization of J2EE application artifacts. Role based security - Roles defined in the J2EE EAR file Defined in application configuration settings (Deployment Descriptors). Enforced by runtime, programmatically, or both. CSIv2 - Used for Authenticating EJB's, replacing IBM proprietary SAS and z/SAS p rotocols. SSL is used by multiple components within the application server: HTTP server and web container ORB component using IIOP over SSL LDAP client using LDAP over SSL JAAC allows application servers to interact with 3rd party authorization provide r using standard interfaces to make authorization decisions. WebSphere components that can use SSL are: HTTP Transport ORB LDAP Client SOAP port Configure WebSphere plug-in to use SSL Set the authentication mechanism as client-cert Create a self-signed certificate for the web server plugin Create a self-signed certificate for the embedded http server in the web contai ner Exchange public keys between the peers Modify the web server plugin file to use SSL/HTTPS Modify the web container to use SSL/HTTPS The Web server plug-in requires a keyring to store its own private and public ke ys and to store the public certificate from the Web container s keyfile (Generating a self-signed certificate for the web serv er using the ikeyman IBM tool). For WebSphere Application Server V6.0 and higher: 1.Open the administrative console. 2.Select Servers > Application Servers > server_name > Server Infrastructure > J

ava and Process Management > Process Definition > Java Virtual Machine > Custom Properties > New. 3.Add a new Custom Property for the JVM: System Property Name: com.ibm.ws.runtime.dumpShutdown System Property Value: true In computer data storage, data striping is the technique of segmenting logically sequential data, such as a file, so that consecutive segments are stored on dif ferent physical storage devices. Striping is useful when a processing device requests data more quickly than a si ngle storage device can provide it. By spreading segments across multiple device s which can be accessed concurrently, total data throughput is increased. It is also a useful method for balancing I/O load across an array of disks. Striping i s used across disk drives in redundant array of independent disks (RAID) storage , network interface controllers, different computers in clustered file systems a nd grid-oriented storage, and RAM in some systems. In data storage, disk mirroring is the replication of logical disk volumes onto separate physical hard disks in real time to ensure continuous availability. It is most commonly used in RAID 1. A mirrored volume is a complete logical represe ntation of separate volume copies. In a Disaster Recovery context, mirroring data over long distance is referred to as storage replication. Depending on the technologies used, replication can be performed synchronously, asynchronously, semi-synchronously, or point-in-time. R eplication is enabled via microcode on the disk array controller or via server s oftware. It is typically a proprietary solution, not compatible between various storage vendors. Mirroring is typically only synchronous. Synchronous writing typically achieves a Recovery Point Objective (RPO) of zero lost data. Asynchronous replication can achieve an RPO of just a few seconds while the remaining methodologies provide an RPO of a few minutes to perhaps several hours. Disk mirroring differs from file shadowing (which operates on the file level) an d disk snapshots (where data images are never re-synced with their origins). RAID 0 RAID 0 comprises striping (but no parity or mirroring). This level provides no d ata redundancy nor fault tolerance, but improves performance through parallelism of read and write operations across multiple drives. RAID 0 has no error detect ion mechanism, so the failure of one disk causes the loss of all data on the arr ay.[4] RAID 1 RAID 1 comprises mirroring (without parity or striping). Data are written identi cally to two (or more) drives, thereby producing a "mirrored set". The read requ est is serviced by any of the drives containing the requested data. This can imp rove performance if data is read from the disk with the least seek latency and r otational latency. Conversely, write performance can be degraded because all dri ves must be updated; thus the write performance is determined by the slowest dri ve. The array continues to operate as long as at least one drive is functioning. [4] RAID 2 RAID 2 comprises bit-level striping with dedicated Hamming-code parity. All disk spindle rotation is synchronized and data is striped such that each sequential bit is on a different drive. Hamming-code parity is calculated across correspond ing bits and stored on at least one parity drive.[4] This level is of historical significance only. Although it was used on some early machines (e.g. the Thinki ng Machines CM-2),[14] it is not used by any current commercially available syst ems.[15] RAID 3

RAID 3 comprises byte-level striping with dedicated parity. All disk spindle rot ation is synchronized and data is striped such that each sequential byte is on a different drive. Parity is calculated across corresponding bytes and stored on a dedicated parity drive.[4] Although implementations exist,[16] RAID 3 is not c ommonly used in practice. RAID 4 RAID 4 comprises block-level striping with dedicated parity.[citation needed] RAID 4 was previously used primarily by NetApp, but has now been largely replace d by an implementation of RAID 6 (RAID-DP).[17] RAID 5 RAID 5 comprises block-level striping with distributed parity. Unlike in RAID 4, parity information is distributed among the drives. It requires that all drives but one be present to operate. Upon failure of a single drive, subsequent reads can be calculated from the distributed parity such that no data is lost. RAID 5 requires at least three disks.[4] RAID 6 RAID 6 comprises block-level striping with double distributed parity. Double par ity provides fault tolerance up to two failed drives. This makes larger RAID gro ups more practical, especially for high-availability systems, as large-capacity drives take longer to restore. As with RAID 5, a single drive failure results in reduced performance of the entire array until the failed drive has been replace d.