Integração de sistema

Olá

Impossível dizer. Pode ser bom em alguns casos é péssimo em outros.

Pelo menos não é tão ruim quanto usar RPC, RMI e outras tecnologias acopladoras e intrusivas do milênio passado.

[]s
Luca

Trabalhar sobre um socket é coisa do século passado? hmm #not [/minhaopniao]

Olá

Também depende. Se for para engrunvinhar os sistemas a serem integrados como em geral ocorre com RPC, acho ruim.

Se for para trocar mensagens sem que um sistema precise saber como o outro trata as mensagens, então pode ser bom.

É como eu disse antes, não há bala de prata. Há que analisar caso a caso. Algumas vezes um arquivo do tipo CSV gravado no file system á mais do que suficiente apesar de ser técnica dos primórdios da computação.

[]s
Luca

Zaperjava:

Pessoal quais são as vantagens e desvantagens de integrar sistemas por meio de Banco de Dados ?

De cara eu diria: desempenho, durabilidade e suporte a grande volume de dados, desempenho pq geralmente uma consulta ao banco é menos custosa do que outros tipos de integração que exigem parsings extensos, durabilidade pq como os dados estão persistidos eles sobrevivem a um eventual crash do servidor e por fim, suporte a grande volume de dados, pq outras tecnologias integradoras como web services tem um péssimo desempenho com dados > 10Mgb, enquanto com banco de dados esse volume é teoricamente ilimitado.

deniswsrosa:

Zaperjava:

Pessoal quais são as vantagens e desvantagens de integrar sistemas por meio de Banco de Dados ?

De cara eu diria: desempenho, durabilidade e suporte a grande volume de dados, desempenho pq geralmente uma consulta ao banco é menos custosa do que outros tipos de integração que exigem parsings extensos, durabilidade pq como os dados estão persistidos eles sobrevivem a um eventual crash do servidor e por fim, suporte a grande volume de dados, pq outras tecnologias integradoras como web services tem um péssimo desempenho com dados > 10Mgb, enquanto com banco de dados esse volume é teoricamente ilimitado.

Mas por exemplo , duas aplicações acessando o mesmo Banco de Dados faz cair o desempenho do SGBD . Não?

Muito relativo. Você pode ter 2 pessoas realizando consultas monstruosas gerando uma visualização em tempo de execução de um DM grande, ou 200 pessoas visualizando dados e realizando poucas alterações.

Pode levar em conta o link de comunicação. Acessar uma base de dados através de uma rede 100mb ou uma adsl 1mb.

E por fim, a própria qualidade do sgbd e o do hardware. Um Oracle sobre 64 núcleos de vários GHz só fica lento quanto tiver alguns Teras de dados, ainda assim provendo serviço adequadamente.

Só fiquei um pouco em dúvida sobre essa integração… seriam apenas dados? Ou lógica de negócio? A aplicação integrada sendo distribuída ou local, nesse caso, também poderia influenciar na tal integração.

E eu achando que integrar pelo banco era sempre ruim…

Valeu pelos exemplos, galera!

Acho entao que a grande desvantagem e talvez a unica seria re-implementar a logica de Negocio certo ?

Zaperjava:

Acho entao que a grande desvantagem e talvez a unica seria re-implementar a logica de Negocio certo ?

Concordo em partes, pq se sua lógica de negócio está carimbada na sua aplicação então você tem um claro problema de arquitetura. Imagine uma requisição para modificar uma de suas regras, vc terá de alterar isso em N outros sistemas.

Um cenário possível por exemplo seria o de vc colocar todas as suas regras de negócio em EJBs, dessa forma vc pode usar as mesmas regras para N aplicações, sem contar as vantagens de Escalabilidade e outros que todo mundo já sabe de cor e salteado.

Pode-se tb fazer uma integração mista, ou seja… tudo que exigir lógicas de negócio vc integra via EJB, tudo que for somente visualização por exemplo vc busca direto do banco.

Mas no geral é difícil mostrar um caminho sem saber o cenário que vc pretende aplicá-la, como vc já deve estar cansado de ouvir, cada caso é um caso.

deniswsrosa:

Zaperjava:

Acho entao que a grande desvantagem e talvez a unica seria re-implementar a logica de Negocio certo ?

Concordo em partes, pq se sua lógica de negócio está carimbada na sua aplicação então você tem um claro problema de arquitetura. Imagine uma requisição para modificar uma de suas regras, vc terá de alterar isso em N outros sistemas.

