Hi John, I've played with Castor and JOX, and will take the next step of eval'ing JAXB and apache soap. When I get some performance results I'll post them!
Gene --- John Harby <[EMAIL PROTECTED]> wrote: > 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". > === message truncated === __________________________________________________ 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".
