Secciones

Arquitectura del Software: Requisitos no-funcionales

Los requisitos no funcionales son aquellos requisitos que no aparecen en casos de uso.  Estos requisitos, en lugar de definir lo que la aplicación hace, definen cómo la aplicación proporciona las funcionalidades requeridas.


Hay tres áreas ámbitos los requisitos no funcionales




  1. Técnicos: Estos son familiares para todos. Se limitan las opciones de diseño mediante la especificación de algunas tecnologías que se deben utilizar. "Sólo tenemos los desarrolladores de Java, por lo que debemos desarrollar en Java." "La base de datos existente se ejecuta en Windows XP." Estos requisitos son por lo general, no negociables.
  2. De negocio: Para los negocios, no hay razones técnicas. Por ejemplo, "A fin de ampliar nuestra base de clientes potenciales, se debe interactuar con las herramientas de XYZ." Otro ejemplo es "El proveedor de nuestro middleware ha aumentado sus precios a niveles prohibitivos, por lo que nos estamos moviendo a una versión de código abierto." La mayoría de estos requerimientos también son no negociables.
  3. De calidad: definir los requisitos de una aplicación en términos de escalabilidad, disponibilidad, facilidad de cambio, la portabilidad, facilidad de uso, por rendimiento...
Una arquitectura de un sistema, aplicación o proyecto debe también tener en cuenta los requisitos que no aparecen explícitamente en los casos de uso del sistema. Los arquitectos del software, por tanto, tienen la  necesidad de entender los requisitos funcionales, para crear una plataforma que apoye  dichos requisitos y satisfaga también los requisitos no funcionales.

Definiciones de Arquitecto de Software

Tratar de definir un término como la arquitectura de software es siempre una actividad potencialmente peligrosa. Realmente no hay una definición ampliamente aceptada por la industria. 

Para comprender la diversidad de puntos de vista, basta con navegar por la lista que mantiene la Software Engineering Institute Ingeniería del Software. No tengo intención de añadirme a este debate. En su lugar, vamos a examinar tres definiciones.
Vamos a comenzar con la definición adoptada por el IEEE:
“Architecture is defined by the recommended practice as the fundamental  organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.”
[ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems]
Esta definición sienta las bases para comprender de la disciplina. La arquitectura del software estructura el sistema de captura en términos de componentes y cómo estos interactúan entre sí. También define el conjunto de normas de diseño cómo un sistema puede evolucionar.
A continuación, vamos a analizar el punto de vista de algunos de los principales pensadores en la materia.
“The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.”
[L.Bass, P.Clements, R.Kazman, Software Architecture in Practice (2nd edition), Addison-Wesley 2003]
Esta nueva definición está basada en la anterior definición ANSI/ IEEE; especialmente en lo que hace que el papel de la abstracción y en una arquitectura con múltiples puntos de vista. 

Por último, comparemos esta definición con esta otra ofrecida por de D. Garlan y M. Shaw:
“[Software architecture goes] beyond the algorithms and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives.”
[D. Garlan, M. Shaw, An Introduction to Software Architecture, Advances in Software Engineering and Knowledge Engineering, Volume I, World Scientific, 1993]
Es interesante revisar estas tres definiciones, ya que todas ellas tienen bastantes cosas en común. He incluido esta tercera, principalmente porque hace referencia explícita acerca de determinadas cuestiones, como la escalabilidad y la distribución, que están implícitas en las dos primeras.

En resumen, la mayor parte del tiempo de un arquitecto dentro de un proyecto, está dedicado a estudiar la forma de particionar con sensatez una aplicación en un conjunto de componentes interrelacionados, sus módulos, objetos y cualquier unidad de software, con el objetivo de definir una arquitectura que sea capaz de satisfacer las necesidades y limitaciones específicas del proyecto.


SOA Manifesto

La semana pasada, entre los días  el 22 y 30 de Octubre del 2009, tuvo lugar en Rotterdam el 2º Symposium anual de SOA. Uno de los mayores acontecimientos que tuvo lugar durante este evento fué la redacción del "Manifiesto SOA", escrito y aprobado por muchas de las personas más influyentes.

El resultado se publicó por primera vez en la web y este escueto texto es, sin duda alguna, ofrece la definición más apropiada que se puede conseguir en estos momentos sobre las arquitecturas SOA.

