I like your idea on SOAP/XML as well. Did you look at any of the JAXB examples? I think a couple of them show unmarshalling SOAP envelopes and then invoking methods. I hear alot of mixed stories on the overhead involved in using XML, it would be interesting to see some actual benchmarking rather than vague claims.
>From: Gene Chuang <[EMAIL PROTECTED]> >Reply-To: Gene Chuang <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Architecture problems: decoupling of web and App tier >Date: Fri, 28 Dec 2001 10:48:28 -0800 > >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". > John M. Harby, CEO JMH Solutions, Inc. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.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".
