Jun 6, 2009

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.
Share:

Jan 13, 2009

CORBA - Calling CORBA using IOR




"The Common Object Requesting Broker Architecture (CORBA) is a standard defined by the Object Management Group (OMG) that enables software components written in multiple computer languages and running on multiple computers to work together." - WikiPedia(http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture)

For objects to be used across a network, a client/server relationship must be established. The middleware that makes this happen is called the Object Request Broker (ORB). 
It is the ORB's job to:

  • intercept a call from the client
  • find the correct object
  • pass it the parameters
  • invoke its method
  • return the results to the client

Clients issue a request on a CORBA object using an object reference. Client side CORBA objects are generated by IDL compiler

The IDL compiler for Java programming language generates client-side stubs, which represent the CORBA object locally in the Java programming language. 
IDL interfaces are programming language neutral.
The command "idltojava Stock.idl" generates the files listed below:

Stock.java
The IDL interface represented as a Java interface
StockHelper.java
Implements the type operations for the interface
StockHolder.java
Used for out and inout parameters
_StockStub.java
Implements a local object representing the remote CORBA object. This object forwards all requests to the remote object. The client does not use this class directly.
So, we know ORB and IDL interface, One more thing which is very important is "IOR".
IOR(Interoperable Object Reference) is the contact details that a client application uses to communicate with a CORBA object. 
Remember, each CORBA object has got identity which is unique within a server process. IOR provides the means to obtain an intial reference to an object, be it naming service, transaction service, or customized CORBA servant. 
ORB's publish object references using IOR. 
Most Important, An IOR contains the information required for a client ORB to connect to a CORBA object. 
An IOR contains the folowing information: IIOP Version, Host, Port, Key, and Component. Host is TCP/IP address of the ORB's host machine. for example:
corbaloc::10.12.13.200:2061/NameService
object_to_string(org.omg.CORBA.Object o) converts the given CORBA object reference to a stringified IOR. 
string_to_object(String ior) converts a stringified IOR produced by object_to_string(.) back to CORBA object reference. 
Both string_to_object(..) and object_to_string(..) are defined in the ORB class. 
So, If we writing a client program, we need an ORB, IOR, Stubs(generated by IDLJ compiler), etc. 
We must understand few more concepts before we lok at an example.
NamingContext - NamingContext is a object that contains a set of name bindings in which each name is unique. 

A helper class is generated after compilig the idl file. 
The id() operation defined in the helper class returns a repository id for the interface. The repository id is a string representing the interface. 

NameComponent - Many of the operations defined on a naming context take names as parameters. Names have structure. A name is an ordered sequence of components.A name component consists of two attributes: the identifier attribute and the kind attribute. Both the identifier attribute and the kind attribute are represented as IDL strings.
resolve( ) method in the NamingContext takes NameComponent as parameter. 
resolve( ) operation is the process of retrieving the object bound t a name in the context. 

NameComponent(String id, String _kind)

Now, we look at the sample code which uses CORBA object for performing operation. 
/* This sample code is used for getting Service Manager. There is a Server to which we gave to connect and get the servce manager object. Idea is to get a Naming Context which is a CORBA object, get server object, authenticate, and then get service manager.  */
// Sample Code Start
Step 1.
              org.omg.CORBA.ORB myOrb = org.omg.CORBA.ORB.init(args, null);
Step 2. 
             Context ctx = new InitialContext();
             org.omg.CORBA.Object rootObj = null;
             NamingContext root = null;
             rootObj = myOrb.string_to_object(nameServiceString); 
             root = NamingContextHelper.narrow(rootObj);
Step 3. 
              NameComponent nc[] =              { new NameComponent(ICorbaSMAF_AuthenticationHelper.id(), "") };            
            org.omg.CORBA.Object authServerObj = root.resolve(nc);
            ICorbaSMAF_Authentication authServer =            ICorbaSMAF_AuthenticationHelper.narrow(authServerObj);
Step 4.    
              String smaf_ManagerFactoryIOR = authServer.authenticate(userid,password);
Step 5. 
               iCorbaSMAF_ManagerFactory =  ICorbaSMAF_ManagerFactoryHelper.narrow(myOrb.string_to_object(smaf_ManagerFactoryIOR));
Step 6.  
               String corbaSmServiceManagerIOR = "";
            corbaSmServiceManagerIOR = iCorbaSMAF_ManagerFactory.getServiceManager();

theCorbaSmServiceManager = ICorbaSmServiceManagerHelper.narrow(myOrb.string_to_object(corbaSmServiceManagerIOR));

// Sample Code Ends

nameServiceString - is an IOR for the NamingContext. And name of the Server is bound to this naming context.  

Step 1, is to instantiate a client ORB. 

Step 2, is to get the CORBA object from the IOR. CORBA object is a NamingContext. Remember, object returned by the string_to_object(String ior) is of CORBA Object type, We must use Narrow( ) to get the more specific reference. 

Step 3, is Contacting the authentication server
We know that, Authentication Server is a object bound to the NamingContext. NamingContext is a CORBA object which we got in the Step 2. 
Getting the object bound to the namingcontext is a two step process. 
First instantiate a NameComponent passing the id, and kind.
Secondly, pass this NameComponent to the NamingContext' resolve method.
remember the syntax for the rsolve method is:
public object resolve(NameComponent [ ] n) throws NotFound. cannotProceed, InvalidName
ICorbaSMAF_AuthenticationHelper.id() method returns the repository id of ICorbaSMAF_Authentication, this repository id is the symbolic name of  Authentication server. We instantiate NameComponent using this id and pass Namecomponent to NamingContext's resolve method. The resolve method returns us a authserver object. 

So, Till now we had a IOR(serviceName), we got object corresponding to the IOR, and the object was NamingContext. We got the authentication server object bound to this naming context. 

Step 4, is authenticating the client, passing the username and password to authenticate method defined the authserver object. 
The suthenticate method returns us a String. Now this String is also a IOR. This IOR is generated for the client(i.e. our program) and it contains user credentials. 
We are going to use this IOR, to establish connection to ManagerFactory and from thyere we get ServiceManager.(Step 5 & Step 6)

Step 5, is used for value for a reference to remote object. We have the helper class, for the desired CORBA object. We would call narrow method to get the object on the Helper class. To tht narrow method we pass the object reference. 
smaf_ManagerFactoryIOR is a client dedicated IOR, we convert it to object refernce using the string_to_object method and pass this reference to narrow method to get the value for this object. 

Step 6, is getting the IOR for the Service Manager.

Now, when we get the Service manager, further we would get object reference for this IOR, and call required methods on the reference CORBA bject.

Share:
© Shift, ShEkUP, Shape, and Surprise | All rights reserved.
Blogger Template Crafted by pipdig