Como você faz a integração do sistema?

Question

Estou curioso para saber como diferentes pessoas resolvem a integração de sistemas.Tenho a sensação de que nos últimos anos se tem trabalhado cada vez mais na integração de sistemas e que este tipo de necessidade de trabalho também aumentará.

Gostaria de saber se você resolve isso desenvolvendo seus próprios pequenos serviços que depois são conectados ou se você usa algum tipo de produto (WebSphere, BizTalk, Mula etc).Eu também acho que seria interessante saber como esse tipo de solução é gerenciado e mantido (como você resolve segurança, instrumentação, etc.), que tipo de problemas você enfrentou com sua solução e assim por diante.

Answer 1

wow - Ok. - terá um post sobre isso, mas vai ser grande

Intergration precisa ser apoiada com uma grande compreensão pela empresa sobre os benefícios - Obter um modelo opertating resolvido - como o negócio pode efectivamente precisam padronizar vez de intergrate, pois isso pode ser caro - a sua porque a maioria SOA falha ! Enterprise Architecture: Benefícios de condução de negócios de TI Autor (es): Jeanne W. Ross

Se intergration é necessária, então você precisa para resolver sobre o tipo de integração.

O que são a velocidade eo desempenho métricas?

Temos um .NET SOA com um aplicativo composto que utiliza BizTalk 2006 e webservices com linha de aplicativos comerciais. Desempenho da aplicação no final composite (consumir) - é limitada à velocidade dos webservices (e sua implementação) na linha de aplicação de negócio! Precisamos sub <3 segundo retorno em resultados - lista de casos. não poderia ser alcançada nos webservices por isso precisamos de ir buscar ao banco de dados diretamente para a busca inicial. Em seguida, ao longo dos webservices para a criação de caso. implicações de custo e maintance se torna um problema aqui.

O ponto aqui é olhar para os critérios de desempenho nas especificações e requisitos de negócios Isso vai ajudar na olhar para o tipo de integração que você precisa fazer - WebServices (HTTP), Arquivo Gota / EDI etc

Funcionalmente para intergration você precisa, em seguida, olhar para os pontos de falha na arquitetura proposta - como isso vai levar a uma cadeia de responisblity em SLA / OLA. Você pode precisar Wrapper os pontos intergration / faliure em coisas que você controla.

No ponto semelhante sobre a integração com linha de negócio é com o quanto você precisa saber sobre o outro produto antes que você possa integrar? Yeah Webservices é suposto ser projeto por contrato, mas a implementação é muitas vezes furado e você precisa entender muito sobre o que está acontecendo - e se este é um produto que você não controlar a abstração mesmo com webservices vazamentos em sua tecnologia intergation aka BizTalk <. / p>

Casal esses dois pontos juntos e você o melhor conselho é para obter um tipo de hub intergration como BizTalk - Wrapper a linha de aplicativos de negócios em webservices você cria - para o lado do BizTalk pode ser livre de abstrações vazamento, então você também pode reduzir o os pontos de falha como a de ter dissociado a linha de aplicativos de negócios a partir do hub intergration e o ponto de falha de uma única fonte, em vez de dentro de uma orquestração.

Instrumentação e diagnosics em SOA e intergation Porjects são difíceis de conseguir! - Não deixe qualquer shiney vendas pessoa tentativa e dizer-lhe de forma diferente! Sim MOM com MOM Ent pode fazer isso UniCenter pode fazer blá.

O principal problema é entender o que o erro arrota aka na média intergation e como recuperar a partir deles ... Você acaba com mensagens preso e você precisa entender o que isso significa para esse processo busienss. Você pode obter um alerta para dizer - processadores são 100% Ram 100% orquestrações falharam -, mas nenhum significado real. Você tem que projetar essas coisas para a solução desde o início - e espero que em você pontos de falha

.

Tipos de padrões de Intergration e como fazê-los precisam ser considerados também.

A descrição acima é uma visão do mundo real de um .NET SOA com o BizTalk em uma implementação LIVE. Mas também é devido às limitações arquitetônicas desta -. BizTalk é principalmente um padrão hub and spoke

Confira Patterns aplicações empresariais até Martin Fowler

Existem muitas maneiras de pele a tarefa!

Outras considerações ... Platform / Desenvolvedor Línguas etc.

Um dos grandes fatores para nós foi o skills necessário para iniciar este material. Tivemos devs OO com Java e C # entendimento, mas, principalmente, C #. Então nós fomos para a pilha MS. Mas quando você escolher o tipo intergration e o produto para gerenciar isso eles vão precisar de mais habilidades em compreender que a tecnologia. Mas hey este é normall para nós Devs certo? Erradas muitos desenvolvedores, independentemente de não tornam a experiência pode vir unstuck com os gostos de BizTalk! mudança grande de paradigma -. o que em parte é devido a mensagens de mudança ao invés de código

