Domotica

El término domótica puede definirse como  "el concepto de vivienda que integra todos los automatismos en materia de seguridad, gestión de la energía, comunicaciones, etc.". Es decir, el objetivo es asegurar al usuario de la vivienda un aumento del confort, de la seguridad, del ahorro energético y las facilidades de comunicación.
Una definición más técnica del concepto sería: "conjunto de servicios de la vivienda garantizado por sistemas que realizan varias funciones, los cuales pueden estar conectados entre sí y a redes interiores y exteriores de comunicación. Gracias a ello se obtiene un notable ahorro de energía, una eficaz gestión técnica de la vivienda, una buena comunicación con el exterior y un alto nivel de seguridad".
 Así concebida, una vivienda inteligente puede ofrecer una amplia gama de aplicaciones en áreas tales como:

• seguridad
• gestión de la energía
• automatización de tareas domésticas
• formación, cultura y entretenimiento
• teletrabajo
• monitorización de salud
• operación y mantenimiento de las instalaciones

De una manera general, un sistema domótico dispondrá de una red de comunicación y diálogo que permite la interconexión de una serie de equipos a fin de obtener información sobre el entorno doméstico y, basándose en ésta, realizar unas determinadas acciones sobre dicho entorno.

¿CÓMO FUNCIONA UN SITEMA DOMÓTICO?

La configuración de un sistema domótico está íntimamaente ligada a los procedimientos de transmisión de información que posibilitan el diálogo entre dichos periféricos y la unidad central. Los terminales ( radiadores de calefacción, electrodomésticos, puntos de luz,etc.)suelen ser equipos convencionales a los que se aporta una inteligencia o capacidad de comunicación a traves de una interfaz. Los elementos de campo comprenden todo el conjiunto de sensores que permiten convertiruna magnitud física en señal eléctrica, y los actuadores u órganos de mando, capaces de tranformar una señal eléctrica en una acción sobre el entorno físico. Todos los elementos de campo envían y reciben señales a través de una red de comunicaciones (bus domótico), para comunicarse entre ellos y con la unidad central encargada de gestionar los intercambios de información. Estas señales de control están codificadas de una determinada forma (protocolos de comunicación), pos lo que se necesitan unos elementos que pasen las señales bus y, a su vez, de señales bus a señales de salida a los actuadores (relés, interruptores, etc.). Estos elementos se suelen denominar de diferentes formas: módulos de entrada/salida, acopladores, interfaces, etc.
Un sistéma domótico puede trabajar de forma centralizada o descentralizada. En el primer caso, el funcionamiento global del sistema depende de la programación introducida en la central domótica. En cambio, en los sistemas descentralizados cada elemento es inteligente y se programa de forma individual. Las posibilidades de aplicación de la domótica en el espacio dom´stico son muy amplias. No obstante, las áreas en las que se han dedicado mayores esfuerzosson las relativas ala segurida, la automatización de tareas domésticas o el confort, la gestión de la energía y las comunicaciones. De hecho para calificar de domótica una vivienda debe contemplar estas cuatro familias de servicios.

ASPECTOS FUNDAMENTALES DE LA DOMÓTICA
La domótica se centra en cuatro aspectos fundamentales:
% La mejora de la comodidad.
% Aportar más seguridad.
% Nuevas formas de comunicación.
% Reducción de los gastos energéticos.

COMENTARIOS
La DOMOTICA es un tema muy interesante en estos dias se trata de un nuevo concepto de vivienda que contiene muchas opciones para la comodidad,seguridad ahorro en muchos aspectos al usuario
Mas que nada es brindarle al usuario una manera de facilitar la vida en las comodidades hogareñas.
Lo que muchos desean tener y alacanze de su casa



FUENTES DE INFORMACION
http://domoticanp.blogspot.mx/2008/01/definicion-de-domotica.html 

MDD

