Integração de sistema

Programação Arquitetura
#21

Olá amigos, só fazendo uma explanação sobre BPM, muito so enxegam como um simples “Workflow Manager”, quando na verdade é uma prática de engenharia de software para modelar o negócio, por isso as notações são realizadas por uma equipe de “processos”, mais atrelada ao Business, onde se pode enxergar as falhas, otimizar, arrumar gargalos, e etc.

Essa visão BPM como Workflow é ultrapassada e o Tom Baeyens que era do Core Team da Jboss está criando um novo produto, Activiti.org, justamente com esse foco.

Orquestração no sentido de “composição de serviços”, com fins práticos de automação e concentração de unidades de serviços, pode ser endereçada pela especificação BPEL.

As Engines, com citado, são os motores de “parsing” das linguagens de notação, para execução.

Quanto a integração de banco de dados, a melhor “conceito” no mundo SOA para o caso é o DataServices. A Jboss possui um excelente produto, MetaMatrix (projeto Teiid) e vale à pena ler um pouco a respeito, caso haja realmente tal necessidade.

Derlan, o OpenESB se propõe à cenários de integração usando patterns EAI, sendo um bus provider. Você pode até ter execução BPEL dentro dele, assim como outros produtos ( WebLogic Integration - WLI), mas não são os mais indicados, o uso normalmente tange ao descrito.

Um abraço,

Kenobi

#22

Como assim?

#23

[quote=Kenobi]Olá amigos, só fazendo uma explanação sobre BPM, muito so enxegam como um simples "Workflow Manager", quando na verdade é uma prática de engenharia de software para modelar o negócio, por isso as notações são realizadas por uma equipe de "processos", mais atrelada ao Business, …[/quote]Oi Kenobi, blz?!! :wink:

Ah, na verdade o q eu destarca inicialmente é q os WorkFlows aí do mercado até então (na maioria das vezes) são Vendor-Lock; -> então o BPEL é 1 padrão q não te deixa preso a nenhum Player ou Ferramenta específica.

Sobre a “prática”, concordo contigo e vou além, esclarecendo q ‘Análise e Gerenciamento por Processos de Negócios’ não é tecnologia (absolutamente) e sim 1 mudança (drástica) na filosofia gerencial e estratégica, na qual as empresas se acostumam ter 1 mentalidade + de Departamentalização e Hierarquia; então o BPM - Gerenciamento por Processos de Negócio busca “horientalizar a coisa”. Na Engenharia de Software não é diferente (constumamos cair no mesmo erro): geralmente, quando vamos desenvolver 1 Sistema, costumamos dividí-lo em Módulos (ou alguma coisa q representa Departamentos/setores da empresa), sendo q o trabalho (e dados) de 1 empresa segue 1 fluxo => e isso é q realmente importa: é com isso q o nosso desenvolvimento tem q ser guiar, e q é até muito + realista (Ah, reparem esta abordagem tambem horientaliza como o Sistema/Software deve ser estruturado e desenvolvido). (Obs.: para saber + sobre este assunto, indico o excelente artigo, na revista MundoJava Ed.13 na coluna MundoOO, ‘da Orientação a Objetos ao SOA - chegando ao BPM’ do Glauco Reis.)

Ah, muito legal vc ter citado novas ferramentas (tenho estado afastado desta área). :thumbup: Mas, a pesar de o WebService possibilitar interoperabilidade total entre Sistemas de qualquer linguagem/plataforma, ainda prefiro a busca dos Dados através de 1 Aplicação feita em Java (preferencialmente), q é multi-plataforma, implementando-a da forma o + granular possível (se for o caso) e vc não fica preso a 1 ferramenta específica. Daí vc integra a Aplicação a 1 Engine de Orquestração BPM ou mesmo a 1 ESB - Enterprise Service Bus.

