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). - 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. - 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. - 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. Ara. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:xdoclet-user- > [EMAIL PROTECTED]] On Behalf Of tek1 > Sent: Wednesday, November 21, 2001 6:56 AM > To: [EMAIL PROTECTED]; swing; swing-advanced; > [EMAIL PROTECTED] > Subject: [Xdoclet-user] advice on how to minimize client-side impact? > > hi all. > > i'm starting to design a system with a swing client and ejb/jboss on the > backend. > > with all the changes going on with ejb and evolution of other > architectures > (jdo, soap, etc.), my head is in a whirlwind as to what to use. for now, > i've decided to go with ejb/jboss since it currently the most appropriate > architecture for my system. > > however, with drastic changes to ejb2 (from 1.1, and certainly more > changes > to come) and a lot of talk about jdo and soap (which i only have basic > understanding), i'm concerned with how many changes will be needed to be > made to the client app if one changes to a different architecture in the > near future. (uncertain of how ejb, jdo, and soap relate, how they will > all tie together, if at all...) > > as such, i'm interested in how other developers are designing their > client-side (swing) apps to minimize the impact by changing server side > architectures or if the ejb spec changes in the future. > > i've attached a rough uml diagram (as a .pdf file) with notes as to a > possible solution to help clients remain agnostic to the server-side > architecture. my knowledge of jdo and soap is still very low, so i'd > appreciate any insights to these technologies, their future, and ejb's > future from the more experienced system architects. > > hope the diagram is understandable and make sense. > > if this is not appropriate for this mailing list, my sincere apologies. > > i really just want to jump into developing my system using just ejb and > forget about trying to make the client serverArchitecture-agnostic (which > could be more of a pain), but constantly seeing articles about jdo and > soap > arouses concern... > > thanks. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
