Architecture problems: decoupling of web and app tier


EJB design: Architecture problems: decoupling of web and app tier

  1. 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!


  2. Gene,

    I would like to address one issue you brought up before I tackle all the others. The first problem you mentioned was "if the ejb/parameter objects change, we need to bounce both tiers". Whoever makes the decisions to modify the EJB interface in the production environment should be shot. :-) The #1 rule of component development is interface immutability. Once an EJB is deployed in production and begins servicing clients, the interface should not change. New iterations of the EJB can only add new functionality but should not take away or change the existing one. If you do not adhere to this rule, you run into the problems you are experiencing. Thus, decoupling is not a real solution but a stronger control over the EJB interfaces implemented in production is. The EJB developers or architects should be responsible for this.

    If you are concerned about app cluster uptime issue, you will not gain much by introducing a JMS/MDB or SOAP-like tier into your design. Web applications are inherently synchronous and do not deal well with asynchronous communications. Unless you are willing to put a progress screen between each request and response events, you will need to wait for the results returned from the app server before a page can be fully rendered. This will still not resolve your problems completely. The bottom line is: if the app server is unavailable, you can not proceed. No matter what approach you take, this will still be true. Whether an MDB or a SOAP service is handling your request, if no results are returned from the app server you will still be SOL. The whole idea behind clustering is ability to transparently add and remove machines. If the cluster is being brought down to deploy new Bean versions, hot deployment options should be researched. WLS offers this functionality.

    As far as decoupling is concerned, if you still wanted to go that route, the approaches you listed may work. In the JMS/MDB approach, you can implement the MDB Proxy pattern to distribute your messages to the correct SLSBs. You can use XML as the message format and have an MDB parse the XML to extract the arguments that will be passed to the business logic methods. Due to synchronous nature of Web applications, as discussed above, you will need to wait for the response to each message you send. You will need to create some kind of mechanism that will shield your Web pages from being aware of the internal workings of the response retrieval process in case you wanted to use other approaches.

    I can not help you with the XML persistence since I have not implemented anything similar myself.

    Good luck,
  3. Hi Leo,

    Yes, in an ideal world, the EJB interfaces as well as the serialized value objects they marshal should not change once the architecture is set. My company is far from the ideal world...

    Actually the best solution would be to break up the Big Blob into similar-service components. This way our web tier will only depend on a small blob and not worry about changes and server bounces of other departments. But I'm faced with a lot of political and technical inertia. So this JMS/XML layer may be a good interim or transitional solution.

    As for the web-presentation-asynchronous issue, what I am trying to say is a lot of our current services are by nature asynchronous already. For example, if a client needs to add money to his account, the app tier will spin off an asynchronous call to an outside resource, say bank or credit card company. The client will be notified that his account will change upon approval, which is a later time. So our feeling is why impose synchronization between our web and app tier when there isn't synchronization between the app and outside "tier"?

  4. Gene,

    if most of the processes you Web site handles are inherently asynchronous, you should definitely capitalize on that. JMS/MDB solution presents a viable route. You can package messages into XML strings and pass them to the MDB(s) that will process them. As I mentioned before, MDB Proxy pattern may be applicable in this situation. The proxy MDB will parse the XML and invoke the correct business logic to handle the message. I am not sure you would need a persistent JMS tier. A queue or several queues that handle your messages would suffice.

    The larger problem is instability of your WLS cluster. No matter what approaches you will come up with to reduce coupling between the Web and Application tiers, if the latter is down the former produces errors. A possible solution can be to create a separate (smaller) cluster for the MDBs that the Web tier communicates with. Thus, if the business logic cluster is down, your Web pages will not suffer because MDB cluster will be up. In case of an error, you can repost the message onto the same queue and continue processing it until it succeeds or number of failures exceeds a predefined limit. Other error handling techniques can also be employed. This approach, however, would only work for the asynchronous pages. Pages requiring synchronous completion would still be vulnerable to WLS cluster outages.

    If I were you, I would still try to institute a more strict control over the architecture. That would eliminate a number of problems for you and other developers and save company a lot of money. Many businesses and managers do not understand what we do technically but they understand the financial aspects of our work. If a stricter architectural control is established, the developers will not need to spend countless hours retrofitting their programs to the new interfaces, performing regression tests and redeploying their applications. The development process will become more streamlined and efficient. Projects will be delivered faster and maintenance costs will diminish. All this translates to direct savings for the company. Any IT manager that can positively affect the bottom line will be praised and promoted. Try running these arguments by yours and you will see how excited s/he will get.

    Good luck,
  5. Hi Gene,
    from a coupling viewpoint, one thing you can consider is the Business Delegate pattern. You can develop your own business delegates as local (to the web tier) classes. These delegates implement your own service interfaces that you can make stable and immutable. The web tier will use business delegates rather than the real remote services. The delegates can be implemented as adapters so that they adapt delegate's interfaces to the remote services interfaces. A change in a remote service will impact only the adapter, not the web tier applications.

    Just my two cent's.


    PS: obviuosly, the business delegates can be remote services as well. It is another architect/design choice.
  6. Hey Gene,

    The second problem you mention:

    >>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

    Isn't that just a simple problem of downtime, period? Even if asynch, your clients will either wait a long time or timeout (which I guess is better than a service-not-found).

    Can't they bounce the WL cluster so that one machine is always up? Or, failing that, if the services are so disparate, can you run your own WL cluster (or own machines in the cluster that don't get bounced) separately?

    I guess if separating your EJB logic from the others were so easy, you'd've done it, hence the name Big Blob. But that seems like the biggest problem...

  7. Part of my proposal is to refactor the web side so some actions are completely asynchronous, such as depositing money into an account. This will spawn off a persistent XML task in the queue, and a message will return to the client saying "You request has been submitted; check later for update".

    We can get away with this, in fact, we should capitalize on this, because like I stated, even though all of our current web requests are synchronous, some are intrinisically asynchronous because a ejb service may call an external service that's asynchronous.

    So, by having a persistent JMS layer between the web and app tiers, we hope to achieve higher levels of reliability and tolerability, and as a side effect, possible performance and scalability improvements, since creating XML tasks should be faster than stracktracing from the web tier through the app tier and finally to the db or system tier.