SOA, Simples Assim!

SOA Patterns

O livro “SOA Design Patterns“, do Thomas Erl já estava no forno mais de 1 ano. Finalmente disponível, a publicação é um daqueles “must read” para quem não quer “reinventar a roda” e seguir boas práticas e padrões nas implementações e integrações baseadas em SOA.

O livro foi feito de forma colaborativa. Além do próprio autor, outros 35 especialistas ajudaram na extensa e excelente lista de patterns que o livro apresenta. Nomes como David Chappell (Oracle),  Mark Little (Red Hat/JBOSS), Pablo Cibraro (Lagash Systems SA), Nelly Delgado (Microsoft Corporation) etc.

Você pode consultar a lista dos patterns neste link. Adicionalmente, Erl disponibilizou um MS Visio Stencil  (template) que você pode baixar aqui e utilizar livremente na representação gráfica dos seus padrões e diagramas (testei no MS Visio, MS Word, MS PowerPoint).

Abaixo o comentário de uma das mais conhecidas analistas, Anne Thomas (Burton Group):

The technical differences between service orientation and object orientation are subtle enough to confuse even the most advanced developers. Thomas Erl’s book provides a great service by clearly articulating SOA design patterns and differentiating them from similar OO design patterns.
- Anne Thomas Manes, VP & Research Director, Burton Group 

Werner Vogels trabalhou por 10 anos em pesquisas de sistemas distribuidos em larga escala. Ele entrou na Amazon em 2004 para ajudar a gigante on-line na tarefa de lidar com as grandes demandas (“picos”) de acesso, para ajudar a planejar quão escalável iriam ser as suas soluções de software, a arquitetura e como disponibilizar a sua infraestrutura de TI da Amazon como um produto.

Justiça seja feita, Vogel é parte de um trio que comanda o desenvolvimento da “cloud computing” da Amazon. Os outros dois são: Andy Jassy (VP Senior que concebeu o modelo de negócios) e Charles Bell (VP e líder técnico do Amazon Web Services, AWS).

A Amazon quer mesmo se tornar uma extensão para o data center corporativo de qualquer empresa, um opção segura e robusta que dê vazão aos “picos” de processamento de sua empresa.

Alguns números interessantes:

- Existem, cadastrados, 440.000 desenvolvedores do AWS
- 29 bilhões de objetos armazenados no “grande disco virtual” S3 (Amazon Simples Storage Server)
- Os acessos à sua “nuvem” (em banda utilizada) ultrapassou o volume trafegado no site da Amazon.com (ou seja, em banda utilizada, maior que o próprio core business)

A InformationWeek/USA tem um artigo excelente sobre ele e os comandantes da AWS. Em português, um resumo da entrevista publicado pela ITWeb.com.br.

Agora um pequeno histórico do Amazon AWS:

