Home/ Questions/Q 550927
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T11:20:24+00:00

I am about to build a system that will have its own engine, as

  • 0

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

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0