El Desarrollo de Software Dirigido por Modelos (DSDM, también denominado MDD por su acrónimo en inglés, Model-Driven Development) es una propuesta para el desarrollo de software en la que se le atribuye a los modelos el papel principal de todo el proceso, frente a las propuestas tradicionales basadas en lenguajes de programación y plataformas de objetos y componentes de software.

Son varias las razones que han motivado la aparición de este nuevo paradigma. En primer lugar nos encontramos con la creciente complejidad de las aplicaciones de software, que han de satisfacer un mayor número de requisitos (heterogeneidad, distribución, alta disponibilidad, adaptabilidad, etc.) con mejores prestaciones y menores tiempos de desarrollo. Por otro lado, las nuevas tecnologías evolucionan demasiado deprisa (COM, DCOM, COM+, CORBA, CCM, J2EE, .NET, Web Services, SOA...), lo que hace que las inversiones en tecnologías concretas sean demasiado volátiles.

Si bien es cierto que esos problemas no son nuevos en el campo de la Ingeniería de Software, está comprobado que la mejor forma de tratar con ellos es elevando el nivel de abstracción de los modelos desde las primeras etapas del desarrollo.
De hecho, el DSDM no es el primer intento por resolver este tipo de problemas. A lo largo de la evolución de la Ingeniería de Software hemos asistido a muchas propuestas para que los programas reflejen de una forma mejor y a más alto nivel, no sólo el dominio del problema, sino también para que traten de ocultar la complejidad de la tecnología sofware subyacente. Normalmente esto se ha llevado a cabo mediante la definición de lenguajes de programación, cada vez de más alto nivel (COBOL, Pascal, C, C++, Eiffel, Java, Python, Ruby, etc.), y la aparición de nuevas técnicas y mecanismos, por ejemplo los marcos de trabajo (frameworks) como Struts o Rails. Sin embargo, estos intentos no han conseguido lograr del todo su objetivo. Quizás una de las razones de su aparente fracaso es que estaban basados en las propias tecnologías del software, cuando es precisamente ahí donde residen la mayoría de los problemas.

Principios básicos del DSDM

Uno de los términos claves en la filosofía del DSDM es el concepto de modelo. De forma sencilla podríamos definir un modelo como una abstracción simplificada de un sistema o concepto del mundo real. Como tal, el modelo contiene un menor nivel de detalle que su correspondiente artefacto de la vida real. Sin embargo, ésta no es la única definición que encontraremos en la literatura sobre el término "modelo". A modo de ejemplo, las siguientes citas muestran algunas de las acepciones más comunes de este concepto en el ámbito de la Ingeniería de Software y del DSDM:

• Un modelo es una descripción de un sistema, o parte de éste, escrito en un lenguaje bien definido. (Warmer y Kleppe, 2003).
• Un modelo es una representación de una parte de la funcionalidad, estructura y/o comportamiento de un sistema (OMG, 2001).
• Un modelo es una descripción o especificación de un sistema y su entorno definida para cierto propósito. Un modelo es representado habitualmente como una combinación de elementos gráficos y de texto. (Miller y Mukerji, 2003).

Según Wermer y Kleppe (2003), cada modelo se centra en la descripción de un único aspecto del sistema, de acuerdo a un propósito específico, y descrito hasta un cierto nivel de abstracción adecuado para el problema modelado. Tal descripción puede facilitarse de forma gráfica o textual (Miller y Mukerji, 2003), haciendo uso generalmente de lenguajes de modelado cuya semántica esté bien definida. A este respecto, la idea compartida por todos los paradigmas englobados dentro del DSDM es la conveniencia de utilizar para el modelado lenguajes de mayor nivel de abstracción que los lenguajes de programación habituales, esto es, lenguajes que manejen conceptos más cercanos al dominio de la aplicación. Así pues, dependiendo del ámbito DSDM que se trate, estos lenguajes que proporcionan mayor nivel de abstracción se denominan lenguajes de modelado (contexto de MDA) o lenguajes específicos del dominio (contexto de DSM y SF).