Outra questão é o q o WebService tem sido muito criticado (e muitos acabam demostrando a mínima fé nele; vide o caso da BI - Business Inteligence (DW, OLAP, ETL, etc.): há 10 anos quase ninguem dava moral/importância (principalemente aki no Brasil) e agora ela tem 1 boom!). O problema é q nem sempre o WebService tem sido utilizado da forma correta, quando o ideal é ter (uma excelente) Governança em Serviços (não importando se os Serviços são implementado em WebServices, ou não). O fato é q o WebService (perfeito, ou não) é muito flexível e poderoso. Então, a SOA pode atender tanto ao BPM, quanto a 1 ESB (ou a ambos simultaneamente, se for o caso).

Ah, acho q faltou só 1 esclarecimento do ESB, q é um Bus, Barramento Comum, usado por várias Aplicações implementadas em diferentes liguagens, ou legadas (plataforma alta, p/ex.). Para facilitar o entendimento, mentalize uma imagem: 10 Aplicações (imagine-as em 1 coluna) q precisam se comunicar com outras 10 Aplicações (imagine-as em outra coluna): sem o Bus do ESB, vc ter um número altíssimo de ligações (entre as Aplicações) , um "espageti", infernalmente impossível de controlar e q certamente te levará ao caos. :x

A todos 1 ]o['ão,

Derlon

#24

Como assim?[/quote]

Ficou horrível a frase, concordo :slight_smile: Normalmente o uso do ESB se aplica à integração e disponibilização.

#25

Derion, só uma coisa a respeito do tal “Espaguetti” aqui concordo com a alusão feita pelo Jim Webber, pois as conexões (point-to-point), mesmo ocultadas por proxies internos, continuam a existir. Por isso ele apelidou de “Enterprise Spaguetti Box”) e concordo com ele.

O que não dizem é sobre os ESBs modernos. Você ter granularidade fina (EntityServices por exemplo), reflete em necessidade de gestão - Controle de falhas, performance,consumo de memória entre muitas SLA´s que você pode definir e acompanhar através de um gestor.

OS ESBs modernos permitem esse tipo de gestão, ou seja, você não vai acabar com o “Spaguetti”, mas terá por exemplo formas de se controlar LoadBalance para múltiplos endpoints por exemplo e saber como está a saúde de cada um.

Aqui começam os benefícios :slight_smile:

º´s

Kenobi

#26

[quote=Kenobi]Derion, só uma coisa a respeito do tal “Espaguetti” aqui concordo com a alusão feita pelo Jim Webber, pois as conexões (point-to-point), mesmo ocultadas por proxies internos, continuam a existir. Por isso ele apelidou de “Enterprise Spaguetti Box”) e concordo com ele.

O que não dizem é sobre os ESBs modernos. Você ter granularidade fina (EntityServices por exemplo), reflete em necessidade de gestão - Controle de falhas, performance,consumo de memória entre muitas SLA´s que você pode definir e acompanhar através de um gestor.

OS ESBs modernos permitem esse tipo de gestão, ou seja, você não vai acabar com o “Spaguetti”, mas terá por exemplo formas de se controlar LoadBalance para múltiplos endpoints por exemplo e saber como está a saúde de cada um.

Aqui começam os benefícios :slight_smile:

º´s

Kenobi[/quote]

… ou seja, ele é uma ferramenta que ajuda você a cuidar de aspectos mais “técnicos” (load balance, SLA, etc). Não é uma cola mágica pra integrar sistemas como ele é vendido. Algumas coisas eu acredito que você consegue simplesmente colocando um apache/nginx na frente (load balance, por exemplo). Será que o custo de aquisição de um ESB, e, principalmente, o custo de desenvolvimento em cima de ESB + custo de operação + custo de manuntenção do ESB compensa os benefícios, já que nós concordamos que ele não faz nenhum milagre (e que o que ele faz talvez possa ser feito por um servidor HTTP)?

Principalmente se considerarmos que ele não é a ferramenta mais barata, nem a ferramenta mais produtiva :slight_smile:

#27

