Usos y prácticas de la arquitectura para un proyecto de software

Usos y prácticas de la arquitectura para el proyecto de Bancoppel.

Carlos Alberto Chong Antonio

31/07/2012

[Escriba aquí una descripción breve del documento. Normalmente, una descripción breve es un resumen corto del contenido del documento. Escriba aquí una descripción breve del documento. Normalmente, una descripción breve es un resumen corto del contenido del documento.]

Usos y prácticas de la arquitectura para un proyecto de software. 31 de julio de 2012

Tabla de contenido1 Definición y nomenclatura de los componentes..................................................................2

1.1 Controller. Clases java que sirven para procesar o recibir las peticiones del usuario...2

1.2 ReqBeanDTO. Clases java que sirven como parámetro para hacer llamada a los servicios....................................................................................................................................2

1.3 ResBeanDTO. Clases java que sirven como variables de retorno de los servicios........2

1.4 Interfaces de servicios. Interfaces (interfaces java) que definen los servicios expuestos.................................................................................................................................2

1.5 Servicios. Clases java donde se implementan las interfaces de servicios.....................2

1.6 Clases de ayuda de persistencia. Objetos que se utilizaran para dar soporte a la ejecución de los servicios.........................................................................................................3

1.7 Fábrica de objetos. Objetos que se encargan de la creación de los objetos.................3

1.8 Excepciones..................................................................................................................3

2 Módulo de presentación......................................................................................................3

2.1 Rutas.............................................................................................................................3

2.2 Buenas Prácticas en html, jsp, javascript y java............................................................4

2.2.1 No usar variables en javascript sin declarar con var.............................................4

2.2.2 Evitar escribir código javascript directamente en las páginas jsp, mejor generar un archivo con extensión js que contenga el código que se quiera ejecutar........................4

2.2.3 Evitar escribir el manejo de los eventos directamente en los elementos HTML, en lugar de eso se agregan por medio de javascript............................................................4

2.2.4 Evitar crear las hojas de estilo directamente en el jsp o html (Inline style), en su lugar generar la hoja de estilo en un archivo css..................................................................5

2.2.5 Evitar enviar una cadena como parámetro al setTimeout, en lugar usar funciones anónimas.............................................................................................................5

2.2.6 No escribir código java dentro de los jsp, para eso es el controller......................5

2.2.7 Evitar usar las excepciones como control de flujo................................................6

2.3 Internacionalización.....................................................................................................6

2.4 Controller.....................................................................................................................7

2.5 Llamadas a los servicios................................................................................................8

3 Servicios (Módulos: negocio, seguridad, persistencia, configuración, auditoria, etc.).......10

3.1.1 Rutas...................................................................................................................10

3.1.2 Construcción de los servicios..............................................................................11

3.1.3 Uso de los parámetros de configuración............................................................11

4 Módulo de persistencia......................................................................................................12


4.1 Ejecución hacia el middleware InterAct.....................................................................12

1 Definición y nomenclatura de los componentes

1.1 Controller. Clases java que sirven para procesar o recibir las peticiones del usuario.Nomenclatura: Controller{nombre del controlador}

Ruta: mx.com.solser.bancoppel.presentacion.controller

Nota: Deben de tener la anotación @Controller

1.2 ReqBeanDTO. Clases java que sirven como parámetro para hacer llamada a los servicios.

Nomenclatura: Req{nombre}DTO.

Ruta: mx.com.solser.bancoppel.beans.req

Nota: Deben de implementar la interfaz Serializable, el constructor debe tener visibilidad por default.

1.3 ResBeanDTO. Clases java que sirven como variables de retorno de los servicios.Nomenclatura: Res{nombre}DTO.

Ruta: mx.com.solser.bancoppel.beans.res

Nota: Deben de extender la clase abstracta AbstractRespuesta e implementar la interfaz Serializable, el constructor debe tener visibilidad por default.

1.4 Interfaces de servicios. Interfaces (interfaces java) que definen los servicios expuestos.Nomenclatura: I{nombre}.

Ruta: mx.com.solser.bancoppel.{modulo}.interfaces