COMENTARIOS

EL MDD es una propuesta para un buen desarrollo de software en la que se le puede considerar los modelos del papel principal de todo el proceso, teniendo en cuenta las opciones con las que ya se contaba anteriormente d las que se constityuyen de lenguajes de programacion y plaaformas de objetos y componentes de sw
Es importante tener en cuenta que  gracias a este metodo se a podido enfrentar la complejidad de las aplicaciones que tienen los software, poder satisfacer los requisitos solicitados cada vez con mayor complejidad

LEY DE MURPHY

-Todo programa, cuando esta listo es obsoleto.
-Todo programa cuesta más y demora más en terminase de lo que se había previsto.
-Si un programa es útil, debe ser corregido.
-Si un programa es inútil, debe estar debidamente documentado.
-Todo programa se expande hasta utilizar toda la memoria disponible.
-La complejidad de los programas crece hasta que exceda la capacidad del programador.
-Si un test de instalación funciona perfectamente, todos los sistemas subsecuentes funcionaran mal.
-Agregar más recursos a un proyecto de software retrasado hace que se demore aún más.
-Es imposible realizar un programas apto para tontos porque los tontos son muy ingeniosos.
-Cuando las cosas están yendo bien, algo comenzara a andar mal.
-Cada vez que las cosas parezcan estar funcionando bien es porque hay algo de que nos hemos olvidado.
-Si parece sencillo es complicado.
-Si parece complicado es imposible.
-Siempre se encontrara un error en el ultimo lugar donde se busque.
-Aquello que no se hace, siempre es más importante que lo que se hizo.
-Todo programador debe de actuar de forma racional luego de que las demás posibilidades ya han sido agotadas.
-Si no entiende una palabra determinada en un documento técnico, ignórela. El documento mantiene todo su sentido igual.
-Si las cosas pueden empeorar, empeorarán.
-Por más de que haga todo lo necesario para que nada salga mal, será insuficiente, ya que algo saldrá mal.
-Cuando todo falla, es el momento de consultar el manual que, naturalmente, no tenemos ni idea de donde pueda estar, o lo que es peor, jamas tuvimos el gusto de conocer.
-Un programa es aquello que cuesta el doble de lo calculado, tarda el doble de lo imaginado y no hace ni la mitad de lo que pensaba.
-Cantidad de líneas pertenecientes a un programa tales que, añadidas al mismo, impiden que quepa en la memoria, y sustraídas de él, no permiten que funcione, como se había previsto en un principio.
-El funcionamiento sin problemas de una computadoras igual a los días de duración de la garantía + 1.
-Los botones de reset y encendido están, por default, puestos en donde sea más fácil pulsarlos por error.
-Si nos olvidamos de hacer un backup, seguramente el Disco Duro se arruinará.
-Cualquier programa bueno requiere más memoria de la que usted tiene.
-La velocidad con que un componente se vuelve obsoleto es directamente proporcional a su valor.
-Los errores de un software son imposibles de detectar por nadie a excepción del usuario final.

 

COMENTARIOS

Mas que nada yo los veo como buenos consejos para como saber actuar en algunos problemas asi y que no me quieran marear con otra informacion .

 

BPM

El BPM (Business Process Management) se está convirtiendo en una de las tendencias de gestión empresarial y tecnológica de mayor crecimiento del mercado y según estudios recientes, esta tendencia irá a más. Sin embargo, para muchas organizaciones no está muy claro qué es realmente un BPM, cuáles son sus funcionalidades y, en definitiva, cuáles son sus diferencias con respecto a “otras siglas”: BPA, PLM, BI, ERP,…
Empezaremos poco a poco, dando pequeños pero seguros pasos para conocer qué es y qué implica un BPM.





Por definicion se dice que el BPM es “un conjunto de herramientas, tecnologías, técnicas, métodos y disciplinas de gestión concebidas para diseñar y ejecutar la automatización de procesos empresariales”.
Es decir, el BPM sirve para automatizar el ciclo de vida de los procesos.  Todas las organizaciones realizan sus actividades según flujos de trabajo más o menos establecidos, y ese “más o menos” puede suponer el éxito o el fracaso de la empresa. Mediante las herramientas BPM una organización tendrá la posibilidad de definir en una aplicación informática sus procesos, organizar la información y el trabajo de las personas, controlar su ejecución en tiempo real y mediante una monitorización adecuada (indicadores, alertas, informes, cuadros de mandos) extraer conclusiones para alinearse con el objetivo último de lograr una mayor eficiencia.

Hay multitud de aplicaciones en el mercado que pueden ayudar a las empresas a definir y gestionar, de manera más o menos sencilla, sus procesos y contenidos. Destacan en general por ser herramientas ágiles y flexibles, que facilitan la capacidad de adaptación al cambio, sin que normalmente sea requerido un perfil técnico para implementar dichas modificaciones una vez implantado el sistema. La tendencia hace que se trate generalmente de herramientas web, que permiten comunicarse internamente a los empleados de la organización mediante portales empresariales, y que además ofrecen la posibilidad de abrir las puertas de la propia organización a clientes, proveedores, socios, etc., para que también éstos, si es necesario, intervengan de manera más activa en la ejecución de los procesos.
Es fácil intuir que para llevar a cabo una estrategia BPM se necesita tener cierto nivel de madurez empresarial y organizativa. El hecho de plantearse implantar un BPM, implica la necesidad de analizar  qué y cómo se están haciendo las cosas en su empresa y si realmente dispone del control que necesita de sus procesos.

Algunos ejemplos de BPMS:

• Oracle SOA Suite
• IBM BPM
• BEA AquaLogic BPMS

BPM también es vista como una disciplina de administración, que requiere que las organizaciones se cambien a un pensamiento centrado en los procesos y que reduzcan su dependencia de estructuras tradicionales de territorio y funcionalidad (los llamados silos). Es un enfoque estructurado que emplea métodos, políticas, métricas, practicas de administración, y herramientas de software para mejorar la agilidad y el desempeño operacional.
La disciplina BPM tiene implicancia en 4 aspectos del negocio:

• Estrategias
• Governance (Administración y Control)
• Estructura Organizacional (Organization)
• Cultura.

COMENTARIOS
El BPM son herramientas, tecnologicas,tecnicas,metodos y disciplinas de gestion  su principal funcion es diseñar y ejecutar la automatizacion de   procesos empresariales.
 Mas que nada estas herramientas sirven para automatizar el ciclo de vida que tienen  los procesos


FUENTES DE INFORMACION
http://www.cio.com.co/2008/bpm1.htm
 http://www.soaagenda.com/journal/articulos/que-es-bpm-que-es-bpms/

CLOUD COMPUTING

Es un término que se define como una tecnología que ofrece servicios a través de la plataforma de internet. Los usuarios de este servicio tienen acceso de forma gratuita o de pago todo depende del servicio que se necesite usar.
El término es una tendencia que responde a múltiples características integradas. Uno de los ejemplos de está “nube” es el servicio que presta Google Apps que incorpora desde un navegador hasta el almacenamiento de datos en sus servidores. Los programas deben estar en los servidores en línea y puedas accesar a los servicios y la información a través de internet.

Cloud Computing es un paradigma que permite ofrecer servicios de computación a través de Internet.

Cloud computing es el desarrollo y la utilización de capacidad de procesamiento computacional basado en Internet (la “nube”). El concepto es un cambio de paradigma, a través del cual los usuarios ya no necesitan contar con conocimientos, experiencia o control sobre la infraestructura tecnológica que se encuentra “en la nube”, la misma que soporta sus actividades. Este concepto involucra típicamente la provisión de recursos fácilmente escalables y casi siempre virtualizados, tratados como servicios sobre Internet.

