codejun

Arquitetura orientada a serviço exige mais disciplina empresarial do que os modelos desenvolvidos anteriormente

Fonte

O preço é um dos pontos mais atraentes dos produtos SOA (do inglês, arquitetura orientada a serviço) em código aberto. No entanto, essas plataformas ricas em características e praticamente sem custos é um serviço corporativo, muitas vezes, não desenvolvido para usuários de negócios e exige tanta experiência que pode derrubar a plataforma. Existem algumas exceções notáveis e os líderes estão mais conscientes do problema, agindo rápido para desenvolver elementos de “orquestração” dessas soluções em open source. Mas, infelizmente, a maioria ainda não chegou lá.

Os mais notáveis entre os ESBs de código aberto são: Apache ServiceMix; Fuse ESB, da Iona; JBoss ESB; Mule ESB e WSO2 ESB. Mas não se precipite. Análise as características específicas para descobrir se um determinado produto em código aberto será um benefício ou um obstáculo para os esforços SOA de sua empresa.

ESB é a estrutura de SOA padronizada, capaz de conectar aplicações por interfaces de serviço. Ao combinar mensagens, web services, XML e transformação/gerenciamento de dados, esse conector pode, de modo confiável, unir, mediar e controlar a comunicação e a interação entre serviços.

Quando se trata de integração tecnológica, os ESBs open source entregam resultados semelhantes aos de seus equivalentes comerciais. E, ainda mais impressionante, eles sempre aderem aos padrões como JBI, o que não é algo que todos os fornecedores comerciais podem alegar. Os ESBs não são apenas perfeitamente testados e decentemente documentados online, como também vêm com vários adaptares para JDBC, SOAP, FTP, HTTP, POP3, TCP (PCT), UDO e até mesmo para sistemas legados, como o AS/400.

No entanto, alinhar as necessidades do negócio e infra-estruturas de TI é fundamental durante a fase de implementação de arquitetura orientada a serviços, e é aí que os ESBs em código aberto falham, pelo menos por enquanto. Os profissionais de TI não terão problema em trabalhar com XML/Java, mas os de negócio podem ter dificuldade no ambiente open source.

Os analistas de negócios geralmente precisam orquestrar visualmente o fluxo de seus processos, fazer mudanças em tempo real em funcionamento, ajustar o nível de serviço dos acordos e substituir desempenho abaixo do desejado. Os produtos comerciais oferecem flexibilidade melhorada através de uma arquitetura plug-and-play e reutilização de serviços existentes.

Os ESBs em código aberto somente oferecem resultados diretos se os usuários tiverem a experiência necessária em XML e Java para usá-los. Por exemplo, imagine uma empresa que precisa aceitar, validar e posicionar pedidos web. No ESB Mule, os end-points, conectores e roteadores são definidos em XML. Em Spring e Mule, um JavaBean e dois arquivos de configuração são criados para aceitar as informações do pedido, mas a conversão do conteúdo do arquivo para XML e a validação que corrige a quantidade exigem um código Java adicional. Um adaptador de web service é então configurado em XML para posicionar o pedido.

Em outro caso, um cliente precisava consolidar um catálogo de produtos com a suíte de produtos complementar da entidade adquirida. Em um curto prazo, com uma equipe de desenvolvedores já comprometida com projetos em andamento, um ESB comercial foi a melhor opção - os analistas de negócio foram capazes de orquestrar visualmente o fluxo do processo sem qualquer código. Em menos de uma semana, os adaptadores que usaram o padrão ODBC fizeram buscas em dois bancos de dados, em locais diferentes, baseando-se em uma lógica de visualização definida. Além disso, uma das portas de um web service estava aberta para que os fornecedores tivessem acesso a toda a suíte de produtos do dois bancos de dados. Nesse caso, um produto que exigisse código extra e experiência tecnológica teria sido um grande obstáculo.

