RMI- CORBA-BPM-BPML

RMI



RMI (Java Remote Method Invocation) es un mecanismo ofrecido por Java para invocar un método de manera remota. Forma parte del entorno estándar de ejecución de Java y proporciona un mecanismo simple para la comunicación de servidores en aplicaciones distribuidas basadas exclusivamente en Java. Si se requiere comunicación entre otras tecnologías debe utilizarse CORBA o SOAP en lugar de RMI.
RMI se caracteriza por la facilidad de su uso en la programación por estar específicamente diseñado para Java; proporciona paso de objetos por referencia (no permitido por SOAP), recolección de basura distribuida (Garbage Collector distribuido) y paso de tipos arbitrarios (funcionalidad no provista por CORBA).
A través de RMI, un programa Java puede exportar un objeto, con lo que dicho objeto estará accesible a través de la red y el programa permanece a la espera de peticiones en un puerto TCP. A partir de ese momento, un cliente puede conectarse e invocar los métodos proporcionados por el objeto.
La invocación se compone de los siguientes pasos:
Encapsulado (marshalling) de los parámetros (utilizando la funcionalidad de serialización de Java).
Invocación del método (del cliente sobre el servidor). El invocador se queda esperando una respuesta.
Al terminar la ejecución, el servidor serializa el valor de retorno (si lo hay) y lo envía al cliente.
El código cliente recibe la respuesta y continúa como si la invocación hubiera sido local.


Arquitectura 

La arquitectura RMI puede verse como un modelo de cuatro capas.
Primera capa
La primera capa es la de aplicación y se corresponde con la implementación real de las aplicaciones cliente y servidor. Aquí tienen lugar las llamadas a alto nivel para acceder y exportar objetos remotos. Cualquier aplicación que quiera que sus métodos estén disponibles para su acceso por clientes remotos debe declarar dichos métodos en una interfaz que extienda java.rmi.Remote. Dicha interfaz se usa básicamente para "marcar" un objeto como remotamente accesible. Una vez que los métodos han sido implementados, el objeto debe ser exportado. Esto puede hacerse de forma implícita si el objeto extiende la clase UnicastRemoteObject (paquete java.rmi.server), o puede hacerse de forma explícita con una llamada al método exportObject() del mismo paquete.
Segunda capa
La capa 2 es la capa proxy, o capa stub-skeleton. Esta capa es la que interactúa directamente con la capa de aplicación. Todas las llamadas a objetos remotos y acciones junto con sus parámetros y retorno de objetos tienen lugar en esta capa.
Tercera capa
La capa 3 es la de referencia remota, y es responsable del manejo de la parte semántica de las invocaciones remotas. También es responsable de la gestión de la replicación de objetos y realización de tareas específicas de la implementación con los objetos remotos, como el establecimiento de las persistencias semánticas y estrategias adecuadas para la recuperación de conexiones perdidas. En esta capa se espera una conexión de tipo stream (stream-oriented connection) desde la capa de transporte.
Cuarta Capa
La capa 4 es la de transporte. Es la responsable de realizar las conexiones necesarias y manejo del transporte de los datos de una máquina a otra. El protocolo de transporte subyacente para RMI es JRMP (Java Remote Method Protocol), que solamente es "comprendido" por programas Java.


Elementos

• Toda aplicación RMI normalmente se descompone en 2 partes:
• Un servidor, que crea algunos objetos remotos, crea referencias para hacerlos accesibles, y espera a que el cliente los invoque.
• Un cliente, que obtiene una referencia a objetos remotos en el servidor, y los invoca.

Para mas información visite http://es.wikipedia.org/wiki/Java_Remote_Method_Invocation




CORBA

