Advice on Application Architecture_问答_开发者

I am about to build a system that will have its own engine, as well as a front end user interface. I would like to decouple these two as much as possible. The engine should be able to accept commands and data, be able to work on this data, and return some result. The jobs for the engine may be long, and the client should have the ability to query the engine at any time for its current status.

A decouple front-end / back-end system is new territory for me and I'm unsure of the best architecture. I want the front end to be web-based. It will send commands to the engine through forms, and will display engine output and current status, all through ajax calls. I will mot likely use a Spring-based web app inside Tomcat.

My question involves the best structure for engine component. These are the possibilities I'm considering:

Implement the engine as a set of threads and data structures within the web app. The advantages here would be a more simple implementation, and messaging between the web app front end and engine would be simple (nothing m开发者_如何学Goore than some shared data structures). Disadvantages would be a tight coupling between the front and back ends, reliance on the server container to manage the engine (e.g if the web server or web app crashed, so would the engine).
Implement the back end as a stand alone Java application, and expose its functionality through some service on a TCP port. I like this approach because it's decoupled from the web server. However, I'm not stoked about the amount of low-level networking / communication code required. I would prefer some higher level of message passing that abstracts Sockets etc.
Use an OSGi container like Spring DM server to host both the web app and engine. This approach is nice because the networking code is nonexistent. The engine exposes services to the OSGI container for the web app to consume. The downside here is the learning curve and overhead of a new technology: OSGi. Also, the front and back end remain coupled again which I dont really want. In other words, I couldn't deploy the front end on any old servlet container, it would have to be in the same OSGi container as the engine.

I have a feeling RMI is the way to go here, but again that's a new area of technology for me, and it still doesn't explain how to design the architecture of the underlying systems. What about JMS?

Thank you for any advice.

If you really want to decouple web app and engine,you can also deploy the engine in a different server and expose the API as web service calls (WS-* or REST).

If it's going to be a Web app, there's no need to decouple the processes like there would be if you had a desktop app front end and a server back end. So keep it simple.

The basis I would use (and am using for a project I'm working on currently as it turns out) is this kind of stack:

Spring 3
Web container
Application deployed as a Web application (WAR);
For persistence, either Ibatis (my preferred option) or JPA/Hibernate (if you prefer a more object persistence approach);
Your preferred choice of Web framework. There's no easy answer here and there are dozens to choose from, from the straight templating to the more componentized (JSF, Seam, etc). Tapestry/Wicket look interesting but I'm no expert in either.

A Spring container is entirely capable of launching a series of threads and it's quite common to do so. So what you'll need is a series of components that will simply be your engine. Unless you have a good reason to do otherwise, Spring beans within a Web application context is simple, flexible and powerful.

On the front end it depends on what you want. Straight HTML can be done with any Web framework. Even if decorated by some Javascript. I use jQuery for that kind of thing.

It only gets a little different if you want the front end to look like a desktop app (a so-called "rich" UI). For this you either need to use the Google Web Toolkit ("GWT"), possibly a component Web framework like JSF (although I tend to think these get real messy real fast) or a Javascript framework like ExtJS, SmartClient, YUI or the fairly new Uki.

You'll decouple your UI if you write your back end as services, and establish an XML or JSON message format to pass between client and services.

All the rest of cletus's comments can hold true for the back end, but the client can be blissfully unaware of it. It can even be a .NET implementation for all it cares. The focus is on the use cases and the messages, not the back end implementation.

This can also be useful in those instances when you use a non-HTML based UI (e.g., Flex).