Application needs web and command line user interfaces

[maureenmartinez]

I am working on the architecture of a telecom monitoring application that must allow the user to kick off actions through a web page, after login security checks, and directly from a command line on the same host as the monitored system. The business-level requirements and validation should be the same, regardless of the user interface, as well as data retrieval thru the APIs of the monitored system. SMPP 3.4 will be used for the API dialog between the application and the monitored system.

The fundamental question I have is where to draw the line between the user interface tier and the business tier?

Architectural Alternatives:
-----------------------------
1. Use (custom) controller(s) for the actions, and have the command line interface translate the action arguments into an HttpServletRequest before firing the request on an action controller. The controller would use the user interface parameter in the request to determine the action view. The command line "view" would just send action results text to STDOUT, STDERR, and possibly to a log file.

2. Have the web page controller(s) translate the action request into an action domain object; fire the appropriate action on it, and then translate the domain object attributes into the appropriate Model and view. The command line "controller" (what would you call it?) would do similar things: translate the command arguments into an action domain object; fire the appropriate action on it, and then translate the domain object attributes into the appropriate Model and View.

I envision having a DAO for each action domain object type which will implement the API calls to the monitored system.

Some of the action commands may be long transactions, taking over an hour to execute. How can we use Spring to oversee the "health" of such long transactions?

Thanks for your advice.

[Alarmnummer]

Architectural Alternatives:
-----------------------------
1. Use (custom) controller(s) for the actions, and have the command line interface translate the action arguments into an HttpServletRequest before firing the request on an action controller. The controller would use the user interface parameter in the request to determine the action view. The command line "view" would just send action results text to STDOUT, STDERR, and possibly to a log file.

I don`t like this one. Now the controller has 2 different views to serve. It makes the controller more complex and what if a third view is required. It also doesn`t give much control to the client.

2. Have the web page controller(s) translate the action request into an action domain object; fire the appropriate action on it, and then translate the domain object attributes into the appropriate Model and view. The command line "controller" (what would you call it?) would do similar things: translate the command arguments into an action domain object; fire the appropriate action on it, and then translate the domain object attributes into the appropriate Model and View.

More from the same.

I would suggest creating a remote interface (with a RMI implementation) that contacts the local services. If you add security to the local services (you need this for your webinterface) you don`t have to do much for security for the remote interface (in a lot of cases it executes the call on the normal servce, provides some extra data transformation (DTO`s for example) but doesn`t do anything else. Security on the local services can be added with Acegi very easy.

for rmi in Spring see: Chapter 16. Remoting and web services using Spring

Some of the action commands may be long transactions, taking over an hour to execute. How can we use Spring to oversee the "health" of such long transactions?

This is not part of Spring. With the cli you could create your own 'httpsession' object (a map would be good enough) where you store the hibernate session (and other information like security related info) and the same goes for the servlet (the hibernate sesson would be stored in the httpsession).


You can 'integrate' systems with servlets. A few weeks ago I have created a servlet for a php frontend. and 2 months ago with another project I have created a servlet for integration with an asp (classic) frontend. But the requirements were very simple, so in these cases it was the simpelest thing to do. But if you need more control, I would suggest dropping the servlet for the cli.

[croco]

What about a commnad line JMX console ? You only need to expose your application's service through JMX, which I suppose is relativelly easy.
If you search on google, the first link is http://java.sun.com/products/JavaMan...Xperience.html. where there are 2 products mention such command line capabilities: jmanage: http://www.jmanage.org/ and http://admc.com/blaine/howtos/jmx/. I have not used these, but maybe they worth a try.

[Costin Leau]

One other options which can integrate very well with your application is using beanshell or bsf. I recommend beanshell because it is very similar to java and fairly easy to integrate.
Take a look at Groovy also as it also works as a scripting language and I think it's already integrated with Spring.