A parte de las definiciones que aparecen descritas en el documento, he prestado especial atención a la parte de prioridades, ya que pienso que es muy esclarecedora y que ofrece una visión bastante real de los retos que una organización debe afrontar para poder conseguir implantar con éxito una arquitectura SOA.



Conseguir anteponer las prioridades de la izquierda en color verde, sobre la de la derecha de color morado, es uno de los retos más difíciles y motivadores en los que nos podemos encontrar a la hora de implantar una arquitectura SOA dentro de una organización.

HISPASEC: ¿Cuando tardan los grandes fabricantes de software en arreglar una vulnerabilidad?

Hispasec sistemas, ha publicado un estudio en Septiembre del 2009 sobre el tiempo que tardan los grandes fabricantes de software del mundo en solucionar sus vulnerabilidades.

El estudio se basa en las vulnerabilidades detectadas o compradas por iDefense y ZeroDayInitiative. Estas empresas se encargan de comprar vulnerabilidades detectadas por usuarios para después verderselas a las compañias de software, a cambio de no publicar la vulnerabilidad hasta que la compañía no tenga preparado el parche.



En esta gráfica podemos ver que la gran mayoría de empresas de software tardan más de 3 meses en resolver más del 30% de sus vulnerabilidades. Entre las peor paradas podemos destacar a Oracle, empresa que tarda más de 9 meses en resolver el 50% de sus incidencias.

En este fragmento, extraído del informe que comentamos, hacen una dura crítica a Oracle por su falta de compromiso con la resolución de vulnerabilidades:


Sin duda Oracle ha sido el peor parado en este estudio, y no sin razón. Desde siempre, ha tenido serios problemas para administrar la seguridad de sus múltiples productos. A pesar de sus esfuerzos para mejorar su política de seguridad, no ha conseguido gestionar eficazmente las vulnerabilidades descubiertas, y ha sido duramente criticado por “abandonar” a sus clientes con vulnerabilidades públicas, explotadas, reconocidas y graves. En 2004, pasó 8 meses sin solucionar 34 vulnerabilidades conocidas. Paradójicamente, a finales de 2001 Internet se llenó de anuncios y banners que prometían que la nueva versión de Oracle era irrompible. Entre la comunidad, este mensaje perteneciente a una agresiva campaña de marketing no pudo más que tomarse a broma. No tardaron en aparecer todo tipo de desbordamiento de memorias intermedias, fallos remotos, locales, internos, exploits... algunos inclusos obvios y triviales. El software de Oracle seguía siendo vulnerable a todo tipo de fallos de seguridad, tanto o más que sus predecesores y, con el tiempo se está demostrando, menos que sus sucesores.

Aconsejo a quienes esteis interesados en el tema en no quedarse sólo con los resultados de las gráficas,  y leais el artículo completo.

Throttling en Oracle Service Bus

Una de las nuevas funcionalidades que se ofrecía en la versión Aqualogic Service Bus 3.0 y que incorpora en Oracle Service Bus 10g es el throttling.




El throttling es una técnica que permite restringir el flujo de mensajes que recibe un business service.


Podeis encontrar información más detallada en aquí.

Saludos,
JK

Tip: Unlimited Strength Jurisdiction Policy Files

Debido a restricciones sobre la exportación de productos criptográficos impuesto por los EEUU, las jdk's y jre's que nos descargamos de Java Sun tienen una limitación que afecta al uso de claves cuyo tamaño excede unos determinados límites.

Si al realizar algún tipo de operación criptográfica, obtenemos un mensaje de este estilo o similar:

Exception in thread "main" java.security.InvalidKeyException:

Puede indicarnos que tenemos una limitación en el uso de claves de un cierto tamaño. Para eliminar esta restricción, debemos descargar de la dirección la web de sun http://java.sun.com/javase/downloads/index.jsp el siguiente link:



Una vez descargado, debemos extraer el contenido en la ruta jre/lib/security.



SOA: JMS Queues versus JMS Topics

Una cola de mensajes es un lugar común donde las aplicaciones pueden publicar y consumir mensajes. Existen así 4 componentes principales en un sistema de mensajería:
  • el publicador,  quien publica un Mensaje en una Cola
  • el consumidor, quien consume Mensajes de una Cola
  • el mensaje, que tiene algún formato que tanto publicador como consumidor conocen.
  • la cola, que es el lugar donde publicadores y consumidores se conectan y comunican a través de mensajes.
Una de las grandes ventajas que ofrece el uso de colas respecto a otras tecnologías, es que el publicador y el consumidor no tienen porque estar disponibles a la vez.