En un sentido general, CORBA "envuelve" el código escrito en otro lenguaje, en un paquete que contiene información adicional sobre las capacidades del código que contiene y sobre cómo llamar a sus métodos. Los objetos que resultan, pueden entonces ser invocados desde otro programa (u objeto CORBA) desde la red. En este sentido CORBA se puede considerar como un formato de documentación legible por la máquina, similar a un archivo de cabeceras, pero con más información.
CORBA utiliza un lenguaje de definición de interfaces (IDL) para especificar las interfaces con los servicios que los objetos ofrecerán. CORBA puede especificar a partir de este IDL, la interfaz a un lenguaje determinado, describiendo cómo los tipos de dato CORBA deben ser utilizados en las implementaciones del cliente y del servidor. Implementaciones estándar existen para Ada, C, C++, Smalltalk, Java, Python, Perl y Tcl.
Al compilar una interfaz en IDL se genera código para el cliente y el servidor (el implementador del objeto). El código del cliente sirve para poder realizar las llamadas a métodos remotos. Es el conocido como stub, el cual incluye un proxy (representante) del objeto remoto en el lado del cliente. El código generado para el servidor consiste en unos skeletons (esqueletos) que el desarrollador tiene que rellenar para implementar los métodos del objeto.
CORBA es más que una especificación multiplataforma, también define servicios habitualmente necesarios como seguridad y transacciones. Y así este no es un sistema operativo en si, en realidad es un middleware.


Para mas información visite http://es.wikipedia.org/wiki/CORBA


BPM
Se llama Gestión o administración por procesos de negocio (Business Process Management o BPM en inglés) a la metodología corporativa cuyo objetivo es mejorar el desempeño (Eficiencia y Eficacia) de la Organización a través de la gestión de los procesos de negocio, que se deben diseñar, modelar, organizar, documentar y optimizar de forma continua. El Modelo de Administración por Procesos, se refiere al cambio operacional de la empresa al migrar de una operación funcional a una operación de administrar por procesos.


Ventajas

Un proceso se puede ver como un conjunto de recursos y actividades interrelacionados que transforman elementos de entrada en elementos de salida. Los recursos pueden incluir personal, finanzas, instalaciones, equipos, técnicas y métodos.
A través del modelado de los procesos de negocio, al interior de una organización, puede lograrse un mejor entendimiento de la operación de la empresa y muchas veces esto presenta la oportunidad de mejorar los procesos y con ello mejorar el desempeño. La estructuración de los procesos reduce errores, asegurando que los procesos se comporten siempre de la misma manera, reduciendo el margen de error y dando elementos que permitan visualizar el estado de los mismos durante cada etapa. La administración de los procesos permite asegurar que los mismos se ejecuten eficientemente, cumpliendo con estándares de calidad previamente establecidos, y ayudando a la obtención de información que luego puede ser usada para mejorarlos. Es a través de la información que se obtiene de la ejecución diaria de los procesos, que se puede identificar posibles ineficiencias o fallas en los mismos, y actuar sobre ellos para optimizarlos.

Razones de La Gestión de Procesos 

Existen diversos motivos que mueven la gestión de los Procesos dentro de una organización, entre los cuales se encuentran:

• Extensión del programa institucional de calidad
• Cumplimiento de legislaciones vigentes
• Crear nuevos y mejores procesos (mejoramiento continuo)
• Entender qué se está haciendo bien o mal a través de la comprensión de los procesos
• Documentar los procesos para la subcontratación y la definición del Service Level Agreement (SLA)
• Automatización y organización de los procesos
• Crear y mantener la cadena de valor

Para mayor Información visite http://es.wikipedia.org/wiki/Gesti%C3%B3n_de_procesos_de_negocio






BPML



BPML es un metalenguaje XML para el modelado de procesos de negocio. Una norma publicada por Business Process Management Initiative (BPMI), que proporciona una forma universal para describir los procesos de negocio en las organizaciones. Los procesos de negocio modelados con BPML se pueden implementar y ejecutar en cualquier sistema de gestión de BPML compatible con procesos de negocio (BPMS).


Fundamentos BPML


Proceso


El proceso es el concepto básico de BPML. Los componentes clave de un proceso son:


* Ejecución de un conjunto de actividades


* La interacción con los participantes por el intercambio de mensajes


* Las reglas predefinidas para determinar el flujo de la ejecución


* Los horarios para gobernar el inicio y la finalización de la ejecución


* Procesamiento de los datos mediante la celebración de los datos internos que pueden ser accedidos por todas sus actividades


