Gene: > I'm presented with a middle-tier architectural reworking project and am > wondering if anyone out there have been through this and can give some > pointers.
My team did exactly this on a large Financial Services project (that sounds remarkably similar to your situation). > 1) if the ejb/parameter objects change, we need to bounce both tiers We took a layered approach to the EJB server/tier and did not expose any domain interfaces directly to the outside world (web/presentation tier) We built a Service EJB layer that acted as the intermediary between the presentation and actual domain entities. This also had a few other benefits....you can use normal Java objects in the domain layer (with a good persistence tool...we used TOPLink) and avoid the overhead of remoteable objects (we used no entity beans). It also forces you to aggregate your remote calls into high level business service invocations, which keeps the granularity (and the network traffic) at a reasonable level. Changes to the Service layer were very tightly controlled to reduce the ripple effect of broken code in both directions. The Service layer acted as a decoupler in this regard, and made use of Holder objects that were used to transport the data across the wire (which were separate objects from the real domain objects). Bit of extra work this way, but it was well worth the effort in the long run! This might not be overly practical if you don't have control over the EJB development. But you should be able to put a Service layer on top of the existing systems EJBs without much trouble. > 2) what's worse, on prod, if another department decides to bring down the > ejb tier, our browser clients are rendered useless, returning 404 pages on > all calls Furthemore, in the Web/Presentation tier we used another layered approach, based on MVC concepts. Servlets were used as the controller.....JSPs as the views and the Model (really a pseudo model, since the "real" model lives in the EJB tier) was a layer that hid the transport protocols from the Servlets/JSPs. We started using a Command pattern and eventually switched to a Facade instead (using proxy/delegate approach). This decoupled things even further...and made it easy to bury things like connection pooling, home lookup pooling and more, inside the Facade (we called it the Application layer). The only place that knew that the app was talking to a remote Service layer using EJBs was inside this Facade. This also made it easy to replace the EJB communication with JMS for asynchronous service invocation (or any other transport protocol for that matter, using XML serialization.....etc.). Things like exception handling were standardized inside the Application/Facade, and were passed back to the View/Controller for appropriate display to the end user. In this way, the user received appropriate notification if the EJB back end was dead or failed on a request. More decoupling between layers. Hmmmm...do I detect a theme here? ;-) > What I would like to do is slip in a persistent queue layer between the > web and app server. I can transform ejb-calls into XML messages > (pseudo-SOAP) and store it in a JMS persistent topic. Hence browser > requests are asynchronous and completely independent of the app tier. > Here are some of my issues: If you build your app the way I had my team do it (as per the above) then replacing EJB calls with XML/JMS messages is a fairly trivial matter that had NO ripple effect on the presentation or the domain layer code. > 1) Can I use MDB's? You could do this. Basically MDB's are just an EJB-friendly was of creating a message consumer. They would act as a transport mechanism, retreiving the queued messages and then delegating them to the appropriate Service-layer EJB for actual processing. > 2) Is XML-RPC/SOAP persistent message the way to go? Are there > alternatives? I would question the need for XML or SOAP in this situation, since you control both ends of the pipe, why go through the overhead of the XML/SOAP parsing (which is not insignificant)? You would be better to just use normal JMS messages and leave the XML behind. If you layer the messaging code, it would be easy to add XML later if you ever needed to interface to an external system/company. XML is the latest "hot thing"....but unless you need that level of decoupling (not usually necessary within a single system/company) or forsee such a need in the near future, better to just architect your transport layer so you can "plug it in" without ripple effect later and forgoe the parsing overhead. > Has anyone out there implement a similar layer and care to share your > thoughts? Thanks! See above. We did this....it worked, and it worked well. EJB Tier (Service, Domain and Persistence layers) along with the Application Layer ( Web tier, Facade) were written by my core, hotshot dev team in Canada. The Presentation layer (Web Tier, Servlet/JSP view/controller) code was written by my UK-based team. Integration testing was done by a third team in another UK location. The decoupling we used allowed me to distribute the dev load across international teams, not an easy task. Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com =========================================================================== 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".