(fonte: http://www.informationweek.com/news/management/interviews/showArticle.jhtml?articleID=212501217&pgno=1&queryText=&isPrev=)

Esta é para a turma do .NET. O título original do artigo é “SOA using C# and WCF“. Quem tiver a curiosidade de ler o mesmo, verá que não está relacionado com SOA e sim com Web Services.

De qualquer forma estes how-to-do são importantes para fixar alguns conceitos básicos. Não se engane e não se deixe enganar: SOA “não é” Web Services e se você tem algum Web Services não significa que você “tem” SOA.

O site DeveloperWorks/IBM está lançando uma série de tutoriais sobre a implementação de Web services utilizando Apache CXF e Spring. A parte 1 deste tutorial está disponível aqui (acesso livre).

O tutorial é muito “hands on” com exemplos dos códigos e link para download de todos os fontes e aquivos de configuração da aplicação-exemplo.

Nos vários eventos e discussões sobre SOA que participamos nestes últimos 03 anos, inevitavelmente, éramos apresentados a cases reais de implementação de arquitetura orientada a serviços que não passavam de um conjunto de Web Services.

Este “erro” é tão comum que existe até um termo em inglês para designar esta arquitetura que “pretende” ser SOA: JBOWS (Just a Bunch of Web Services, ou apenas uma porção de Web Services). Este termo foi definido pelo Joe McKendrick ainda em 2005 (!).

Muitos arquitetos de integração estão implementando JBOWS, Web Services Integration (WSI) ou qualquer outra coisa e “juram de pés juntos” que isto é SOA. Não é!

Desde que Ronald Schmelzer escreveu um artigo com o título “Why Service Consumers and Service Providers Should Never Directly Communicate“, esta polêmica aumentou e provocou uma boa discussão na blogosfera.

Afinal, por que Service Consumer não deve ser comunicar diretamente com Service Provider?

Por várias razões mas, basicamente porque seu ambiente SOA deve pressupor um ambiente heterogêneo, sujeito a mudanças e com “baixo acoplamento”:

1. Baixo acoplamento na Implementação
2. Baixo acoplamento no “Contrato” de Serviço
3. Baixo acoplamento na “Política” de Serviço
4. Baixo acoplamento no Processo
5. Baixo acoplamento no Schema de Dados
6. Baixo acoplamento na Infraestrutura
7. Baixo acoplamento na “Camada” Semântica

Sobre este assunto recomendo este artigo: “The Seven Layers of Loose Coupling” (também no site Zapthink.com).

Qual a Solução? Resposta: “Late-Biding”!

Late-biding significa basicamente que um cliente não está ciente (aware) do seu endpoint (service ou server). Um cliente faria uma requisição a um IP virtual e um “proxy” (também chamado de application delivery controller) verifica o cabeçalho HTTP para determinar o endpoint apropriado . O termo “late” (atrasado) é utilizado porque a decisão de direcionar ao endpoint só é tomada após a requisição do cliente.

1. Cliente envia uma requisição para o application delivery controller
2. O application delivery controller verifica a requisição e determina o endpoint (server ou pool)
3. O application delivery controller direciona a requisição para o endpoint (server ou pool)

No mundo real uma das formas de implementar o late binding é através do uso do WSDL (Web Services Description Language).

1. Cliente requisita o WSDL apropriado, opcionalmente de um registry
2. Cliente determina o endpoint através de um parsing no WSDL
3. Cliente direciona a requisição para o endpoint definido no passo anterior

Mais detalhes aqui.

Conclusão

O “Late-binding” não é a solução para tudo. Existem outras abordagens e em cada cenário devem ser avaliados os prós e contras. Este é um trabalho do arquiteto de integração mas, certamente você deve, sempre que possível, ter em mente os 7 níveis de abstração em seu ambiente SOA e o bom senso para fazer o trade-off correto.

Uma crítica interessante e cuja leitura também recomendo está neste post do blog da Anne Thomas Manes (Burton Group).

Boa sorte!

Sempre acreditei que KISS ( “Keep It Simple, Stupid”) é mais do que um princípio, é uma filosofia (está até na Wikipedia).
Pois bem, esta é a tônica deste artigo de John Hagel e mais outros 2 autores.

É uma leitura interessante (são apenas 3 páginas). Não sei precisar exatamente quando foi escrito, mas garanto que todo o conteúdo é muito atual.

O título é “The Secret to Creating Value from Web Services Today: Start Simply“.

• Keep it Simple
  • Simple Data: verifique o que é importante e que informações trazem valor para a organização
  • Simple Protocol: SOAP, FTP etc
  • Simple Business Process: parceiros e sistemas precisam trocar informações e não, necessariamente, ter conhecimento de todo processo
• Keep it Incremental
  • Business Partners: ele cita um excelente exemplo da Dell. Neste caso ela selecionou poucos parceiros de negócios para diminuir o tempo entre um pedido de uma máquina e o envio da mesma
  • Level of Specification: “descer ao mundo real”. Ao invés de uma abordagem de produzir grandes e complexas especificações, prefira especificações “menores”, de menor complexidade que possam produzir resultados mais rápidos.
  • Amount of Value: o CIO deve se perguntar, sempre, o que exatamente traz valor? O autor cita um exemplo de uma empresa da área financeira que iniciou a utilização de Web Services para distribuir análises do mercado para seus clientes. Perfeito. Baixo risco, cliente satisfeito com o resultado, empresa “ganha confiança” para desenvolver novos serviços via Web Services… …e o ciclo recomeça.
• Learn, Learn, Learn – a melhor forma de aprender é desenvolvendo. Inicie simples, mas inicie – o meio mais difícil de aprender é não fazer nada.

 O dilema “OO versus SOA” é um dos artigos da SOA Magazine de Fev/2008. Além deste, a edição deste mês tem outros 3 (três) que tratam sobre SOA no Governo, Segurança em SOA e Integração com Composição de Serviços baseados em Processo.  Vamos a um pequeno resumo destes artigos:

• “SOA in Government: Law Enforcement Use Case“: um exemplo de como a adoção de SOA pelas agências do governo (americano) tem crescido. O exemplo citado neste artigo detalha como a arquitetura orientada a serviços foi utilizada por um agência do Segurança do governo dos EUA. Mais precisamente, como os vários sistemas de rastreamento e de segurança foram integrados através de um ESB. 
• “Integration with Process-Centric Service Composition“:  sugere que com uma abordagem orientada a processos as empresas serão mais ágeis e poderão responder ao mercado em um tempo menor. Se os nossos sistemas não serão mais vistos como “silos” nossos processos não podem ser vistos como “funções de negócio”. 
• “Service-Orientation and Object-Orientation Part I: A Comparasion of Goals and Concepts“: o próprio editor da SOA Magazine, Thomas Erl, assina este artigo. A figura abaixo (extraida do artigo) mostra como Orientação a Objetos (OO), EAI, and Web Services, juntamente com BPM influenciaram a Orientação a Serviços:Uma visão interessante de como a Orientação a Serviços é um superset da Orientação a Objetos é mostrada na figura abaixo (que eu preparei com base neste artigo):
• “Security in SOA – It’s the Car, Not the Garage“: segurança em SOA é sempre uma questão complexa. Este artigo traz comparações interessantes sobre os aspectos de segurança de alguns “paradigmas” que utilizamos hoje. Veja a tabela abaixo:

Estou cada vez mais convencido de que quando a performance é um requisito, devemos avaliar alternativas para os Web Services.

O exemplo detalhado neste artigo é um case da bolsa de mercadorias de Nova York onde, devido a questões de performance, o Java Messaging Service (JMS) foi a escolha da Progress Software para implementação de um projeto baseado em SOA.

Este sistema irá suportar até 1.2 milhões de contratos (negociações)/dia (aumento de 38% no volume atual) e irá processar mais de 50,000 mensagens/segundo.

Segundo o CTO da Progress Software, Hub Vandervoot,

HTTP SOAP just isn’t reliable enough nor does it have the performance for the kind of traffic we’re talking about here.

Este artigo da SOA World Magazine traz uma comparação de vários Web Services engines que são open source. Veja na tabela abaixo os engines testados:

# de Transações por Segundo

Tempo médio de resposta de uma Transação (segundos)

Conclusão dos autores:

First, it seems obvious that the performance of third-generation SOAP engines is significantly better than that of its first- and second-generation counterparts.

It’s concluded that the JibX Binding Framework offers the best performance and a great deal of flexibility through its binding definition file. However, defining bindings for complicated objects can become very cumbersome and time-consuming.

It’s also concluded that XFire with JibX offers the best marshalling and un-marshalling performance, and is only marginally slower than Axis2 with JibX in round-trip performance, which can be largely attributed to the slower client-side processing by the XFire-based JibX client. XFire also seems to offer the best scalability, speed, and throughput among all test cases. Moreover, the ease of development using JibX binding with XFire over Axis2 with JibX makes this an attractive option.

However, it’s worth noting that, if ease of use and development is of essence, Axis2 with ADB offers the best balance between ease and performance – Axis2 with ADB is extremely easy to use (however, it’s less flexible than JibX) and offers very decent performance.

InnoQ has this amazing poster that shows an overview of the Web services standards. There is also a PDF version.