Hi Andrzej, Thanks for your input. Your architecture is a lot like mine at my old job, Kiko. There we had a SSB facade mimicing a State Machine, and a single RequestData object initializes the state machine propagation of synchronous as well as asynchronous process routes.
To implement that system in my current job would require major refactoring of the Big Blob I mentioned. This may be the long-run goal, but in the short run I may have to design a JMS layer around the Blob to satisfy our immediate needs. I would like to use XML, not because I would like to add another buzzword into our architecture :-), but because other departments in our company have been going down the SOAP/Web Services route to handle external requests and I want easy transition and adaptability in case we decide to call these external requests ourselves. Gene --- Andrzej Jan Taramina <[EMAIL PROTECTED]> wrote: > 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". > __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.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".
