JRFramework es un entorno de programaci�n que permite el desarrollo r�pido de aplicciones en Java.

La idea b�sica consiste en un fichero XML que describe la aplicaci�n y unos servicios que proveen los m�todos de negocio.

El fichero XML se genera por una aplicaci�n (el Modeler) que permite desarrollar prototipos a gran velocidad y sin cononcimientos de metodolog�as, Java , EJB o conocimientos profundos de Java.

El fichero XML es ejecutado por una aplicaci�n (el Runner) que puede estar implementado en diferentes plataformas, incluyendo versiones en cliente ligero (WEB)

El dise�o de las aplicaciones se basa en definir cada aplicaci�n como un conjunto de "Casos de Uso". Los casos de uso se definen como un conjunto de ventanas. Las ventanas se definen como un Panel y un conjunto de llamadas a Operaciones. En la definici�n de las ventanas se indica la navegaci�n a otras ventanas.

Metodo de desarrollo de aplicaciones

Los analistas analizan el problema, y ven las entidades (u objetos) del �mbito de la aplicaci�n. Despu�s enumeran los casos de uso ( o procesos ) de la aplicaci�n. Toman entonces el modeler y crean los casos de uso identificados.
Para cada Caso de uso se definen las ventanas que los forman.
Para cada ventana definen sus contenidos (sus componentes), los servicios que se pueden llamar desde cada ventana, y las navegaciones a otras ventanas seg�n los resultados de los servicios.
Para describir la apariencia de la ventana se pueden describir ventanas espec�ficas (que luego habr�n de programarse) o bien se utilizan los paneles previamente definidos de uso general. Tambien se puede utilizar un dise�ador de pantallas que incluye el modeler. Estas pantallas utilizan componentes de bajo nivel (button, label, checkBox, table,...) que se integran con la aplicacion.

El analista, una vez hecha la definici�n de ventanas, se lo pasa al equipo de programaci�n que se encarga de implementar los servicios que falten por hacer y de hacer los componentes espec�ficos que sean necesarios.

Una vez finalizado el desarrollo (con sus correspondientes pruebas) la puesta en servicio es muy sencilla, ya que �nicamente se pasa al entorno de explotaci�n un .jar con la descripci�n del caso de uso (el .xml), con los componentes especificos, los servicios, y los iconos y plantillas de esta aplicaci�n. Se a�ade la classpath del 'runner' de explotaci�n, y ya est� disponible para los clientes, sin afectar a otras aplicaciones.

A bajo nivel, la ejecuci�n es posible porque se utilizan varias tecnicas y librerias que facilitan todo el proceso.

En primer lugar se consigue un desacoplamiento en las aplicaciones, igual que el principio de MVC (Modelo-Vista-Controlador), el controlador es el runner y los XML que describen los casos de uso, la vista son los paneles de las ventanas y el modelo son los servicios que se llaman y forman los m�todos de negocio.

Para un caso de uso, tenemos separada la navegaci�n de la l�gica del programa. Igual que en 'Struts' para las aplicaciones WEB, definimos para cada ventana a que servicios puede llamar y a que ventanas ir� seg�n los resultados.
Los componentes de la ventana (paneles) y los m�todos de negocio (servicios) se comunican, �nicamente a trav�s de un 'Contexto' (igual que en 'struts') de forma que estan muy levemente acoplados y son facilemente intercambiables y reutilizables.

Si definimos los paneles utilizando nuestro editor, nos permite utilizar componentes simples sin programarlos (label, textfield, button, combobox). El truco est� en que estos widgets envian sus datos (contenido, selecci�n,...) al contexto, y otros componentes tienen 'listeners' sobre el contexto, de forma que si el contexto cambia, ellos actualizan su informaci�n. De esta manera los componentes envian datos a los servicios, y estos envian datos a las ventanas.
De esta manera definimos las ventanas, con la interacci�n entre los componentes, y la interacci�n con los servicios, sin programar nada.

Implementaci�n de los servicios.

Los servicios son clases java que se llaman. En el interfaz simplemente hay que tomar del contexto los datos que necesite el servicio y hacer el proceso. El resultado lo debe dejar en el contexto. Adem�s debe dejar un resultado que luego se utilizar� para la navegaci�n entre ventanas. Estas clases interfaz son muy simples de hacer y permiten utilizar servicios a 2 � 3 niveles, permiten usar EJB , WebServices, etc,...

Parece que se queda corto.

Efectivamente, es solo un entorno, igual que el 'Struts' para una aplicaci�n WEB, no es una aplicaci�n en s�. Simplemente necesita unos componentes y servicios b�sicos seg�n el tipo de aplicaci�n a realizar.
Necesita unos interfaces con Hibernate, con JDO, con EJB o con lo que se quiera utilizar.

A donde va...

Pues se pueden añadir ejecuci�n en java en los componentes, es decir, que podemos a�adir a los componentes fragmentos de codigo java a ejecutar segun ciertos eventos (onOpen, onSelect, onPress, etc,..) de forma que las aplicaciones sean similares a PowerBuilder, VisualBasic, Delphi, etc,.. pero en Java.

Tambien se puede a�adir un componente 'Catalogo' que tenga informaci�n sobre los elementos, los campos, los tipos, los perfiles de visibilidad, etc,.. de forma que los paneles (y las tablas) se muestren en 'run-time' sin tener que cambiar ningun programa (ni xml, ni nada). Es decir, cambiando el 'catalogo' cambiamos los campos que aparecen al editar una determinada entidad. Con este cat�logo el desarrollo es mucho m�s r�pido, porque al definir ventanas o paneles, no hay que enumerar los campos y sus tipos, sino que el cat�logo lo hace para todas las ventanas.

Por Hacer...

Falta hacer el cat�logo y hacer una implementaci�n de �l.
Falta hacer unas aplicaciones de prueba en diferentes entornos (2, 3 niveles, web services, ejb, jdo,....)