Top Most WebSphere Application Server Profile, Cell, Node, Application Server Basic

WebSphere Application Server is a key SOA building block. We can build a complete SOA application only using WAS. But If we look at the SOA reference Architecture, WAS can be used to develop and deploy Business Application Services. WAS(WebSphere Application Server comes in different packaging with different application server capabilities. Major packages are Base, Express, and Network Deployment.

Network Deployment(WAS ND) package come some unique feature clustering which is not available in other packages. WAS is organized based on the concept of cells, nodes, an servers. All these elements are present in all the packages, and are of most significance in WAS ND. The application server is the run time component under which J2EE application executes. It exists in all packages. In WAS ND we can create clustered and distributed environment, but in Base and Express there can be multiple application servers, but each application server functions as a separate entity.

Profile- Profile is run time instance running in separate JVM instance. Profiles are similar to instances in some application servers. But instances in WAS5 used to have separate configuration files, but used to share some information. WAS6 onwards, profiles were introduced, which used to share core product files, and each profile also had collection of user files. Each profiles created in separate directory, and created using a tool PMT(Profile Management Tool). There are multiple types of profiles. We can say an WAS instance has those features according to defined by the type of its profile. A profile type decorates the WAS instance with features. Different profile types are cell, management, application server, custom, and secure proxy. To deploy and run J2EE application, we need an application server profile, which creates a Stand alone application server.

 Stand alone application server, application server acts as a unique entity. Profile Type “Application Server” contains one application server definition. Multiple stand alone application servers can co exist in same machine, and each one can be admistered by their administrative console. In WAS ND, there can be multiple application servers managed from a central location(deployment manager).

Cluster - A logical group of application servers within same cell, and all running the same set of applications and services is Cluster. Application servers are grouped into Nodes, and each node has a node agent, Node Agents communicate with Deployment Manager, and  Management of Deployment Manager is done by the Administrative Console.  Nodes and Application Servers belong to same cell. Remember, Nodes and Application Servers can be created independently and federated to the cell.

Node, Each application server belongs to a node. Multiple applications servers can be grouped under one node. Node can be assumed to be the physical system on which there are some instances of the application server. There can similarly different machines/nodes. Each node has Node Agent. Node Agent is created when a stand alone node is federated to cell. Node Agent is only included in WAS ND. Node Agents communicate with Deployment manager(One Deployment Manager in one cell, and all node agents of code belonging to same cell).  Deployment Manager is the centralized manager of all nodes. Nodes can also be grouped together into Node Group. There can be multiple node groups under one cell.

So, cell is grouping of nodes. At a min a cell must have one node, but when we create cell, two nodes are created(one for deployment manager and other for federated application server). A Stand alone Application Server exists with one stand alone node, this node exists within a cell, which contains only one node. In WAS ND, we can created an env, where multiple nodes(containing multiple servers) can be managed by one deployment manager. 

Most Important - 

Resource Scopes

First time when we create cell(while installation), two nodes are created, one contains application server(federated) and other contains deployment manager. If we create any resource(like JMS, JDBC Data Source, etc. ) it can exist within different scopes-

1. All (Resource would be visible to everyone)                                                                                

 2. Cell(Top level),   Aug2010Cell01                                                                                            

 3. Node1(containing Application Server) second level,  Aug2010Node02                           

 4. Node 2(containing deployment manager) second level,     Aug2010CellManager01     

 5. Application Server, lowest level, only visible to this application server.  Aug2010Node02, Server=server1                                                                               

In Bold are the names( in my environment, names may differ in yours).

After WAS installation we can create a Stand alone application server, and when we create any resource using Administrative console of this stand alone server, apart from all we have three scopes – cell(top level), node, and server(lowest level). 

In clustered environment, there are multiple nodes within a cell, and there i a deployment manager, which is the central administration point of the cell. Deployment Manager itself runs under a node an communicates with other nodes using their node agents. All the nodes federated to the cell, are managed by single deployment manager.

Multiple Deployment Managers(of different cells), and stand alone application servers, and other administrative agents are managed by Job Manager.  Multiple Stand alone Application Servers can be managed from central point using administrative agents and Job Manager.

Top Most WebSphere Application Server Messaging

Messaging is a way to exchange data between different applications. Several applications deployed over WAS can exchange information.  The Service Integration Bus (SIBus, or just the bus) provides a transport mechanism for WebSphere Application Server. The bus serves as the main transport mechanism for messages. Consumers consume messages form some Destination in Bus.  Producer produces and sends messages to some destination in Bus. Bus might be distribued, but applications act if they are interacting with single Bus.  Applications are using Bus to exchange mesages, and thus integrating with each other.  I would like to mention that WAS BUS is different from  WebSphere ESB, which is a separate product. And contains several more features.  WebSphere ESB is built on WebSphere Application Server.  WebSphere ESB also includes additional functions not supplied with WebSphere Application Server.

BUS contains a list of destinations. Incoming messags are routed to destination.  Message Consumers consume messages from Destination.  Most Important, a message can also be routed from one destination to another before being consumed by a receiver.

A mediation is a piece of code which is always associated with a destination. Mediation code operates on a message as it traverses that destination.

Following figure would explain the collaboration between producer, consumer, destination and mediation -

Ref. - http://www.ibm.com/developerworks/websphere/techjournal/0501_reinitz/0501_reinitz.html

A bus is defined at the cell level. In a standard configuration, no more than one bus is normally required within a cell.

(taken from Red book) In above figure we have one Bus(HR Department Bus) for one cell.  And two Nodes federated. Each Node have on Node Agent. Each node has two application servers. Only one application server is part of the bus. Application Server 2 is Bus Member of HR Department Bus. When a bus member is added, a messaging engine is created in that WebSphere instance, which has its own data store for messages.

For most development activity, you will create and assign a single bus member to the bus.

The Messenging Engine (ME) is a component of WebSphere Application Server.  It communicates messages to destinations, in cooperation with the other MEs of other bus members.  All of the messages that are sent to the destination will be handled by this messaging engine.

(Ref. - ibm.com/developerworks/websphere/library/techarticles/0504_barcia/0504_barcia.html

Multiple application servers can become part one bus.  A messaging engine is associated with a bus member.   When an application server is added as a member of a bus, a messaging engine is automatically created and associated with this application server. Messaging Engines wont be shared among Application Servers.

However, a cell can contain any number of buses. Multiple application servers can become part of different Bus.  If an application server is added as a member of multiple buses, that application server is associated with multiple messaging engines, one messaging engine for each bus of which it is a member. For example, if cell has 4 aplication servers, AS1, AS2, AS3, and AS4. AS1 and AS4 can be member of one bus. AS2 and AS3 can be member of another bus. And As1 can be member of a third bus. And all bus belong to same cell.  Below picture depicts above scenario (picture taken from Red Book) -

A message point is the location on a messaging engine where messages are held for a bus destination. A message point can be a queue point, a publication point, or a mediation point (this is a specialized message point) for eg., A queue point is the message point for a queue destination. If the bus member is an application server, a single queue point will be created and associated with the messaging engine on that application server.

When one is browsing the Application Server Console for messages,   s/he has to peek into the message point. for example, in below figure I have created two destinations inside the BUS ( by default there is one more – System.Exception.Destination), and we can see the Queue Depth against the Queue Points -

Messages can also be viewed, by going deep into the Queue Points -

JMS - Java Messaging Service (JMS) is the standard API for accessing enterprise messaging systems from Java-based applications. Java Enterprise Edition (Java EE) applications (producers and consumers) access the SIBus and the bus members through the JMS API.  We can create JMS Connection factory, JMS destinations in WAS console.  Generally we create a Bus, make J2EE(which needs to send or receive messages to BUS) as BUS member.  We also create destinations within the BUS, destinations which would hold messages produced by J2EE applications or which are going to be consumed by J2EE applications.  J2EE applications use JMS API to connect to destinations, send and receive mesages. We need to create JMS Connection Factory and JMS Destination for that. We associate the JMS connection factory and JMS destination to our BUS. JMS destination is associated to SIBUS destination.  Session Enterprise JavaBeans (EJBs)use a JMS connection factory to connect to the JMS provider.  J2EE component Message Driven Beans are EJB’s which listen to any JMS destination, and consume messages. (MDBs) use a JMS activation specification to connect to the JMS provider. The interface between an MDB and its destination is the JMS activation specification.

A JMS activation specification is a group of messaging configuration properties, it cannot be manually started and stopped.  It is possible to share a single JMS activation specification with multiple MDBs.  This simplifies administration because it is only necessary to provide a single set of messaging configuration properties.  Activation specifications are simple to configure, because they only require two objects: the activation specification and a message destination.

Below picture depicts how one EJB sends messages to a JMS Destination(associated to a SIBUS destination), and mesages are consumed by a MDB from the same JMS destination (taken from Redbook)-

Some time back I made a video of how to create a JMS Queue in WebSphere Application Server. I uploaded the video under one of my channel, video would really be helpful for a newbie in Web Sphere & JMS -

http://www.youtube.com/watch?v=uCaly04a_lk&feature=plcp&context=C37a70fcUDOEgsToPDskI0v3O4Yifj6K61aKcNwG6n

Top Most Prevent Message Loss in Message Driven Bean deployed in WebSphere Application Server

This is small setting in WAS to prevent message loss upto some extent -
But, If you are using MDB in WAS(WebSphere Application Server), there some settings specific to WAS which needs t be done, instead of JMS specific settings discussed in my previous posts. There are some settings which need to done over Destination, and some over Messaging Engine.

To make message persistent, Quality Of Service Settings that can be done onDestinations - Default reliability and Maximum reliability should be set as Assured persistent, in all other cases message is discarded when messages engine fails or restarted.

Exception Destination must be set. By default, there is one default exception queue – _SYSTEM.Exception.Destination… in BUS. It would be bright Idea to create a seperate excepition queue for different Queues or type of messages. So, that messages from different destinations are mixed into one Exception destination.

I would like to mention, that messages are only trasferred to Exception Queue, after some numbr of retries.  In case of failure and Exceptions, message is redeilered, Message is redelivered specified number of times.  Retry interval is set over Message Engine –Default blocked destination retry interval.

The time delay, in milliseconds, that is introduced by the system under certain circumstances before a failed message delivery to an application will be retried.  This delay can be overridden by individual Queue destination configurations.  When you configure a bus destination, you can specify an associated exception destination and a maximum number of times that an individual message fails to be consumed before it is put on that exception destination.

I would like to mention, above setting doesn’t works in all versions of was. Check – http://www-01.ibm.com/support/docview.wss?uid=swg1PK75860

Some time back I made a video of how to create a MDB in WAS - 
http://www.youtube.com/watch?v=ocFLBD1nqcA&feature=plcp&context=C3c38e9fUDOEgsToPDskKSSJK3QzHN_KhrucqVSuQ0

Top Most JMS Administered Objects in IBM MQ

WebSphere MQ, Version 7.0 integrates JMS configuration into its graphical, Eclipse-based tool, MQ Explorer, making it easier to design and deploy JMS solutions. JMS objects, such as connection factories and destinations, are now displayed in MQ Explorer along with WebSphere MQ objects, such as queues and channels. MQ Explorer can remotely configure the entire WebSphere MQ network, it is now easier to explore and configure JMS messaging across the network. Now MQ Explorer makes it easier to see all the properties of JMS resources at a glance and update JMS object properties. It is easier to create JMS resources, such as connection factories, using step-by-step wizards.


Administered Objects:
Administered objects encapsulate provider specific implementation and configuration information about connections and destinations. Administered Objects can be accessed by client applications through standard JNDI lookup code.
There can be several types of Administered Objects like Destination, ConnectionFactory, XAConnectionFactory, SOAPEndpoint, etc.
Destination represents a physical destination.
ConnectionFactory establishes physical connection between a client application and a Message Queue message server.
XAConnectionFactory is used to establish physical connections that support distributed transactions.


Although the JMS specification does not require JMS clients to lookup administered objects in a JNDI namespace, there are distinct advantages to doing so: it allows for a single source of control. it allows connections to be configured and reconfigured without having to recode, and it allows clients to be portable to other JMS providers.
Using administered objects means that client programmers do not have to know about provider specific syntax and object naming conventions or provider specific configuration properties. By specifying that administered objects be read only, administrators can ensure that client applications cannot change administered object attribute values that were set when the administered object was first created.
Administered Objects are placed in an object store, where they can be accessed by client applications through JNDI lookup.
Message Queue supports two types of objects tore: a standard LDAP directory server and a file-system object store. LDAP is recommended object store for production messaging systems.


MQ classes for JMS
IBM provides Web Sphere MQ classes for Java, which encapsulate MQI, and native MQ API's with some object oriented interfaces. A Java application can directly use MQ classes for Java, to perform any kind of operation.
IBM also provides MQ classes for JMS, which implement the javax.jms package.
Difference can be noticed while using the API's.
For instance using MQ classes for Java, we use MQQueueManager and MQQueue.
while using MQ classes for JMS we use ConnectionFactory and Destination.
where connection factory generally corresponds to Queue Manager, and Destination corresponds to Queeue.


MQ classes for JMS comes with two extensions, i.e. two extension's of JMS API or two implementations of JMS API.
First set of extension is implemented in objects such as MQConnectionFactory, MQQueue, and MQTopic objects.hese objects have properties and methods that are specific to WebSphere MQ. The objects can be administered objects, or an application can create the objects dynamically at run time.
With MQv7 came a new set of extension which is more generic and is implemented in objects such as JmsQueueConnectionFactory, JmsXAConnectionFactory, JMSQueue, JMSTopic, etc. This new set of extension is also called IBM JMS extension. Main focus for this extension is creating an configuring Connection Factory and Destination dynamically at runtime.
Remember, there is a big difference in using the previous API, and the new API.
Previous API expected that Connection Factory and Destination should be administered objects, i.e., bind to JNDI namespace, and client can perform lookup and use them to send and receive messages.
But new IBM JMS extension API's main focus is to creating and configuring Connection Factory and Destination dynamically at runtime.


Below, we are going to discuss the first set of API, where we are going to see how to make administered JMS objects, i.e. how to bind connection factory and destination to JNDI name, and how client can use them.


The JMS specification expects ConnectionFactory and Destination objects to be administered objects. An administrator creates and maintains administered objects in a central repository, and a JMS application retrieves these objects using the Java Naming and Directory Interface (JNDI). WebSphere MQ classes for JMS supports the use of administered objects, and an administrator can use either the WebSphere MQ JMS administration tool or WebSphere MQ Explorer to create and maintain administered objects.


Create .bindings file using MQ Explorer.


Create JMS Objects under a specific JNDI namespace.
Basically we would be creating a .bindings file, which would hold all information related to JNDI root, JNDI namespace, and JMS objects( for Queue Manager & Queue)





We would be creating a file based JNDI context and configure the JMS objects in that JNDI namespace.


These JMS objects would be used by applications running in OC4J to connect WebSphere MQ Manager.


The setting is for file based JNDI. So first cerate a directory where to create .bindings file.
In this case it is (C:\MQ-JNDI)





Pressing :Next” would give this screen:
Next screen contains “Context nickname” which would be used in the applications deployed in OC4J.





Connect the Newly created Context:








Right Click “Connection Factories” and create new Connection Factory.





Select “Queue Connection Factory” as type.
Select “Transport” as “Bindings” if in case MQ and client applications are on the same machine.
But generally, this would be rare, and also in this case you would need some dll's.
Transport should be selected as “MQ Client”, if Queues would be accessed by remote applications.
I would suggest, alsways use Client transport mode, so that you can access Queue(/Destination), from remote location also.
Selecting "Bindings" means bindings transport mode, which improves speed, but needs application to be on same machine and also needs some MQ server dll's.
Name of the Connection Factory is important as this name can be used by Message Driven Bean, and deployment descriptors.
Select the Queue Manager to be associated with this Connection Factory:
i.e. click “Base queue manager:”, select the our newly created queue manager.





Check finish.
This would create a Queue Connection Factory which would connect applications to the mentioned Queue Manager.
Queue manager has Queue, and this Queue would be “destination”. Destination from where our MDB would pick messages.
In coming steps we would be adding the queue as a destination, to which MDB would be listening.


Select Destinations and create a new destination:





Enter name of destination. This name is very important as this name would be used in the MDB, and this is the destination name where MDB would be listening.
Also, Select Queue Manager and Queue to be associated with this destination.
Queue manager should be same as the one to which we created the connection factory.





After this wizard completes, .bindings file is created in the location C:\MQ-JNDI.
Don't make any changes to this file.


Assuming that, we mentioned the name of QueueConnectionFactory as "MQQCF", and Destination as "MQQ", below is the sample Java program to send message on the MQ Queue:

Remember, always use "Client Transport mode", to make above program work.
It will also need many jars to work, like jms.jar, jndi,jar, fscontext.jar, etc.