1.5 Servicios. Clases java donde se implementan las interfaces de servicios.Nomenclatura: {nombre}EJBImp.

Ruta: mx.com.solser.bancoppel.{modulo}.ejb

Nota: Deben de extender de la clase ArchitectBase, y contienen las siguientes anotaciones:

@Stateless .- Indica que es un EJB sin estado.@Remote(“{nombreInterfaz}.class”).- Indica que es un EJB remoto, se pone como parámetro el nombre de la interfaz. @Interceptors(SpringBeanAutowiringInterceptor.class).- Anotación requerida por Spring.@RemoteBinding(jndiBinding="{nombreEJB}”).- Anotación para indicar el nombre con que se podrá buscar el servicio por jndi.


1.6 Clases de ayuda de persistencia. Objetos que se utilizaran para dar soporte a la ejecución de los servicios.

Nomenclatura: Los mismos nombres que en el proyecto original

Ruta: mx.com.solser.bancoppel.persistencia.helper

1.7 Fábrica de objetos. Objetos que se encargan de la creación de los objetos.

FactoryBeanReq se encarga de la construcción de los objetos que se utilizan como parámetros de los servicios.

Ruta: mx.com.solser.bancoppel.beans.req

FactoryBeanRes se encarga de la construcción de los objetos que se utilizan como parámetros de regreso de los servicios.

Ruta: mx.com.solser.bancoppel.beans.res

FactoryBeanDTO se encarga de la construcción de los beans.

Ruta: mx.com.solser.bancoppel.beans

1.8 Excepciones.

ArchitectException.- Se lanzan cuando no se cumple con lo especificado en la arquitectura.

PersistenciaException.- Se lanza cuando fallan los llamados a InterAct.

2 Módulo de presentación. El módulo de la presentación, está formado por archivos java, jsp, js, css, png, jpg, etc. utilizando como base el framework de spring mvc.

2.1 Rutas

Las rutas donde se deben de colocar cada uno de los componentes es la siguiente:

Archivos de contexto de la aplicación:

mx\com\solser\architecbase\bancoppel\config\Context-Mode.xml

mx\com\solser\architecbase\bancoppel\config\ApplicationContext.xml

WebContent\WEB-INF\Principal-servlet.xml

WebContent\WEB-INF\Publico-servlet.xml

Archivos jsp: WebContent\WEB-INF\jsp\privado\

WebContent\WEB-INF\jsp\publico\

Archivos java “Controller”: mx.com.solser.bancoppel.presentacion.controller

Archivos js: WebContent\js\publico

WebContent\js\privado

2.2 Buenas Prácticas en html, jsp, javascript y java.

2.2.1 No usar variables en javascript sin declarar con var

Mal: index = 0 Correcto:

var index = 0

2.2.2 Evitar escribir código javascript directamente en las páginas jsp, mejor generar un archivo con extensión js que contenga el código que se quiera ejecutar.

Mal:

<SCRIPT LANGUAGE="JavaScript"></SCRIPT>

Correcto:

<script type="text/javascript" src="${pageContext.servletContext.contextPath}/js/publico/index.js"></script>

deshabilita:function(){$('body').bind('keydown',global.disableCtrlKeyCombination);}

2.2.3 Evitar escribir el manejo de los eventos directamente en los elementos HTML, en lugar de eso se agregan por medio de javascript.

Mal:

<a href="" style="color: #4ae7ff; font-family: verdana; font-size: 10;" onclick="abreSesion(2, 'frmActivacion.jsp'); window.status='BanCoppel'; return false;" >Activar Usuario</a>


Correcto:

$('#frmActivacion').bind('click',function(){index.abreSesion(2, 'frmActivacion.go');window.status='BanCoppel'; return false;

});

2.2.4 Evitar crear las hojas de estilo directamente en el jsp o html (Inline style), en su lugar generar la hoja de estilo en un archivo css.

Mal:

<table border="0" align="center" cellspacing='3' bgcolor="#0171b9" width="100%" style="color: #4ae7ff; font-size: 10;">

Correcto:

table { font-family:Arial, Helvetica, sans-serif; font-size:10px; color: #4ae7ff;}

2.2.5 Evitar enviar una cadena como parámetro al setTimeout, en lugar usar funciones anónimas.

Mal:

var det_maskUsuario=setTimeout('EnmascaraV2("maskUsuario","usuario",true)',1);

Correcto:

var maskUsuario = “maskUsuario”;var usuario = “usuario”;

var det_maskUsuario=setTimeout(function(){

EnmascaraV2(maskUsuario,usuario,true);},1);

2.2.6 No escribir código java dentro de los jsp, para eso es el controller

Mal :

<% request.getSession().setAttribute("SesionActiva", "True"); request.getSession().setAttribute("mostrarCodigo", new Boolean(true)); %>


2.2.7 Evitar usar las excepciones como control de flujo.

Mal :

try{ if(iDv != iDvNumero){ throw new Exception("error:UsuarioGeneral"); } if(usuarioForm.getNumCliente().trim().compareTo(respStores[1].trim())==0){ bValida=true; }else { throw new Exception("error:UsuarioGeneral"); }

}catch(Exception e){

if(e.getMessage().compareTo("error:UsuarioGeneral")==0){request.setAttribute("error", "error.usuario.datoserroneos");

}

}

Correcto:

if(iDv == iDvNumero){ if(usuarioForm.getNumCliente().trim(). compareTo(respStores[1].trim())==0){ bValida=true; }else { request.setAttribute("error", "error.usuario.datoserroneos"); } }else{

request.setAttribute("error", "error.usuario.datoserroneos"); }

2.3 Internacionalización

Para manejar la internacionalización se debe de agregar al inicio de cada jsp las siguientes líneas:

<%@ page isELIgnored="false" %> <%@ taglib uri="http://www.springframework.org/tags" prefix="spring"%>

Cada uno de los textos que se van a internacionalizar deben agregarse en alguno de los archivos de properties:

publico.properties: para los textos de los jsp que se encuentren en la parte pública.

privado.properties: para los textos de los jsp que se encuentren en la parte privada.

messages.properties: para los mensajes de error


Los archivos mencionados se encontraran en la siguiente ruta del proyecto BanCoppelClient:

mx.com.solser.architecbase.bancoppel.config.i18n

La nomenclatura que se seguirá para los properties es la siguiente:

{publico|privado}.{nombre del jsp}.{label} = {descripcion}

Ejemplo:

publico.index.nomBanco = Banca Electrònica BanCoppelpublico.index.cveAcceso = Clave de Acceso:

Para hacer uso de dichos properties primero se deben de declarar dentro de los jsp y esto se hace de la siguiente manera:

<spring:message code="publico.index.nomBanco" var="nomBanco" /><spring:message code="publico.index.cveAcceso" var="cveAcceso"/>

Ya que hayan sido declarados se pueden utilizar con la notación ${variale}.

Ejemplo:

<td><strong>${cveAcceso} </strong></td>

2.4 Controller

El controller es el encargado de recibir y/o procesar las peticiones del cliente, para generar un controlador se genera una clase java con la anotación de @Controller.

Ejemplo:@Controller

public class ControllerPublico {

...

}

El nombre de la clase puede ser cualquiera pero por convención en el proyecto debe de empezar con el prefijo Controller y todos los controller se ubicaran en la siguiente ruta: mx.com.solser.bancoppel.presentacion.controller.

Dicha clase se debe de registrar en uno de los archivos de contexto que se están manejando en la aplicación (/WEB-INF/Publico-servlet.xml, /WEB-INF/Principal-servlet.xml).

Ejemplo:

<bean id="controllerPublico" name="controllerPublico" class="mx.com.solser.bancoppel.presentacion.controller.ControllerPublico"></bean>


Para que el controlador pueda procesar la petición del usuario, primero se debe de definir un método con la anotación @RequestMapping. La anotación @RequestMapping sirve para hacer el mapeo de la petición con el método, por lo cual dicha anotación requiere como parámetro el nombre de la petición (pagina). Cada método que se utiliza para procesar peticiones debe de regresar un objeto del tipo ModelAndView. En el constructor del objeto ModelAndView se envía el nombre del jsp sin extensión como parámetro.

Ejemplo:

@RequestMapping(value="index.go")public ModelAndView view() {

return new ModelAndView("index");}

En la mayoría de las ocasiones las peticiones vienen con parámetros, para poder procesar dichos parámetros se deben de utilizar los objetos HttpServletRequest request y HttpServletResponse response, los cuales se deben de definir como parámetros del método que va a procesar la solicitud.

Ejemplo:

@RequestMapping(value="/activar.go") public ModelAndView activar(HttpServletRequest request, HttpServletResponse response) {

String numTarjeta = request.getParameter("numTarjeta");String folioact = request.getParameter("folioact");String sucursal = request.getParameter("sucursal");return new ModelAndView("activar");

}

Para que el controlador pueda funcionar desde la arquitectura debe de extender de la clase ArchitectBase.

Ejemplo:

@Controllerpublic class ControllerPublico extends ArchitectBase{…}

2.5 Llamadas a los servicios

Para que el controlador pueda hacer llamados a los servicios de otros módulos primero se tiene que registrar un objeto del tipo JndiTemplate, dicho objeto nos permitirá obtener las referencias a los servicios remotos. Para poder usar el JndiTemplate primero se tiene que configurar y para esto se carga un archivo de properties llamado jndi.properties. El archivo jndi se encuentra en la siguiente ruta:

mx/com/solser/architecbase/bancoppel/config/jndi.properties


Para cargar el archivo de properties se tiene que agregar una configuración a los archivos de contexto de la aplicación:

<context:property-placeholder location="classpath:mx/com/solser/architecbase/bancoppel/config/jndi.properties"/>

Registro del objeto del tipo JndiTemplate:<bean id="jndiSeguridadTemplate" class="org.springframework.jndi.JndiTemplate"> <property name="environment"> <value> java.naming.factory.initial = ${seguridad.java.naming.factory.initial} java.naming.factory.url.pkgs = ${seguridad.java.naming.factory.url.pkgs} java.naming.provider.url = ${seguridad.java.naming.provider.url}

</value> </property></bean> Ya que se tiene registrado el objeto JndiTemplate se pasa a registrar el servicio a utilizar, para eso se utilizara como ayuda un objeto del tipo JndiObjectFactoryBean el cual recibe los siguientes parámetros:

Propiedad: jndiTemplateReferencia: Es el nombre del objeto JndiTemplate que se definió con anterioridad en nuestro caso es jndiSeguridadTemplate.Propiedad: jndiNameReferencia: Es el jndi con el que se va a localizar el servicio mx.com.solser.bancoppel.seguridad.ejb.LoginEJBPropiedad: proxyInterfaceReferencia: Es la interface (interface java) definida para el servicio.

<bean id="loginService" class="org.springframework.jndi.JndiObjectFactoryBean"> <property name="jndiTemplate" ref=" jndiSeguridadTemplate"/> <property name="jndiName" value="mx.com.solser.bancoppel.seguridad.ejb.LoginEJB"/> <property name="proxyInterface" value="mx.com.solser.bancoppel.seguridad.interfaces.ILogin"/></bean>

Ya que se tiene definido el servicio a utilizar, el siguiente paso es configurar el controller para que se le pueda inyectar dicho servicio, para lo cual se requieren dos pasos el primer paso es definir una propiedad cuyo tipo es el definido en proxyInterface: mx.com.solser.bancoppel.seguridad.interfaces.ILogin.

Ejemplo:

@Controllerpublic class ControllerPublico extends ArchitectBase{

private ILogin loginService = null;/** * @return El loginService */


public ILogin getLoginService() {return loginService;

}/** * @param loginService lo setea en la propiedad loginService */public void setLoginService(ILogin loginService) {

this.loginService = loginService;}

}

El segundo paso es modificar la definición del controller en el archivo de contexto, en la definición del controller se agrega la propiedad del servicio.

<bean id="controllerPublico" name="controllerPublico" class="mx.com.solser.bancoppel.presentacion.controller.ControllerPublico">

<property name="loginService" ref="loginService"/></bean>

Después de que se hayan realizados los 2 pasos anteriores se puede utilizar el servicio en cualquier método dentro del controller.

@RequestMapping(value="/login.go")public ModelAndView activar(HttpServletRequest request, HttpServletResponse response) { ….

String usuario = request.getParameter("usuario");String password = request.getParameter("password");

reqLoginDTO = FactoryBeanReq.getReqLoginDTO(usuario, password, remoteAddr);

loginService.login(reqLoginDTO,getSessionBean());return new ModelAndView("inicio");

}

NOTA: Al hacer la llamada a los servicios siempre se debe de pasar como parámetro un objeto del tipo ArchitectSessionBean el cual se puede obtener haciendo uso del método getSessionBean() que proporciona la arquitectura.

3 Servicios (Módulos: negocio, seguridad, persistencia, configuración, auditoria, etc.)

3.1.1 Rutas

Las rutas que tendrán cada uno de los componentes serán los siguientes:

Interfaces:

mx.com.solser.bancoppel.{modulo}.interfaces


Implementaciones EJB:

mx.com.solser.bancoppel.{modulo}.ejb

Archivos de contexto:

/beanRefContext.xml

mx\com\solser\architecbase\bancoppel\config\SeguridadContext.xml

mx\com\solser\architecbase\bancoppel\config\PersistenciaContext.xml

mx\com\solser\architecbase\bancoppel\config\ConfigContext.xml

mx\com\solser\architecbase\bancoppel\config\NegocioContext.xml

3.1.2 Construcción de los servicios

Los servicios están construidos a partir de EJBs versión 3.0 utilizando como ayuda el framework de spring. Los pasos para definir un servicio son los siguientes:

a) Generar un interfaz (interfaz de java) con los servicios que se expondrán al cliente. Cada uno de los métodos definidos en la interfaz deberán recibir un objeto del tipo ArchitectSessionBean. Como parámetro debe de recibir un objeto del tipo con prefijo Req, y el objeto de la arquitectura ArchitectSessionBean y como respuesta debe ser un objeto del tipo con prefijo Res.

public interface ILogin {ResLoginDTO login(ReqLoginDTO login, ArchitectSessionBean sessionBean);

}

b) Generar la clase que implementa dicha interface con las anotaciones correspondientes

