¿Qué es Bajo Acoplamiento?

Para las personas familiarizadas con la Programación Orientada a Objetos y los patrones de diseño GRASP (General Responsibility Assignment Software Patterns), una clase está altamente acoplada si tiene muchas asociaciones con otras clases, la principal consecuencia es la poca mantenibilidad que le da al código, pues modificar una clase involucra también realizar cambios en muchas otras.

Ahora, a modo más general y hablando no en términos de clases sino de aplicaciones, el contexto de acoplamiento cambia, pues empieza a tomar importancia cuando es necesario usar mecanismos de integración para lograr interoperabilidad entre aplicaciones. Se habla de distintas dimensiones que permiten medir este acoplamiento, a continuación algunas de estas:

Ubicación: Una aplicación no debe tener datos “quemados” en su código fuente como la dirección física o IP de donde residen otras aplicaciones con las cuales se desea establecer una comunicación. Esta mala práctica o antipatrón de diseño se conoce como Hard code.

Número de receptores: Una aplicación se considera altamente acoplada si tiene un orden explicito de llamados a otras aplicaciones. Esta tarea de controlar los mensajes entre aplicaciones la debe realizar una capa superior, por ejemplo, mediante orquestación de servicios web.

Disponibilidad de los sistemas: Una aplicación no debe depender de la disponibilidad de otras aplicaciones para funcionar, si necesita enviar un mensaje, se debe contar con un mecanismo de buffering en caso de que la aplicación destino no se encuentre disponible, y entregárselo una vez cambie de estado.

Tiempo de respuesta: cuando una aplicación hace llamados a otras aplicaciones, la decisión sobre el límite de tiempo de espera para recibir una respuesta debería considerar distintos factores como los canales de comunicación o la carga sobre otros sistemas.

Referencias:

http://wiki.sdn.sap.com/wiki/display/BBA/Loose+Coupling+Through+Web+Services

http://es.wikipedia.org/wiki/Hard_code

http://www.infoq.com/articles/tilkov-10-soa-principles

¿El FUTURO DE SOA?

Ante la aparición de Web  2.0 estos servicios cada día se ven  necesitados a enfocarse en el tema de la red. Por lo cual se busca la  consolidación de un nuevo modelo arquitectónico, el cual está llamado a ser el modelo a utilizar en el futuro, donde todo, desde la información hasta el acceso a otros recursos están orientados a la web. Es habitual encontrar que  en una organización la adopción de SOA se limita a ser implementada y accesible desde un ámbito privado de la organización (red privada).Por lo tanto es necesario adoptar una arquitectura orientada  a la web (WOA).

WOA (Web-Oriented Architecture o Arquitectura Orientada a la Web)  Podemos  definir WOA como una extensión de SOA en la que los artefactos son implementados como recursos REST (Representational State Transfer) y que serán accesibles por medio de UDDI (Universal Description Discovery and Integration) que se encargará de identificar la ubicación de los recursos en la red.

Una de las características más importantes de WOA, es que los mensajes y las interacciones están auto-contenidos.WOA no requiere de un contrato de servicios como los tradicionales webservices ya que este está implícito en la URL y en la forma del recurso.

Por último  se puede diferenciar la concepción de  SOA como la necesidad de hacer sistemas de negocios de TI que sean agiles respecto a los cambios en el mercado y a WOA como la necesidad de llevar estos sistemas a la evolución de la web con la llegada de la web colaborativa. Por lo tanto SOA es un tipo de arquitectura que sigue vigente y se acomoda a las nuevas necesidades que se van presentando.

Referencias:

http://www.zdnet.com/blog/hinchcliffe/the-soa-with-reach-web-oriented-architecture/27
http://www.tec.url.edu.gt/boletin/URL_19_SIS07_REDES.pdf
http://blogs.vass.es/?p=535

UDDI

Universal Description Discovery and Integration (UDDI) es un framework independiente de plataforma que permite describir, descubrir e integrar Web services.