Isso é um ótimol discurso de vendas. Mas será que na prática, esse tipo de técnica+ferramenta entrega o que promete? Existem N ferramentas que prometem possibilitar o usuário/especialista do negócio colocar as regras de negócio numa linguagem/notação que ele entende, reduzindo muito o esforço de codificação.
Um exemplo é o Maker… tem basicamente a mesma promessa, de que o usuário/especialista de negócio utiliza uma notação visual para colocar as regras de negócio sem a necessidade de um programador codificar as regras de negócio.

Eu acho que esse tipo de ferramenta promete um milagre e acabam não servindo para o pessoal de negócios modelar seus processos e deixando o pessoal de desenvolvimento presos a uma plataforma e arquitetura que fazem com que o desenvolvimento tenham uma produtividade muito baixa. Até agora eu não vi nada mais produtivo do que deixar o pessoal da equipe de desenvolvimento junto com o pessoal da equipe de negócios, com comunicação e feedback constante. Além de deixar a equipe de desenvolvimento utilizar plataformas e ferramentas modernas.

Mas… a discussão não era sobre BPM e sim sobre integração via DB…

[quote=Kenobi]Quanto a integração de banco de dados, a melhor “conceito” no mundo SOA para o caso é o DataServices. A Jboss possui um excelente produto, MetaMatrix (projeto Teiid) e vale à pena ler um pouco a respeito, caso haja realmente tal necessidade.
[/quote]

Simplemente deixar o seu banco de dados exposto como um webservice quase tão prejudicial quanto deixar ele acessível diretamente. É claro que as vezes um produto desse tipo tem aplicações, mas eu não acredito que seja para integrar sistemas da forma como é feito no banco de dados… Para buscas e operações de leituras simples é tão, mas se você criar um DataServices que permite que outras aplicações alterem ou incluam dados no seu banco a esmo, você vai ter os mesmos problemas que deixar várias aplicações incluirem e alterarem dados direto no banco de dados.

#28

Uma desvantagem é que você não pode ser encrencado com o DBA, senão… :expressionless:

As vantagens e desvantagens o pessoal já falou aí. Por experiencia, nunca tive grandes problemas com integração por BD, nada além do normal. Não acho ruim as triggers e afins, acho ruim quando tem MUITO objeto auxiliar no banco por conta de integração. É um porre manter .

Sei lá. Acho que resumidamente só acho feio, mas funcional.

#29

Eu concordo com o Rubens.

As maiores dores de cabeça que tive integrando sistemas foi através de banco de dados!

Normalmente nestes casos eu minimizo a dor de cabeça criando algum contrato entre os sistemas através de procedures e/ou views. Assim é possível diminuir o impacto na integração e ainda permite evoluir o banco mais tranquilamente.

Na minha opinião quando houver este tipo de integração a equipe deveria encarar o outro banco como outro sistema.

#30

[quote=Rubem Azenha][quote=Kenobi]Derion, só uma coisa a respeito do tal “Espaguetti” aqui concordo com a alusão feita pelo Jim Webber, pois as conexões (point-to-point), mesmo ocultadas por proxies internos, continuam a existir. Por isso ele apelidou de “Enterprise Spaguetti Box”) e concordo com ele.

O que não dizem é sobre os ESBs modernos. Você ter granularidade fina (EntityServices por exemplo), reflete em necessidade de gestão - Controle de falhas, performance,consumo de memória entre muitas SLA´s que você pode definir e acompanhar através de um gestor.

OS ESBs modernos permitem esse tipo de gestão, ou seja, você não vai acabar com o “Spaguetti”, mas terá por exemplo formas de se controlar LoadBalance para múltiplos endpoints por exemplo e saber como está a saúde de cada um.

Aqui começam os benefícios :slight_smile:

º´s

Kenobi[/quote]