Voy a usar un proceso handlePurchaseOrder simple para ilustrar cómo modelar un proceso que utiliza BPML. El proceso contiene los siguientes pasos:


1. En el inicio del proceso esperará a que la "orden de compra" del mensaje.


2. Cuando se recibe una orden de compra, el proceso será comprobar si es un cliente existente, y creará una cuenta de cliente si se trata de un nuevo cliente.


3. El proceso de revisar el sistema de inventario para ver si hay suficiente inventario para cumplir con la orden.


4. El proceso envía un intento de envío a todas las compañías se contrae. Se establece un precio predefinido, y aceptar la primera oferta que cumpla con el criterio de precio.


5. Los horarios de procesar una orden de entrega con el portador seleccionado.


6. El proceso envía una notificación de envío para el cliente.




Tomado de http://business.highbeam.com/436115/article-1G1-90305758/model-your-business-processes-using-bpml-just-bpml

SOA, SAAS, ASP, C/S

SOA

La arquitectura orientada a servicios de cliente (en inglés Service Oriented Architecture), es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio.
Permite la creación de sistemas de información altamente escalables que reflejan el negocio de la organización, a su vez brinda una forma bien definida de exposición e invocación de servicios (comúnmente pero no exclusivamente servicios web), lo cual facilita la interacción entre diferentes sistemas propios o de terceros.
SOA define las siguientes capas de software:

• Aplicaciones básicas - Sistemas desarrollados bajo cualquier arquitectura o tecnología, geográficamente dispersos y bajo cualquier figura de propiedad;
• De exposición de funcionalidades - Donde las funcionalidades de la capa aplicativa son expuestas en forma de servicios (generalmente como servicios web);
• De integración de servicios - Facilitan el intercambio de datos entre elementos de la capa aplicativa orientada a procesos empresariales internos o en colaboración;
• De composición de procesos - Que define el proceso en términos del negocio y sus necesidades, y que varía en función del negocio;
• De entrega - donde los servicios son desplegados a los usuarios finales.

SOA proporciona una metodología y un marco de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividades de integración y consolidación.


Diseño y Desarrollo De SOA

La metodología de modelado y diseño para aplicaciones SOA se conoce como análisis y diseño orientado a servicios. La arquitectura orientada a servicios es tanto un marco de trabajo para el desarrollo de software como un marco de trabajo de implementación. Para que un proyecto SOA tenga éxito los desarrolladores de software deben orientarse ellos mismos a esta mentalidad de crear servicios comunes que son orquestados por clientes o middleware para implementar los procesos de negocio. El desarrollo de sistemas usando SOA requiere un compromiso con este modelo en términos de planificación, herramientas e infraestructura.
Cuando la mayoría de la gente habla de una arquitectura orientada a servicios están hablando de un juego de servicios residentes en Internet o en una intranet, usando servicios web. Existen diversos estándares relacionados a los servicios web. Incluyen los siguientes:

• XML
• HTTP
• SOAP
• REST
• WSDL
• UDDI

Hay que considerar, sin embargo, que un sistema SOA no necesariamente necesita utilizar estos estándares para ser "Orientado a Servicios" pero es altamente recomendable su uso.
En un ambiente SOA, los nodos de la red hacen disponibles sus recursos a otros participantes en la red como servicios independientes a los que tienen acceso de un modo estandarizado. La mayoría de las definiciones de SOA identifican la utilización de Servicios Web (empleando SOAP y WSDL) en su implementación, no obstante se puede implementar SOA utilizando cualquier tecnología basada en servicios.


Diferencias Con Otras Arquitecturas
Al contrario de las arquitecturas orientado a objetos, las SOAs están formadas por servicios de aplicación débilmente acoplados y altamente interoperables. Para comunicarse entre sí, estos servicios se basan en una definición formal independiente de la plataforma subyacente y del lenguaje de programación (p.ej., WSDL). La definición de la interfaz encapsula (oculta) las particularidades de una implementación, lo que la hace independiente del fabricante, del lenguaje de programación o de la tecnología de desarrollo (como Plataforma Java o Microsoft .NET). Con esta arquitectura, se pretende que los componentes de software desarrollados sean muy reutilizables, ya que la interfaz se define siguiendo un estándar; así, un servicio C# podría ser usado por una aplicación Java. En este sentido, ciertos autores definen SOA como una Súper-Abstracción.


