Note: the original message is posted on EJB Design forum. Please post all responds here:

http://www.theserverside.com/discussion/thread.jsp?thread_id=10968


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

Is there any particular reason why you bring up SOAP/XML in your plan? You already know both ends of the pipe so you are not dealing with unknown trading partners. Since this is an internal system, I am also making the assumption that you don't have to deal with firewall issues.

francis!

Francis, good question. I included the "SOAP" buzzword to attract more attention to my proposal! :-)

Actually, what I meant was I like to create an XML event with SOAP-like XML-RPC capability; simply these queued events can call remote ejb services. As a future consideration, other departments in my company are implementing SOAP in components to call outside services. We may call these components or outside services directly in the future, hence I'm planning for the transition.

Gene

Well, essentially you want to put some type of messaging layer to intermediate between your layers such that each can run without the other.

You have a number of products/libraries to do this ranging from just plain JMS messaging, MQS, Corba Notifications (CosNotification), XML messaging (various forms), and even funkier ones like OracleDBMessaging.

XML-RPC (and its derivate SOAP-RPC) by itself won't help as it doesn't provide a guarantee of service. If you make an RPC call and you have just dropped your App tier, the call will fail. It will up to you to do the persistance and retry behaviour.


The question is what are the more important requirements that you need to address?

do you need the QoS that a true queueing product provides?
do you need true interoperability (SOAP messages vs. just XML as payload in a specific message container)
how much coding are you willing to do?

francis!

I don't understand what this buys you. If the interfaces presented by the EJB layer change, don't you need to change your clients, whether they are talking directly to the EJBs, or translating an EJB call into XML which then gets used to call the (changed) EJB?

Tom

As long as you're using session facade and business delegate patterns you should have a resonable degree of decoupling anyway. Maintaining an additional xml message layer on front of that might end up a headache.

If rendering a page requires data from the EJB layer then it makes no difference whether you are communicating asynchronously or synchronously between tiers you will have to wait till the ejb server comes back up before a response can be generated. If there is no data read from the ejb layer and you are simply updating it then use MDB's.

Stuart