Existen dos tipos de colas en Java Message Service  o JMS; Topic y Queue:
  • En las colas tipo Queue, existen uno o varios publicadores, y un consumidor. Los publicadores van dejando sus mensajes en la cola, y son tomados en orden por el consumidor. Si el consumidor no está disponible, la cola va guardando los mensajes, de manera que el consumidor pueda retomar su procesamiento cuando vuelva a estar disponible.

  • En las colas tipo Topic,  siguen el modelo "publicador/subscriptor". Uno o varios consumidores se "suscriben" al Topic, y van reciendo los mensajes que se publican. Cuando se desconectan dejan de recibir esos mensajes, y los pierden.


De esta forma, podemos decir que:
  • Las colas tipo Topic se utilizan cuando la información es "time sensitive", por ejemplo en las quotas de stocks...
  • También utilizaremos las colas Topic cuando la información se envía a una audiencia amplia.
  • En cambio utilizaremos colas de tipo Queue cuando realizemos transacciones.
Saludos,
JK


SOA: Bajo acoplamiento versus composición

Los principios de diseño de servicios que propone Tomas Erl en su libro "SOA: Principles of service design", habla de los siguientes principios que se deben tener en cuanta a la hora de diseñar servicios en una infraestructura SOA:
  1. Estandarización y diseño del contrato.
  2. Bajo acoplamiento.
  3. Abstracción.
  4. Reusabilidad.
  5. Autonomía.
  6. Sin estado. (Stateless)
  7. Catalogación.
  8. Composición.
En este post, voy a hablar de la relación entre el bajo acoplamiento y la composición, pero antes creo que es necesario algunas definiciones:
Acoplamiento: Unión de dos piezas o cuerpos que se ajustan perfectamente.
Composición:  Acción y resultado de componer.
Componer: Formar una cosa juntando y ordenando varias.
Como podéis comprobar en estas definiciones, ambos principios están bastante ligados, ya que tratan de temas relacionados con la unión entre componentes. Por tanto cuando se define un servicio con un grado de acoplamiento bajo, se están diseñando piezas independientes, es decir, que su grado de ajuste es mínimo.
Esta característica tiene una serie de ventajas, quizás la más importante sea que si alguno de los componentes cambia, la repercusión sobre los demás será pequeña, cosa que no sucedería si el grado de acoplamiento fuera alto.

La composición por contra, mide la capacidad de crear servicios nuevos a partir de otros. Pero si estos servicios tienen un índice de acoplamiento bajo, tendré más dificultad para componer nuevos a partir de los existentes, ya que su grado de ajuste en pequeño.

Como conclusión, cuando menor sea el grado de acoplamiento, menor será el grado de composición o al menos mayor será el trabajo que se debe realizar para componer nuevos servicios.

Espero no haberos aburrido demasiado con este tema.

Saludos,

JK

Tip: Portecle; GUI sobre keytool

Otra de las herramientas Open Source que utilizo bastante a menudo y que facilita el trabajo con almacenes de claves en Java, también denominadsos KeyStores es Portecle.


Se trata de una GUI sobre Java que permite realizar de forma sencilla tareas como:
  • Create, load, save, and convert keystores.
  • Generate DSA and RSA key pair entries with self-signed version 1 X.509 certificates.
  • Import X.509 certificate files as trusted certificates.
  • Import key pairs from PKCS #12 and PEM bundle files.
  • Clone and change the password of key pair entries and keystores.
  • View the details of certificates contained within keystore entries, certificate files, and SSL/TLS connections.
  • Export keystore entries in a variety of formats.
  • Generate and view certification requests (CSRs).
  • Import Certificate Authority (CA) replies.
  • Change the password of key pair entries and keystores.
  • Delete, clone, and rename keystore entries.
  • View the details of certificate revocation list (CRL) files.
Saludos,

JK


Tip: Howto testing Two ways SSL

Cuando nos encontramos con problemas al configurar un servidor con seguridad SSL podemos utilizar las herramientas que vienen por defecto con openssl.

One-Way SSL
Si queremos testear una conexión SSL que no requiere autenticación por parte de cliente, podemos utilizar el siguiente comando:
openssl s_client -connect localhost:443
Two-Way SSL
Si queremos testear una conexión SSL que requiere autenticación de cliente,el comando es un poco más complicado:
openssl s_client -connect localhost:443 -key test_1.pem -cert test_1.cer

