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.

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.

Emerson Macedo wrote:@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

Kenobi wrote:
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.

Kenobi wrote:
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.

Rubem Azenha wrote:

Kenobi wrote:
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.

Kenobi wrote:
É 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

Rubem Azenha wrote:

Kenobi wrote:
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é?

asaudate wrote:...concordo que deveríamos discutir isso em outra thread, já que acabamos desviando o assunto dessa....

Rubem Azenha wrote: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".