Hi, thanks for the input - so I'll add EJBs to the list of possible solutions :o). I agree with you, that SOAP is not really the method of choice for this kind of problem - although in some instances it might be.
Tom Emmanouil Batsis wrote: > > Hello Tom, > > In short, there is no panacea or golden formula. I usually go for EJBs > for my business logic (so, RMI & JMS). You can bypass RMI when on the > same JVM by using local interfaces and in some servers AFAIK you dont > even have to explicitly do that. > > Personally, i try to avoid web services, especially the SOAP/WSDL crap > but thats just me. REST might be good if you like it. I have seen > several systems working perfectly for years with simple XML messaging > (asynchronous or not) over HTTP; it's the implementation quality that > matters here. > > hth, > > Manos > > Tom Ziemer wrote: > >> Hi, >> >> I am a developer, currently working working on a medium scale app. There >> is a base module, which is Spring managed, that handles data access - a >> web tier and now a couple of web services. Up until now, we deployed >> everything as one application, so communication between the modules was >> API-based and thus not really an issue. Now I am wondering, whether it >> is prudent to deploy each module separately and add a communication >> layer. >> >> So my question is, whether or not it is sensible to break the app apart >> (for the sake of modularity) and if so, how the individual components >> should communicate with each other. >> >> - Most of my requests to the business layer will be synchronous, so I am >> not sure whether JMS is the right technology to apply. >> >> - RMI would result in a very tight coupling and I'd be restricted to >> using JAVA everywhere. >> >> - CORBA - haven't used it yet. >> >> - SOAP - great when interoperability is an requirement, lots of overhead >> (XML). >> >> I am not trying to start a rant about which technology is better - I am >> simply looking for the best solution for my problem. Surely, many of you >> had to make a similar decision at one point or another, so I'd be >> grateful if you would share your experiences and/or advise on how I >> should proceed. >> >> Regards, >> Tom >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