Como principales beneficios de UDDI están las facilidades de reutilización y ahorro en tiempo y costos de implementación de servicios web, pues mediante el descubrimiento de servicios ya existentes y publicados por terceros, es posible mantener procesos de negocio de forma ágil y lograr interoperabilidad no solo a nivel interno de la organización, también entre diferentes empresas.

Para dar una idea de los posibles usos de este framework, podemos hablar de las aerolíneas, estas pueden registrar sus servicios de reserva de vuelos en un directorio de UDDI, las agencias de viajes pueden buscar las interfaces o los contratos de los servicios web de las aerolíneas, y una vez encuentren el que necesitan, puede empezar a usarlo inmediatamente.

Los principales conceptos de UDDI son:

• UDDI Data Model: Incluye tipos de datos que incluyen descripción de los servicios, por ejemplo, cual es su función (businessService) o quien es el publicador del servicio (businessEntity).

• UDDI Nodes and Registers: incluye una específica definición de las relaciones de jerarquía que hay entre los servidores que tienen implementaciones de UDDI.

• Essential Programmatic Interfaces: provee funcionalidades claves como publicar o buscar información sobre un servicio en el registro UDDI.

UDDI es patrocinado por OASIS (Organization for the Advancement of Structured Information Standards), un consorcio que impulsa el desarrollo, convergencia y adopción de estándares abiertos y la organización que más desarrolla estándares de servicios web.

Referencias:

http://www.w3schools.com/WSDL/wsdl_uddi.asp

http://www.oasis-open.org/who/

http://uddi.xml.org/uddi-101

http://www.ibm.com/developerworks/webservices/library/ws-featuddi/

CUANDO LOS MUNDOS DE LA ARQUITECTURA SOA Y WEB 2.0 CHOCAN

Hola esta semana les hablaremos de como dos tipos de arquitecturas como SOA y WEB 2.0 las cuales tienen propósitos diferentes pero su integración permite una mejor forma de soportar los procesos de una organización.

Aparentemente SOA y WEB 2.0 se basan en filosofías muy diferentes, El primero se basa en la idea de la fuerza de la  estandarización  cuidadosa  a través de contratos. Los cuales me permiten la integración de los diferentes sistemas  que soportan los  diferentes procesos de negocio de la organización. Por otro lado Web 2.0 tiene como objetivo principal la oportunidad de conectar personas y soportar sus esfuerzos colaborativos. Ciertamente Web 2.0 también dirige elementos asociados a conexión de aplicaciones y datos, pero se distingue en que se dirige explícitamente a una dimensión más social. Por esta razón se cuestiona su uso empresarial.

Como se puede observar estas dos arquitecturas comparten  los siguientes aspectos de :

1.          La integración de plataformas de servicios.
2.          La no dependencia de un unico proveedor. 

La combinación de estas dos filosofías que va a permitir la obtención de las siguientes características:

Mejora de accesibilidad
Una mejor  forma de acceder a  los servicios SOA es  proporcionando una interfaz mas sencilla mediante WEB 2.0 a través de REST, lo que implica más facilidad en la comunicación.

Reutilizacion 

Tanto WEB 2.0 y SOA poseen el concepto de reutilizacion. lo que permitirá la construcción de aplicaciones mas complejas a partir de unas ya existentes.

Fácil Desarrollo 

Tienen entornos para el desarrollo rápido y fácil de aplicaciones.

Innovación 
Realizar aplicaciones de gran impacto visual utilizando WEB 2.0 soportando sus operaciones con servicios SOA.

Referencias
http://www.itsc.org.sg/pdf/synthesis08/Five_SOA.pdf
http://www.zdnet.com/blog/hinchcliffe/when-the-worlds-of-soa-and-web-20-collide/35
http://webdoscero.blogspot.com/2006/05/soa-versus-web-20-en-espaol.html

La