Greetings everybody, I am developing a stateless session bean with both local and remote component interfaces. I am planning on using Business Interface pattern. So, I was wondering if I need to create two business interfaces, one interface (BusinessInterfaceRemote) containing business methods that throw RemoteException, and the other interface (BusinessInterfaceLocal) which contains business methods that don't throw RemoteException. Assuming that I will need two business interfaces, Local component interface will extend BusinessInterfaceLocal and remote component interface will extend BusinessInterfaceRemote. Which interface will my bean class implement? Any suggestions are appreciated. Thanks in advance !! Ram
Hello Bill, Thanks for your suggestion. I will look into XDoclet. I still am confused as to which business interface (BusinessInterfaceLocal or BusinessInterfaceRemote) the bean should implement. Does it really matter which interface the bean should implement since there is no difference between the business method signatures? Thanks a ton, Ram
Originally posted by Ram Chilukuri: I still am confused as to which business interface (BusinessInterfaceLocal or BusinessInterfaceRemote) the bean should implement. Does it really matter which interface the bean should implement since there is no difference between the business method signatures?
First of all, +1 on the XDoclet suggestion. I can't begin to convey how much happier my programming time is not having to propogate new methods from the bean to the interfaces et al. Two thumbs way up! XDoclet will generate both your local and remote interfaces, your local and remote home interfaces, and more. It takes some work to get started, so definitely subscribe to the mailing list. Now, since your remote interface is going to throw RemoteException but the local one won't, you can't use the same interface for both. What I did, however, was use the Service Delegate pattern (might be the wrong name, sorry) in front of my session beans. I started by taking the generated local interface as the business interface. Then there are two delegates that implement that interface: one remote and one local. The only difference between them is that the remote delegate catches RemoteExceptions and throws a ServiceException (unchecked application exception) with the RE as the cause. Each delegate has a session bean stub that it creates the first time the service is requested. The delegates are regular Java Beans with accessors for the JNDI factory class, URL, and root. Those are used to connect to the bean. With that, each method simply delegates to the bean (thus the name). Just last night when I was confronted with creating a third delegate for a new session bean I took the time to refactor the code. Now there is an abstract class hierarchy for the delegates: ServiceDelegate LocalServiceDelegate RemoteServiceDelegate Those declare the configuration property accessors and the framework for connecting to the bean (catching excceptions mostly). To create a pair of delegates for a new session bean, I create the interface from the generated local interface and create two classes: Local<bean>Delegate and Remote<bean>Delegate. Each extends the appropriate base class and implements the bean's business interface. All they need is one method to connect to the bean and then the actual business methods that are cut-n-paste as they all look the same. The nice thing is that I can swap out the remote or local delegate with no chnanges to the client. Since I'm using DTOs to pass all data, there are no local/remote artifacts in the delegates themselves. I'm quite sure I could create a template for XDoclet to generate the delegates, too. Maybe that's next week.
snakes are really good at eating slugs. And you wouldn't think it, but so are tiny ads:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop