Requisitos em SOA – Parte 2 - Engenharia de Software 29

Requisitos em SOA – Parte 1

No primeiro artigo desta série foi abordado como identificar os primeiros serviços e determinar seus requisitos de negócio em um projeto Service-Oriented Architecture (SOA). Foram comentadas as principais abordagens para identificar serviços, assim como foram expostas algumas categorias para requisitos de negócios. Por fim, discutiu-se um processo simples para modelar os requisitos de negócio para os serviços identificados.

Neste artigo, serão explorados diferentes tipos de soluções tecnológicas que precisam ser conhecidas a fim de capturar os requisitos técnicos de um projeto SOA. Serão apresentadas também algumas exigências que devem servir de base para a captura de requisitos técnicos, prevendo-se o lançamento de um programa SOA generalizado para a empresa. Um programa deste porte visa: garantir a escala e o controle dos investimentos dentro de um cenário de orçamentos restritivos, permitir uma maior visibilidade dos serviços compartilhados e um melhor planejamento e revisão da arquitetura.

Por onde começar?

O foco principal em um projeto SOA deveria ser dado às exigências do negócio, porém como a maioria das iniciativas SOA acabam sendo lideradas pelas equipes de TI (e não pelas equipes de negócio) os requisitos de tecnologia ganham tanta importância quanto os requisitos de negócio. Dada essa realidade, (e aqui não se vai discutir se ela é correta ou não, pois simplesmente é a realidade) os grupos de TI, desde o início do projeto, iniciam discussões de questões como: a adoção do SOAP e WSDL, o uso de Web Services, Universal Description Discovery and Integration (UDDI), Enterprise Service Bus (ESBs), e o uso de ferramentas de governança em SOA (ver definições detalhadas na Nota 1). Na prática, a equipe de TI escolhe um serviço de negócio a ser usado em uma prova de conceito (POC) e concentram-se fortemente na tecnologia que será utilizada no desenvolvimento deste POC.

Neste ponto vale a pena uma reflexão, é preciso cautela na utilização de algumas das soluções tecnológicas listadas anteriormente, principalmente no que diz respeito a três delas: UDDI, ESB e as Ferramentas de Governança. Partindo da premissa que os projetos estão no início e que algumas soluções necessitam de maturidade, é preciso aprender antes de tomar decisões baseadas em folhetos de fornecedores. Por exemplo, o UDDI é conceitualmente perfeito, no entanto, a sua implantação em um projeto SOA que provavelmente iniciará com um pequeno número de serviços e uma base de consumidores relativamente limitada, é um exagero. No início, é bem mais produtivo gastar tempo na definição de contratos WSDL bem estruturados, pois eles darão base às informações que serão manipuladas pelos repositórios UDDI.

Padronizando os Padrões

O padrão SOAP éutilizado pelos Web Services e é responsável por definir o modelo da troca de mensagens. Para isso utiliza um arquivo XML que define envelopes e os nós intermediários da comunicação.

O padrão WSDL é responsável por identificar o protocolo e o endereço no qual um serviço está publicado, assim como seus parâmetros de entrada e saída.

O padrão UDDI permite que os serviços sejam categorizados, porém sem fornecer uma riqueza de textos para que buscas por um serviço específico sejam feitas.

O padrão ESB permite customizações no serviço de mensagens, isto é, ele funciona como um Mediador. A partir dele é possível fazer validações e roteamento de mensagens baseado no conteúdo da mensagem. Um barramento ESB permite um baixo acoplamento entre sistemas visto que um sistema de origem não precisa conhecer o sistema de destino.

A mesma linha de argumento é válida para um ESB. Dependendo da complexidade da solução SOA a ser adotada, um ESB pode não ser a melhor solução para o problema. Um ESB deve ser usado quando existem diversos sistemas que precisam conversar de diversas maneiras e que estão distribuídos em locais diferentes (é o caso típico de aplicações em portais web).

O ESB atualmente tornou-se uma poderosa ferramenta de propaganda das arquiteturas orientadas a serviços, atuando como uma camada de abstração das interfaces dos serviços. Por meio do ESB é possível integrar os sistemas, mantendo seu encapsulamento e ainda existem ESBs que fazem mais: podem até controlar o SLA de um serviço. Todas essas características tornam a idéia de ter um ESB muito atraente, porém ele não é parte obrigatória de uma arquitetura orientada a serviços. Em casos que existem só dois sistemas (ex: Java e .net), é bem razoável considerar a possibilidade de usar algo mais simples, como o JMS por exemplo.