El termino “nube” (cloud en ingles) es usado como una metáfora para el Internet, basado en como el Internet es representado en los diagramas de redes computacionales y como  abstracción de la infraestructura subyacente que el misma oculta. Los proveedores de cloud computing proveen aplicaciones en línea de negocio, las mismas que se pueden acceder desde exploradores de internet (Firefox, IE, Opera, Chrome, Safari, etc), mientras el software y los datos son almacenados en los servidores.

Estas aplicaciones están ampliamente divididas en las siguientes categorías: Software como Servicio (Software as a Service – SaaS), Utility Computing, Web Services, Plataformas como Servicio (Platform as a Service – PaaS), Proveedores de Servicios Administrados (Managed Service Providers – MSP), Servicio de Comercio (Service Commerce) e Integración de Internet (Internet Integration).
El nombre de “cloud computing” fue inspirado por el símbolo de la nube que usualmente representa a la Internet en diagramas de flujo y de redes.

Comparaciones

Cloud computing puede ser confundido con:

1. Grid computing – “una forma de computación distribuida, a través de la cual una ‘super computadora virtual’ compuesta de un grupo de computadoras que se encuentran conectados a la red libremente, trabajan en conjunto para realizar tareas muy complejas”
2. Utility computing – el “empaquetado de recursos computacionales, tales como capacidad de procesamiento y almacenamiento, medido de forma similar como los servicios tradicionales, ej.: servicio de electricidad”
3. Computación autónoma – “sistemas de computación capaces de auto-administrarse”

Efectivamente, muchas implementaciones de cloud computing dependen de “redes computacionales” (también llamadas Grids) de características autónomas, las mismas que se facturan como servicios.
Sin embargo cloud computing se inclina a expanderse más alla de las redes computacionales (grids) y de los servicios. Algunas arquitecturas exitosas en la “nube” tienen muy poca infraestructura o la misma no se encuentra centralizada e incluso ni siquiera cuentan con sistemas de facturación, como ejemplo se encuentran las redes peer-to-peer como BitTorrent y Skype, e incluso computación de voluntariado como el proyecto SETI@home.

Las capas de cloud computing

Existen varias capas que conforman el concepto de “Cloud Computing”, sin embargo para contar con una explicación clara y sencilla, nos concentraremos en las tres capas más importantes.

Software

El software en la nube (Software as a Service – SaaS, por sus siglas en inglés) potencia el concepto de “cloud computing” en una arquitectura de software, eliminando frecuentemente la necesidad de instalar y ejecutar la aplicación en la computadora del usuario final, eliminando la carga del mantenimiento del software, los costos de las operación y el soporte técnico.

Plataforma

Una plataforma en la nube (Platform as a Service – PaaS, por sus siglas en inglés) entrega una plataforma computacional y/o un conjunto de soluciones como servicio, que generalmente utilizan infraestructura en la nube y soportan software o aplicaciones en la nube. Facilita la implementación de aplicaciones sin el costo y complejidad de comprar y administrar el hardware subyacente y sus capas de software.

Infraestructura

Infraestructura en la nube (Infrastructure as a service – IaaS, por sus siglas en inglés), es la entrega de infraestructura de computación como un servicio, generalmente en un entorno de virtualización de plataforma.

COMENTARIOS

es una herramienta intersante ya que proporciona al usuario servicios de computacion atraves de internet. Los usuarios que cuentan con este servicio tienen acceso de forma gratuita o de pago depende mucho del servico que necesite usar ,y cuales son las caracteristicas del servicio.


FUENTES DE INFORMACION
http://www.desarrolloweb.com/articulos/que-es-cloud-computing.html
http://www.salesforce.com/es/cloudcomputing/