Beneficios

Los beneficios que puede obtener una organización que adopte SOA son:

• Mejora en los tiempos de realización de cambios en procesos.
• Facilidad para evolucionar a modelos de negocios basados en tercerización.
• Facilidad para abordar modelos de negocios basados en colaboración con otros entes (socios, proveedores).
• Poder para reemplazar elementos de la capa aplicativa SOA sin disrupción en el proceso de negocio.
• Facilidad para la integración de tecnologías disímiles.

Para mas informacion visite http://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios

SAAS

Software como Servicio (del inglés: Software as a Service, SaaS) es un modelo de distribución de software donde el software y los datos que maneja se alojan en servidores de la compañía de tecnologías de información y comunicación (TIC) y se accede con un navegador web o un cliente fino especializado, a través de internet. La empresa TIC provee el servicio de mantenimiento, operación diaria, y soporte del software usado por el cliente. Regularmente el software puede ser consultado en cualquier computador, esté presente en la empresa o no. Se deduce que la información, el procesamiento, los insumos y los resultados de la lógica de negocio del software están hospedados en la compañía de TIC.



Las características del software como servicio incluyen:

• Acceso y administración a través de una red.
• Actividades gestionadas desde ubicaciones centrales, en lugar de la sede de cada cliente, permitiéndoles tener acceso remoto a las aplicaciones mediante la web.
• La distribución de la aplicación es más cercana al modelo uno-a-muchos (una instancia con múltiples usuarios) que al modelo uno-a-uno, incluyendo arquitectura, precios, colaboración y administración.
• Actualizaciones centralizadas, lo cual elimina la necesidad de descargar parches por parte de los usuarios finales.
• Frecuente integración con una red mayor de software de comunicación, bien como parte de un mashup o como un enlace para una plataforma como servicio.

Ventajas 

• No es necesario que el cliente cuente con un área especializada de soporte para el sistema, por lo que se reducen sus costes y riesgo de inversión.
• La responsabilidad de la operación recae en la empresa IT. Esto significa que la garantía de disponibilidad de la aplicación y su correcta funcionalidad, es parte del servicio que da la compañía proveedora del software.
• La empresa IT no desatiende al cliente. El servicio y atención continua del proveedor al cliente es necesaria para que este último siga pagando el servicio.
• La empresa IT provee los medios seguros de acceso en los entornos de la aplicación. Si una empresa IT quiere dar SaaS en su cartera de productos debe ofrecer accesos seguros para que no se infiltren datos privados en la red pública.
• No es necesaria la compra de una licencia para utilizar el software, sino el pago de un alquiler o renta por el uso del software. Aunque se dan casos particulares donde el servicio es totalmente gratuito, como por ejemplo en el servicio de blogs de diferentes compañías: Wordpress, Blogger, etc. Es decir, se cuenta con el servicio, se puede acceder libremente, se garantiza usabilidad y actualidad, pero no se paga por el servicio.
• Se le permite al cliente completa flexibilidad en el uso de los sistemas operativos de su preferencia, o al cual pueda tener acceso.

Inconvenientes

• La persona usuaria no tiene acceso directo a sus contenidos, ya que están guardados en un lugar remoto, y en caso de no contar con mecanismos de cifrado y control disminuye el índice de privacidad, control y seguridad que ello supone, ya que la compañía TI podría consultarlos.
• El usuario no tiene acceso al programa, por lo cual no puede hacer modificaciones (dependiendo de la modalidad del contrato de servicios que tenga con la compañía TI).
• Al estar el servicio y el programa dependientes de la misma empresa no permite al usuario migrar a otro servicio utilizando el mismo programa (dependiendo de la modalidad del contrato de servicios con la compañía de TI).
• Si el servicio de Internet no está disponible por parte del ISP, el usuario no tendrá acceso al programa, por lo que sus operaciones se verán afectadas hasta que dicho servicio se restablezca.
• Otras consideraciones sobre dificultades en implementaciones SaaS, surgen de una falta de entendimiento de las verdaderas implicaciones de depender de un servicio externo que pueden llevar a incurrir en sobrecostos pero sobre todo en un servicio que no cumple las expectativas de ciertos clientes.

