Hi Gene,
I'm not sure that making the interface between your web-tier and
ejb-tier asynchronous is going to be what you want (if I understand you
correctly). What happens if the web server makes a request of the ejb
tier and the ejb tier doesn't come back up for 10 minutes? Placing those
requests into a queue is not going to help the user of the application
know what's going wrong.
Have you looked into the J2EE patterns from Sun? I think what might
serve you better would be to make use of the Business Delegate and Service
Locator patterns. If the ejb server is down the following is what would
happen:
1) person uses web browser to hit web site
2) web tier makes a call to the Business Delegate
3) Business Delegate tries to make use of the ejb tier (either by using
the Service Locator to find an ejb, or using a cached reference).
4) Business Delegate has trouble reaching the ejb tier (either because its
cached reference to the ejb it needed to use has gone stale, or the
Service Locator was unable to gain a reference to the ejb it needed)
5) Business Delegate translates the system level exception into an
application level exception that the web tier can interpret for the user
6) web tier displays a page to the user with an informative message ("The
system is down for maintenance right now.")
The idea, then, is to point all of your applications at the Business
Delegate and make them know nothing about the ejb tier. The Business
Delegate and Service Locator are the only ones who would know about the
ejb tier.
Disclaimer: I've never done this before. I am going to be going through
some of these same things as we move our J2EE webapp to EJB. What I
suggested above comes only from what I've read and no real world
experience whatsoever.
-M@
--
Matt Hixson
Aventail Corporation
Seattle, Washington
www.aventail.com
On Thu, 27 Dec 2001, Gene Chuang wrote:
> Hi,
>
> 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 group is mainly concerned with a browser-based client where pagesare rendered on
> Dynamo web server. Currently this server connects to a centralized Weblogic server
>for
> ejb calls. These clustered ejb servers we call the Big Blob because 3-4 departments
>use
> it and serves 50 difference SSBs for disparate services. Our delimma is we are too
> tightly coupled to the app tier for our liking:
>
> 1) if the ejb/parameter objects change, we need to bounce both tiers
> 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
>
> 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:
>
> 1) Can I use MDB's? I want the persistent queue layer to be independent from EJB
> container; are there EJB vendors that allow a separate JMS server for their MDBs?
>
> 2) Is XML-RPC/SOAP persistent message the way to go? Are there alternatives?
>
> 3) If I go the XML-persistence route, are there any good transformation API's
>available?
> I've checked out Castor and JOX for parameter-passed JavaBean-to-XML
>transformation, but
> what about actual method invocation using XML representation (pseudo-XML-RPC)?
>
> Has anyone out there implement a similar layer and care to share your thoughts?
>Thanks!
>
> Gene
>
> __________________________________________________
> 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".
>
===========================================================================
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".