Em projetos SOA

Felizmente, nem todas as decisões são difíceis, uma boa notícia é que existem tecnologias que já possuem um razoável nível de padronização de mercado, seja para projetos iniciais (POC) ou projetos já amadurecidos. Tais tecnologias são: os Web Services, WSDL e SOAP. Os Web Services (baseados em XML) são o tipo de implementação de serviços mais largamente aceito e bem sucedido. Este tipo de implementação possui como requisitos fundamentais:

• Comunicação via protocolos internet (normalmente HTTP);
• Envio e recebimento de dados formatados como documentos XML.

A ampla aceitação dos Web Services resultou no surgimento de um conjunto de tecnologias suplementares que se tornaram um padrão de fato. Assim, ao desenvolver um Web Service deve-se considerar o uso de tecnologias que:

• Forneçam uma descrição de serviço que, no mínimo, consista de um documento WSDL;
• Sejam capazes de transportar documentos XML utilizando SOAP sobre HTTP.

Os Web Services devem ser definidos numa forma consistente para que possam ser descobertos e “interfaceados” com outros serviços e aplicações. A WSDL é uma especificação W3C que fornece a linguagem mais avançada para a descrição de definições de Web Services.

Apesar de ter sido inicialmente concebido como a tecnologia para transpor a brecha entre plataformas baseadas em comunicação RPC, o SOAP se tornou um dos mais conhecidos formatos de mensagens e protocolo utilizado por Web Services baseados em XML. Por este motivo, o acrônimo SOAP é referido frequentemente como Service-Oriented Architecture (or Application) Protocol (protocolo de arquitetura orientada a serviços) ao invés de Simple Object Access Protocol que curiosamente é seu nome verdadeiro.

Requisitos Técnicos para um serviço

Esta seção descreve quais são as categorias dos requisitos técnicos de um serviço em um projeto SOA. Em um sentido amplo, as categorias mais importantes são listadas abaixo, porém o requisito primordial para uma empresa, quando se trata de tecnologia SOA, é permitir a agilidade nos negócios – também conhecida como tolerância a mudanças. Uma empresa que utilize SOA com sucesso está sempre evoluindo e permitindo mudanças de cenários tecnológicos.

Segurança. A questão de segurança é atualmente a principal preocupação das empresas na tomada de decisões em relação a implementação de projetos SOA. De acordo com uma pesquisa global [4], patrocinada pela CA, 43% dos executivos sênior de TI classificam as ameaças à segurança como o item mais crítico na implementação de aplicações de SOA e de serviços baseados na Web. Quem pode acessar o serviço? Quem pode acessar os dados de dentro de cada serviço? E como os dados são garantidos em uma transmissão entre os serviços? São perguntas que devem ser tecnologicamente respondidas assim que um projeto inicia.

Simplicidade. Como alguém que queira utilizar um serviço, pode facilmente utilizá-lo? Esta é a pergunta que fica na fronteira entre os requisitos técnicos e os de negócio. Um serviço deve ser de fácil invocação, apresentar as funcionalidades esperadas, ter um bom tratamento de erros e, geralmente, ser capaz de se integrar com outros serviços. O ideal é que uma empresa menos madura deva ser capaz de utilizar um serviço sem um grande investimento em tecnologia ou grandes mudanças em seus processos de negócio.

Qualidade. Considere a disponibilidade, escalabilidade, confiabilidade, entre outras características como fatores de qualidade de um serviço. Quais são as consequências de SOA em uma perspectiva de negócios? Um aspecto fundamental em arquiteturas orientadas por serviço é a gerência contínua da qualidade em todo o ciclo de desenvolvimento de processos de negócio e serviços. A qualidade de software está cada vez mais ancorada no atendimento a processos de negócio de ponta a ponta, que é traduzido no conceito de governança de TI, que é a chave para qualquer projeto SOA de sucesso.

Em alto nível, a captura destas categorias é um excelente ponto de partida. É evidente que cada uma possui um maior detalhamento, planejamento, coordenação e gestão de projetos. No entanto, a orientação para o tipo de informação que se precisa capturar já ajuda a definir os requisitos técnicos fundamentais.

Características tecnológicas de um serviço

Para chegar a um modelo de arquitetura tecnologicamente desacoplada entre cliente e serviço, é preciso criar um ambiente propício para o compartilhamento e reuso de funcionalidades, assim como a composição de funcionalidades nas aplicações. Abaixo são apresentadas algumas características tecnológicas essenciais a serviços integrados a uma arquitetura.