test_1.pem es la clave privada del certificado utilizado para identificarse como cliente.
test_1.cer es el certificado de la clave privada.
En este link podeis algunos howtos muy interesantes sobre temas relacionados con el protocolo SSL o TLS.

Saludos,
JK

LiveScribe; Mi nuevo gadget

Hace unos días compré por ebay mi nuevo gadget. Se trata del bolígrafo digital de la marca livescribe.

A partir de ahora, espero no volver a perder ninguna nota de este estilo:



O de este otro ;-)

También puedo guardar las firmas digitales de algunos compañer@s:


Y como una imagen, o video en este caso, vale más que mil palabras, aquí os dejo el link donde podeis ver las cosas que se pueden hacer con el:




Tip: TinyCA; Una CA simple

Muchas veces necesitamos realizar tareas que implican tener conocimientos sobre temas relacionados con la seguridad criptográfica, como por ejemplo, configurar un servidor con SSL, crear un certificado de servidor, crear un certificado de cliente, crear un webservices con tokens SAML...

Para facilitar este tipos de trabajos, podemos utilizar TinyCA que es una herramienta para generar de forma gráfica y sencilla tareas como las que hemos comentado anteriormente y además funciona tanto en Linux como en Windows.



Para todos aquellos Ubunteros, que cada vez somos más, la instalación es muy sencilla, basta con ir al gestor de paquetes y buscar tinyca, para los de windows next --> next --> next... ;-)

Por cierto, Josep White, era esta la herramienta que utilizamos ;-)


Saludos,
JK

Tip: Default Passwords in Weblogic 10g R3 KeyStore

Por defecto cuando se instala Weblogic Server 10g R3, se crean una serie de KeyStores donde se encuentran las claves y los certificados generados por defecto. Se crean dos keystores:
  • DemoIdentity.jks. Contiene las claves privadas utilizadas para establecer sesiones SSL de servidor.
  • DemoTrust.jks. Contiene la lista de autoridades de certificación de confianza.
Los passwords por defecto para cada uno de estos keystores, son:
  • DemoIdentity.jks. DemoIdentityKeyStorePassPhrase
  • DemoIdentity.jks. DemoTrustKeyStorePassPhrase
Saludos,
JK

WorkShop: Best Practices en el diseño de WebServices

¿Quien no ha realizado alguna vez una prueba de concepto sobre webservices? La gran mayoría de IDE's ofrecen ya la posibilidad de crear de forma simple y sencilla un web service sin necesidad de tener un conocimiento profundo de la tecnología básica, es decir, sin saber que es una WSDL, XSD, SOAP, y por supuesto XML... Pero cuando queremos llevar a cabo desarrollos que van más hallá de esas pruebas iniciales, es necesario conocer y dominar estas tecnologías.

A parte de dominar la tecnología, también es necesario tener en cuenta una serie de principios de diseño que nos van a permitir crear servicios con un alto grado de reutilización. Estos principios son comentados en profundidad en el libro de Tomar Erl , "SOA Principles of Service Design":
  • Standardized Service Contract
  • Service Loose Coupling
  • Service Abstraction
  • Service Reusability
  • Service Autonomy
  • Service Statelessness
  • Service Discoverability
  • Service Composability

Para dar a conocer tanto la parte de tecnología como la parte de diseño de servicios web, junto con Pedro Canet, hemos preparado un workshop que se impartirá los días 26 de Junio y 03 de Julio en IN2.

Saludos,

JK

Freemind y Xmind: Mapas mentales open source

La definición de mapas mental según la wikipedia:

Un mapa mental es un diagrama usado para representar las palabras, ideas, tareas, u otros conceptos ligados y dispuestos radialmente alrededor de una palabra clave o de una idea central. Se utiliza para la generación, visualización, estructura, y clasificación taxonómica de las ideas, y como ayuda interna para el estudio, organización, solución de problemas, toma de decisiones y escritura.


Xmind y Freemind son dos herramientas open source que permiten crear mapas mentales de forma sencilla, son fáciles de instalar y multiplataforma. Mientras que Xmind está basado en eclipse framework , freemind implementa su propia lógica de presentación, aunque también está desarrollado en Java.

Espero publicar en próxima entradas varios mapas mentales sobre patrones de diseño, service bus, soa, etc...

Saludos,
JK

Toshiba G450 y Ubuntu 8.10