Para saber mas visite http://es.wikipedia.org/wiki/Software_como_servicio







Arquitectura Cliente -Servidor

Una arquitectura es un conjunto de reglas, definiciones, términos y modelos que se emplean para producir un producto. 
La arquitectura Cliente/Servidor agrupa conjuntos de elementos que efectúan procesos distribuidos y computo cooperativo.



Beneficios: 
Mejor aprovechamiento de la potencia de cómputo (Reparte el trabajo). 
Reduce el tráfico en la Red. 
Opera bajo sistemas abiertos. 
Permite el uso de interfaces gráficas variadas y versátiles. 


¿Qué es el Cliente? 
Conjunto de Software y Hardware que invoca los servicios de uno o varios servidores. 


Características: 
El Cliente oculta al Servidor y la Red. 
Detecta e intercepta peticiones de otras aplicaciones y puede redirigirlas. 
Dedicado a la cesión del usuario ( Inicia...Termina ). 
El método más común por el que se solicitan los servicios es a través de RPC (Remote Procedure Calls). 
Funciones Comunes del Cliente: 
Mantener y procesar todo el dialogo con el usuario. 
Manejo de pantallas. 
Menús e interpretación de comandos. 
Entrada de datos y validación. 
Procesamiento de ayudas. 
Recuperación de errores. 



¿Qué es el Servidor? 
Conjunto de Hardware y Software que responde a los requerimientos de un cliente. 


Tipos Comunes de Servidores: 
Servidor de Archivos. 
Servidor de Bases de Datos (SQL, CBASE, ORACLE, INFORMIX). 
Servidor de Comunicaciones 
Servidor de Impresión. 
Servidor de Terminal. 
Servidor de Aplicaciones. 
Funciones Comunes del Servidor: 
Acceso, almacenamiento y organización de datos. 
Actualización de datos almacenados. 
Administración de recursos compartidos. 
Ejecución de toda la lógica para procesar una transacción. 
Procesamiento común de elementos del servidor (Datos, capacidad de CPU, almacenamiento en disco, capacidad de impresión, manejo de memoria y comunicación). 


Arquitectura Multi-Capas

La arquitectura cliente/servidor genérica tiene dos tipos de nodos en la red: clientes y servidores. Consecuentemente, estas arquitecturas genéricas se refieren a veces como arquitecturas de dos niveles o dos capas.
Algunas redes disponen de tres tipos de nodos:

• Clientes que interactúan con los usuarios finales.
• Servidores de aplicación que procesan los datos para los clientes.
• Servidores de la base de datos que almacenan los datos para los servidores de aplicación.

Esta configuración se llama una arquitectura de tres-capas.
Ventajas de las arquitecturas n-capas:

• La ventaja fundamental de una arquitectura n-capas comparado con una arquitectura de dos niveles (o una tres-capas con una de dos niveles) es que separa hacia fuera el proceso, eso ocurre para mejorar el balance la carga en los diversos servidores; es más escalable.

Desventajas de las arquitecturas de la n-capas:

• Pone más carga en la red, debido a una mayor cantidad de tráfico de la red.
• Es mucho más difícil programar y probar el software que en arquitectura de dos niveles porque tienen que comunicarse más dispositivos para terminar la transacción de un usuario.

Ventajas

• Centralización del control: los accesos, recursos y la integridad de los datos son controlados por el servidor de forma que un programa cliente defectuoso o no autorizado no pueda dañar el sistema. Esta centralización también facilita la tarea de poner al día datos u otros recursos (mejor que en las redes P2P)..
• Escalabilidad: se puede aumentar la capacidad de clientes y servidores por separado. Cualquier elemento puede ser aumentado (o mejorado) en cualquier momento, o se pueden añadir nuevos nodos a la red (clientes y/o servidores).
• Fácil mantenimiento: al estar distribuidas las funciones y responsabilidades entre varios ordenadores independientes, es posible reemplazar, reparar, actualizar, o incluso trasladar un servidor, mientras que sus clientes no se verán afectados por ese cambio (o se afectarán mínimamente). Esta independencia de los cambios también se conoce como encapsulación.
• Existen tecnologías, suficientemente desarrolladas, diseñadas para el paradigma de C/S que aseguran la seguridad en las transacciones, la amigabilidad de la interfaz, y la facilidad de empleo.