@Stateless@Remote(IUsuarios.class)@Interceptors(SpringBeanAutowiringInterceptor.class)@RemoteBinding(jndiBinding="mx.com.solser.bancoppel.persistencia.ejb.UsuariosEJB")

public class LoginEJBImp implements ILogin{

public ResLoginDTO login(ReqLoginDTO login, ArchitectSessionBean sessionBean) {...

}

3.1.3 Uso de los parámetros de configuración


Para poder utilizar los parámetros de configuración, se tienen que agregar como propiedad el servicio parametroService tanto en los contextos de la aplicación como en la clase java.

<bean id="bDIbpi" name="bDIbpi" class="mx.com.solser.bancoppel.persistencia.helper.BDIbpi" depends-on="parametroService">

<property name="parametroService" ref="parametroService"></property></bean>

4 Módulo de persistencia

4.1 Ejecución hacia el middleware InterAct

Se utilizaran clases de ayuda las cuales tendrán como propiedad un objeto del tipo Executor. Este objeto será el encargado de mandar a ejecutar la trama hacia interAct. Para la ejecución se realiza con el llamado al método executeInterAct la cual recibe dos parámetros, el primero parámetro es la trama y el segundo parámetro es el nombre de la base.

Ejemplo:

private Executor executor = Executor.getInstance();

public ResLoginDTO login(final ReqLoginDTO reqLoginDTO) {...oRec = executor.executeInterAct(trama, paramNegocio.BDBPI);...

}

El método executeInterAct regresa un objeto del tipo Header que contiene el resultado de la consulta. La cadena resultante se obtiene a partir de la llamada get_io_buf.

Ejemplo:

oRec = executor.executeInterAct(trama, paramNegocio.BDBPI);

String resp = oRec.get_io_buf()

Usos y prácticas de la arquitectura para un proyecto de software

Documents

Transcript of Usos y prácticas de la arquitectura para un proyecto de software