Middleware y SOA por Ejemplo

Clases/ejemplo Java para cada tecnología. puede que no sea posible en un solo post porque lo que preguntaste es que la industria de la evolución pasó en la última década y sigue evolucionando. Por lo tanto, lo que sucedió durante la última década no se puede cubrir en un solo post. Sin embargo, es bueno entender cómo pasó por esta fase y por qué se requiere una nueva pila de tecnología y qué tipo de problema resuelve.

• EJBs Enterprise Java Beans serverside component architecture. Permite una rápida y simplificada desarrollo de

  1) distribuido (donde múltiples servidores de aplicaciones se comunican entre sí, componentes del servidor (por ejemplo, servicio llamando a otro servicio alojado en un servidor diferente).

  2) transactional - persistance bean (DB TXNs), la parte más importante de cualquier aplicación simple/web/distribuida. Fácil desarrollo, por ejemplo, base de configuración. Escriba XML que se encargue de la transacción, por ejemplo, cuándo confirmar, cuándo revertir (en excepciones), etc. Las API de persistencia de Java de JPA proporcionan una relación de objetos mapeo. Por ejemplo, la fila de la tabla se asigna a su objeto java a través de la configuración xml.

  3) secure-authentication(uid / pwd) and authorization (role based - who is logged in user and what all task he can do?).

Esto se ve bien en un momento para desarrollar cualquier aplicación empresarial, sin embargo, tiene algunas desventajas, por ejemplo, su muy pesado (todos los frascos incluidos en ella.). Las clases utilizadas como bean deben confirmar los estándares EJB (las clases deben haber implementado ciertos interfaz para EJB engine para entender qué tipo de bean es).

Para superar tales escenarios, hay muchas alternativas están disponibles en la industria para EJBs e.g Hibrnate hace las mismas cosas como O mapeo, TXN manejo mismo proporcionado por persistance bean en EJB. Spring, light weight framework y simplifica la lógica de negocios (puede usar su clase de compilación ya que no necesita implementar ninguna interfaz, excepciones verificadas o extiende algunos de los resúmenes obligatorios clase).

Hoy en día, la mayoría de las empresas realmente en el trabajo de marco ligero como Spring, Hibernate, iBATIS, Axis-2.

• Arquitectura orientada a Servicios (SOA) La arquitectura orientada a servicios es una respuesta a la independencia de la plataforma a nivel empresarial. O Para integrar su aplicación más rápido, para comunicarse entre diferentes servidores de aplicaciones.

  Solo piense que desea implementar una solución donde está proporcionando la opción para la reserva de hotel todos por todo el mundo. Su requisito es comprobar la disponibilidad de habitaciones en esos hoteles. Ahora, significa que necesita interactuar con múltiples aplicaciones de hoteles a la vez. No es necesario que cada hotel esté utilizando el mismo estándar o que su aplicación(servidor, lenguaje de programación) se pueda implementar en los diferentes servidores de aplicaciones. Al mismo tiempo, no es práctico escribir diferentes aplicaciones que pueden hablar con todos los tipos diferentes del servidor de aplicaciones. Necesitamos alguna solución basada en estándares que puede resolver este problema. Es posible a través de los servicios Web.

Es posible porque los servicios web están enviando mensajes en el SOAP(Simple Object Access Protocol), basado en el XML. XML se utiliza para intercambiar datos a través de cualquier idioma, plataforma o protocolo de red.