Os testes são uma boa maneira de ganhar experiência em produtos de código aberto. Assim que um web service é criado, seus desenvolvedores tendem a desenvolver, imediatamente, um cliente-teste usando a linguagem que acreditam ser a mais apropriada. Isso acontece com freqüência em novas iniciativas, como na fase piloto de SOA. Quando se trata de testes em standalone, o JMeter e o SoapUI oferecem as mesmas características de muitos produtos comerciais com ferramentas suficiente para testar a fundo um projeto-piloto da plataforma. Você pode já utilizar o JMeter para testar aplicações, mas o SoapUI também deveria ser obrigatório no arsenal de ferramentas de todo mundo. Se características adicionais e suporte forem necessários, experimente o SoapUI Pro, que oferece mais características por US$ 350 anuais; ou o PushToTest, que integra SoapUI e oferece tanto download gratuito quanto assinaturas pagas.

Compare esses preços com os produtos comerciais, que normalmente tem licença para CPU com planos de suporte que vêm entre 15% e 20% da licença de CPU, no mínimo. Isso significa um custo entre US$ 75 mil e US$ 100 mil apenas para começar a usar um produto comercial.

Governança limitada

Arquitetura orientada a serviço exige mais disciplina empresarial do que os modelos desenvolvidos anteriormente. Sem essa disciplina, não há nada que evite que as pessoas criem uma pletora de Web services e aplicações compostas dentro da empresa, destruindo a eficiência que deve ser entregue se os serviços não puderem ser reutilizados e não puderem ser facilmente encontrados em registros e depósitos. Os registros e depósitos também direcionam o problema de gerenciamento dependente, em que um serviço que falhe pode prejudicar uma quantidade imensa de aplicativos.

Ao contrário dos ESBs, em que os produtos de código aberto estão disponíveis, quando se trata de governança de SOA, há apenas uma solução de código aberto no mercado: o Mule Galaxy. Isso não é necessariamente uma coisa ruim porque o esforço de toda a comunidade está focado no desenvolvimento e refinamento de uma única plataforma que com certeza entrega e mantém as mesmas habilidades de seus equivalentes comerciais.

O Mule Galaxy oferece artefatos de console administrativo de Web como arquivos XML, XSD e WSDL que podem ser colocados em registro. As equipes de TI podem aplicar e reforçar políticas e os usuários podem gerenciar ciclos de vida e dependências, assim como ativar relatórios. A plataforma suporta auto-descobrimento de serviços e expõe uma interface de publicação Atom, que é fácil de usar. As mesmas características são encontradas em produtos comerciais, portanto o Mule Galaxy deve ser levado em consideração quando você estiver escolhendo as opções de governança.

O ESB Mule, em particular, oferece ferramentas adicionais para monitoramento, gerenciamento, disponibilidade e performance (Mule HQ e Mule Saturn) em sua assinatura paga, o que deve ser considerado pelas empresas que precisam de alta disponibilidade, alta performance e suporte técnico. Assim como em todos os projetos de código aberto, suporte via comunidade está sempre disponível em fóruns de mensagens online, embora isso possa não ser suficiente para os negócios.

O custo da maioria dos produtos de código aberto relacionados com SOA se resume a tempo, esforço e, provavelmente o mais importante, especialidade tecnológica. Para implementar efetivamente um ESB em código aberto, as áreas de TI devem estar preparadas para aprender estrutura, modelo de componentes e modelo de script XML, assim como ter um bom conhecimento de Spring e Java. Para as empresas com o talento e o tempo, a governança excelente e características testadas, além de escalabilidade, capacidade de gastar, confiança e disponibilidade fazem do uso de produtos em código aberto uma alternativa viável aos produtos comerciais mais caros.

*Cristian Sturek é fundador e principal arquiteto de SOA da XWebServices, com mais de 12 anos de experiência em arquitetura corporativa. 

Powered by Bookmarkify™

Saiu no slashdot

http://lmaugustin.typepad.com/lma/2008/09/commercial-open-source-in-europe-verses-the-us.html

Tabelinha resumo muita:

Para adoção
Europa:
 Não depender de fornecedor
USA:
 Custo

Motivo principal para criação de um modelo de negócio baseado em Open-source
Europa:
Criar um mercado local de software
USA:
Inicio para um grande projeto para vender depois para investidores

Entre outras coisas…

Powered by Bookmarkify™