… ou seja, ele é uma ferramenta que ajuda você a cuidar de aspectos mais “técnicos” (load balance, SLA, etc). Não é uma cola mágica pra integrar sistemas como ele é vendido. Algumas coisas eu acredito que você consegue simplesmente colocando um apache/nginx na frente (load balance, por exemplo). Será que o custo de aquisição de um ESB, e, principalmente, o custo de desenvolvimento em cima de ESB + custo de operação + custo de manuntenção do ESB compensa os benefícios, já que nós concordamos que ele não faz nenhum milagre (e que o que ele faz talvez possa ser feito por um servidor HTTP)?

Principalmente se considerarmos que ele não é a ferramenta mais barata, nem a ferramenta mais produtiva :)[/quote]

Não sei se me fiz claro, mas estava me referindo ao Service Enabling, que começava ali. Isso não significa que não seja uma plataforma para integração, pelo contrário, se você começar a entender os cenários de integração e uma das coisas que o ESB faz é tradução de protocolos, se você está preso ao HTTP não vai conseguir fazer.

PS: As antigas plataformas de integração EAI como Tuxedo hoje foram substituídas por soluções de barramento na maior parte das empresas, ou seja, é uma plataforma de integração.

Outra coisa são os patterns de integração que um ESB suporta e os problemas que ele endereça: http://camel.apache.org/enterprise-integration-patterns.html

Custo de aquisição do Camel é nenhum, assim como JBoss ESB e implementação é mais simples que fazer qualquer codificação de pattern na mão, senão estariámos fazendo FrontController não usando frameworks MVC.

Em última instância, o ESB pode ser visto como um Framework atividades específicas e quando vc precisa falar com um SAP ou Mainframe, fazer uma represa processamento (Throttling) e persistir as mensagens num sistema de Mensageria, vai começar a entender que um ESB pode o tornar muitíssimo mais produtivo.

PS: A promoção das operadoras Torpedão do Faustão (SMS) rodam sob arquitetura de Oracle OSB com 16 domínios em Cluster e fazem diversas tarefas como roteamento, split, Throttling para sistemas legados, controle de SLA´s, Workmanager de Threads para processamento e por aí vai. Cada vez que o Faustão dá a chamada na Globo milhares de mensagens são processadas por segundo, não pode haver perdas pq cada uma custa 4,99 e aí começam seus problemas de verdade.

#31

[quote]Isso é um ótimol discurso de vendas. Mas será que na prática, esse tipo de técnica+ferramenta entrega o que promete? Existem N ferramentas que prometem possibilitar o usuário/especialista do negócio colocar as regras de negócio numa linguagem/notação que ele entende, reduzindo muito o esforço de codificação.
Um exemplo é o Maker… tem basicamente a mesma promessa, de que o usuário/especialista de negócio utiliza uma notação visual para colocar as regras de negócio sem a necessidade de um programador codificar as regras de negócio.
[/quote]

BPM é um conceito sobre como “Mapear” seus processos internos e encontrar gargalos. Você poderia usar o BPM até para enxergar o que está errado no seu processo e está muito menos preso à ferramentas e esse é o primeiro erro de pensamento.

Mapear um processo e principalmente ter um visualizador do que está acontecendo (métricas) atrai um grande valor para a TI que deixa de ser somente código e traz visibilidade de negócio, tanto que Gartner Group, Forrester Research que publicou essa semana um estudo sobre SOA aponta a prática de BPM como uma tendência nas empresas e novamente, isso não tem haver com geração de código diretamente.

“Compor” uma solução, orquestrar, via BPEL é necessário que você tenha sua granularidade de serviços bem resolvida, centrada normalmente em TaskServices. Se você usa uma abordagem EntityServices e muito fina, concordo contigo, a dificuldade é bastante grande de abstração. Mas esse é um erro comum, confundir Composição - Orquestração com Mapeamento de Processos.

