On my current project, we use Enterprise Javabeans (EJB) technology. The EJB specification defines a component object model concerned with making services available to remote systems. Much like model-view-controller (MVC) is a component object model that facilitates user interface design by disentangling UI widgets from underlying logic, the EJB approach facilitates accessing a service remotely by disentangling the logic that handles network communication from the business functionality handled by the enterprise bean.
So, naturally serialization underpins much of the usefulness of EJBs. Most useful services take arguments and return some value. Because EJBs are all about remoting, all arguments and return values must be serializable.
It is also often the case in Java that a developer will make use of a language feature called an inner class, or sometimes a kind of inner class called ananonymous inner class. If your EJB returns such an inner class from a business method, though, you might be unaware of a subtle interaction between serialization and this language feature that will manifest as all kinds of mysterious
EOFException
s on the client and other strange behavior.This happens because (non-static) inner classes have an implicit
this
reference to their outer class(es). So, while the inner class itself may seem serializable, it is in fact not serializable unless the implicitly referenced enclosing class is also serializable. Even if the outer class is serializable, though, it's worth noting because you may not wish to marshal up your entire bean and send it off (especially since I believe sending the bean component of an EJB violates the specification—if not in name, in spirit...the bean part of the component object model is supposed to stay put in the app server).If you use this bit of knowledge to save yourself some trouble
No comments:
Post a Comment