Estou trabalhando atualmente num projeto de Integração do grupo Intermédica, solução aqui é WLI + SmartConnect SAP + ESB.
[/quote]
Curiosidades:
Então as dependências ficariam assim: ALBPM -> ALSB -> WLI -> SmartConnect -> SAP (legado). Correto?
O WLI também expõe serviços, como num barramento tradicional. O ALSB agrega valor nessa configuração!?
Tenho estudado um pouco sobre a suíte de soluções da BEA e percebo uma grande sobreposição de funcionalidades entre o WLI e ALSB. No caso do seu projeto, pq foram utilizadas as duas ferramentas?
[/quote]
O WLI expoe por intermédio da JSR 181, onde você anota e expõe o JPD como serviço. Entretanto ele não faz tradução de protocolos como a solução ESB . Nessa arquitetura que citei, você precisa do ESB pois o SmartConnect funciona em cima do ALSB. Uma vez exposto o serviço no barramento, você pode consumí-lo no WLI de várias formas, como uma JMS por exemplo.
Mas mantendo tudo WebService, mesmo assim precisa do ALSB. Você vai expor e definir segurança , SLA uma série de características da sua configuração ali e vai consumir dentro de um JPD ( processo) no WLI.
Espero ter sido claro… estou meio enrolado hoje … acho que é o sono …
SAP -> SmartConnect - ALSB - WLI ( aqui depende do que você vai fazer, se vai persistir em base, se vai expor como serviço modificando algo, se vai fazer qualquer outro processo).
1 - É sempre um processo no WLI que vai chamar o serviço no barramento. Se for persistir em base, tb é um serviço no barramento que é invocado. Correto?
2 - Vc faz as composições de serviços no ALSB ou no WLI? Vc concorda que as composições também podem ser feitas no ALSB?
SAP -> SmartConnect - ALSB - WLI ( aqui depende do que você vai fazer, se vai persistir em base, se vai expor como serviço modificando algo, se vai fazer qualquer outro processo). [/quote]
[/quote]
Certo,
1 - É sempre um processo no WLI que vai chamar o serviço no barramento. Se for persistir em base, tb é um serviço no barramento que é invocado. Correto?
Não - Pode ser um serviço no barramento que recebe dados no Barramento, aí é um JPD por exemplo que tem o JDBC Control ou qualquer outro componente, como DataServices e faz a persistência.
Mas quem cuida de persistência na maneira tradicional ( maior parte dos projetos hoje) é o WLI. Ele tem componentes para as mais diversas necessidades, como arquivos, banco, mail, ejb e por aí vai.
2 - Vc faz as composições de serviços no ALSB ou no WLI? Vc concorda que as composições também podem ser feitas no ALSB?
Se tiverem todas expostas como serviço sim. Entretanto para criar um serviço, você vai usar componentes de abstração - persistência a dados, leitura de arquivos, processamento EJB e por aí vai.
Resumindo - WLI serve para você criar um processo que será exposto como serviço no barramento. Seria o miolo da coisa.
parece que na nova versão do ALSB (3.0) vc pode montar as composições no Workshop e “deployar” no servidor. No 2.6 vc só utilizava o Console. Percebo uma tendência (isso em ferramentas da IBM tb) de trazer os recursos do WLI (antigo EAI) para o barramento (ESB). Como os recursos estão disponíveis nas duas ferramentas, parece que existem diversas configurações possíveis…
parece que na nova versão do ALSB (3.0) vc pode montar as composições no Workshop e “deployar” no servidor. No 2.6 vc só utilizava o Console. Percebo uma tendência (isso em ferramentas da IBM tb) de trazer os recursos do WLI (antigo EAI) para o barramento (ESB). Como os recursos estão disponíveis nas duas ferramentas, parece que existem diversas configurações possíveis…
É que o WLI pode contemplar outros cenários, como por exemplo integração de alta performance, onde trafegar XML não é o melhor caminho.
Com WLI você pode fazer implementações turbinadas de JPA por exemplo, para virtualização de dados, parecido com o DataServices, mas com Hibernate, encapsulando num Control.
Seria legal estudar um pouco do Apache Beehive para entender melhor onde o WLI poderia auxiliá-lo e onde deixa de fazer sentindo.
parece que na nova versão do ALSB (3.0) vc pode montar as composições no Workshop e “deployar” no servidor. No 2.6 vc só utilizava o Console. Percebo uma tendência (isso em ferramentas da IBM tb) de trazer os recursos do WLI (antigo EAI) para o barramento (ESB). Como os recursos estão disponíveis nas duas ferramentas, parece que existem diversas configurações possíveis…
É que o WLI pode contemplar outros cenários, como por exemplo integração de alta performance, onde trafegar XML não é o melhor caminho.
Com WLI você pode fazer implementações turbinadas de JPA por exemplo, para virtualização de dados, parecido com o DataServices, mas com Hibernate, encapsulando num Control.
Seria legal estudar um pouco do Apache Beehive para entender melhor onde o WLI poderia auxiliá-lo e onde deixa de fazer sentindo. [/quote]
Hmmm,
tah aí uma situação onde o WLI se sairia melhor… concordo.