Desventajas

• La congestión del tráfico ha sido siempre un problema en el paradigma de C/S. Cuando una gran cantidad de clientes envían peticiones simultaneas al mismo servidor, puede ser que cause muchos problemas para éste (a mayor número de clientes, más problemas para el servidor). Al contrario, en las redes P2P como cada nodo en la red hace también de servidor, cuanto más nodos hay, mejor es el ancho de banda que se tiene.
• El paradigma de C/S clásico no tiene la robustez de una red P2P. Cuando un servidor está caído, las peticiones de los clientes no pueden ser satisfechas. En la mayor parte de redes P2P, los recursos están generalmente distribuidos en varios nodos de la red. Aunque algunos salgan o abandonen la descarga; otros pueden todavía acabar de descargar consiguiendo datos del resto de los nodos en la red.
• El software y el hardware de un servidor son generalmente muy determinantes. Un hardware regular de un ordenador personal puede no poder servir a cierta cantidad de clientes. Normalmente se necesita software y hardware específico, sobre todo en el lado del servidor, para satisfacer el trabajo. Por supuesto, esto aumentará el coste.
• El cliente no dispone de los recursos que puedan existir en el servidor. Por ejemplo, si la aplicación es una Web, no podemos escribir en el disco duro del cliente o imprimir directamente sobre las impresoras sin sacar antes la ventana previa de impresión de los navegadores.

Para mayor informacion visite http://es.wikipedia.org/wiki/Cliente-servidor

Diferencias y Similitudes Entre Varias Arquitecturas


1. ES LO MISMO CLIENTE SERVIDOR QUE SOA


Para nuestro concepto tanto SOA como la arquitectura c/s son arquitecturas de gran importancia ya que la primera es la lógica del negocio y la segunda es la arquitectura en la cual se distribuye la información, Al contrario de las arquitecturas orientadas a objetos, SOA está formada por servicios de aplicación con acoplamiento débil y altamente interoperable.
Una diferencia clara de SOA con la arquitectura c/s es que esta está orientada a procesos y enfocada al cambio. De esta forma las empresas TI se benefician mucho ya que con esta pueden reconfigurar rápidamente sus recursos de TI sin necesidad de realizar una integración profunda, lo cual les permite liberar recursos para abrir espacio a la innovación y a la alta calidad.


2. ES LA  ARQUITECTURA CLIENTE SERVIDOR LA BASE DE SOA


La arquitectura C/S si es la base de SOA ya que SOA es una evolución de esta, aunque hay que tener en cuenta que SOA puede ser claramente independiente de la arquitectura C/S ya que esta es la lógica del negocio.
Como evolución de la arquitectura C/S esta contempla en si unos puntos claros de la arquitectura c/s Tales como:
-las funciones de la interface del usuario
- la lógica de las aplicaciones
- la administración de los datos, están separados de forma que cada una puede ser implementada usando las plataformas y las tecnologías que mejor se adapten a la tarea.
SOA incorpora servicios que corren en distintas plataformas y estos  están alojados en distintos servidores.


3. COMO SE ACOPLA SOA Y C/S CON SAAS Y ASP


