¿Cómo se hace la integración del sistema?

Question

Tengo curiosidad por saber cómo diferentes personas resuelven la integración de sistemas.Tengo la sensación de que en los últimos años se ha trabajado cada vez más en la integración de sistemas y que este tipo de necesidad de trabajo también aumentará.

Me pregunto si lo solucionas desarrollando tus propios pequeños servicios que luego se conectan o si utilizas algún tipo de producto (WebSphere, BizTalk, Mula etc).También creo que sería interesante saber cómo se gestionan y mantienen este tipo de soluciones (cómo se resuelve la seguridad, la instrumentación, etc.), qué tipo de problemas ha experimentado con su solución, etc.

Answer 1

Vaya, está bien, recibiré una publicación sobre esto, pero será importante.

La integración debe estar respaldada por una gran comprensión por parte de la empresa sobre los beneficios. Obtener un modelo operativo resuelto, ya que es posible que la empresa necesite estandarizar en lugar de integrar, ya que esto puede ser costoso. ¡Es por eso que la mayoría de SOA fallan! Arquitectura empresarial:Dirigir los beneficios comerciales de TI Autor (s):Juana W.ross

Si es necesaria la integración, deberá decidir el tipo de integración.

¿Cuáles son las métricas de velocidad y rendimiento?

Contamos con un .NET SOA con una Aplicación Compuesta que utiliza BizTalk 2006 y servicios web con Aplicaciones de Línea de Negocio.El rendimiento de la aplicación en el extremo compuesto (consumidor) está limitado a la velocidad de los servicios web (y su implementación) en la línea de aplicación comercial.Necesitamos un retorno de resultados inferior a 3 segundos: lista de casos.No se pudo lograr en los servicios web, por lo que debemos ir directamente a la base de datos para la búsqueda inicial.Luego, a través de los servicios web para la creación de casos.Las implicaciones de costos y el mantenimiento se convierten en un problema aquí.

El punto aquí es observar los criterios de rendimiento en las especificaciones y los requisitos comerciales, esto ayudará a determinar el tipo de integración que necesita realizar: servicios web (HTTP), entrega de archivos/EDI, etc.

Funcionalmente para la integración es necesario observar los puntos de falla en la arquitectura propuesta, ya que esto conducirá a una cadena de responsabilidad en SLA/OLA.Es posible que deba envolver los puntos de integración/fallo en cosas que usted controla.

Un punto similar sobre la integración con la línea de negocio es ¿cuánto necesita saber sobre el otro producto antes de poder integrarlo?Sí, se supone que los servicios web se diseñan por contrato, pero la implementación a menudo tiene fugas y es necesario comprender mucho sobre lo que está sucediendo, y si se trata de un producto, no controla la abstracción incluso con las filtraciones de servicios web en su tecnología de interconexión, también conocida como BizTalk.

Combine estos dos puntos y el mejor consejo es obtener un tipo de centro de integración como BizTalk: envuelva la línea de aplicaciones comerciales en los servicios web que cree, de modo que el lado de BizTalk pueda estar libre de abstracciones con fugas y luego también pueda reducir los puntos de falla. ya que ha desacoplado la aplicación de línea de negocio del centro de integración y el punto de falla a una única fuente en lugar de dentro de una orquestación.

¡La instrumentación y el diagnóstico en SOA y proyectos de interconexión son difíciles de lograr!- ¡No dejes que ningún vendedor brillante intente decirte lo contrario!Sí, MOM con MOM Ent puede hacer esto. UniCenter puede hacer bla.

El principal problema es entender qué significan los errores, también conocidos como eructos, en la interconexión y cómo recuperarse de ellos...Terminas con mensajes atascados y necesitas entender lo que eso significa para ese proceso de negocios.Puede recibir una alerta que diga: los procesadores son 100 % Ram y el 100 % de las orquestaciones han fallado, pero no tiene ningún significado real.Tienes que diseñar estas cosas en la solución desde el principio y, con suerte, en tus puntos de falla.

También es necesario considerar los tipos de patrones de integración y cómo realizarlos.

Lo anterior es una visión del mundo real de .NET SOA con BizTalk en una implementación EN VIVO.Pero también se debe a las limitaciones arquitectónicas de esto: BizTalk es principalmente un patrón HUB y SPOKE.

Verificar Patrones de aplicaciones empresariales por Martin Fowler

¡Hay muchas maneras de desvelar la tarea!

Otras Consideraciones...Lenguajes de plataforma/desarrollador, etc.

Uno de los factores más importantes para nosotros fueron las habilidades necesarias para comenzar con esto.Teníamos desarrolladores de OO con conocimientos de Java y C#, pero principalmente de C#.Entonces optamos por la pila de MS.Pero cuando elige el tipo de integración y el producto para gestionarlo, necesitarán más habilidades para comprender esa tecnología.Pero bueno, esto es normal para nosotros, los desarrolladores, ¿verdad?¡Muchos desarrolladores equivocados, independientemente de su experiencia, pueden fracasar con empresas como BizTalk!Gran cambio de paradigma, que en parte se debe a un cambio en los mensajes más que en el código.