Um cenário possível por exemplo seria o de vc colocar todas as suas regras de negócio em EJBs, dessa forma vc pode usar as mesmas regras para N aplicações, sem contar as vantagens de Escalabilidade e outros que todo mundo já sabe de cor e salteado.

Pode-se tb fazer uma integração mista, ou seja… tudo que exigir lógicas de negócio vc integra via EJB, tudo que for somente visualização por exemplo vc busca direto do banco.

Mas no geral é difícil mostrar um caminho sem saber o cenário que vc pretende aplicá-la, como vc já deve estar cansado de ouvir, cada caso é um caso.

Em relação a parte negritada, não sei se você está afirmando isso de maneira geral ou em cima do problema do autor do tópico.

Pois não dá para afirmar isso de maneira generalista pois existem inúmeros sistemas que concentram a lógica de negócio na aplicação e usam o BD apenas como repositório de dados.

[]'s

Daniel_MV:

…

[]'s

Olá!

Citei isso com base no possível problema do autor, pois se na integração de duas aplicações através de banco de dados você precisar “replicar a lógica de negócios” , então deve-se na verdade ter uma única lógica de negócio que é acessada por ambas.

Agora se tiver um sistema isolado ( leia-se, “Ninguém mais mexe no meu queijo”). Você pode sem problema nenhum carimbar sua lógica dentro da sua aplicação. Que na prática é o que acontece em 90% dos casos, senão mais.

Eu só recomendaria em casos muito específicos, não como primeira opção.

Grande desvantagem é apelido. Nessas horas você acaba usando o mesmo sistema para ser leão-de-chácara do BD, e fazendo integração por ele, o que deixaria de ser integração por BD.

A grande questão é se você consegue fazer essa integração e ainda manter os dados consistentes, durante todas as dezenas de anos que os sistemas que se integrarem com este banco se mantiverem funcionando.

As vantagens são reais, tem muita velocidade, mas pra isso precisa ter rédeas curtas e controle absoluto.

@Zaperjava,
Os colegas já levantaram alguns aspectos críticos a serem levados em conta na definição de 1 Arquitetura p/ Integração.
Gostaria de apenas deixar minha opinião: defendo fortemente a centralização do Fluxo, Lógica e Regras de Negócio em um (tipo de) Business-Core / Servidor de Aplicações.
Mas, tb depende: se sua Organização estiver pensando em Governança de Serviços (SOA), aí já seria mais indicado uma Engine de Orquestração BPM: um BPMS.
Ou seja, vai depender muito de seu Cenário e seus Requisitos.

derlon:

@Zaperjava,
…Engine de Orquestração BPM: um BPMS.
Ou seja, vai depender muito de seu Cenário e seus Requisitos.

Cara, o que é “Engine de Orquestração BPM”?

Já que BPM é o gerenciamento dos processos, esse engine centralizaria as regras de negócio?

Exatamente xdraculax!!
Não só as Regras, mas tb o Fluxo e a Lógica de Negócio!
Aliás, existem BPMSs q oferecem/permitem a implementação de 1 Módulo ‘Gerenciamento de Regras de Negócio’, no qual o Analista de Negócio/Gerente/DomainExpert (ou seja, 1 cara não tecnico, q não é programador, etc.) alterar as Regras de Negócio sem q seja preciso alterar 1 linha de código do Fonte. 8)

Eu tenho péssima experiências com integração via banco de dados! Depende de cara projeto, mas eu geralmente sou contra.

Eu acho muito problemático ter várias aplicações lendo uma mesma base de dados, pior ainda várias aplicações alterando a mesma base de dados. É muito fácil a situação ficar caótica e você não conseguir enchergar que aplicação altera que dado em que tabela. Sem falar na duplicação de códigos entre aplicações para interpretar o que cada dado significa, validações, etc e todos so problemas que essa duplicação de código traz.

O pior é tratar os eventos que devem acontecer quando um dado é inserido ou alterado… numa aplicação que eu trabalhei no ano retrasado, várias aplicações liam e alteravam os dados dos funcionários. Isso era um problema por que existia uma necessidade de executar um processo de uma das aplicação cada vez que um funcionário era demitido ou entrava de férias… No fim acabamos fazendo uma aplicação só pra cuidar do cadastro dos funcionários, todas as outras aplicações que precisavam acessar ou alterar dados dos funcionários passaram a utilizar essa aplicação e tinhamos mecanismos que permitiam trabalhar melhor com notificações de eventos (nada muito sofisticado, tinha muito espaço para melhoras, mas é melhor que usar trigger).