Siendo SOA una evolución de la arquitectura cliente servidor enfocándose a los servicios podemos decir que hay una alta relación con las arquitecturas saas y asp ya que siendo ASP un proveedor de servicios, Y SAAS un modelo de distribución de software podemos contemplar que todos están con un mismo fin satisfacer las necesidades del cliente ofreciendo en si un servicio o un software de calidad.
Aunque existen diferencias notables entre estas arquitecturas como por ejemplo ASP siendo proveedor de software este ofrece sus servicios a múltiples clientes y este puede adaptar dicho software a su modo para garantizar su necesidad en cambio en SAAS estando esta en la nube presta sus servicios a muchos clientes con la clara diferencia de que estos solo pueden acceder a este sin modificarlo un ejemplo claro de este es gmail y siendo SOA una arquitectura orientada a servicios en donde su claro objetivo no es más que darle soporte a los requisitos del negocio y contemplando la clara perspectiva de que la arquitectura c/s no garantiza la buena lógica de negocios ya que esta presentaba La congestión del tráfico ya que esta siempre ha sido un problema en el paradigma de C/S. Cuando una gran cantidad de clientes envían peticiones simultáneas al mismo servidor, puede ser que cause muchos problemas para éste ya que a mayor número de clientes, más problemas para el servidor por este motivo fue creado SOA ya que este satisface dichos problemas. Entonces como conclusión podemos decir que estas arquitecturas buscan la mejora de las tecnologías en sí, ya que un cliente siempre lo que espera en un software o en un servicio es la seguridad, la fiabilidad y la disponibilidad estas están en la clara respuesta sobre estos planteamientos ofreciéndonos siempre un servicio o un software de alta calidad garantizándonos éxitos a nosotros como clientes.


4. ESTANDARES DE SOA


Service Component Architecture (SCA): En el post pasado dijimos que esta especificación provee un modelo para la creación de componentes de servicios dentro de una solución de negocios, es decir las actividades las cuales están en el corazón de las aplicaciones. SCA provee un modelo de programación para crear componentes de servicios escritos ya sea en Java, BPEL, C++ o lenguajes declarativos como XSLT.


Service Data Objects (SDO): Establece un significado consistente a los datos que operan entre diversas aplicaciones sin importar la fuente o el formato de las mismas.Ofrece un mecanismo para unificar datos de diversas bases de datos y servicios.


Business Process Execution Language (BPEL): Provee un estándar de procesos de negocio empresarial para la ejecución y orquestación. Usando BPEL se pueden diseñar procesos de negocio que integran servicios discretos dentro de un flujo de proceso de presentación final. Esta integración reduce tremendamente los costos de proceso y complejidad.


Transformaciones XSL (XSLT): Procesa documentos XML y transforma datos de un esquema de documento XML en otro. 


Java Connector Architecture (JCA): Provee una solución en tecnología Java para la conexión entre diversos servidores de aplicaciones.
Java Messaging Service (JMS): Provee un estándar de mensajeo para comunicar diversas aplicaciones basadas en Java 2 y Enterprise Edition (Java EE) a través de sistemas heterogéneos.


Archivos Web Services Description Language (WSDL): Proporcionan los puntos de entrada en una aplicación compuesta SOA (composite application). El archivo WSDL proporciona un lenguaje estándar reducido y es la base para entender las capacidades de un servicio. El Simple Object Access Protocol (SOAP) proporciona el protocolo de red para la entrega de mensajes.


http://oscaryani.blogspot.com/2010/07/estandares-adoptados-por-oracle-soa.html




5. SOA NO ES LO MISMO QUE WEBSERVICES ¿Por qué?


SOA y servicios web son dos cosas diferentes ya que estos  son la preferencia basada en estándares  al contrario de SOA ya que este se puede implementar con múltiples tecnologías tales como MOM, CORBA, COBOL ETC.


SOA  es un mecanismo de intercambio de información dentro de los muchos que se utilizan,  para conectar o transmitir información de las aplicaciones. Estos son estándares, lo que comúnmente utilizamos. Es importante concretar que Web Services no es SOA, sino un mecanismo de intercambio de información.


Aunque hay que tener en cuenta que cuando se desea conseguir la máxima reutilización de información  se pueden utilizar los estándares más ampliamente soportados teniendo en cuenta aspectos como la reutilización de funcionalidades por otros consumidores, Reutilización de funcionalidades de otros servicios, Aprovechamiento de otras herramientas y Conocimiento del personal.


En conclusión podemos decir que SOA es una abstracción del éxito de los servicios web para integración de sistemas de información ofreciendo así un gran alto potencial ,bajos costos , alta integración y de gran flexibilidad favoreciendo en si la automatización de las relaciones de negocio a negocio a través de Internet.