OOWS TECHNOLOGY

OWSS (Metodo de produccion de soluciones web orientadas a objetos)

Desarrollo de metodos de produccion de software que permite construir aplicaciones web complejas
con comportamiento dinamico, que seasn compatibles con los estandares metodologicos y notacionales mas extendidos en la actualidad y que establezcan como diseñar y desarrollar aplicaciones web basadas en SW XML.

OOWS:Un metodo de desarrollo de aplicaciones web

La funcionalidad del sistema y la interacion con los usuarios
Nuevas caracteristicas navegacionales
Compilador de modelos conceptuales (model compiler)

CARACTERISTICAS

Aborda de forma sistematica el modelo conceptual de aplicaciones we
Propone una arquitectura software multinivel basada en servicios web
Introduce un conjunto de reglas que permite transformar  las abstracciones conceptuales en cada uno de los cmponentes software que implementan los niveles de la arquitectura, haciendo uso intensivo de patrones de diseño.

Proceso de desarrollo de una aplicacion web

Para mdelar la navegacion asociada al sistema deseado se propone un proceso de desarrollo de soluciones web con dos pasos principales:
 a) Especificacion del problema
b)desarrollo de la solucion

MODELO DE NAVEGACION DE OOWS

Su objetivo es definir como se le proporcionara a cada usuario del sistemas el acceso a la informacion y la funcionalidad que le  es relevante para llevar a cabo su tarea dentro del sistema y que secuencias de caminos deberan seguir para conseguirlo.

En la aproximacion OOWS, los requisitos navegacionales de una aplicacion web se obitnen añadiendo una  "vista navegacional" (mapa navegacional) sobre el modelo de objetos OO-Method, indicando el conjunto posible de caminos navegacionales que se le proporcionaran al usuario.

El modelo de navegacion esta compuesto por un conjunto de mapas de navegacio (uno por cada agente) que representan y estrcuturan la vision global ddel sistema para cada tipo e usuario,definiendo su navegacion permitida.

Existen dos posibilidades:que los nodos (contextos) navegacionales sean alcanzables desde cualquier ubicacion en el sitema (llamados contextos de exploracion)  o que los nodos solo sean alcanzables sigueindo un camino predeterminado de pasos de navegacion ( llamados contextos de secuencia).

COMENTARIOS
en estas tecnologias tienen como mision proporcionar al usuario de sisteas el acceso a la informacion y funcionalidad que necesita para poder cumplir con su tarea que le fue dada dentro del sistema y todos los caminos que este mismo necesitara para poder llegar a su meta establecida

FUENTES DE INFORMACION
http://www.inf.udec.cl/~adweb/docs/ecweb2009/MemoriaProyectoTesis.pdf

SOA

¿ QUÉ NO ES SOA ?

La mejor manera de comenzar a explicar SOA, es explicar qué NO es:

• SOA no es un software, no es un MOM, no es un EAI, aunque una arquitectura SOA puede apoyarse en un conjunto de herramientas como MOMs o EAIs para conseguir su objetivo.
• SOA no es una metodología de proyecto, aunque a la hora de iniciar un proyecto orientado a conseguir una arquitectura SOA en mi empresa, algunas metodologías se ajustan mejor que otras: es preferible seguir un modelo en iteraciones (no confundir con iterativo como UP), como las metodologías ágiles (XP, etc..), que seguir metodologías Waterfall
• SOA no es otra forma de llamar a los WebServices, aunque los webservices son una herramienta válida para conseguir una arquitectura SOA, incluso una arquitectura SOA podría apoyarse en la programación distribuida (DCOM, CORBA, RMI, EJBs...)

¿Qué es SOA – Service Oriented Architecture?

La palabra de moda en los últimos años en el área de desarrollo de software ha sido SOA – Arquitectura Orientada a Servicios. ¿Pero qué significa SOA en realidad? 

