Ara Abrahamian wrote: > I'm also involved in a project that has a huge swing client. What we've > done is: > > - We created stateless session beans for each sub-system or major > functionality (goods specification, filing, warehouse and sub-subsystems > like access points to specsheets and things like that).
Good. But these are not mapped to client-side use-cases right? I mean, they expose system functionality, but are not tightly bound to what the client wants to do. > - We wrapped these session beans under an Apache SOAP layer. It's easy, > just create the soap deplyment file and Apache SOAP lets you call all > remote methods or the ejbean. Is it important that you use SOAP, or is any HTTP-protocol ok? > - We use dataobjects for server-client communication. Client creates a > dataobjects, sets some values and passes it to server and vice versa. > Note that it's also easy to marshal/demarshal dataobjects via Apache > SOAP. In worst case you have to write some custom marshallers but the > important thing is that server deals with pure no-ejb no-soap normal > dataobjects and also the client. If a usecase involves several of the above-mentioned subsystems, then will the client have to do several calls? Or do you SSB's that model these on the server? > - I assume you use JDK 1.3 or higher. You can make the SOAP client > access code cleaner by using Proxy mechanism. Take a look at this > article: > http://www.javaworld.com/javaworld/jw-07-2001/jw-0706-soap.html. > Actually we had to enhance it and create some JNDI-like mechanisms to > even further hide SOAP details. Right now we just use the remote > interface of the ejbeans as the interface for the Proxy but if I find > time I'll convert them to a business interface which does not derive > from EJBObject, hence a real ejb-free client. > - The fact that you use JDO or entity beans or whatever is completely > hidden for the fat client. Use whatever is appropriate for you. I don't > know which one is the final winner, JDO or entity beans, but just > remember you should use interfaces and abstraction as much as possible, > don't expose ejbean/etc to the caller. So, it seems that what you want really is some way to * access the server using transfer objects * use HTTP for firewall reasons * hide server-implementation details from the client If so, then I think I have a better idea. Use WebWork: http://sourceforge.net/project/webwork With the recent ClientServletDispatcher servlet addition, you can now instantiate actions on the client, send them over to the server (in serialized form), and have them execute on the server. When it's done, the action is sent back, so that the client can access any result data and display it. This has a number of advantages: * optimized format, since serialization is used * no format converters needed. Pure Java * can go through firewalls since HTTP is used * since execution is on server-side, actions can use fine-grained calls to EJB's, i.e. there's no need to optimize the SSB's for remote calls. You can even use local interfaces! * Actions can get data-transfer objects from many entities or session beans at a time * regardless of how complex the use-case is, i.e. no matter how many session beans are involved in it, only one network call is made. (VEEERY IMPORTANT!) All in all, it's a killer solution for Java clients wanting to access J2EE-servers easily and in an optimized manner. Plus, if your client is an applet there is a minimal download of about 10k for the WebWork client instead of having to download huge EJB-packages or XML/SOAP parsers. /Rickard -- Rickard �berg _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