Enfim, acho que o banco de dados deve ser utilizado por apenas um sistema, os outros sistemas não devem acessar direto o banco de dados e sim usar algum outro mecanismo de integração (queue, WS, EJB…)

Concordo plenamente o o Rubem Azenha! :thumbup: Além de essa abordagem só trazer transtornos, como o de Inconsistência nos Dados, Sou totalmente contra usar “artifícios” de BD, como Triggers, Stored Procedures, Fuctions, Views, etc. Só se for para melhorar performance -> e se não tiver outro jeito mesmo! :hunf:

Ah, xdraculax: Opa, eu não tinha visto a sua pergunta

xdraculax:

Cara, o que é “Engine de Orquestração BPM”?

Rubem Azenha:

Eu tenho péssima experiências com integração via banco de dados! Depende de cara projeto, mas eu geralmente sou contra.

Eu acho muito problemático ter várias aplicações lendo uma mesma base de dados, pior ainda várias aplicações alterando a mesma base de dados. É muito fácil a situação ficar caótica e você não conseguir enchergar que aplicação altera que dado em que tabela. Sem falar na duplicação de códigos entre aplicações para interpretar o que cada dado significa, validações, etc e todos so problemas que essa duplicação de código traz.

O pior é tratar os eventos que devem acontecer quando um dado é inserido ou alterado… numa aplicação que eu trabalhei no ano retrasado, várias aplicações liam e alteravam os dados dos funcionários. Isso era um problema por que existia uma necessidade de executar um processo de uma das aplicação cada vez que um funcionário era demitido ou entrava de férias… No fim acabamos fazendo uma aplicação só pra cuidar do cadastro dos funcionários, todas as outras aplicações que precisavam acessar ou alterar dados dos funcionários passaram a utilizar essa aplicação e tinhamos mecanismos que permitiam trabalhar melhor com notificações de eventos (nada muito sofisticado, tinha muito espaço para melhoras, mas é melhor que usar trigger).

Enfim, acho que o banco de dados deve ser utilizado por apenas um sistema, os outros sistemas não devem acessar direto o banco de dados e sim usar algum outro mecanismo de integração (queue, WS, EJB…)

Como disse no início, é claro que cada caso é um caso, mas só usaria se não houvesse outra opção.

[]s

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

Como assim?

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, …

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

Como assim?

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

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

º´s

Kenobi

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

º´s

Kenobi

… 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

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…

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.

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.

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

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.

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.

Rubem Azenha:

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

º´s

Kenobi

… 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 :)

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.

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.

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.

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.

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.

@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

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

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

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.

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é?

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.

Rubem Azenha:

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.

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.

É 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

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.

Rubem Azenha:

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.

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é? :)

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

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

Esse é o principal motivo por que tenho certeza que integrações burras um desastre esperando acontecer. A partir do momento que alguém duplica as regras de negócio em outra aplicação, essa regra passa a evoluir independente, e daqui há anos, o time terá em mãos duas aplicações que trabalham de maneira diferente em cima dos mesmos dados, quando estes deveriam ter o mesmo tratamento.
E não dá pra falar que alguém vai ter cuidado com isto, as aplicações podem estar nas mãos de dois analistas diferentes, trabalhando para duas gerências diferentes.

Daí começam inconsistências dentro da própria empresa, cálculos de lucros ficam errados, a equipe de DW fica louca atrás de consertar os relatórios gerenciais.

Um exemplo simples é um cadastro de pessoas, onde a pessoa pode ter múltiplos telefones, ou endereços de correspondência/entrega. Para a aplicação que construiu o DB, não importava qual era o endereço principal, e então não há indicação alguma disto.

Um segundo sistema, precisa deste dado de endereço principal. Este decide que o endereço é o que tiver a data de atualização mais recente.
Um terceiro sistema, decide que endereço é o primeiro cadastrado.

Um quarto sistema integra com o segundo e com o terceiro. Qual endereço está certo?

Enfim, é uma dor de cabeça quando todas as partes estão certas, nas suas próprias maneiras, e você tem que definir um critério de desempate, e este critério é que vai definir que partes da empresas/filiais vão receber mais investimentos/cortes no próximo ano.