¡Lo mejor para el final!

El número de transacciones que probablemente se enfrentarán en la integración es probablemente el factor más importante en todo esto.Ya que esto guiará qué patrón, puntos de falla y tolerancia para tales cosas.

Debe seleccionar el correcto en los volúmenes previstos.¡Algo que pueda ampliarse y ampliarse!Seleccionamos BizTalk porque puede escalar y escalar correctamente y con mejor comprensión que otros.

Si no tiene volúmenes, considere no conseguir algo para administrarlos y opte por un estilo de tipo de servicio web a servicio web sin administración; será necesario codificar en ellos la comprensión del rendimiento y las fallas.

Si está en una plataforma Windows con .net 3, eche un vistazo a WWF/WCF, ya que esto puede ayudar en el servicio web a servicio web; ahora hay mucho más en la plataforma actual para todas estas preocupaciones sin la sobrecarga de BizTalk y otros.

Espero que esto ayude.

Answer 2

En mi experiencia, depende del tipo de problema que estés abordando.

En mi experiencia, es difícil superar a BizTalk 2006 R2 en términos de rentabilidad, pero implica el uso de una pila de tecnología de Microsoft.

Websphere MQ parece ser más fácil de vender a corporaciones más grandes y probablemente haya tenido un mayor uso a nivel empresarial.

Ambos proporcionan buena instrumentación, pero realmente depende de usted, como desarrollador, personalizarla para satisfacer los requisitos de sus clientes.

En algunos casos, he descubierto que lo más apropiado es una solución personalizada o aprovechar tecnologías como MSMQ para mantener bajos los costos.

Answer 3

Mencionaste WebSphere, BizTalk, Mule.Cada uno de los cuales tiene características muy diferentes con sus puntos buenos y malos.Si solo busca integración, recomendaré Mule.Tuve muy buena experiencia con él y, lo que es más importante, el arquitecto no es invasivo, por lo que siempre puedes migrar a un ESB diferente u otra solución de quejas de palabras de moda.Uno de los puntos fuertes de Mule es que puede integrarse dentro de su aplicación y su artefacto final puede implementarse en Webshpere, WLS, Glassfish, etc.sin siquiera mostrarle que incruste un ESB.Luego, este ESB puede realizar toda la plomería de integración (administrar tipos y protocolos de conexión).Mientras que algunos de los puntos finales podrían ser otra solución de integración que mencionaste.

Answer 4

Estamos usando Mule por un tiempo (ahora investigamos la migración de la versión 1.4 a la 2.1.x).

Bueno, es uno de los mejores ESB con una comunidad en vivo y una reacción rápida por parte del proveedor, pero en mi opinión la versión 2.1.x todavía está un poco cruda (o solo somos la compañía que la usa para llamar a CXF web :) consulte también mi publicación para obtener más detalles http://www.nabble.com/Migration-from-XFire-to-CXF:-Is-Web-Service-Client-in-Mule-2.x-broken--to19969320.html#a19969320)

Answer 5

Tenemos un contrato con Oracle.Entonces estamos usando Oracle Stack.SOASuite 10.1.3.4.Principalmente soluciones BPEL y para transformaciones simples intentamos utilizar ESB.

El ESB tiene un mecanismo de manejo de fallas defectuoso.Para BPEL hay muchas maneras de manejar errores.Intentamos desarrollar servicios web java para conectarnos a SOA Suite y nuestros sistemas principales son los sistemas Oracle EBS.Se comunican con sistemas heredados u otros entornos de EBS a través de los adaptadores de EBS predeterminados que se envían con SOA Suite.

El problema que encontramos es la falta de conocimiento sobre los adaptadores EBS.Encontramos algunos problemas con una solución BPEL que recibía información de los sistemas EBS.Fue un trabajo increíble preparar la producción de la solución.

Proteger nuestros servicios web no es un gran problema.Con la pila de Oracle viene Oracle Web Service Manager.Con eso podemos asegurar, iniciar sesión, etc.todos los servicios web.

El mayor problema que encontramos es la falta de nuestros propios estándares.Hacer que la empresa sienta que también puede crear soluciones SOA.No podemos explicar los beneficios que obtienen con una solución SOA.¿Más rápido?No !¿Más económico?¡Diablos, no!¿Soluciones más fáciles?Bueno, tal vez cuando consigamos buenos servicios reutilizables...bueno, esa parte más fácil tiene un problema:¿Cómo sabemos qué aplicaciones utilizan los servicios web reutilizables?

Necesitamos un registro que pueda mostrar este tipo de información.Como no podemos encontrar una buena solución de código abierto, estamos intentando crear nuestro propio registro.Solución APEX simple, nuevamente de la pila de Oracle.;)

¿Alguien conoce un buen producto para registrar este tipo de información?