domingo, 20 de mayo de 2012

Arquitectura Orientada a Servicios SOA


Encontré mucha definiciones sobre lo que es la Arquitectura Orientada a Servicios SOA, desde mi punto de vista, y después de haber leído varios autores,  básicamente podemos decir que es un paradigma, orientado a la forma que debemos ver a una empresa del giro que sea e independiente de los fines que persiga, él como la información interactúa en todos los aspectos de la empresa y como se debe utilizar.

SOA  es una Arquitectura orientada a Servicios, se basa en la independencia de plataformas de hardware, de sistemas operativos y de lenguajes de programación, fortalece la reutilización de los sistemas actuales que se construyeron y se venido utilizando y crea un ambiente en el que los negocios y la tecnología de la información pueden interactuar entre sí.

SOA se fundamenta en:

• Ejecutar rápido, adaptarse al mercado, ganar ante la competencia.
• Reutilizar los componentes de los procesos de negocios.
• Medir los resultados y tomar acción sobre ellos.
• Garantizar resultados que sean repetibles y predecibles.
• Empezar donde sea necesario (área de negocios - área de tecnología).

  

Un ejemplito …   Para entenderle un poco más

Si analizamos bien las tareas de negocios e identificamos aquellas que podemos repetir, esas tareas las podríamos definir como “Servicios”. Verificar un crédito, abrir una cuenta, comprobar existencias, son tareas de negocio repetibles que podemos denominar servicios. Siendo así, cualquier negocio, independientemente de su industria, posee servicios.
Ahora bien, supongamos que cada uno de esos servicios son “bloques  y veamos cada uno de ellos como un “servicio”, que a su vez, es una tarea de negocios. En teoría con SOA podríamos tomar cada uno de esos bloques y unirlos de la manera que quisiéramos, pues todos encajan. Podemos ensamblarlos y volver a ensamblarlos de manera dinámica, a medida que cambian las necesidades de la empresa.


Cada bloque de equivale a una tarea de negocios dentro de una empresa. Un Gerente de X área  podría tomar algunos bloques y el gerente de otra X área otros, y construir algo diferente utilizando los mismos componentes (o Servicios).

La Arquitectura Orientada a Servicios (SOA) consiste en la forma en que unimos esos bloques (Servicios). 

Un poco de historia … Esto si quieren no lo lean. 


La arquitectura orientada a los servicios no es nueva, pero es un modelo alternativo con respecto a los modelos orientados a los objetos estrechamente acoplados de una manera más tradicional que han emergido en las últimas décadas. Al tiempo que los sistemas basados en SOA no excluyen el hecho de que se puedan construir servicios individuales con diseños orientados a los objetos, el diseño total está orientado a los servicios. Dado que permite objetos dentro del sistema, SOA está basado en objetos, pero no está, en su totalidad, orientado a los objetos. La diferencia está  en las interfaces propiamente dichas. Un ejemplo clásico de un sistema proto-SOA que ha estado alrededor por un tiempo es Common Object Request Broker Architecture (CORBA), que define conceptos similares a SOA.
  
Los servicios de Web no son la única forma de implementar SOA. Tal como se explicó anteriormente, CORBA es otra forma y también sistemas Message-Oriented Middleware

De donde salió…

SOA surge de la necesidad de hacer que los sistemas de negocios de IT sean más ágiles con respecto a los cambios en la empresa. Al permitir relaciones fuertemente definidas, si bien implementaciones específicas flexibles, los sistemas de IT pueden obtener las ventajas de los sistemas existentes y, no obstante, estar lista para cambios futuros en sus interacciones.

Que tecnologías los componen

En sí mismo SOA es un concepto abstracto sobre cómo se debe unir el software, como lo mencione en un principio, considero es un paradigma y nace de las ideas y tecnologías implementadas en XML y en servicios de Web para existir en la forma de software. Asimismo, para funcionar con efectividad, también requiere soporte de seguridad, administración de políticas, un messaging confiable y sistemas contables.
  
Esto sí es importante que lo lean

Para establecer un control apropiado de todo ese messaging, así como también para aplicar las necesidades de seguridad, política, confiabilidad y contabilidad, hay un nuevo objeto de software que entra en la escena de SOA. Es el Enterprise Service Bus (ESB), que es responsable del control y del flujo apropiado, y tal vez también de las conversiones de todos los mensajes entre los servicios, usando cualquier cantidad de protocolos de messaging posibles. No se requiere absolutamente el ESB, pero es un componente vital para administrar apropiadamente sus procesos de negocios en SOA. El ESB propiamente dicho puede ser un único motor o aun un sistema distribuido.