Melhor pouco para o final!

O número de transações que são susceptíveis de serem enfrentados na integração é provável o único fator maior em tudo isso. Pois isso irá guiar o teste padrão, pontos de falha e tolarance para essas coisas.

Você precisa selecionar melhor em volumes anticpated o caminho certo. Algo que pode aumentar e escalar para fora! Selecionamos BizTalk uma vez que pode aumentar e escalar de forma correcta e com uma melhor compreensão do que alguns outros.

Se você não tiver volumes em seguida olhar para não ficar algo para gerenciá-los e ir para um webservice para tipo estilo webservice sem gestão -. Desempenho e compreensão falha terá de ser codificado para eles

Se o seu no Windows plataforma com .net olhar 3 demorar pelo WWF / WCF como isso pode ajudar no webservice para webservice -. Muito mais na plataforma acutal agora para todas essas preocupações sem a sobrecarga de BizTalk e outros

Espero que isso ajude.

Answer 2

Na minha experiência, isso depende de que tipo de problema que você está alinhavando.

Na minha experiência, é difícil de bater BizTalk 2006 R2 para bater a bola mas implica o uso de uma pilha de tecnologia Microsoft.

Websphere MQ parece ser uma venda mais fácil para empresas maiores e provavelmente visto uma maior utilização ao nível da empresa.

Ambos oferecem boa instrumentação mas é realmente até você como um desenvolvedor de personalizar este para atender às necessidades do seu cliente.

Em alguns casos eu descobri que um bespoke solução é mais adequado ou tecnologias alavancadas, tais MSMQ para manter os custos baixos.

Answer 3

Você mencionou WebSphere, BizTalk, Mule. Cada um dos quais tem características muito diferentes, com o seu bom e mau pontos. Se apenas a integração que você está depois, vou recomendar Mule. Eu tive uma experiência muito boa com ele e mais importante do arquitecto é não invasivo, de modo que você sempre pode migrar para um ESB diferente ou outra solução palavra queixa Buzz. Um aos sweet spots de mula é que ele pode ser incorporado dentro de sua aplicação e seu artefato final pode ser implantado em Webshpere, WLS, Glassfish etc ... sem sequer mostrando embeded um ESB. Então este ESB pode executar todas (os tipos de conexão de gestão e protocolos) o encanamento integração. Considerando alguns dos pontos finais poderia ser outra solução de integração que você mencionou.

Answer 4

Estamos usando mula por um tempo (agora investigar a migração de 1,4 a 2.1.x versão).

O Bem É um dos melhores ESB com a comunidade ao vivo e reação rápida do lado do fornecedor, mas IMO versão 2.1.x ainda é um pouco cru (ou estamos apenas a empresa que usá-lo para chamar CXF web :) ver também a minha pós para detalhes http://www.nabble.com/Migration-from-XFire-to-CXF:-Is-Web-Service-Client-in-Mule-2.x-broken- -to19969320.html # a19969320 )

Answer 5

nós temos um contrato de Oracle. Então, nós estamos usando a pilha Oracle. SOA Suite 10.1.3.4. Principalmente soluções BPEL e para um simples transformações tentamos usar ESB.

A ESB tem um mau mecanismo de tratamento de falhas. Para o BPEL há muitas maneiras de lidar com erros. Tentamos desenvolver webservices java para se conectar à SOA Suite e nossos principais sistemas são sistemas de Oracle EBS. Eles se comunicam com sistemas legados ou outros ambientes EBS através dos adaptadores EBS padrão que são enviados com o SOA Suite.

Os problemas que encontramos é a falta off conhecimento sobre os adaptadores EBS. Nós encoutered alguns problemas com uma solução BPEL que recebeu informações dos sistemas EBS. Foi um inferno de um trabalho para obter a produção solução pronta.

Protegendo nossos webservices isnt't um grande problema. Com a pilha a Oracle vem o Oracle Web Service Manager. Com isso, podemos garantir, ingresse etc. todos os webservices.

Os maiores problemas que encontramos é a falta de nossos próprios padrões. Obtendo o negócio para sentir que eles também podem construir soluções de SOA. Nós não podemos explicar os benefícios que obtêm com uma solução SOA. Mais rápido? não ! Mais barato? De jeito nenhum! soluções mais fácil? Bem, talvez quando temos bons serviços reutilizáveis ??... bem, essa parte mais fácil tem um problema dentro dele: como é que sabemos quais aplicativos usar os webservices reutilizáveis?

Precisamos de um registo, que pode exibir esse tipo de informação. Porque não podemos encontrar uma boa solução opensource, estamos tentando construir o nosso próprio registo. solução APEX simples, novamente a partir da pilha Oracle. ;)

Então, alguém sabe um bom produto para registrar este tipo de informação?