Estamos começando a implementar uma arquitetura mais “SOA” aqui. A idéia é mesmo ter componentes que forneçam diversos serviços e estejam disponíveis às diferentes aplicações da companhia.
Quem já trabalha nesta arquitetura, como tem feito o deploy destes serviços?
É viável fazer o deploy de um JAR (módulo EJB) para cada serviço?
Estamos usando JBoss 4.0.3-SP1 e Java 5.
Abraços
[quote=danieldestro]Estamos começando a implementar uma arquitetura mais “SOA” aqui. A idéia é mesmo ter componentes que forneçam diversos serviços e estejam disponíveis às diferentes aplicações da companhia
Quem já trabalha nesta arquitetura, como tem feito o deploy destes serviços?.[/quote]
Eu já, mas de fato só um projeto e muitas pré-vendas. 
Mas deu para aprender um pouquinho.
[quote=danieldestro]É viável fazer o deploy de um JAR (módulo EJB) para cada serviço?
Estamos usando JBoss 4.0.3-SP1 e Java 5.[/quote]
Sim, é possivel se necessário. Utilize EJB Session stateless. Expõa seus serviços como EJB e WebService. Incentive a utilização de EJB sempre que possível, é mais rápido.
O mais importante, crie um wiki e forum na intranet, aonde todo mundo pode consultar e comentar sobre os serviços.
É primordial uma arquitetura de versionamento de serviço, uma sugestão bem simples (sem o uso de um ESB): Use numeros. Exemplo, serviço de correito (consulta de cep, preco de sedex e etc):
CorreiosService1, a proxima versao seria CorreiosService2 e a 1 não morreria.
Lembre-se que serviços são contratos entre quem usa e quem provê. E você não pode mudar seus serviços. Apenas criar novos.
Seria importante, mas por efeito moral que qualquer outra coisa, chamar os seus clientes (que vão consumir seus serviços) para um apresentação e forum sobre o as interfaces dos serviços.
[]s
Jose Peleteiro
Mto bom!
Aqui tb estão começando com essa historia de SOA… bom, ja da pra ter uma ideia de como ir preparando meus projetos…
Entao significa que em uma correção de problema, a proxima versao seria ArquivoJar2 ? E a 1 continuaria com problemas?
Ou somente para novas funcionalidades?
Gostei da ideia de wiki ou forum. Mesmo para uma equipe trabalhar com bibliotecas comum já é uma otima ajuda…
[quote=brlima]Entao significa que em uma correção de problema, a proxima versao seria ArquivoJar2 ? E a 1 continuaria com problemas?
Ou somente para novas funcionalidades?[/quote]
Somente quando há mudança de interface ou de comportamento. Se for uma mudança que não vai precisar de nenhum esforço de atualização para os usuário pode ser na mesma. (uma correção de bug que não altere o comportamento, melhora de performace e etc)
É verdade.
Dependendo do tamanho da orientação a serviços que se quer chegar, eu recomendaria a utilização de um ESB.
Num ESB você pode generalizar a camada de transporte, versionamento, transação e segurança dos serviços. Além de criar um “local único”* aonde os clientes buscam serviços.
No ESB por exemplo, você pode pegar dois serviços e transformar em um serviço só.
Exemplos de ESB opensources:
http://mule.codehaus.org
http://servicemix.org
O JBoss comprou recentemente o ESB Rosseta, que é muito bem conceituado no mercado. Eles ainda não lançaram nenhuma versão, mas é impolgante o fato de partir de um ESB com pedigree.
Falando um pouco mais de ESB, o mule é um dos melhores opensource disponíveis no mercado.
Relativamente simples de ser configurado, exige pouca implementação de código e muito bem documentado.
Várias tarefas como mudança de protocolos, filtros entre outros podem ser controlados diretamente no ESB. Isso é utilizável até quando não temos um padrão claro dos atributos de WebServices por exemplo, e temos clientes e serviços em formatos diferentes - como .NET acessando algo em Java, ou fazer um WebServices client, conversar com um EJB.
Outro ponto à favor do mule está no conceito http://www.eecs.harvard.edu/~mdw/proj/seda/SEDA de processamento.
Para quem utiliza Spring, há como configurar o bean do mule diretamente, facilitando muito o trabalho do desenvolvedor.
PS: Novamente o Spring dando uma mãozinha … 
[quote=danieldestro]Estamos começando a implementar uma arquitetura mais “SOA” aqui. A idéia é mesmo ter componentes que forneçam diversos serviços e estejam disponíveis às diferentes aplicações da companhia.
Quem já trabalha nesta arquitetura, como tem feito o deploy destes serviços?
É viável fazer o deploy de um JAR (módulo EJB) para cada serviço?
Estamos usando JBoss 4.0.3-SP1 e Java 5.
Abraços[/quote]
Quanto ao Jar para cada serviço, perfeitamente viável e o correto, a fim de garantir uma melhor manutenibilidade da sua aplicação.
Li e nao entendi qual a ideia do ESB (ideia de onde usar)… Entendi pra que serve, mas nao vi onde aplicar… :S
Só achei ruim mais um markup text: RESP… O XML já nao estava bom?
Uma outra técnica para ajudar no problema do versionamento é definir pontos de extensão no esquema das mensagens e usar novos elementos (novo ns) para as mudanças. Claro que não dá para evoluir para sempre desse jeito, por isso não substitui a idéia do José.
Só lembre de não deixar seus serviços presos a webservice. WS têm que ser um opção e nunca o unico protocolo de acesso aos serviços. Só usem WS quando não houver outro meio mais binario. WS são 10x mais lentos que uma chamada RMI
[quote=Kenobi]Falando um pouco mais de ESB, o mule é um dos melhores opensource disponíveis no mercado.
Relativamente simples de ser configurado, exige pouca implementação de código e muito bem documentado.
Várias tarefas como mudança de protocolos, filtros entre outros podem ser controlados diretamente no ESB. Isso é utilizável até quando não temos um padrão claro dos atributos de WebServices por exemplo, e temos clientes e serviços em formatos diferentes - como .NET acessando algo em Java, ou fazer um WebServices client, conversar com um EJB.
Outro ponto à favor do mule está no conceito http://www.eecs.harvard.edu/~mdw/proj/seda/SEDA de processamento.
Para quem utiliza Spring, há como configurar o bean do mule diretamente, facilitando muito o trabalho do desenvolvedor.
PS: Novamente o Spring dando uma mãozinha … [/quote]
O mule é do caramba. Já salvou minha pele algumas vezes :D, só que é bom observar o JBossESB que já vem com pedigree. O Rosetta (que foi comprado pela JBoss e está sendo usado como base do JBossESB) é um ESB fantástico.
O unico problema do mule que ele é muito “java”, e quando se trata de ESB isso não é muito bom. (não existe, ate aonde eu sei, chamada nativa em .NET ou DCOM por exemplo).
Ótimo! Não use. Ignore o uso de um ESB. Não é em todo lugar que ele é necessário.
Vou dar um exemplo que vivi pessoalmente e que o ESB foi ponto chave na solução do problema.
Um empresa que fiz consultoria queria utilizar um serviço (de terceiros) de verificação de dados do cliente.
E o cliente queria ter:
:arrow: Contigência
Ou seja, quando esse serviço estivesse indisponível ele chamaria um outro de uma empresa que fornece o mesmo serviço.
:arrow: Poder de negociação com os fornecedores de serviços.
Os consumidores internos do serviços não podiam ficar presos ao serviço de um fornecedor específico.
Mudar de um fornecedor para o outro seria num passe de mágica.
:arrow: Dividir o consumo
Como o cliente já contratos com dois fornecedores diferentes ele queria dividir o consumo desse serviço entre os fornecedores.
O ESB é quem faz isso, o ESB pega esses dois serviços criar uma interface comum que é a interface que vai ser exposta internamente, faz o balancemante, gerência a disponibilidade e inclusive faz um cache (duas consultas a uma mesma pessoa, só vai gerar uma consulta ao provedor do serviço).
Um outro lugar, aonde o muitas pessoas confundem ESB com EAI (integração) é:
Digamos que você tem contrato com uma empresa de logistica que faz entregas do seu produto. A unica forma deles comunicarem com fazendo um ftp de um arquivo texto contendo os pedidos entrege.
Você por sua vez têm não um, mas dois serviço internos que tem que ser utilizados, um que muda o status de um pedido e outro que libera o pagamento para empresa. O ESB transforma esses dois serviços em um, cujo a chamada é uma transferencia de arquivo por ftp (ou mesmo um email) E faz todo o controle de segurança, transação e etc.
O ESB transformou dois serviços em um só, e o expos pelo protocolo de comunicação “FTP”. Isso é orientação a serviço, embora possa parecer EAI. Em um ambiente totalmente orientado a serviço, não existe EAI.
Não isso é muito bom. Não vivemos em um mundo que fala só uma lingua, e o papel do ESB também e de traduzir de um protocolo para o outro. REST é realmente muito bom, exelente quando você têm que expor seus serviços para flash e javascript.
Bom, tenha a incumbência de produzir o material que definirá a arquitetura e design das aplicações Java para atender ao conceito de SOA.
A empresa caminha para a compra de um caro software de ESB.
Minha preocupação inicial é definir como as aplicações Java deverão ser construídas para estarmos compliant com esta arquitetura.
O ponto aqui vai ser o desenvolvimento das aplicações.
Como empacotar?
Como distribuir?
Como implementar segurança?
Como usar contingência para os serviços?
Não vejo uma outra forma de implesmentar os serviços a não ser usando EJB.
Crio o core do meu sistema/serviço e através de Session Façades eu crio as interfaces dos serviços, propriamente ditos.
Através de Business Delegates eu possibilito meus clientes Java acessarem esses serviços, remotos ou não.
Um exemplo inicial que fiz aqui estava assim:
app1.jar (classes de negócio, VOs, DAOs)
app1-modulo1.jar (Façade expondo um serviço específico, implementado no jar acima)
Esses dois JARs eu disponibilizei no deploy do JBoss. As aplicações cliente que rodam na mesma instância podem usar o serviço diretamente, pois as classes estão carregadas no mesmo classloader geral (UCL).
Aplicações remotas devem adicionar um JAR com as classes e interfaces necessárias (delegate, VO, exceptions).
Funciona bem.
Minha dúvida é se esse é mesmo o melhor caminho num ambiente puro Java.
E como fica a questão de segurança? Qual sistema pode acessar que funcionalidades de um determinado serviço? Usar a implementação de segurança do próprio JBoss me proporcionaria o que eu pretendo? Posso delegar a configuração disso pra um BD em invés de um XML?
Depois, com interoperabilidade, o meu ESB pode cuidar de publicar o serviço ou eu mesmo posso disponibilizar meu serviço como um Web Service. Enfim!
Se alguem tem alguma experiência parecida e puder contribuir com as soluções adotadas, eu agradeço!
Sim, o Jboss permite que vc inclua interceptadores (AOP) na chamada aos seus serviços. Um interceptador poderia oferecer grande flexibilidade no momento de autorizar o acesso aos seus serviços, inclusive podendo consultar o BD para isso.
Caros colegas,
Talvez fuja um pouco do assunto, mas vah lah:
Estou implementando um aplicativo para instalar em milhares de pontos de venda. O processamento eh central e as transacoes sao pequenas e enviadas pela WEB.
O servidor recebera dezenas de requisicoes, muitas ao mesmo tempo e tem q ficar disponivel 24h.
Estou pensando em utilizar um aplicativo cliente conversando com o servidor atravez de WS com a dupla Tomcat e Axis no servidor (por traz de um firewall, obvio). O q vcs acham? Muito pesado para uma aplicacao como essa? Dispensavel o SOA?
Fiquei tentado a usar o WS pela sua facilidade de integracao.
Estou em duvida, pois, como jah disseram, o WS eh 10x mais lento q um binario… obvio, XML deve consumir muito mais bytes…
Teria algum beneficio em usar o Axis, tipo disponibiilidade e escalabilidade?
Os dados sao sigilosos, WS eh realmente seguro?
Ou eh melhor usar algum outro metodo de comunicacao?
Antes eu pensava em usar apenas URLs com dados no metodo POST… http padrao.
Agradeço antecipadamente sua opniao.
Valeu colegas