Ken Delong wrote: > I've run into similar issues. I often write client-side proxies for my > remote EJBs (Business Delegates, or in WebSphere, Access Beans). My > instinct is to package these separately (in a client.jar), but like you said > they also need access to the EJ Bean interfaces. I certainly don't want to > package my bean interfaces in two places.
In my case the client needs access to the actual bean as well, since I'm using the command pattern+visitor pattern instead of value objects. > To me, there seems to be a natural packaging schemes of server-side-only > classes (EJB implementation classes), client-side only (Business Delegate), > and a shared package of interfaces, exceptions, and data types that form the > shared lingo that the client and server use to talk to each other. Yes, normally this would be correct, but my case isn't normal :-( > I don't particularly like this, since now the war has access to the > server-side classes (the last thing I need is a maintenance programmer > directly instantiating an AccountBean), but it seems to be least-bother > solution. I'm not that worried about people instantiating AccountBean's. If they do, it all goes wrong, which shows itself pretty fast. Also, I expect all of those that write on the codebase to have a pretty good understanding of how EJB works. But this depends on the actual situation, of course. YMMV. /Rickard -- Rickard �berg Author of "Mastering RMI" Chief Architect, TheServerSide.com The Middleware Company - We Build Experts! =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