Con respecto al desarrollador, las herramientas que usa necesitan conocer las capacidades de SOA y permitirle trabajar efectivamente con objetos de SOA. Esto incluye el proceso de diseñar el modelo de SOA, desarrollando servicios y objetos de servicio, y probar la aplicación de SOA en su totalidad. De este modo, las herramientas del desarrollador deberán estar listas para Service-Oriented Application Design and Development (SOAD).

Tecnologías SOA

SOA puede interactuar con una cantidad de otras tecnologías, pero con respecto a esto el encapsulado y el agregado de componentes tienen un rol significativo. Tal como se indicó anteriormente, un servicio de SOA puede ser un objeto simple, un objeto complejo, una colección de objetos, un proceso que contiene otros procesos, y asimismo una colección entera de aplicaciones que dan un único resultado.
  
Los servicios se pueden implementar en cualquier lenguaje de programación siempre y cuando pueda generar e interactuar con WSDL. SOAP en sí mismo no es un requisito absoluto, pero es un sistema de messaging común. De este modo, los servicios miembros en SOA pueden ser implementados en casi cualquier variedad de lenguaje de programación y plataforma que dé soporte a WSDL.
  
Los servicios de SOA y de Web son independientes de lenguaje de programación, pero el lenguaje Java está entre los principales lenguajes de desarrollo (por eso vemos Java en el propedéutico de Computación, supongo). La disponibilidad de interfaces de Java bien definidas, así como también las abundantes implementaciones de Java de los varios protocolos, le dan a los desarrolladores de Java una ventaja cuando se construye en este modelo.

Salu2



domingo, 22 de abril de 2012

Entropia y el modelo de la información ....


Originalmente nacida en la termodinámica como lo muestra el libro The Information y bajo las propuestas de Maxwell enfocadas a la termodinámica mismas que fueron postulados y en donde se mezcla varias “teorías” para sus demostraciones como la estadística, la probabilidad, la información y trata de dar una explicación del origen de la entropía en el ámbito de la termodinámica y haciendo una comparación directa en la teoría de la información.

En el texto The Mathematical Theory of Communication desde mi punto de vista para poder estar en condiciones de entender el capitulo 7 es necesario ahondar en mas apartados del libro, ya que trata de “aterrizar” si se le puede llamar de alguna manera, a la teoría de la información y comprobar la entropía por medio de métodos “lógicos” (logaritmo basado en la probabilidad) haciendo coincidir la teoría inicialmente de la termodinámica en la teoría de la información

Básicamente el video y las lecturas nos dan un panorama de donde nace y como se llega a la entropía, como es que se articula la teoría de la información y como el papel que juega la entropía, nos muestra su conformación y lo importante que es en la teoría de la información y lo importante del modelo de Shannon.




FUENTE DE INFORMACION: Selecciona el mensajedeseado de un conjunto de mensajes posibles.
TRANSMISOR: Transforma o codifica estainformación en una forma apropiada al canal.
SEÑAL: Mensaje codificado por el transmisor.
CANAL: Medio a través del cual las señales son transmitidas al punto de recepción.
FUENTE DE RUIDO: Conjunto de distorsiones o adiciones no deseadas por la fuente de información que afectan a la señal. Pueden consistir en distorsiones del sonido (radio, teléfono), distorsiones de la imagen (T.V.), errores de transmisión (telégrafo), etc.
RECEPTOR: Decodifica o vuelve a transformar la señal transmitida en el mensaje original o en una aproximación de este haciéndolo llegar a su destino.


Entropía e información


Creo que los postulados que podemos extraer son:
  • Medición de la información
  • Este establece que mientras más probable sea un mensaje menos información proporcionará
  • La probabilidad que tiene un mensaje de ser enviado y no su contenido, lo que determina su valor informativo
  • La información es tratada como magnitud física, caracterizando la información de una secuencia de símbolos utilizando la Entropía
  • De acuerdo a la teoría de la información, el nivel de información de una fuente se puede medir según la Entropía de la misma.

Para codificar los mensajes de una fuente intentaremos pues utilizar menor cantidad de bits para los mensajes más probables y mayor cantidad de bits para los mensajes menos probables de forma tal que el promedio de bits utilizados para codificar los mensajes sea menor a la cantidad de bits promedio de los mensajes originales. Siendo la base de la compresión de datos.

Salu2



jueves, 19 de abril de 2012

Bienvenida a tod@s a este nuevo Blog

Hola, mi nombre es Eduardo Muñoz y curso la Maestría en Tecnologías de Información y Administración en el ITAM, actualmente comparto con ustedes este nuevo Blog que servirá como ventana para expresar algunas opiniones propias en relación a las Tecnologías de la Información.

Salu2