Michael Nascimento Santos's Blog

Practical AOP (Part 1): Transparent remoting with AOP and EJBs

There are basically four views about AOP nowadays (ok, it's more or less the same for any technology): those who think it's the golden hammer and everything is a nail, those who think it has some applicability, those who are strongly against it or have deep concerns about its wild adoption and those who simply couldn't care less about it. :-) I hope this kind of posts I intend to write help all the four groups in some way.

Let's start with an example most people are familiar with: remoting. Many technologies try to address remoting with different approaches - RMI, CORBA, EJB, webservices etc. - and each one has its own applicability, since most of them (are intended to) do more than just remoting. Also, these technologies can be implemented in several ways - consider the way EJB implementations in application servers has evolved, as an example. So, let's narrow our requirements for this case of study:

• Remoting should be transparent to the user. So, this means not even lookup or interfaces should be necessary for a user to call a remote component.
• We want to keep the benefits provided by EJB technology - security, transactionality, etc. - but without any complicated constraint on our code. We don't want to write tons of rules for a Hello World.

In a simple way, we want EJB benefits without any of its limitations. How could we implement this?

Using genesis this should be as hard as:

public class RemoteClass implements java.io.Serializable {
   /**
    * @Remotable
    */
   public void helloWorld() {
      System.out.println("Hello world");
   }
}

public class Client {
   public static void main(String[] args) {
      RemoteClass remote = new RemoteClass();
      remote.helloWorld();
   }
}

If you run this example using a genesis empty-project based structure, putting RemoteClass in your shared sources dir and Client in your client sources dir you will see that "Hello World" actually gets printed in your application server console. How this magic happens?

genesis' aspect named net.java.dev.genesis.aspect.EJBCommandExecutionAspect intercepts execution of methods annotated as @Remotable as defined in aop.xml and executes the method call inside a Stateless Session Bean in the server side. Since you have a simple POJO, you are not constrained and can take advantage from any OO feature you want, including instantiating a remote object with new if that's what you want, and you still get all the benefits from EJB technology. It's a much cleaner approach to remoting than other ones currently available and it's certainly going to be expanded on future releases to support full Session Beans semantics with plain POJOs - as well as the current model.

For further information about how this actually is implemented by genesis, refer to the documentation pages for genesis aspects and genesis business component model.

Comments

• Interesting post Michael,

  To me this is a perfect example of why I fall into what you call your third AOP viewpoint.

  As you said, magic happens; but it is also totally invisible from the actual source code. I can't imagine how one would debug a complex application.

  Consider operator overloading: Many argued against its inclusion in Java, because it could make the source look less obvious.

  To me, this source looks far less obvious.

  However, it might only be me who feels this way.

  Posted by: cajo on December 17, 2004 at 05:02 PM

• I can't necessarily argue with what Michael is trying to accomplish, just in how it's being accomplished. The problem with many of these AOP implementations is that you are modifying the behavior of an object for everyone. The behavior of RemoteClass is intrinsic, adding a client's ability to remote 'helloWorld' is extrinsic to RemoteClass and IMHO shouldn't be applied for all clients of RemoteClass (at compile time). This is why I like the idea of annotations-- where you now flip the AOP tables. Instead of applying some behavior to everyone, you instead define behavior that is available to the context or client that's explicitly looking and ready for it. e.g. Declaring methods asynchronous.

  I've written quite a bit on this subject in my blog:
  Validation via Annotations
  Rediscovering OOP

  Posted by: jhook on December 19, 2004 at 10:16 PM

• Michael -- nice article. The problem, in general, with marketing the benefits of AOP is that the majority of AOP implementations use byte-code manipulation, and a LOT of people (including managers) are still uneasy about it. So I see two things that need to be done -- attempt to get people used to AOP with simple libraries/containers (I'd like to see some of these articles), and get people comfortable with the idea of byte-code manipulation. I think the whole-hog solution is choking a lot of folks, and smaller bites are required.

  Posted by: gerryg on December 20, 2004 at 04:12 PM

• A cleaner example of AOP's power would have been taking a POJO and making it transactional. Objects that are remotable should clearly relflect that. This example commits the fallacy "The network is reliable" from the eight distributed computing fallacies.

  A well defined remotable object should declare to throw a remote exception. IMHO remoting is not something you want to hide.

  Posted by: ablperez on December 20, 2004 at 09:10 PM

This work is licensed under a Creative Commons License.