Just a simple approach to what you are doing that has worked for me in the past - define the APIs for the various services you require on the client and obtain a reference to the implementation via a service factory. I used this technique some time ago when EJBs emerged as 1.0 and were *the* talk after the '99 JavaOne. We were not sure where they would be maturity wise, so we abstracted out the services into a standard API (using a Java interface) and the implementation class was specified in a properties file. We could change the implementation by changing the properties file (on the fly, BTW). This worked well, as we built all of our services as standard Java classes, then later swapped them for stateless session beans and even a JMS connection to a message queue!
Now that EJB is pretty mature but newer distributed technologies are out, the same technique could be applied to abstract you from services that are EJB, MOM, .Net, JNI/JCA, or web service. Be sure to build the interfaces in a manner that is efficient and proper for distributed computing (serializable classes, all data in, result out in out pass, etc). Also, define the API very clearly - preconditions, postconditions, etc. so that the contract the interface is providing does not change and thus doesn't ripple changes to the client. Obviously, the solution I used is a bit dated, but it is also simple to help hide the details of the implementation from the client. Use of JNDI may be used in place of properties files, and coupling it with other solutions offered on this list and other sites can make this technique even better. Enjoy! ----- Original Message ----- From: "tek1" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "swing" <[EMAIL PROTECTED]>; "swing-advanced" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, November 20, 2001 9:26 PM 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. > _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