Recientemente cambié mi antiguo proveedor de telefonía móvil por Simyo, debido fundamentalmente, a su tarifa de navegación de datos. Aconsejo a todos aquellos que quieran utilizar su teléfono para navegar le dé una ojeada ya que si navegas menos de 500 Mb al mes, sólo pagas 5 euros.

El teléfono que compré al hacer la portabilidad fué el Toshiba G450, un móbil que tiene la peculiaridad de funcionar muy bien como modem, debido a que soporta los protocolos 3G y HSPDA y a su reducido tamaño que lo hace muy portable.



Otra de las características que me decantó a elegir este teléfono, es que está soportado por Ubuntu 8.04 y 8.10. En el blog de canx.blogspot.com, en concreto en estos links, podeis ver como se configura:
  • http://canx.blogspot.com/2008/11/howto-toshiba-g450-con-ubuntu-804.html
  • http://canx.blogspot.com/2008/12/howto-toshiba-g450-con-ubuntu-810.html
Para controlar el tráfico he instalado además el programa vnstat tal y como se explica en este link:
  • https://help.ubuntu.com/community/HowToMonitorInternetTrafficTotals


Multicast Java Test

En la mayoría de ocasiones en las que tenemos que montar un cluster, es necesario checkear la comunicación multicast entre ambos nodos para garantizar que cuando se configure el cluster no habrá problemas de comunicación entre ambos nodos.

Algunos fabricantes como Bea Weblogic, proporcionan algunas herrmientas junto con sus productos para poder esta comprobación, pero en la mayoría de productos open source este checkeo se debe realizar de un modo alternativo.

En esta dirección podeis encontrar dos clases java muy sencillas para realizar la comprobación multicast.

Para llevar a cabo la prueba basta con seguir los siguientes pasos:
  1. Ejecutar java mcsend 224.0.0.120 1024 desde el nodo 1 del cluster.
  2. Ejecutar java mcreceive 224.0.0.120 1024 desde el nodo 2 del cluster.
  3. Desde el nodo 1 del cluster, escribir un texto.
  4. Verificar que desde el nodo 2 se recibe el mensaje escrito en el nodo 1.
Repitiendo la prueba en orden inverso, podeis asegurar que la comunicación en ambas direcciones es correcta.

Saludos,

JK

Web Services Protocol Stack

Los Web Services son un conjunto de protocolos basados en XML (Extensible Markup Language). Muchos de vosotros ya están familiarizados con sus protocolos de base que sirvieron para definir la parte de la primera especificación para Web Services.
  • Simple Object Access Protocol (SOAP). Define el tiempo de ejecución que contiene el mensaje de solicitud de servicio y la respuesta. SOAP es independiente de cualquier particular, el transporte y la aplicación de tecnología.
  • Lenguaje de descripción de servicios Web (WSDL). Describe un servicio Web y el mensaje SOAP. Proporciona una forma de programación para describir lo que hace un servicio, facilitando el camino para la automatización de la generación de código.
  • Universal Discovery, Descripción, Integration (UDDI). UDDI es un iniciativa de la industria para crear un estándar para la localización de servicios, junto con un registro de instalación que facilita la edición y procesos de localización.
Estos protocolos base han permitido a muchas empresas a poner en marcha servicios web en producción. Sin embargo, para mejorar la seguridad y la fiabilidad de los Servicios Web y hacer frente a escenarios más complejos, se ha trabajado en la definición de una amplia gama de protocolos adicionales.

Estos protocolos adicionales se han propuesto en un formato de un marco modular, lo que permitirá:
  • A los desarrolladores utilizar sólo los módulos necesarios para realizar sus servicios Web.
  • Cada módulo puede evolucionar de forma aislada.
No existe ninguna definición estándar del stack de protocolos de servicios web a pesar de la W3C hizo público un documento de arquitectura de servicios Web que proporciona un excelente marco para los distintos protocolos.

Con la ayuda de xmind, y recopilando información de varias webs, he creado un mapa mental donde se mencionan y organizan los diferentes protocolos de web services que existen actualmente.

Como no todos los protocolos se encuentran maduros, he puesto un símbolo de OK en aquellos que si que se encuentran aprovados, un símbolo amarillo en aquellos que están en fase de experimentación. El resto, se encuentran en estado de definición o conceptualización.

También podeis descargar el archivo del xmind en esta siguiente dirección y hacer vuestras modificaciones.

Espero que os sirva de ayuda.

JK