Encapsulate Obtaining References

I first noticed this idiom when we were doing a port of some Java code from one CORBA ORB vendor (Iona) to another (Visigenics). The problem was this -- even though our IDL was the same, so that 90% of our code was identical in the two systems, the way in which each vendor obtained the reference to a remote object was different. Iona and Visigenics both had their own proprietary naming schemes, and they both provided slightly different versions of the CORBA naming service. So, depending on how you looked at it, we had three or possibly four ways of obtaining a reference to a remote object.

To make our lives easier, and to ease the transition between the two, we structured our code like this -- we encapsulated obtaining a remote reference away from the rest of our code in FactoryMethod. Each different remote object would be obtained from a different FactoryMethod.

So our code went from something resembling:

   // unportable nastiness to obtain an object ref
   org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService?");
   NamingContext? namingContext = NamingContextHelper?.narrow(objRef);
   NameComponent? nc = new NameComponent?("myObject", "");
   NameComponent? path[] = {nc};
   Object objRef = namingContext.resolve(path);
   MyClass myObject = MyClassHelper?.narrow();

   // Now do something
   myObject.doSomething(); // FINALLY

to something like:

   // use a factory method to get the object reference
   MyClass myObject = getMyObject();
   // now do something
   myObject.doSomething();

I thought I had left this behind when I went into the brave new world of Enterprise Java Beans, where (I thought) that everything would be standardized. Alas, this turned out not to be the case, as I noticed that even within IBM's EJB-supporting products that there are slight configuration differences in obtaining the initial context of an EJB Home. So I pulled this out of my bag of tricks and went back to work...

KyleBrown

---

An alternative way to do this is via ThirdPartyBinding. Write the application logic so that it doesn't obtain object references itself. Encapsulate each binding mechanism in a "third party" that instantiates the component containing the application logic and binds it to the objects it requires. --NatPryce.

---

We HaveThisPattern. In fact, we have a wrapper around ORB instances, so that we only need to rewrite that class to fix any ORB-related problems. (Not all CORBA problems, just ones related to org.omg.CORBA.ORB.) One of the things this wrapper class does is knows what naming scheme we are using, and how to access the naming service to get references.

--JohnFarrell

We, also, HaveThisPattern. Whether I'm working with AsynchronousMessaging? or EJB, this pattern always comes in handy. It is particularly useful when testing. If used properly, this should allow swapping in a MockObject for testing. Also, the isolation layer often makes migration, specification changes, or vendor changes much more manageable.

--MikeRettig

---

VisualAge for Java and WebSphere 3.0 now make this idiom part of the basic product in what is called a AccessBean. A type of AccessBean called a WrapperBean? simply implements this idiom. They can be generated in VA-J from any EJB. --KyleBrown

---

Just to connect the languages together -- CoreJ2eePatterns calls this pattern BusinessDelegate. --KyleBrown

---

CategoryPattern