[quote]
Simplemente deixar o seu banco de dados exposto como um webservice quase tão prejudicial quanto deixar ele acessível diretamente. É claro que as vezes um produto desse tipo tem aplicações, mas eu não acredito que seja para integrar sistemas da forma como é feito no banco de dados… Para buscas e operações de leituras simples é tão, mas se você criar um DataServices que permite que outras aplicações alterem ou incluam dados no seu banco a esmo, você vai ter os mesmos problemas que deixar várias aplicações incluirem e alterarem dados direto no banco de dados.[/quote]

Isso varia normalmente a cada cenário. Esse desenho descrito “datacentric” ou EntityServices (Thomas Erl) normalmente é indicado quando você tem muita regra no próprio banco,PLS por exemplo que carregam muitas regras, ou nas entidades, algo como ActiveRecord.

Se você tem um sistema “CRUD”, talvez eles possam fazer sentido no primeiro momento, mas seu reúso será limitado ou terá uma alta dependência para “compor” uma solução.

Já vi muitos exemplos REST usando EntityServices acoplados à ActiveRecord por exemplo, onde a granularidade é bastante fina. Isso tem haver com modelagem, assunto que cabe bastante estudo até mesmo tentar unir técnicas de DDD.

Por fim, acho que vale à pena darem uma espiada no MetaMatrix - http://www.redhat.com/f/pdf/metamatrix/MetamatrixMasterDataManagement_web.pdf e o que ele propõe a resolver. Eventos, como citado pelo Rubens, onde você precisa disparar a cada insert por exemplo, pode ser uma grande solução.

#32

@Kenobi
Eu já trabalhei com BPM identificando gargalo em processos de negócios de um Grande Banco/Seguradora aqui do Brasil. Esse estudo serviu de base para a iniciativa SOA da empresa. Eu concordo contigo que um ESB pode ser bem útil para abstrair alguns problemas de integração e criar um ponto central, mas quanto ao BPEL, tenho a impressão que montar uma DSL pode ser bem mais interessante, IMO. Eu não gostei muito de BPEL, achei muito de propósito geral. Prefiro algo mais enxuto.

O que você acha?

[]s

#33

[quote=Emerson Macedo]@Kenobi
Eu já trabalhei com BPM identificando gargalo em processos de negócios de um Grande Banco/Seguradora aqui do Brasil. Esse estudo serviu de base para a iniciativa SOA da empresa. Eu concordo contigo que um ESB pode ser bem útil para abstrair alguns problemas de integração e criar um ponto central, mas quanto ao BPEL, tenho a impressão que montar uma DSL pode ser bem mais interessante, IMO. Eu não gostei muito de BPEL, achei muito de propósito geral. Prefiro algo mais enxuto.

O que você acha?

[]s [/quote]

Emerson, é que na verdade, o propósito de BPEL NÃO é funcionar como BPM. Sei que muitos vendors/players vendem assim, mas a idéia é orquestrar web services (algo que, obviamente, DSLs não conseguem fazer). E, mesmo assim, tenho a impressão de que DSLs não servem para o que se propõem (veja meu blog para saber mais; particularmente, um comentário do próprio Rubem a respeito).

IMHO, BPEL é ótimo no que se propõe a fazer (não é excelente), e a respeito de integração de processos de negócio, a dupla BPEL + Business Rules é matadora.

[]´s

#34

A visão que tenho hoje do BPEL é que ele serve como ferramenta para fazer “Composições”. Quando você tem uma série de serviços, síncronos, assíncronos e precisa criar uma nova solução à partir de algo pré-existente.

Seria um grande “Facade” e possui uma série de configurações para tuning de performance, transformação de tipos de dados, monitorar cada ponto de chamada (sensores), trabalhar os erros de cada um dos serviços e por aí vai.

O problema do BPEL está em usar com uma granularidade extramamente fina para criar soluções de negócio. O desafio não está nem tanto no design e sim no refactoring, quando você tiver que fazê-lo e principalmente se seus requisitos não estão suficientemente claros.

O BRMS (engine rules), é melhor para abstração das regras e o Drools não tem custo algum e é uma ferramenta matadora. Vale à pena estudar construção de DSL´s com a ferramenta.

