Archive for April, 2011

Hacia tiempo que no escribía un post técnico y ya ha llegado el momento. Recientemente, desarrollando una aplicación a medida para un cliente, me he visto en la necesidad de conectar una aplicación de escritorio con una aplicación web. En los años que llevo programando no he tenido necesidad de realizar esta operativa, muchas veces ha sido conectar una aplicación web con otras aplicaciones, tanto web, servidores de diferentes tipos como de escritorio, pero han sido siempre desde la perspectiva de la lógica de negocio en el servidor, consumiendo servicios web, accediendo a base de datos o incluso leyendo archivos. Esto es distinto, tengo que ofrecer acceso a mi aplicación web para aplicaciones de escritorio. Nada complicado si se utilizan webservices. Pero he aprovechado la coyuntura para probar unas nuevas herramientas, spring roo, que genera de forma espectacular una aplicación web y al que ya dedicare un post con mas tranquilidad. Por el momento decir que genera aplicaciones con JPA en Hiberanate (mas bien en cualquier cosa) y spring para el negocio. Ademas de hacer un scaffold de las web con GWT. Para la seguridad puedes incluir spring security, que es lo que yo he introducido. Hasta aquí todo bien, funciona perfectamente y sin ningún problema, puedes controlar el acceso por métodos de negocio con simples tag, muy fácil. Ahora viene la parte en que conectamos la aplicación de escritorio, en mi caso con una aplicación swing (por cierto con netbeans y matisse, muy sencillo también). Spring te ofrece un montón de opciones de interconexión, RMI directamente y de forma sencilla, HTTP-Invoke o webservices, entre muchos. He probado RMI y muy contento, pero al final me he decantado por HTTP-invoke por varios motivos:

• RMI necesita configurarse ademas un puerto concreto, complicando la instalación en según que sitios. Si el servidor y la red son tuyos no hay muchos problemas, pero si utilizas algo como la PAAS de google puedes tener algunos problemas. En cambio HTTP-Invoke usa el mismo puerto 80.

• Rendimiento: Tanto RMI como HTTP-Invoke tienen muy buenos rendimientos, ambos usan serialización de objetos.

• Configuración, al ir por el puerto 80 no requiere configuración extra de seguridad.

El problema lo tuve en la seguridad, como configurar la seguridad y realizar un login remoto, que es lo que voy a explicar aquí.

Servidor

Para configurar el lado del servidor hay que realizar los siguientes pasos:

• Crear una capa de servicios: para ello creamos unas clases en nuestro código que ofrecerá los servicios que nos interesen.

public interface ServicioSaludo {

@Secured(“ROLE_ADMIN”)

public String getSaludo();

}

@Service(“saludador”)

public class ServicioSaludoImpl implements ServicioSaludo {

@Override

public String getSaludo() {

return “Hola”;

}

}

Es en la interfaz donde declaramos la seguridad con los tags @Secured. Luego pondré la configuración básica de seguridad.

El tag @Service le indica a spring que es un bean y que debe nombrarlo como saludador, de esta manera no hará falta ponerlo expresamente en el xml de configuración. Claro que para que funcione debéis configurar vuestro spring con el siguiente código.

<context:component-scan base-package=”paquete”>

Si no, simplemente lo declaráis expresamente como un bean

<bean name=”saludador” class=”paquete.ServicioSaludoImpl”/>

Ya tenemos el servicio declarado, ahora lo exponemos con HTTP-Invoker.

<bean name=”/saludadorHTTP” class=”org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter”>

<property name=”service” ref=”saludador”/>

<property name=”serviceInterface” value=”paquete.ServicioSaludo”/>

</bean>

/saludadorHTTP indica donde estará accesible, después ponemos con que lo exponemos, e indicamos las clases que queremos exponer.

Aquí tenéis el archivo de configuración de seguridad.

<?xml version=”1.0″ encoding=”UTF-8″?>
<beans:beans xmlns=”http://www.springframework.org/schema/security”

xmlns:beans=”http://www.springframework.org/schema/beans”

xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”

xsi:schemaLocation=”http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd”>

<http auto-config=”true” use-expressions=”true”>

<intercept-url pattern=”/login.*” access=”permitAll”/>

