Accessing the Enterprise Java Beans

InfoSphere® MDM is a headless application, or an application with no primary user interface, that is integrated with an organization’s line of business applications around customers, products, and contracts.

These applications integrate InfoSphere MDM into their processes using the InfoSphere MDM API. The API takes the form of several hundred services, all of which are accessed through a single InfoSphere MDM stateless session bean. The EJB through which all of the InfoSphere MDM services are accessed is called the DWLServiceControllerEJB.

The following is a depiction of a hypothetical cluster upon which InfoSphere MDM is installed and running:

Figure 1. Cluster C1 An illustration of a hypothetical cluster upon which InfoSphere MDM is installed and running

In this sample, the cluster is named c1. There are three computers in the cluster: Computer1, Computer2, and Computer3. Each computer has one AppSrvr profile running on it that corresponds to a WebSphere® Application Server ND node. These nodes are named Computer1Node01, Computer2Node01, and Computer3Node01. When creating a node, WebSphere Application Server ND, by default, names a node by concatenating <the DNS name of the computer> + <Node> + <a sequential number> determined by how many nodes are already installed on the computer. There is also the cell manager node, which is used by WebSphere Application Server ND to manage the collection of computers within the cell. See the WebSphere Application Server ND documentation for more information on WebSphere Application Server ND topologies. Each node contains two cluster members. These are the components of WebSphere Application Server ND that actually do the work. As we’ve already seen, they are the J2EE application containers. The members are called member1 and member2 for each node respectively. The number within each cluster member box represents the bootstrap port address for each application container, which is the port the programs use to get the home interface of the InfoSphere MDM EJB.

The following code snippet illustrates how you can access the home interface of the DWLServiceController EJB on a cluster comprised of three computers, each of which is running two application servers (cluster members):

public static DWLServiceControllerHome createDWLServiceController2() {

String ControllerJNDIName =
 	"cell/clusters/c1/com/dwl/base/requestHandler/beans/DWLServiceController";

	DWLServiceControllerHome controllerHome = null;
	Hashtable<String, String> env = new Hashtable<String, String>();
	env.put(Context.INITIAL_CONTEXT_FACTORY,  
			"com.ibm.websphere.naming.WsnInitialContextFactory");
	env.put(Context.PROVIDER_URL, 
			"corbaloc:iiop:computer1:2811,:2812," +
			":computer2:2811, :computer2:2812,” +
“:computer3:2811, :computer3:2812)”;
	try {
		InitialContext initCtx = new InitialContext(env);
		Object obj = initCtx.lookup(JNDIName);
		Class theClass = DWLServiceControllerHome.class;
		controllerHome = (DWLServiceControllerHome) PortableRemoteObject
				.narrow(obj, theClass);
		return controllerHome;
	} catch (NamingException e) {
		e.printStackTrace();
		return null;
	} catch (Exception e) {
		e.printStackTrace();
		return null;
	}
}

There are two parts of this code snippet to pay close attention to. For the first part, see the following part of the snippet:

String ControllerJNDIName =
 	"cell/clusters/c1/com/dwl/base/requestHandler/beans/DWLServiceController";

The actual JNDI name for the DWLServiceController is com/dwl/base/requestHandler/ beans/DWLServiceController. You can still use that JNDI name if you are going to access the EJB directly from a single cluster member such as member1 on Computer2Node01, which is illustrated in the following code snippet:

...
String ControllerJNDIName = “com/dwl/base/requestHandler/beans/DWLServiceController";

	DWLServiceControllerHome controllerHome = null;
	Hashtable<String, String> env = new Hashtable<String, String>();
	env.put(Context.INITIAL_CONTEXT_FACTORY, "com.ibm.websphere.naming.WsnInitialContextFactory");
	env.put(Context.PROVIDER_URL, "corbaloc:iiop:computer2.ottawa.ibm.com:2811”);
...

In the event that member1 on Computer2Node01 is not working for some reason, your program won’t be able to get the Home Interface of the bean, which will affect High Availability. The second part of the code snippet that :

env.put(Context.PROVIDER_URL, 
			"corbaloc:iiop:computer1.ottawa.ibm.com:2811,:2812," +
			":computer2.ottawa.ibm.com:2811,:2812,” +
“:computer3.ottawa.ibm.com:2811,:2812)”;

To use an EBJ that is running remotely on another computer, the URI of the computer and bootstrap port number through which the application server can return the EJB’s interface are required. In this case, the code has actually specified all the members of cluster c1 where the EJB is residing. Because of this, the underlying infrastructure will pick one out from the list and use it. If it can’t connect to one, it will move to another on the list, and so on. If it can’t connect to any one on the list, then the entire system is down.

Once you have the home interface of the EJB, you can use the EJB create method to get the actual EJB and carry on with your operations. All the rest is handled by WebSphere Application Server ND, and it distributes your requests to ALL of the cluster members depending on how much weight you’ve assigned to each cluster member. The higher the weight assigned to a cluster member, the greater the proportion of requests will be routed to that member.

Last updated: 13 Sep 2017