Brett mclaughlin (Brett@oreilly.com) writer and editor, O'Reilly and associates 2003 Although business delegation is really brings exciting new flexibility to your business Java design, but for each application A session bean is coding a business delegation or too much trouble. In this article in the EJB Best Practice Series, Brett McLaughlin shows you a more versatile version of how to create a business delegate: Dynamic delegation. In the previous skill article, we discussed how to use the business delegate class (please do not confuse the business interface mode) to access your EJB component. By inserting a business delegate class between client code and EJB code, we can isolate the application's Web layer with EJB semantics and business logic. One way to study this type of design is to see how common. First start with an application, the business logic and technical functions in the application are closely intertwined, and we have gradually separated the different layers of the application, and different techniques are used to reduce their interdependence. When doing this, you should find that the more common fabrication of the application underlying structure, then the more robust and maintainability over time. In this skill article, we will continue to use the ideas of common design. We will start from the restrictions on the current business delegation implementation, and then I will show you how to overcome these restrictions by creating more common (so non-tall) business delegations. Business delegation: Review reviews the business delegation of the library bean interface we discussed last month. Most of the code of the LibraryDelegate class is just a way to copy the original library bean. LibraryDelegate adds the init (), destroy (), and constructor method, and then uses these methods to delegate the task to library beans. In doing so, delegate the buffer between the Web layer and the enterprise bean. Here is the business interface of the original bean. The process of breeding is 10, 20 or more methods, in consideration of multiple session beans, otherwise the problem is not obvious. In fact, it is not rare to find a session bean with 50 or more methods! Because the service interface of the bean must include all methods of this bean, the business delegation class will also do this. That will make the code too large and it is easy to go wrong. Is your input too fast? When using EJB components, we often copy a number of methods across remote interfaces, business interfaces, implementation classes, and current business delegations. Many of us like to cut and paste them between editor windows and IDEs, rather than manually enter them, but please note: Press Option V or Control V to be as easy to erroneously entered as manual input methods - you added The more methods, the greater the possibility of error. By carefully verify that you correctly enter the method correctly, and whether it is cut and pasted, you can avoid much trouble. In addition to the huge code, we must also consider the factors. Because the DELEGATE class must copy all the methods of the bean, Bean inevitably change, you will find a lot of time to add a new method to Delegate, let alone recompile, it is possible Test the new code. As far as it is itself, this seems not very serious problem. However, if we start using the business delegation class to abstract business and representations from the technical infrastructure (in this article refer to EJB components). If you need to change your business delegation, then, in fact, our business delegate is still associated with the underlying component.
We need a better way, you said yes. There is really a better way. The dynamic delegation solution is to use dynamic delegation, and it uses Java Reflection (REFLECTION). You can make the delegate dynamically call the method of the remote interface of the target EJB component (through the Java Reflection API) without having to hardly encode each business method into the delegation. This allows thoroughly eliminating coupling from a remote interface because it does not need to be changed in the business delegation when adding a method for the service or remote interface of the service or remote interface. Using the dynamic delegation also makes it easier to change your technical infrastructure. Migrate from remote interfaces and EJB technology to another (such as Java Data Objects, JDO) only needs to change the delegated init () method. All other methods call will continue to delegate through the BEAN and can continue to be used without further changes.
Listing 1 shows the dynamic version of the Library business delegate: Listing 1. Library bean's business delegate package com.ibm.library; import java.lang.reflect.Method; import java.lang.reflect.InvocationTargetException; import java.rmi.RemoteException ; import java.util.HashMap; import java.util.Map; import javax.ejb.CreateException; import javax.naming.NamingException; public class LibraryDelegate implements ILibrary {private ILibrary library; private Map availableMethods; public LibraryDelegate () {init ( );} public void init () {// Look up and obtain our session beantry {LibraryHome libraryHome = (LibraryHome) EJBHomeFactory.getInstance () lookup ( "java: comp / env / ejb / LibraryHome", LibraryHome.class);. library = libraryHome.create (); // Get the methods available for use in proxyingavailableMethods = new HashMap (); Method [] methods = ILibrary.class.getMethods (); for (int i = 0; i