Serviços são orientados a mensagens. Os serviços são formalmente definidos em termos das mensagens trocadas entre agentes fornecedores e agentes consumidores. A estrutura interna e a implementação são propositalmente abstraídas. Logo, existe um limite entre consumidores e fornecedores e esse limite representa a fronteira entre a interface pública de um serviço e sua implementação interna, privada. O limite de um serviço é publicado por meio do WSDL e pode incluir declarações que ditam as expectativas sobre o serviço. O cruzamento desse limite pode ser considerado uma tarefa cara por motivos como:

• O local físico do serviço pretendido pode ser um fator desconhecido;
• Os modelos de segurança e de confiança provavelmente mudarão a cada cruzamento do limite;
• O empacotamento e a conversão de dados entre as representações pública e privada de um serviço podem exigir recursos adicionais; alguns deles podem ser externos ao próprio serviço;
• Ainda que os serviços sejam criados para durar, as configurações de serviço são criadas para mudar. Esse fato implica que um serviço confiável pode sofrer repentinas quedas de desempenho em função de configurações de rede ou de migração de local físico.

Serviços são autônomos. Os serviços são entidades implantadas independentemente, com versões e gerências próprias. Os desenvolvedores não podem fazer suposições em relação às distâncias limites de um serviço, visto que essas distâncias têm muito mais probabilidade de mudar do que os limites propriamente ditos. Por exemplo, os limites do serviço devem ser estáticos para minimizar o impacto da versão para o consumidor. Ainda que os limites de um serviço sejam bem-estáveis, as opções de implantação desse serviço em relação à diretiva, ao local físico ou à topologia da rede provavelmente mudarão.

Os serviços são tratados dinamicamente por meio de URIs, permitindo que seus locais e topologias de implantação mudem ou evoluam com o tempo, com pouco impacto em relação ao próprio serviço (isso também é válido em relação aos canais de comunicação de um serviço). Ainda que essas alterações possam ter pouco impacto sobre o serviço, elas podem ter um impacto devastador sobre aplicativos que o utilizem. E se um serviço que estava sendo usando hoje passar para uma rede na Irlanda amanhã? A alteração no tempo de resposta pode ter impactos esperados ou inesperados sobre os consumidores do serviço. Os designers de serviço devem adotar uma visão pessimista sobre o uso dos serviços: os serviços falharão e seus comportamentos associados (níveis de serviço) estarão sujeitos à mudança. Níveis apropriados de tratamento de exceções e de lógica de compensação deverão ser associados a qualquer invocação de serviço. Além disso, consumidores de serviço podem precisar modificar suas diretrizes para declarar tempos de resposta mínimos de serviços a serem utilizados.

Os consumidores de serviço não são os únicos que devem adotar visões pessimistas do desempenho: os provedores de serviço devem ser da mesma forma, pessimistas ao antecipar como seus serviços serão utilizados. Deve-se esperar que os consumidores de serviço falhem, algumas vezes sem notificar o próprio serviço. Os provedores de serviço também não podem confiar que os consumidores “farão a coisa certa”. Por exemplo, os consumidores podem tentar se comunicar usando mensagens mal-elaboradas/mal-intencionadas ou tentar violar outras diretrizes necessárias para uma interação de serviço bem-sucedida.

Feitas essas considerações, alguns princípios de design simples que ajudam a garantir a compatibilidade com a segunda característica (Serviços são autônomos) são:

• Os serviços devem ser implantados e ter a versão atualizada, independentemente do sistema em que sejam implantados e utilizados;
• Os contratos devem ser projetados pressupondo-se que, uma vez publicados, não possam ser modificados. Essa abordagem força os desenvolvedores a criarem flexibilidade em seus designs de esquema;
• Os serviços devem ser tolerantes a falhas, adotando uma visão pessimista. Da perspectiva do consumidor, deve-se esperar níveis pouco confiáveis de disponibilidade e de desempenho do serviço. Da perspectiva do fornecedor, espere que o serviço seja usado de forma errada (deliberadamente ou não) e que os consumidores do serviço falhem, talvez sem notificar o serviço.