<intercept-url pattern=”/**” access=”isAuthenticated()” />

<form-login/>

<anonymous />

<http-basic />

</http>

<global-method-security secured-annotations=”enabled”/>

<!– Configure Authentication mechanism –>

<authentication-manager alias=”authenticationManager”>

<authentication-provider>

<user-service>

<user name=”admin” password=”admin” authorities=”ROLE_ADMIN”/>

</user-service>

</authentication-provider>

</authentication-manager>

</beans:beans>

use-expressions sirve para utilizar las nuevas forma de definir las seguridad, bastante mas completas.

Global-method-security sirve para poder utilizar las anotaciones de seguridad en las interfaces que hemos usado antes.

En cuanto a lo demás, es básico en seguridad de spring, así que no haré mas comentarios.

Ahora cargamos otro dispacher de spring en el web.xml, se pueden tener todos los que se quieran, y es recomendable separarlo, si tenéis uno para el MVC de spring, podéis dejarlo intacto y añadir este otro solo para las conexiones remotas.

<servlet>

<servlet-name>remoting</servlet-name>

<servlet-class>

org.springframework.web.servlet.DispatcherServlet

</servlet-class>

<init-param>

<param-name>contextConfigLocation</param-name>

<param-value>/WEB-INF/spring/remoting-servlet.xml</param-value>

</init-param>

<load-on-startup>2</load-on-startup>

</servlet>

<servlet-mapping>

<servlet-name>remoting</servlet-name>

<url-pattern>/remoting/*</url-pattern>

</servlet-mapping>

Varias cosas, para los que no lo sepan, el contextConfigLocation no es necesario, siempre y cuando llaméis al archivo con la nomenclatura servletName-servlet.xml y ubicado en WEB-INF/classes. Si lo queréis en otro sitio y con otro nombre pues se pone.

Aquí nos quedamos con la URI /remoting, que se usara en el cliente. Con esto ya tendremos configurado el servidor.

Cliente

Le toca al cliente, en este caso utilizare una simple aplicación de consola. Necesitaremos varias cosas:

• Las interfaces del servidor: podemos empaquetar solo las interfaces del servidor y añadirlas nuestro proyecto cliente.
• Las librerias de spring: tanto el core como security.

Ahora configuramos nuestra aplicación creando un archivo de configuración cliente para spring, por ejemplo cliente.xml, e introducimos lo siguiente:

<bean id=”servicio”>

<property name=”serviceUrl” value=”http://localhost/remoting/saludadorHTTP”/>

<property name=”serviceInterface” value=”paquete.ServicioSaludo”/>

<property name=”httpInvokerRequestExecutor”>

<ref bean=”httpInvokerRequestExecutor”/>

</property>

</bean>

<bean id=”httpInvokerRequestExecutor”     class=”org.springframework.security.remoting.httpinvoker.AuthenticationSimpleHttpInvokerRequestExecutor”/>

La dirección del servicio donde lo tengáis, en mi caso en localhost, seguido de remoting que es donde mapeamos el servlet para servicios remotos y por último la dirección del servicio concreto que configuramos en el archivo xml de spring del servidor. Ademas cargamos el bean para que lo use de autenticado.

Y nos vamos al main de la clase cliente.

//Creamos una autenticación con el usuario y contraseña

Authentication request = new UsernamePasswordAuthenticationToken(“admin”, “admin”);

//Este es el contexto que extiende del servidor, es aqui donde nos logeamos

SecurityContextHolder.getContext().setAuthentication(request);

//Cargamos el archivo de configuración

ClassPathXmlApplicationContext contexto = new ClassPathXmlApplicationContext(“cliente.xml”);

 

ServicioSaludador servicio = (ServicioSaludador) contexto.getBean(“servicio”);

String cadena = servicio.getSaludo();

Y ya esta, facilísimo.

Bueno, quien dice un main dice una aplicación swing, es la mar de sencillo, yo por el momento uso netbeans que funciona muy bien.

El software a medida o los programas a medida o sistemas a medida, da igual como lo llames, la cuestión es hacer un programa a medida que cumpla con las necesidades exactas.

Lo curioso es que cuando hablo de desarrollo de software con clientes o amigos les resulta algo bastante confuso y nada claro. Como dice un amigo, toda la vida se ha llamado programas y ahora nos da por llamarlo software o sistema. Tiene razón en parte, aunque creo que la palabra programa se queda algo corta para definir los sistemas que desarrollamos ahora. Un programa que le das a ejecutar en un equipo no tiene nada que ver con los sistemas que muchos hacemos, bases de datos, servidores de aplicaciones, clientes pesados y ligeros, sistemas de transferencia de datos, transacciones, cola de mensajes, ajax, spring, gwt, google, y un largo etc … como podéis ver la cosa se ha complicado mucho desde hace unos años, y no os equivoquéis, no es malo, quizás confuso para alguien que empieza, incluso para mi hay ocasiones en que me gustaría que hubiera menos opciones, pero eso es lo bonito del desarrollo software, aprender cosas nuevas, o por lo menos para mi.

La programación es algo que al que le gusta le apasiona, y al que no le gusta lo odia. Afortunadamente a mi me encanta, y disfruto cada día de mi trabajo. Aunque tengo que admitir que cada vez que google saca una nueva versión de GWT, que suele ser cada pocos meses, me tiemblas las teclas del teclado, por que los cambios suelen ser mucho aunque impresionantes.

Pero a lo que estamos, la programación a medida, es caro, no hay duda, pero si se hace bien y siguiendo los estandares puede durar muchos años con poco mantenimiento y amortizar de sobra su inversión. Quiero hacer hincapié en dos puntos importantes:

• Poca satisfacción del cliente: este punto lo he visto en algunos casos y he llegado a la conclusión de que es debido a las elevadas expectativas del cliente, principalmente por desconocimiento del desarrollo de software. Yo entiende que no sean expertos en la programación pero existe mucha fantasía a su alrededor. Algunos se creen que programar se hacer en dos minutos, quien no ha escuchado la frase “ese campo lo cambias en poco tiempo” , sin saber que puede que tengas que cambiar la base de datos, procurando no romper la consistencia de los datos, cambiar la capa de acceso a a datos, la de servicios, y por ultimo la vista, si no te toca cambiar la capa de servicios web o cualquier otra interfaz, vamos, facilísimo.
• Por esto motivo me encanta desarrollar con metodologías ágiles, involucrando al máximo al cliente, que vea el día a día, y se enfrente a los problemas. Y por supuesto se consigue un desarrollo dirigido por el cliente y para el cliente, mejorando la satisfacción de este. Esto resulta muy interesante ya que se obtienen resultado rápidamente, aunque sea de escasa funcionalidad se parte en pocas semanas de algo tangible, aliviando la ansiedad del cliente. Y como pasa muchas veces, la teoría esta muy bien en papel, pero cuando se lleva a la práctica es cuando te das cuenta de lo poco que encaja, por eso si el cliente esta desde el principio, se puede corregir el rumbo del desarrollo sin llegar a tirar meses de trabajo.

Y por último destacar algunas ventajas, no todo son malas noticias, existen grandes ventajas y muy importantes. Si se hace bien y se mantiene correctamente, el software a medida puede durar mucho tiempo e ir evolucionando con la empresa, que en estos tiempos es un punto muy importante. Me he dado cuenta en estos últimos años que las necesidades han cambiado, la mayoría del software a evolucionando para añadir muchísimas funcionalidades llegando a ser muy complejo, más formación, mas errores cometidos, mas posibilidades para hacer el bien, pero también el mal. Pero programas como gmail, twitter y 37signal han demostrado que lo que la gente quiere es todo lo contrario, cosas sencillas y usables. Con lo que es un gran motivo para desarrollar software a medida. Y el punto mas interesante, que se pueda integrar con sistemas existentes, y eso si que es ahorro.

Algún día hablare de las historias que he tenido con algunos cliente, solo diré que los clientes que mas contentos han estado con mis desarrollos son precisamente lo que mas sabían del tema.

¿Y vosotros?¿ Habéis tenido experiencias parecidas?

Desde que Amazon ofreciera la instancia micro por un año de forma gratuita, llevo tiempo queriendo montarme una, y ahora que estamos terminando el proyecto tenemos la escusa perfecta.

Así que me he puesto manos a la obra, tutoriales un montón. Solo aportare los problemas que he tenido y sus soluciones. Aquí y aquí tenéis unos buenos tutoriales. Yo comenzé siguiendo los pasos que te da Amazon, pero hay algunas diferencias que hacían que no me funcionara.

Lo primero es aclarar algunos términos y condiciones a tener en cuenta:

• AMI (Amazon Machine Image): Es decir, las imágenes de los sistemas operativos. Hay muchas, unas son las que proporciona Amazon pero parece que son un poco mas complicadas de administrar, y otras son las de la comunidad. Yo he utilizado ubuntu y me he guiado por esta lista actualizada de imágenes de ubuntu. Importante, elegir la zona correcta, por temas de latencia.
• EBS (Elastic Block Store): Es un volumen, como un disco duro, que no se pierde al apagar o terminar la instancia. Por que realiza snapshot en S3 (Simple Storage Service). Con este volumen podeis asociarlo a cualquier instancia, si cambiais la instancia podeis mantener el EBS, eso si, asociado a una sola instancia a la vez.
• Estados, reboot, stop y start, que no requieren de explicación, salvo que si paráis una instancia se perderán los datos almacenados, salvo que se almacenen en EBS. Y Terminate, que se para la instancia y posteriormente se elimina, tarda un tiempo pero desaparecerá.

Una vez creada la instancia y almacenado en un buen sitio la key part, ojo que no se puede volver a descargar, así que guardarla muy bien, si no nos toca crear una nueva y  crear una nueva instancia, porque tampoco se puede cambiar la key de una instancia creada. Una vez la tengais en el ordenador hay que darle permisos al archivo, amazon nos dice de hacer chmod 400 pero a mi me ha funcionado chmod 600, que lo indican en la guia de ubuntu. Si queréis usar putty deberéis convertir las claves de pem a ppk, lo cual se puede hacer con puttygen.

Modificamos la seguridad en Security Groups para añadir el puerto ssh (22). Y ya solo nos queda conectarnos al servidor para seguir con lo que queramos hacer, solo un ultimo apunte, Amazon nos dice que nos conectemos por root, pero las imagenes de ubuntu utilizan el usuario ubuntu y sin contraseña.

Ya os ire contado la experiencia con estos servidores en la nube, que resultado dan y si realmente es algo interesante, por el momento lo parece, montar un servidor dedicado en pocas horas y aun coste que parece bajo, ya te lo dire cuando se termine la promoción.

¿Alguno a utilizado estos servicios en alguna aplicación? seria interesante saber con que condiciones de carga y programación funcionan estos servidores.

NOTA: He estado probando instancias ubuntu lucid de 32 bits, y hay un error conocido al instalar java. Las soluciones son instalarlo con la instancia que no sea micro y luego cambiar a micro. O si se puede reinstalar una instancia de 64bis.