MVC framework development in Swing

Not sure whether there is any like JSF/Struts kinds are there for fat client development. I thought something similar should work well with the desktop apps. Here is what I think -

Develop a framework XML schema design that will map each of the users' screen into the event source, the listener, target business component, target business method and its parameters in terms of the source screens' saved properties. The XML will look something like this -


com.pkg.gui.Source
com.pkg.gui.listener.Listener
com.pkg.model.Model
methodName
sourceProperty

outcome
com.pkg.gui.TargetScreen
fileName

.....
Several other mappings
....

The main idea is to reduce the application code and not unnecessary handling the screen flow. The developer can concentrate on - Designing the front screen, modelling the business data and the objects containing the business logic.

Once a event is detected, the registered listener's corresponding method is invoked. Inside the method, developer can simply call - Controller.invoke(this, sourceScreen); This call will get Controller to read the XML file to find out the source screen mapping. It will take the action source by the help of the event (From the listener) and based on the mapping load the corresponding business object and invoke the designated method with the designated parameter "reflectively".

There are several gray area in this - such as - how the target screen will populate the screen's property? Essentially, what I try to do here is eliminate the developer's codes like -
if (event.source is button)
then
 if button id is search
  then
    take text from this field
    make the object of this class
    invoke this method
    if (result is x)
         initialize this screen
   else
       initialize screen x
 else
  ........
Instead of all these code under ONE listener's action method, one will write - Controller.invoke(params);

However, this seems to be a much convoluted XML design game. WIP.

Value of Meta-Information and management in an integration project

This is the most complicated integration environment for me. This takes care of all the background financial, HR, project related transactions; all the utility business related transactions with the market and the vendors; real time information flows with the field worker and also integrates the third party service provider systems with the in-house built applications. In short most of the day-today business transactions is heavily depending on the EAI software functioning properly.

This is perhaps the most complicated integration scenario for me so far. I believe the main reason being the absence of SAP and the presence of the application silos for most of the individual functionality. Some legacy applications do not have clear information anywhere. However, this is also one of the best managed projects I have ever been . Although the integration is being done with the help of a very old version of the software, manageability and maintenance of the system is very mature and in many cases the problems are prevented rather than being dealt with.

the main reason to me why it has become so mature over the years (About 6-7 years) is the management of the pertinent information, such as:
1. Preparation of a guide for any new system administrator that comprehensively provide the information about the company, running applications, architecture, details about EACH application that is connected through EAI software.
2. An application connectivity guide with the information regarding the connectivity details for each environment.
3. An interface related guide that lists out all the interfaces and the kind of transactions they are taking care of, also listing what are the end applications they connect to individually.
4. Configuration details: A sheet that gets the information regarding the configuration in the software components. For instance, X adapter is meant to connect to system Y with the following configuration in place.
5. List of the problems encountered in the productive environment and how to resolve them - possible reason and the solution/work around.
6. A system maintenance guide that will help an administrator to figure out how to health check the system.
7. A system development guide for any new development/enhancement guidelines.
8. Most importantly, a user should know where to find what. So, a meta-information (Information of information) is handy. It may be an excel sheet in a well-known shared location or a Wiki.

These are some of the basic necessary artifacts for a decent management of the EAI software.