Serviços compartilham esquema e contrato. Como já foi dito, a interação com um serviço deve seguir diretrizes definidas no contrato deste serviço. A maioria dos desenvolvedores define classes para representar as várias entidades dentro de determinados domínios de problemas (por exemplo, Cliente, Pedido e Produto). As classes combinam comportamento e dados (mensagens) em uma única linguagem de programação ou construção específica à plataforma. Os serviços dividem esse modelo para maximizar a flexibilidade e a interoperabilidade. Os serviços que se comunicam usando mensagens baseadas no esquema XML não reconhecem as linguagens e as plataformas de programação, garantindo níveis mais amplos de interoperabilidade. O esquema define a estrutura e o conteúdo das mensagens, ao passo que o contrato de serviço define o comportamento do próprio serviço.

Resumindo, o contrato de um serviço consiste nos seguintes elementos:

• Formatos de troca de mensagens definidos com o Esquema XML;
• Padrões de troca de mensagens (MEPs) definidos com o WSDL;
• O BPEL pode ser usado como contrato no nível de processo comercial para orquestrar vários serviços.

Os consumidores de serviço utilizam um contrato de serviço para invocar um serviço e interagir com ele. Havendo essa confiança, o contrato de um serviço deve permanecer estável com o passar do tempo. Os contratos devem ser projetados da forma mais explícita possível, ao mesmo tempo tirando proveito da natureza extensível do esquema XML e do modelo de processamento SOAP.

O maior desafio da terceira característica é sua continuidade. Depois que um contrato de serviço é publicado, é extremamente difícil modificá-lo e ao mesmo tempo minimizar o impacto sobre antigos consumidores do serviço. A linha entre as representações de dados interna e externa é fundamental para a implantação e a reutilização bem-sucedida de determinado serviço. Os dados públicos (dados passados entre serviços) devem se basear em padrões organizacionais ou verticais, garantindo ampla aceitação entre diferentes serviços. Os dados privados (dados dentro de um serviço) são encapsulados em um serviço. De alguma maneira, os serviços são como representações menores de uma organização que conduz transações de e-business. Assim como uma organização deve mapear uma Ordem de compra externo em seu formato interno de OC, um serviço também deve mapear uma representação de dados sob contrato em seu formato interno. As experiências com encapsulamento de dados OO podem ser reutilizadas para ilustrar um conceito semelhante: a representação interna dos dados de um serviço só pode ser manipulada por meio do contrato do serviço.

Feitas essas considerações, vão aqui alguns princípios de design simples que o ajudam a garantir a compatibilidade com a terceira característica:

• Garantir que o contrato de um serviço permaneça estável para minimizar o impacto sobre os consumidores do serviço. O contrato nesse sentido se refere à representação de dados pública (dados), ao padrão de troca de mensagens (WSDL) e a recursos e níveis de serviço configuráveis (diretriz);
• Os contratos devem ser os mais explícitos possível, visando minimizar a má interpretação. Além disso, os contratos devem acomodar a futura versão do serviço por meio da extensibilidade da sintaxe XML e do modelo de processamento SOAP;
• Evitar transpor a fronteira entre as representações de dados pública e privada. O formato interno dos dados de um serviço deve ficar oculto para os consumidores e o esquema de dados público deve preferencialmente seguir um padrão organizacional.
• Serviços de versão quando há alterações no contrato de serviço são inevitáveis. Essa abordagem minimiza a ruptura de implementações do antigo consumidor.

Conclusão

As demandas de uma arquitetura orientada a serviços em termos de disponibilidade, escalabilidade, desempenho, confiabilidade e assim por diante são ainda mais importantes quando postas frente às mudanças tecnológicas na área de TI. Em SOA existe um aumento significativo do risco de não acompanhar as necessidades do negócio se a infraestrutura não atender a demanda e não existir uma previsão ou planejamento para essa demanda. Portanto, em linhas gerais é vital ser cauteloso: planejar com antecedência, manter o ciclo de comunicação aberto, conhecer as tendências em serviços do setor, quais os próximos serviços a serem construídos e assim por diante. Em resumo, o importante é seguir um processo, ser pró-ativo em termos de capacidade de planejamento, gestão e acompanhamento das soluções adotadas.

Do ponto de vista de arquitetura de software, é sempre bom manter os olhos sobre as tecnologias SOA mais atuais, padrões e frameworks. Provavelmente, os serviços que seus clientes estão usando agora possuem uma vasta gama de tecnologias, de modo que você precisa monitorar continuamente estas tendências. Por isso, é prudente ter um Plano de interoperabilidade, ou melhor, tentar prever os desafios de interoperabilidade em termos de escolhas de tecnologia.

Links