Hi Matt,
Thanks for the pointers, I will definitely be using a proxy/delegate model for
client-side ejb calls. This way the client won't know nor care whether its calling an
ejb, creating a to-do task, or calling the service-out-of-order delegate which will
return the appropriate response.
However, we do in fact intend to make many of our web requests asynchronous. In fact,
many currently are: for example, if the client want to add money to an account, this
ultimately gets called out to an asyncronous outside process (bank, credit card company
or what not), and the money isn't verified and actually added to the account until
later.
So we are only shooting ourselves in the foot by artificially stipulating all requests
are synchronous when by nature many are not.
For now I will categorize all web possible requests into two groups, synchronous and
asynchronous. Things like login obviously will have to be synchronous, and if the
ejb-service for login verification is down, then user is screwed non-the-less.
Ultimately though I would like to be able to bundle all requests as asynchronous. So
in
the meantime I have a synchronous/asynchronous hybrid simply as a proof of concept;
this
hybrid will not necessarily be any more robust than what we currently have.
Gene
--- Matthew Hixson <[EMAIL PROTECTED]> wrote:
> 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".
>
__________________________________________________
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".