#35

Quanto a questão de implementação dos EAI, eu concordo que utilizar uma plataforma já implementada e testada é melhor do que desenvolver uma solução do zero. Não trabalhei com o Camel nem com o JBoss ESB, a minha experiência com ESB se limitou ao Oracle Service Bus e naquele cenário em particular não vi o uso de ESB trazendo muitos benefícios. Acabei não trabalhando com nada diferente de SOAP. A ferramenta web e Eclipse tinha vários wizzards e facilidades para trabalhar com SOAP, contratos, etc.

Quanto a questão do Torpedão do Faustão, não conheço a arquitetura e os requisitos, mas você tem diversas opções pra tratar milhares de mensagens por minuto/segundo com um custo alto onde não pode haver perdas. Operadoras telecom, bancos, companias elétricas, etc. lidam com esse cenário há muito tempo e já vi a boa e velha arquitetura J2EE com servidor de aplicações JBoss trabalhar bem nesses cenários.

Acho que vai aquela velha regra… analisar cada situação… Alias… podemos discutir sobre ESB, BPM e etc numa outra thread né? :slight_smile:

#36

Acho que você concorda comigo que usar uma ferramenta estilo “DataServices” para simplesmente expôr o seu banco de dados via SOAP/REST/etc não é uma boa idéia e tem conceitualmente o mesmo problema que expôr o seu banco de dados livremente. Acredito que esse tipo de ferramenta pode ajudar em muitos casos, mas acho que geralmente vale a pena criar uma camada de serviços de verdade, com “inteligencia”, regras de negócio, etc. E não simplesmente deixar o seu banco aberto para qualquer aplicação ler, alterar, incluir e excluir dados sem muito controle.

#37

[quote=Rubem Azenha][quote=Kenobi]
Isso varia normalmente a cada cenário. Esse desenho descrito “datacentric” ou EntityServices (Thomas Erl) normalmente é indicado quando você tem muita regra no próprio banco,PLS por exemplo que carregam muitas regras, ou nas entidades, algo como ActiveRecord.

Se você tem um sistema “CRUD”, talvez eles possam fazer sentido no primeiro momento, mas seu reúso será limitado ou terá uma alta dependência para “compor” uma solução.

Já vi muitos exemplos REST usando EntityServices acoplados à ActiveRecord por exemplo, onde a granularidade é bastante fina. Isso tem haver com modelagem, assunto que cabe bastante estudo até mesmo tentar unir técnicas de DDD.

Por fim, acho que vale à pena darem uma espiada no MetaMatrix - http://www.redhat.com/f/pdf/metamatrix/MetamatrixMasterDataManagement_web.pdf e o que ele propõe a resolver. Eventos, como citado pelo Rubens, onde você precisa disparar a cada insert por exemplo, pode ser uma grande solução.
[/quote]
Acho que você concorda comigo que usar uma ferramenta estilo “DataServices” para simplesmente expôr o seu banco de dados via SOAP/REST/etc não é uma boa idéia e tem conceitualmente o mesmo problema que expôr o seu banco de dados livremente. Acredito que esse tipo de ferramenta pode ajudar em muitos casos, mas acho que geralmente vale a pena criar uma camada de serviços de verdade, com “inteligencia”, regras de negócio, etc. E não simplesmente deixar o seu banco aberto para qualquer aplicação ler, alterar, incluir e excluir dados sem muito controle.[/quote]

É por essas e outras que existe esse tipo de solução. O DataServices pode se preocupar, por exemplo, com políticas de autenticação.
Para o cenário que você descreveu, onde monitorava os eventos de uma determinada tabela, entre outros.

Não existe uma regra fechada, vai depender do caso e cenário, minha opinião, assim também como ferramentas de ETL. Tanto que a JBoss publicou vários cases em cenários como Financeiro, Saúde e já vi outros de Call Center e por aí vai.