Básicamente SOA es un cambio significativo en la manera en que nosotros diseñamos y construimos aplicaciones. Esta arquitectura toma la naturaleza abierta de la Web y la convierte en una nueva manera de pensar acerca de las arquitecturas de aplicaciones.

SOA significa integración a través de sistemas diversos. SOA utiliza protocolos estándar e interfaces convencionales – usualmente Web Services – para facilitar el acceso a la lógica de negocios y la información entre diversos servicios. SOA nos brinda los principios y la guía para transformar el conjunto de recursos de TI de la compañía – los cuales son por lo general heterogéneos, distribuidos, inflexibles y complejos -  en recursos flexibles, integrados y simplificados, que pueden ser cambiados y compuestos para alinearse más fácilmente con los objetivos del negocio. Podemos decir entonces, que SOA no es una herramienta, no más bien es un conjunto de patrones de construcción de las nuevas aplicaciones de la empresa – más dinámicas y menos dependientes. 

SOA es la evolución del modelo de programación orientado a componentes, ya que SOA agrega herramientas de computación distribuida a estas tecnologías que hemos venido utilizando por años. Podríamos decir que el cambio más grande es filosófico: en lugar de pensar en el diseño de aplicaciones individuales para resolver problemas especificos, SOA ve el software como un patrón que soporta todo el proceso del negocio. Cada elemento de un servicio es un componente que puede ser utilizado muchas veces a través de muchas funciones y procesos dentro y fuera de la empresa. Los servicios se pueden actualizar y escalar conforme sea requerido, o se pueden cambiar a una librería de terceros, sin afectar la operación del negocio – esto se da por que el componente clave de SOA no es la aplicación o el componente en uso si no más bien el contrato de uso, la interface.

La idea detrás de todo esto es que es más efectivo trabajar con servicios que con aplicaciones. Todos los componentes de una infraestructura de TI tradicional permanecen en una implementación de SOA, pero esta vez en lugar de que una aplicación soporte una funcionalidad, esta se pone disponible para todo el negocio.

Esta idea de aplicaciones como servicios alineadas a los procesos del negocio no es nueva, solamente que en esfuerzos anteriores se requería mucho esfuerzo para integrar las aplicaciones heterogéneas, además de que cada uno de estos esfuerzos tenían su propio API y su forma propietaria de comunicarse; por ejemplo CORBA y COM+.

Sin embargo, esta solución moderna que llamamos SOA, toma mucho de estos esfuerzos y de los estándares abiertos de Internet para posibilitarnos llevar a cabo esta tarea. Al día de hoy XML se ha convertido en la lengua de facto entre máquinas, lo que permite a los arquitectos ligar nuevas herramientas con aplicaciones “legacy”, y desarrollar el B2B – Business to Business - alrededor del mundo.  Esta intercomunicación no es solo entre componentes, ya que incluso se pueden describir procesos de negocio con documentos XML, utilizando lenguajes de orquestación como BPEL.

A nivel del servicio, la información se maneja como mensajes XML, definidos por un esquema XML, mientras que las interfaces de la aplicación pueden ser servicios web. XML y Servicios Web son soportardos por Java y .NET,  y estan empezando a ser soportadas por muchas más tecnologías.

En la siguiente imagen podemos ver la composición de una arquitectura orientada a servicios y la interacción de sus diversos componentes. En esta imagen faltan los elementos de infraestructura tales como el ESB, BPEL, etc.

En esta imagen se puede ver que una arquitectura orientada a servicios agrega una interface de servicios ( capa lógica de servicios ) sobre los objetos de negocio y sobre las aplicaciones legacy que están alineados con los procesos del negocio. Estos objetos de negocio a su vez tienen una capa de acceso a datos la cual es la que se encarga de abstraer el acceso a las diversas fuentes de datos que utiliza la empresa.

FUENTES DE INFORMACION

http://www.theserverlabs.com/folletos/Folleto%20SOA