Los servicios web se pueden clasificar basados en SOAP y REST. Servicio basado en SOAP JAX-RPC y JAX-WS ( http://www.ibm.com/developerworks/webservices/library/ws-tip-jaxwsrpc/index.html )

Se pueden desarrollar servicios web contrato primero-primera escritura WSDL. primero el código - primero escribe el código.

Ahora, vamos a hablar de cómo empezar para los servicios web prácticamente.

El servicio web más simple o hello world(JAXWS) se puede escribir como seguir:- http://svn.apache.org/viewvc/cxf/trunk/distribution/src/main/release/samples/java_first_jaxws/

• Middleware orientado a mensajes (MOM)
• JMS

• Cola de mensajes (Punto a punto)

  Se requiere que MAMÁ supere las desventajas de la comunicación de estilo solicitud-respuesta. El servidor debe estar activo cuando el cliente envía la respuesta. El cliente espera la respuesta hasta que el servidor se ejecute y responda.

  Respuesta a la solicitud: la aplicación fallará si el servidor o cliente está caído. MOM-Cualquiera de los puntos finales no es necesario para estar a tiempo de enviar el mensaje de solicitud para el procesamiento.

  MOM es concepto y JMS es especificación de este concepto. Muchos proveedores tienen implementación de esta especificación, por ejemplo, IBM tiene MQ, implementación de código abierto OpenJMS, EMS de Tibco, etc.

La especificación JMS tiene principalmente dos patrones. Pub / sub y ponin-to-point.

Pub / sub es el tema, su aplicación quiere publicar cierta información a todas las partes interesadas. por ejemplo, tablero de instrumentos. (Aplicación de valores desea notificar cierto mensaje a todos los oyentes registrados).

La comunicación Punto a punto se realiza a través de la cola de mensajes.

Caso de uso comercial - cree que tiene una aplicación, por ejemplo, una solicitud del cliente al servicio de atención al cliente. Otro lado tiene varios representantes de atención al cliente y otros clientes secundarios a veces más que los representantes de atención al cliente, a la vez solo un representante recibirá la solicitud para ser procesada y él/ella no recibirá la siguiente solicitud hasta que termine la tarea. (Una misma cola de múltiples ventanas y que cada ventana es libre procesará la solicitud). Puede pensar en otra complejidad en esto, por ejemplo, qué pasa si uno de los nodos falla, la solicitud no se procesa y un tipo particular de solicitud debe procesarse por un nodo particular. sucesivamente.

Producir código:- http://docs.oracle.com/javaee/1.4/tutorial/examples/jms/simple/src/SimpleProducer.java

Código síncrono del consumidor:- (Clases POJO) http://docs.oracle.com/javaee/1.4/tutorial/examples/jms/simple/src/SimpleSynchConsumer.java

Http://www.java2s.com/Code/Java/J2EE/ThisexampleisasimpleJMSclientapplication.htm

Consumir código asíncrono: - (Spring por ejemplo-lee mensaje de destino hasta que el programa no será dejar.) http://www.springbyexample.org/examples/simple-spring-jms-listener-config.html

Sin embargo, es solo básico hay muchos aspectos que se cubren en esta MAMÁ, por ejemplo, lo que es mecanismo de conmutación por error, lo que es selector, mensaje duradero, modos de reconocimiento de mensajes, etc...

• Bus de servicio/ESB
• Endpoints & Routes
• Apache Camel
• Mula

Ahora, digamos que has adoptado a SOA y MAMÁ hace mucho tiempo y tienes un montón de servicios que habla entre sí para lograr la tarea de toda la empresa. Imagine administrar la lógica como múltiples destinos a los que se debe redirigir desde donde será muy engorroso. Algunas personas llaman a esta aplicación lógica. Los buses de servicio se utilizarán para reducir la lógica de la aplicación y centrarse más en la lógica de negocios(funcionalidad proporcionada por la aplicación).

En palabras simples, considere Punto final como URL expuesta en el servidor. Utilizará esta url / punto final para invocar su Servicio.

E. g. http://localhost:8888/Context/MyService?wsdl

En el código: -

    String endpointAddress = "http://localhost:8080/jaxws/services/hello_world?wsdl";

    // Add a port to the Service
    service.addPort(PORT_NAME, SOAPBinding.SOAP11HTTP_BINDING, endpointAddress);

    HelloWorld hw = service.getPort(HelloWorld.class);
    System.out.println(hw.sayHi("World"));

Rutas Cuando el autobús de servicio recibe un mensaje particular, lo enrutará a través de no de destinos de servicios / corredores, como colas / temas. Este camino se conoce como ruta.

Por ejemplo, su aplicación de stock tiene alguna entrada por parte del analista, se procesará a través del componente de aplicación / web y luego el resultado se publicará a todos los interesados / registrados miembros para actualización de existencias en particular.

Apache Camel y Muel http://camel.apache.org/how-does-camel-compare-to-mule.html proporciona una solución para la integración empresarial.

Enterprise Integration Patterns puede ayudarle a entender cómo todo encaja.

[actualización:] Su pregunta de seguimiento sobre otra respuesta me hizo darme cuenta de que está confundido acerca de productos específicos. Esto se debe en parte a que el software en la práctica tiende a mapear más de un concepto y en parte a que diferentes compañías argumentan que proporcionan "todo", cuando en realidad no lo hacen.

Los ESB son conjuntos de herramientas / bibliotecas que le permiten conectar todo. No son ni los servicios en sí mismos, ni las implementaciones de mensajería, sino la sustancia pegajosa que llena los pequeños vacíos en el medio. Si estuvieras escribiendo todo desde cero, es posible que ni siquiera lo necesites, porque lo que hacen mejor es arreglar el desajuste entre toda una pila de tecnologías diferentes, y si estás empezando desde cero puedes evitar ese lío.

Los servicios son, bueno, los servicios. Puede usar algunos EJB al implementar uno (solo menciono esto porque para alguna razón por la que los incluyas en tu pregunta).

El middleware de mensajería es un software que recibe mensajes de A a B. Eso es extremadamente útil, pero también complejo, y todos y su hermano han inventado el suyo propio. Así que necesitas algo de abstracción que te permita evitar el bloqueo. Eso puede ser un ESB o, si eres todo-Java entonces puede ser JMS. Pero incluso cuando todo está en Java con JMS, es posible que aún desee usar un ESB porque son bibliotecas de todos los bits de código Java que aún querría necesidad de escribir (bits aleatorios de la lógica de enrutamiento, reformateo de mensajes, etc etc).

Espero que eso ayude. Mi respuesta original es más acerca de los patrones abstractos que construyes con estas herramientas - cuando estás cableando cosas juntas, los mismos problemas surgen una y otra vez.

Endpoints & Routes: de dónde viene y a dónde va la información. La cola de mensajes es un tipo de punto final. El otro tipo es un Tema de mensaje.

Un punto final es un 'nombre lógico para una cosa', por ejemplo, PRICE.MSFT, que es utilizado por un editor o aplicación de consumo para obtener cosas de o enviar a. Los temas entregan información a todos los suscritos( uno a uno o uno a muchos), las colas entregan mensajes al primero que la recibe (generalmente uno a uno). Olvídate de las colas, todo también puede se hace con los temas y los temas tienen varias ventajas.

Middleware orientado a mensajes (MOM): la infraestructura de software que entrega información entre temas o queus. Es' orientado a mensajes 'no' orientado a paquetes ' como lo es TCP. Así que cada gota de información se entrega en un mensaje, con suerte auto-descriptivo. La implementación de tu MAMÁ te da una API donde puedes hacer cosas como msg.get ("bid")

JMS y AMQP son ejemplos de especificaciones MOM. MADRE las implementaciones son los productos reales que implementan estas especificaciones: TIBCO EMS, Websphere MQ, MSMQ, Solace, y muchos, muchos otros

Apache Camel - enfoque muy interesante sobre cómo configurar flujos de trabajo en este mundo MOM. Pero un concepto más avanzado.

Arquitectura orientada a Servicios (SOA), Bus de Servicio/ESB son solo nuevas palabras de moda para lo que solía llamarse EAI (Enterprise Application Integration). Son recomendaciones sobre cómo usar ' MOM's y una forma de pagar alto precio consultores. Lo que' ESB 'agrega a una MADRE es la idea de pensar en sus editores como' servicios ' que brindan un servicio. En otras palabras: no pienses demasiado en lo que un consumidor quiere en este momento. Podría haber 5 consumidores en el futuro y ese editor debería proporcionar un servicio, no "crear información que el consumidor A quiere". (Se volverá más claro una vez que su arquitectura haya crecido a más de 5 aplicaciones). También debe tener algún modelo de objeto común, tal vez en XML para hacer las cosas simples entre aplicación.

Mule - una forma de ESB, pero no es exactamente main-stream. En 5 años, la mayoría de las acciones de middleware podrían haberse movido a AMQP o a otra cosa por completo.

EJBs: La idea de Sun de clases Java sofisticadas que se ejecutan en un contenedor. Se supone que facilita el desarrollo de aplicaciones. Pero en muchos casos hizo las cosas más complejas. Una mejor alternativa sería 'Primavera' - pero EJB son sobre otra cosa (no solo MAMÁ). Más sobre cómo desarrollar aplicaciones más grandes (ver patrón CoI).

Si estás buscando por dónde empezar: Te recomendaría aprender acerca de JMS (todas las otras mamás son simliar y JMS es la base de EJB / Mule, ...) y, a menos que tenga requisitos de rendimiento súper altos, considere que los mensajes son un TextMessage que contiene XML. La mayoría de las herramientas están disponibles en esa área. O incluso más simple pero menos sofisticado, un MapMessage con pares clave/valor.

Tomando todos sus requisitos y empaquetándolos en una consulta, me encontré con un excelente estudio de caso que debería satisfacer sus necesidades:

• Arquitectura Orientada a Servicios: Un Plan de Integración

Seguí adelante y busqué texto completo en el libro usando la función "Buscar dentro de este libro" de Amazon. Cubre todos los casos de integración que ha discutido, parece ser exhaustivo y lo guía a través de todo el diseño y la implementación proceso.

Me avergüenza decir que no he leído este yo mismo, pero recomiendo encarecidamente el uso de las mismas herramientas que hice para ver si se ajusta a sus necesidades antes de invertir en una copia. Parece más minucioso, más completo y más útil que simplemente imponerte una gran cantidad de documentación incompleta o poner contenido en cola en una respuesta aquí.

Mezclas muchos conceptos y tecnologías diferentes con diferentes niveles de abstracción. Pero todos sus conceptos tienen algo que ver con la integración de aplicaciones (empresariales). Voy a tratar de comentar sus definiciones:

• Arquitectura orientada a Servicios (SOA)
  SOA proporciona un conjunto de principios y metodologías para integrar las aplicaciones existentes como unidades de acoplamiento flexible. De los Patrones de Integración Empresarial (ver más abajo): " SOAs difuminan la línea entre la integración y distributed applications ".
• Bus de servicio/ESB
  El ESB es un concepto principal de SOA para reducir las dependencias dentro de las aplicaciones SOA. En lugar de muchas dependencias entre las aplicaciones, cada aplicación está conectada al ESB.
• Middleware orientado a mensajes (MOM)
  MOM es una infraestructura para enviar y recibir mensajes entre sistemas distribuidos. Esto se utiliza para integrar aplicaciones. MAMÁ era el martillo de oro antes de que saliera el bombo de SOA. Puesto que ambos son útiles, big integration suites proporciona ESB y MOM (o use MOM dentro de su ESB).
• Cola de mensajes
  Una cola de mensajes es solo un aspecto técnico en la arquitectura MOM. Cuando se desacopla el envío/recepción de mensajes, los mensajes se almacenan en colas hasta que el destinatario esté listo.
• Apache Camel
  Cuando el libro Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions llegó al mercado, se crearon algunas soluciones de software que proporciona la implementación de los patrones en este libro. Apache Camel es uno de ellos. Camel también es parte de Apache ServiceMix, que también es un ESB de código abierto. FuseSource y Talend están empaquetando Apache ServiceMix, Apache Camel y Apache Active MQ (MOM) en paquetes con soporte comercial.
• Mula
  Mule también es una plataforma de ESB e integración de código abierto.
• EJBs
  De Wikipedia: Enterprise JavaBeans (EJB) es una arquitectura de componentes administrada del lado del servidor para construcción modular de aplicaciones empresariales. Esto significa que EJB es un componente dentro de una aplicación y no tiene nada que ver con la integración de aplicaciones.
• Endpoints & Routes
  Cuando trabaja con Apache Camel está diseñando rutas entre endpoints, vea un tutorial . En resumen, los mensajes entran / salen de su sistema a través de endpoints y se procesan en un flujo definido por una ruta.
• JMS
  JMS o Java Message Service es un Middleware orientado a Mensajes (MOM) con una API Java estandarizada.

Enterprise Application Integration (EAI) es clave para conectar aplicaciones empresariales con sistemas heterogéneos. A lo largo de los años, los arquitectos de soluciones de integración han inventado su propia mezcla de patrones de diversas maneras. Pero la mayoría de estas arquitecturas tienen similitudes, iniciando un conjunto de estándares ampliamente aceptados en la arquitectura de patrones de integración. La mayoría de estos estándares se describen en el Catálogo de patrones de integración Empresarial disponible en: http://www.eaipatterns.com/toc.html .

WSO2 ESB

WSO2 Enterprise Service Bus (ESB) 4.7.0 documentación! WSO2 ESB es un ESB rápido, ligero, 100% de código abierto y fácil de usar distribuido bajo la licencia de Software Apache v2.0. WSO2 ESB permite a los administradores y desarrolladores de sistemas configurar convenientemente el enrutamiento de mensajes, la mediación, la transformación, el registro, la programación de tareas, la conmutación por error, el equilibrio de carga y más. Es compatible con la empresa más utilizada Integration Patterns (EIPs) y permite el cambio de transporte, la eventing, la mediación basada en reglas y la mediación basada en prioridades para requisitos de integración avanzados. El tiempo de ejecución de ESB está diseñado para ser completamente asíncrono, sin bloqueo y streaming basado en el motor de mediación Apache Synapse.