Quem quiser conhecer mais sobre o assunto, achei esse artigo na InfoQbr : http://www.infoq.com/br/articles/narayanan-soa-data-services

#38

Políticas de autenticação é a menor das minhas preocupações. Estou mais preocupado com problemas como duplicação de regras de negócio/código entre aplicações por acessar direto os dados sem nenhuma “inteligência”.

Tenho certeza que a JBoss pode publicar vários cases em vários cenários… não significa que é uma boa idéia usar o produto deles como plataforma para integração entre aplicações via banco de dados.

#39

[quote=Rubem Azenha][quote=Kenobi]
Não sei se me fiz claro, mas estava me referindo ao Service Enabling, que começava ali. Isso não significa que não seja uma plataforma para integração, pelo contrário, se você começar a entender os cenários de integração e uma das coisas que o ESB faz é tradução de protocolos, se você está preso ao HTTP não vai conseguir fazer.

PS: As antigas plataformas de integração EAI como Tuxedo hoje foram substituídas por soluções de barramento na maior parte das empresas, ou seja, é uma plataforma de integração.

Outra coisa são os patterns de integração que um ESB suporta e os problemas que ele endereça: http://camel.apache.org/enterprise-integration-patterns.html

Custo de aquisição do Camel é nenhum, assim como JBoss ESB e implementação é mais simples que fazer qualquer codificação de pattern na mão, senão estariámos fazendo FrontController não usando frameworks MVC.

Em última instância, o ESB pode ser visto como um Framework atividades específicas e quando vc precisa falar com um SAP ou Mainframe, fazer uma represa processamento (Throttling) e persistir as mensagens num sistema de Mensageria, vai começar a entender que um ESB pode o tornar muitíssimo mais produtivo.

PS: A promoção das operadoras Torpedão do Faustão (SMS) rodam sob arquitetura de Oracle OSB com 16 domínios em Cluster e fazem diversas tarefas como roteamento, split, Throttling para sistemas legados, controle de SLA´s, Workmanager de Threads para processamento e por aí vai. Cada vez que o Faustão dá a chamada na Globo milhares de mensagens são processadas por segundo, não pode haver perdas pq cada uma custa 4,99 e aí começam seus problemas de verdade.
[/quote]

Quanto a questão de implementação dos EAI, eu concordo que utilizar uma plataforma já implementada e testada é melhor do que desenvolver uma solução do zero. Não trabalhei com o Camel nem com o JBoss ESB, a minha experiência com ESB se limitou ao Oracle Service Bus e naquele cenário em particular não vi o uso de ESB trazendo muitos benefícios. Acabei não trabalhando com nada diferente de SOAP. A ferramenta web e Eclipse tinha vários wizzards e facilidades para trabalhar com SOAP, contratos, etc.

Quanto a questão do Torpedão do Faustão, não conheço a arquitetura e os requisitos, mas você tem diversas opções pra tratar milhares de mensagens por minuto/segundo com um custo alto onde não pode haver perdas. Operadoras telecom, bancos, companias elétricas, etc. lidam com esse cenário há muito tempo e já vi a boa e velha arquitetura J2EE com servidor de aplicações JBoss trabalhar bem nesses cenários.

Acho que vai aquela velha regra… analisar cada situação… Alias… podemos discutir sobre ESB, BPM e etc numa outra thread né? :)[/quote]

Rubem, só gostaria de lembrar que ESBs servem para interligar não somente SOAP, como também outros recursos (JMS, JMX, arquivos, FTP, etc, etc, etc… ).

Ah, e eu concordo que deveríamos discutir isso em outra thread, já que acabamos desviando o assunto dessa.

[]´s

#40

Olá

Eu também. A discussão ficou interesante, muitas opiniões boas mas na minha opinião sem nada a ver com integração via BD que como o Rubem Azenha, eu acho roubada. A gente faz quando necessário mas já preparado para algumas dores de cabeça.

[]s
Luca