O povo aqui na empresa está pensando em montar uma aplicação de loja virtual usando SOA (service-oriented architecture). A idéia deles é simples, mas me deu alguns calafrios: criam-se a base de dados e alguns webservices que exportam os dados da base para a camada de visão (asp.not) mostrar ao cliente. Sem classes com lógica de negócios. Todo o processamento ou está na visão ou nos webservices (mais ou menos como define o SOA).
Agora, a perguntinha: vale a pena?! Até que ponto SOA pode ser mais flexível do que as arquiteturas existentes?
Se você controla a aplicação de ponta-a-ponta, webservices só te compram uma degradação significativa na performance.
SOA não é novidade, vc já tem isso na J2EE, com SessionBeans, ou DCOM/Remoting no .NET.
Se a idéia é usar webservices somente para transportar montes de VO, pode esperar uma performance pífia.
A não ser, claro, que o projeto já esteja prevendo a existencia de agentes externos interagindo diretamente com os webservices, passando por cima do ast.not.
Quando comecei a brincar de WebServices eu achei muito bom. Mas a performance é muito ruim (se for usar XML WebService). Fazer uma aplicação toda com SOA pode ser decepcionante nesse ponto, principalmente de tiver que acessar WebServices fora da rede local.
Acho que importar todos os dados da base por WebServices é inviável, a menos que vc faça um esquema muito bom de cache na sua aplicação client. Ou se pelo menos todos os WebServices estejam em rede local.
Eu acho a principal vantagem do SOA é justamente como integração de sistemas, seus WebServices podem conversar com client de várias plataformas, de vária linguagens e de várias funcionalidade diferentes.
[]'s
Rodrigo C. A.
[quote=“louds”]Se você controla a aplicação de ponta-a-ponta, webservices só te compram uma degradação significativa na performance.
SOA não é novidade, vc já tem isso na J2EE, com SessionBeans, ou DCOM/Remoting no .NET.
[/quote]
Foi o que eu tentei explicar para o povo: você consegue SOA com COM+ ou até CORBA, por exemplo. E, até onde eu sei, o controle da aplicação fica de ponta-a-ponta com a empresa. Embora uma abordagem meramente XML-WS possa ser interessante caso se queira fazer a integração com aplicações internas das lojas, como um sistema de supply-chain, por exemplo.
Essa é a utilidade de WS, facilitar integração. Alêm disso, caso a interface do seu serviço não seja exatamente oque o outro lado espera, basta colocar um gateway passando XSLT no SOAP.
Existe alguns grandes problemas com WS, nenhuma implementação hoje suporta segurança, SOAP gateways e outros recursos mais avançados (j2ee 1.4 implementa o WS 1 Basic Profile, .net tá no mesmo pé), ou seja, você precisa se preocupar com isso!
Todo esse lance de distribuir o serviço é bem antigo porém o hype que a mucrosoft tem criado faz parecer coisa nova e solução para tudo. Eu realmente não vejo pq usar webservice se não na ponta da aplicação para expor os dados para uma aplicação externa ao meu ambiente. E na boa para integrar sistemas webservice ainda está bem longe do prometido, na prática o pessoal trabalha bem mais com EJB, J2EECA, CORBA etc. Um amigo meu trabalha no setor de integração de sistemas na TIMBrasil e é isso que se usa lá! A microsoft quer atolar webservice como a solução universal de todos os problemas e muita gente até no mundo java tem entrado na dança. Eu até acho o WS legal, mais devemos saber para o que ele serve da mesma maneira que o EJB e outras tecnologias.