Composição de Serviços - Parte I: Coordenação

Uma das principais características de um Serviço, que deve ser perseguida desde o momento da especificação, é a sua capacidade de se compor com outros Serviços para a elaboração de um novo de mais alto nível de abstração. A figura abaixo ilustra esta capacidade.


Os próximos posts têm como objetivo apresentar algumas das opções de implementações para a Composição de Serviços.

Usualmente, a tecnologia de orquestração (geralmente associada a BPM) é a primeira a ser lembrada. Contudo, dependendo dos requerimentos, outras opções devem ser consideradas:

• Coordenação ("Coordination")
• Orquestração ("Orchestration", como mencionado acima) e Coreografia ("Choreography". Não, ela não é sinônimo de Orquestração como frequentemente é encontrado em diversos materiais).

Neste post descrevo de forma introdutória o primeiro item. O segundo fica para a parte II.

Coordenação
Este modelo, primeiramente, define a figura do Coordenador. O Serviço é o responsável pela execução dos Serviços Compostos, também chamados de Participantes. Usualmente, é ele que é exposto aos Serviços Consumidores, abstraindo para estes a existência dos seus Serviços Compostos. Como podemos imaginar, os Serviços Compostos tipicamente são independentes entre si, promovendo mais uma vez o conceito de baixo acoplamento.

A figura abaixo ilusta a situação. Um exemplo clássico para uma composição de serviços é aquele sobre um Agente de Viagens. O Agente cumpria o papel de Serviço Coordenador, enquanto uma Companhia Aérea, um Hotel e uma Locadora de Carros forneceriam os Serviços Participantes.


Há alguns padrões para Web Services que definem frameworks para Coordenação de Serviços. Dentre eles destaco:

• WS-Transactions: família de especificações da OASIS que compreende:
• WS-BusinessActivity (WS-BA)
• WS-AtomicTransaction (WS-AT)
• WS-Coordination (WS-C): framework genérico que suporta WS-AT e WS-BA

Segundo o WS-Transactions, todos os Serviços pertencentes à composição dependem de um runtime ou framework específico chamado de Coordinator (não confundir com o Serviço Coordenador descrito acima). O Coordinator expõe dois serviços: Activation Service e Registration Service. A figura abaixo ilustra os Serviços da Coordenação e o Coordinator. O Coordinator é tipicamente implementado por engenhos como um Servidor de Aplicação.

O fluxo entre os Serviços da Coordenação e o Coordinator seria mais ou menos assim:

1. O Serviço Coordenador (no nosso exemplo, a Agência de Viagens) faz uma requisição ao Activation Service do Coordinator.
2. O Coordinator inicia uma nova coordenação e responde ao Serviço Coordenador com um contexto. O contexto possui informações diversas. Dentre as mais importantes, a identificação da coordenação e o endereço do próprio Coordinator.
3. O Serviço Coordenador faz uma chamada ao Registration Service do Coordinator indicando que irá conduzir a coordenação.
4. O Serviço Coordenador invoca o primeiro Serviço Participante (por exemplo, a Companhia Aérea) passando as informações de contexto recebidas do Coordinator. Tais informações são inseridas no cabeçalho SOAP da mensagem
5. O Serviço Participante faz uma chamada ao Registration Service para registrar-se como integrante da coordenação.
• Os passos 4 e 5 são realizados para os demais Serviços Participantes (no nosso exemplo, o Hotel e a Locadora de Carros).
6. Os Serviços Participantes finalizam o seu processamento e informam o Coordinator. Note que os Serviços Participantes são totalmente independentes entre si e, portanto, não há uma ordem definida para o término e consequente resposta ao Coordinator.
7. O Coordinator informa ao Serviço Coordenador sobre o finalização dos Serviços Participantes.
8. O Serviço Coordenador envia ao Coordinator uma requisição para finalizar a coordenação.
9. O Coordinator envia uma mensagem para finalização de coordenação para cada Serviço Participante.

Todo o processo fica mais interessantes em situações de exceção: suponha que o cliente da Agência de Viagens (representado pelo Serviço Consumidor) não fique satisfeito com as reservas realizadas. Neste caso o Serviço Coordenador envia uma requisição de compensação ao Coordinator. Este, por sua vez, requisita que o Serviço Participante relativo desfaça a reserva feita.

Os passos descritos acima são chamados, dentro da família WS-Transactions, de Business Activity, definido pelo padrão WS-BusinessActivity (WS-BA). O WS-Transactions define também o padrão WS-AtomicTransaction (WS-AT). A diferença é clara: por um lado o WS-AT define o conceito de Transação Atômica em um cenário de "tudo-ou-nada" entre os Serviços Participantes. Por outro, o WS-BA define o que chamamos de Long-Running Transactions. Eu fiz uma discussão sobre este tema em um post anterior. O exemplo foi dado justamente porque acredito que tenha mais aderência em uma Arquitetura Orientada a Serviços.

A figura ilustra uma situação onde temos somente um Coordinator interagindo com todos os Serviços. Isso quase sempre não é factível: em um ambiente absolutamente distribuído usualmente temos a presença de diversos Coordinators, um em cada ambiente onde os Serviços estão rodando. Deste modo, os Coordinators trocam mensagens a respeito das atividades realizadas pelos Serviços em relação à coordenação (por exemplo, os registros realizados pelos Serviços Participantes). O primeiro Coordinator (responsável pela interação com o Serviço Coordenador) é chamado de root, enquanto os demais são chamados de proxy.

Há inúmeras referências a respeito de Composicão de Serviços, mais precisamente, Coordenação (e Transações). Gostaria de destacar:

• Service-Oriented Architecture, Concepts, Technology and Design de Thomas Erl, capítulo 6.
• Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More de Sanjiva Weerawarana, Francisco Curbera, Frank Leymann, Tony Storey e Donald F. Ferguson, capítulo 11.
• Understanding SOA with Web Services de Eric Newcomer e Greg Lomow, capítulo 10.

SOA e IAM - Segurança em Web Services

Quando há o uso de Web Services para a implementação de uma Arquitetura de Serviços, os padrões WS-Security têm uma importância indiscutível. São eles que permitirão que o processamento de mensagens SOAP seja feito de modo seguro.

Este "post" tem como objetivo ilustrar um pouco o uso deste padrões. Entretanto, em primeiro lugar, gostaria de descrever o que tipicamente acontece em um ambiente sem Web Services. Acho que podemos encontrar muitas analogias importantes depois.


Web Single Sign-On (SSO)
Comentei no "post" passado sobre a típica arquitetura de segurança de aplicações usando um servidor específico de Autenticação e Autorização. Abaixo uma imagem ligeiramente diferente daquela que utilizei:

A fatoração entre as lógicas de Aplicação (apresentação, negócio, acesso a dados, etc) e de Autenticação e Autorização é uma excelente idéia em qualquer lugar. Em um ambiente Web, com o usuário manipulando um "browser", não é diferente.

Antes de descrever o fluxo de processamento, é importante notar que a inserção de um Servidor de Autenticação e Autorização na arquitetura de software, apesar de trazer inúmeras vantagens, implica em um evento intrusivo no ambiente:

• O primeiro momento de "intrusão" no ambiente é a própria presença deste servidor.
• As aplicações são protegidas por um componente de software posicionado entre o browser e elas próprias. Tal componente é chamado de agente e é tipicamente localizado em um Servidor Web ("Web Server"). Este é o segundo momento de "intrusão" no ambiente. As responsabilidades do agente são (1) verificar se o usuário já foi autenticado e (2) autorizar o uso, ou controlar o acesso a um recurso da aplicação pelo usuário.
• O terceiro momento de "intrusão" no ambiente ocorre pela necessidade de alteração da aplicação, posto que as lógicas de autenticação e autorização foram implementadas pela própria.

No momento da autenticação do usuário o que acontece é mais ou menos isso:

• O usuário requisita a execução de uma aplicação através de uma URL bem conhecida.
• Um sistema de proteção da aplicação, ou o agente mencionado acima, verifica se o usuário já foi autenticado. Esse passo consiste em analisar a presença de um token de autenticação na requisicão HTTP enviada pelo browser. Caso o token não esteja presente, significa que o usuário nunca foi autenticado e portanto deve ser redirecionado ao Servidor de Autenticação e Autorização (o redirecionamento ocorre pela resposta 302 à requisição HTTP).
• O usuário é submetido ao processo de autenticação previamente estabelecido. Novamente, tal processo é tão complexo quanto se queira, envolvendo diversos tipos de credenciais, fatores de autenticação, etc.
• O Servidor de Autenticação e Autorização faz uso das bases de dados existentes (LDAP, SGBD, etc) para autenticar o usuário.
• Caso o usuário tenha sido autenticado com sucesso, o Servidor de Autenticação (1) cria um token de autenticacão e (2) redireciona novamente o usuário à aplicação. A requisição é a mesma daquela original emitida pelo usuário com a diferença que desta vez há a presença do token de autenticação.
• Como o token, desta vez, está presente na requisição HTTP, o agente permite que a mesma seja enviada à aplicação.
• A aplicação inicia o tratamento da requisição. Note que não ocorrência de autenticação por parte da mesma.

O "Single Sign-On" é atingido quando todas as aplicações estiverem protegidas pelo agente. Ou seja, o token de autenticação é reconhecido pelo agente e transferido a quaisquer aplicações. Deste modo, o usuário é requisitado para apresentar suas credenciais somente uma vez. Diria que uma arquitetura como essa traz vantagens bem mais valiosas do que o próprio "Single Sign-On". Mais uma vez, a flexibidade dos processos de autenticação, juntamente com a sua separação em relação aos processos de negócios implementados pelas aplicações são os seus maiores benefícios.






Basic Web Services
Os fundamentos de Web Services são bastante simples: há um Provedor de Serviços ("Service Provider") e um Consumidor ("Service Consumer"). Mensagens SOAP trafegam entre os dois elementos para requisição de informações e respectiva resposta. A figura abaixo exibe o que chamamos de "Basic Web Services".


Contudo há pelo menos duas questões que inicialmente devemos considerar em relação à segurança: (1) não há qualquer referência ao usuário responsável pela requisição de um Web Service e (2) as mensagens SOAP, muito provavelmente, atravessarão nós intermediários até o seu destino. Cada nó intermediário poderá ser um sistema específico responsável por um tipo de processamento a ser imprimido na mensagem SOAP até chegar no provedor do serviço.
.

O uso de tecnologias como SSL ("Secure Sockets Layer"), apesar de necessário, garante somente a segurança das informações entre nós. Outras tecnologias devem ser adicionadas para endereçar não somente os dois itens acima mas outros que também podem surgir.

Web Services Security
Entra o padrão Web Services Security (WS-Security ou WSS), conduzido pelo OASIS. Trata-se de uma extensão que permite a inserção de mecanismos baseados em tokens em mensagens SOAP.

A figura abaixo exibe a estrutura de uma mensagem SOAP sem o padrão WSS. Importante notar a presença de um "header" na mensagem. Este "header" é usado para descrever características da mensagem. O WSS, então, define como inserir informações de tokens de segurança no "header" da mensagem. Isso é ilustrado na mesma figura.


Note que o WSS permite o uso de diversos tipos de tokens como certificados digitais X.509, tickets Kerberos, etc. O uso mais comum atualmente para este token é o padrão SAML, também do OASIS.

STS (Security Token Service)
Postas as novas variáveis, uma pergunta aparece: qual componente da arquitetura é o responsável pela emissão de tokens SAML? Novamente aparece a figura do STS. Este servidor cumpre um papel semelhante àquele desempenhado pelo Servidor de Autenticação e Autorização em ambiente Web Single Sign-On explorado anteriormente. De fato, tipicamente, temos à disposição no mercado produtos que podem ser usados em ambas as situações (Web SSO e STS). A figura abaixo ilustra a situação.

Além do STS, a figura exibe o padrão WS-Trust também do OASIS. Esta padrão estende o WSS para que um elemento da cadeia de mensagens Web Services possa requisitar a emissão, renovação, validação, etc de tokens de segurança (SAML, mais uma vez, é um padrão disso).
Em resumo, este framework percorre o seguinte fluxo:

• O consumidor faz uma requisição WS-Trust para o STS para autenticação informando credenciais.
• O STS verifica as credenciais nas bases de dados de usuários existentes.
• Caso o usuário seja autenticado, um token SAML é criado.
• Os tokens SAML são usados por WS-Security para a sua inclusão no cabeçalho da mensagem SOAP.
• Todos os nós seguintes, incluindo o destino da mensagens têm acesso à mensagem, e consequentemente ao token SAML.

Como conclusão: em um ambiente corporativo de Web Services para a construção de uma Arquitetura Orientada a Serviços, o uso dos padrões WS-Security, WS-Trust, SAML, além do próprio STS é absolutamente obrigatório. Infelizmente, estes elementos não recebem a atenção necessária em um projeto de implementação SOA. Como se vê, esta questão deve ser encarada com seriedade e diria que deveria ser conduzida como mais um subprojeto dentro do espectro amplo de SOA.

Segurança SOA - Arquitetura de Serviços e Gerenciamento de Identidade e Acesso II

A disciplina IAM ("Identity and Access Management" - Gerenciamento de Identidade e Acesso) pode ser dividida em diversos temas. Para simplificar, em uma primeira classificação, teríamos as questões funcionais separadas em dois grupos: (1) gestão de usuários e (2) garantia ou execução ("enforcement") das políticas descritas a tempo de gestão.

A figura abaixo ilustra este agrupamento:

Toda a estória começa aqui: em um ambiente corporativo, é natural que tenhamos uma infinidades de bancos de dados que armazenam as contas de usuários de aplicações e sistemas. Dentre eles:

• Sistemas Operacionais
• Servidores de Diretório: LDAP, NIS, X.500, Microsoft Active Directory, etc
• Gerenciadores de Bancos de Dados
• Sistemas de Autenticação: RADIUS, Kerberos, RACF, TopSecret, etc.
• Pacotes de Aplicações: ERP, CRM, SCM, etc
• Bancos de Dados proprietários de aplicações caseiras
• etc, etc, etc.

Gestão de Usuários
Nem todo usuário deve existir em todo sistema ou aplicação. Os processos de Gestão de Usuários (basicamente Aprovisionamento e Gerenciamento de Perfis) preocupam-se em definir quais usuários devem ser inseridos em quais sistemas e bancos de dados de usuários. Chamamos de Ciclo de Vida dos Usuários as operações realizadas desde a criação de um usuário, eventuais alterações, até a sua eliminação dos sistemas.

Veja que os processos de Gestão de Usuários deve se relacionar com diversas categorias de bases de dados e sistemas, localizados em diferentes níveis de abstração desde sistemas operacionais, pacotes de mercado, bancos de dados de aplicações customizadas.

Autenticação e Autorização de Usuários
Definições sucintas:

• Autenticação de Usuário: processo de reconhecimento de um usuário por um sistema. Uma credencial é fornecida pelo usuário para a sua autenticação: par usuário/senha, certificado digital, "tokens" de senhas, dado biométrico, etc.

• Autorização de Usuário: processo de controle de acesso a recursos protegidos. Recursos são quaisquer elementos que um usuário ou aplicação deseja manipular: tabelas de banco de dados, URLs, arquivos, impressoras, etc. O processo de autorização ocorrre após a autenticação do usuário.

Estes processos basicamente consomem as informações inseridas e manipuladas pelos processos de Gestão para implementar uma inteligência específica e necessária que não seria possível de ser realizada por uma única base de dados de usuários. Dentro deste contexto, é possível então que tenhamos autenticação baseada em contexto (por exemplo, considerando data e hora, endereço IP, etc), autenticação multi-fator, etc.

As aplicações basicamente resolvem estas questões de duas formas:

• As lógicas de AuthN e AuthZ fazem parte da própria aplicação: neste caso a aplicação faz um contato com alguma base de dados de usuário como LDAP, X.500, MS Active Directory, etc.

• As lógicas de AuthN e AuthZ são implementadas por servidores específicos. Neste caso, as aplicações enviam requisições a estes servidores e o contato com as bases de dados é feito por estes servidores.

Distribuição e Consolidação de Processos

Outra observação importante é que os processos de Gestão de Usuários (Aprovisionamento, Gerenciamento de Perfis, etc) tendem a ser consolidados enquanto os processos de Autenticação e Autorização são inerentemente distribuídos. Em uma arquitetura de software corporativa é absolutamente natural que tenhamos vários pontos de autenticação e autorização de usuários. A figura abaixo ilustra esta questão. Veja que há domínios de aplicações que fazem uso, para efeito de Autenticação e Autorização de Usuários de um infraestrutura própria. Aplicações Mainframe, por exemplo, provavelmente apoiam-se em softwares como RACF ou TopSecret.

Em SOA, é bastante comum o uso de servidores STS ("Secure Token Service") também representados na figura acima. Um STS é responsável pela autenticação dos usuários que consumirão os serviços disponíveis. Como qualquer Servidor de Autenticação, o STS permite que vários tipos de credenciais sejam fornecidas. Caso a autenticação tenha ocorrido com sucesso, o STS emite um "token" de autenticação que deverá ser "carregado" pelo consumidor de serviço em interações seguintes.

A figura abaixo ilustra uma composição básica com a Arquitetura de Serviços, STS e Intermediador de Serviços.

A figura aponta a interação entre o Intermediador de Serviços (responsável pela Governança em tempo de execução ("run time")) e o STS. Na verdade quaisquer outros pontos da arquitetura podem eventualmente se relacionar com o STS. Por exemplo, um dos consumidores de serviços pode vir a ser um engenho BPM ("Business Process Management"). O contato com o STS pelo BPM pode ocorrer para que o "token" seja criado no momento de uso de um Processo de Negócio definido pelo BPM. O "token", posteriormente, é transferido para os demais elementos da arquitetura como o próprio intermediador, Serviço de Negócio, etc.

O "post" seguinte tratará com mais detalhes o componente STS e os padrões de mercado que normalmente são implementados por ele.

Segurança SOA - Arquitetura de Serviços e Gerenciamento de Identidade e Acesso

Como disse no "post anterior", o assunto Segurança em uma Arquitetura de Serviços deve ser tratada de modo amplo. Alguns aspectos muito importantes são aqueles tipicamente resolvidos por aquilo que o mercado qualifica como Gerenciamento de Identidade e Acesso (ou, em inglês, IAM - "Identity Access and Management").

Na verdade, aqui, aqui e aqui, eu já havia discutido temas relacionados a IAM e SOA. Os "posts" seguintes têm como objetivo descrever um pouco melhor a relação entre esses dois assuntos.

Desde o início, gostaria de salientar que ambos os projetos, SOA e IAM, deveriam ser conduzidos separadamente com um horizonte de sinergia entre ambos. Idealmente, o projeto SOA seria responsável pela implementação de serviços de negócio enquanto o projeto IAM ficaria com a oferta de serviços de segurança.

Resumindo:

• Projetos IAM possuem vida própria e oferecem um conjunto de serviços de segurança a serem consumidos por quaiquer classes de sistemas, SOA ou não.
• Projetos SOA também possuem vida própria e são mais um dos potenciais consumidores das funcionalidades implementadas pelo sistema IAM.

Dentro do espectro de IAM, um bom início é a arquitetura de referência definida pelo Burton Group. A imagem abaixo está em diversos documentos produzidos por ele, incluindo referências externas como esta palestra realizada em Outubro 2009.


Como se vê o espectro funcional é bastante amplo envolvendo diversos temas como:

• Aprovisionamento de Usuários
• Autenticação e Autorização de Usuários
• Sincronismo, replicação e/ou virtualização de dados de Usuários
• Auditoria dos processos realizados
• Definição de Federação

As questões pertinentes têm se ampliado com outros temas como

• Gerenciamento de Perfis de Usuários ("Enterprise Role Management")
• "Compliance" de Identidades
• Gerenciamento de Granularidade Fina dos Atributos de Usuários ("Entitlement Management")

Nos próximos "posts" abordarei com mais detalhes a implicação destes temas em um contexto de Arquitetura de Serviços.

Segurança SOA

SOA não é sinônimo de Web Services. Portanto quando falamos de Segurança SOA, não faz sentido reduzirmos o assunto aos padrões pertinentes a segurança de Web Services como Web Services Security, WS-Trust, SAML, etc, etc, etc.

Mais uma vez é preciso que tenhamos uma visão mais ampla sobre o tema, envolvendo todos os componentes da arquitetura, e não somente o ESB ou motor BPEL ou qualquer outro software específico isoladamente.

Com este objetivo, um modelo de segurança SOA foi elaborado aqui na Sun, há mais ou menos 3 anos. O modelo parte de conceitos bem conhecidos pertinentes ao tema e é basicamente definido em uma matriz de 7 aspectos por 6 facetas específicas de segurança. Por outro lado, o modelo é extensível para permitir a adição de novos mecanismos de segurança, novos aspectos, padrões, especificações, etc.

Aspectos de Segurança

1. Autenticação: Identificação de um sujeito (humano, processo, componente, sistema externo).
2. Autorização: Avaliação de permissão de recursos por parte da entidade. Acontece, usualmente, após a autenticação.
3. Integridade: Garantia de não modificação de informações durante a transferência do seu originador. Tipicamente atingida por assinaturas digitais.
4. Confidencialidade: Garantia que informações não estão disponíveis para sujeitos não autorizados. Tipicamente atingida com criptografia.
5. Responsabilidade (“Accountability”): Associação histórica de eventos que ocorreram com sujeitos.
6. Aprovisionamento de Usuários: Manipulação de bases de dados para inclusão, alteração e remoção de usuários.
7. Políticas de Segurança: Conjunto de regras de negócio que estabelecem o comportamento de um sistema de computação. Podem ser definidas em quaisquer participantes SOA.

Facetas de Segurança

1. Transporte: Proteção de informação durante o trânsito entre duas partes. Fácil implementação através de SSL ou TLS.
2. Mensagens: Proteção de requisições individuais quando são roteadas entre os consumidores, intermediários e provedores de serviços. Em comunicação baseada em SOAP é definida no padrão emergente WS-Security.
3. Aplicação: Mecanismos de segurança da lógica da aplicação. Por exemplo: um diretor pode aprovar ordens de compra até $50K e valores superiores necessitam de aprovação de algum VP.
4. Ativos (Dados): Proteção de quaisquer ativos usados e/ou encapsulados em um serviço. O mais comum é a proteção de dados mas outros tipos de ativos como dispositivos devem ser considerados.
5. Conhecimento: Proteção de informações que descrevem serviços, aplicações e outros ativos sensíveis. Exemplos são: WSDLs e schemas, repositório de políticas, etc.
6. Controle: Inclui todos os mecanismos de segurança que existem para a proteção da solução de governança propriamente dita. Dentre eles estão: violação dos dados de governança, “bypassing workflows”, ataques à infra-estrutura de governança e gerenciamento de serviços.

A idéia é que, de posse destes aspectos e facetas, construamos uma matriz onde possamos identificar o nível de aderência entre estes dois grupos. A matriz abaixo é um exemplo disso:


Os símbolos descrevem o nível de suporte de um determinado aspecto em relação a uma faceta. A tabela abaixo indica o significado de cada símbolo.
Fornece: solução provê esta funcionalidade nativamente ou com mínimo suporte dos consumidores e provedores de serviços.
Suporta: solução facilita a implementação desta funcionalidade pelos consumidores e provedores de serviços.
Permite: solução não atrapalha a implementação desta funcionalidade pelos consumidores e provedores de serviços.
Não fornece: esta funcionalidade está fora do escopo de atuação da solução.

Então, como exemplo: a matriz acima indica que o ambiente usado para a implementação de SOA fornece e implementa o aspecto de autenticacão na faceta de Transporte mas não na de Conhecimento ("Knowledge"). Claro que o ideal é que todas os aspectos sejam endereçados corretamente em todas as facetas do ambiente.

Como conclusão temos que as questões envolvendo Segurança SOA devem ser pensadas de forma mais ampla do que aquela envolvendo as mensagens trafegando por entre os componentes da arquitetura. Melhor seria que o projeto de Segurança SOA fosse encarado como subprojeto de Governança. Em outras palavras, Segurança SOA é melhor entendida como uma dos diversas dimensões ou um caso particular de Governança SOA.

Sobre as decisões para construir uma Arquitetura Orientada a Serviços

Eu comentei em um "post" antigo sobre as razões pelas quais uma Arquitetura Orientada a Serviços deve (ou deveria) ser construída. Gostaria de voltar ao tema.

Fundamentalmente, a decisão para criar uma Arquitetura Orientada a Serviços não deveria ser de responsabilidade do Departamento de Tecnologia de qualquer empresa. Esta decisão deveria necessariamente ser de Áreas de Negócio da companhia.

Esta forma de tomada de decisão não é absolutamente nova. Serve para quaisquer tecnologias desde sempre. Ou deveria servir. Exemplos são inúmeros: bancos centenários sobreviveram durante muito tempo sem o uso de qualquer tecnologia digital. A decisão sobre a introdução de sistemas de computadores em instituições financeiras é dramaticamente mais nova do que o próprio banco.

Neste passado remoto, a substituição de tarefas manuais por sistemas de computadores tinha como objetivo atingir resultados que não são muito diferentes dos atuais: agilidade nos processos, melhor atendimento ao cliente, redução de custos, inovação em produtos, etc, etc, etc. Mais uma vez, nesta época, as decisões não foram tomadas baseadas nas belezas tecnológicas existentes ou por diletantismo mas sim, em reais necessidades de negócio.

Atualmente, é assim também com SOA. Não somente com SOA mas com toda e qualquer tecnologia que se possa discutir.

Contudo, por algum motivo, essa lógica (necessidades de negócio fazendo uso de tecnologia) foi se invertendo: tecnologias são empregadas sem que haja uma real consciência sobre o seu benefício. Não precisamos pensar muito para concluir que tal lógica não é sustentável.

Assim, acredito que SOA não pode ser um fim em si mesmo. Tem que ser um meio para resolução de problemas reais de negócio. Então a lógica original deveria produzir alguma coisa como:

• Forças de mercado e concorrência geram pressão nas empresas por melhores resultados.
• Empresas acreditam que recursos tecnológicos podem ajudá-las a melhorar o seu desempenho, distinguirem-se da concorrência, etc, etc, etc.
• Dentre as diversas opções tecnológicas disponíveis, SOA endereça exatamente estes pontos.
• Áreas de negócio invocam e pressionam a área de tecnologia para entregar tal requerimento.

Dentre os vários motivos pelos quais SOA ainda não teve a adoção pelas empresas, gostaria de citar dois:

• As forças que regem o mercado e a concorrência entre as empresas não tiveram ainda intensidade suficiente para que estas buscassem coisas como SOA.
• A inabilidade de "vender" o que é realment SOA para as áreas de negócio e tomadores de decisão das empresas.

Acho que, quando as pressões de mercado forem de tal ordem, as empresas buscarão soluções como SOA para os seus problemas. E então, teremos investimentos em equipes específicas com conhecimento apropriado. Portanto, reafirmo, enquanto SOA for tratado somente com os seus atributos tecnológicos, com o trato de APIs, produtos, etc, não será adotada plenamente pelas empresas.

Governança SOA e Intermediação de Serviços

No último "post" sobre Governança SOA, eu elaborei um exemplo com duas versões de um mesmo Serviço. Cada versão seria invocada de acordo com condições estabelecidas pelo "Governance Officer" como perfil do consumidor do serviço, hora de requisição do serviço, ou qualquer outra particularidade.
Toda essa mecânica não acontece por mágica: é preciso que tenhamos um componente novo para (1) permitir que as condições sejam descritas e (2) aplicar tais condições no momento da requisição dos serviços.

Esse componente novo é chamado e implementado de diversar formas: Service Gateway, Service Proxy, SOA Governance Gateway, XML Gateway. Eu gosto do termo "Intermediador de Serviços". Usualmente implementado como software, há versões também disponíveis como "appliances".
Uma figura ilustrativa do Intermediador de Serviços pode ajudar:


O Intermediador de Serviços, então, posta-se entre os Consumidores e os Provedores de Serviços. Toda requisição de serviço deve, necessariamente, atravessar o Intermediador.

Alguns comentários:

• O "Governance Officer" estabelece o que chamamos de Aspectos de um serviço, ou características não-funcionais, que são passíveis de configuração para atingir um determinado objetivo.
• Os Aspectos podem ser relativos a questões como Segurança, Performance, Disponibilidade, etc.
• Todas as descrições dos Serviços, juntamente com os Aspectos, ficam armazenados em um Repositório de Serviços, normalmente o mesmo que possui os WSDL usados a tempo de implementação dos serviços.
• Note que a tecnologia empregada para a implementação dos Consumidores e Provedores de Serviços é totalmente irrelavante para o "Governance Officer" pois é abstraída pelo Intermediador. Note também que o BPM, nesta perspectiva, é novamente considerado apenas como mais um Consumidor de Serviços.
• Claro que a alteração de um Aspecto pode ser dependente da infraestrutura onde os Serviços foram implementados. Por exemplo: caso a requisição de um serviço tenha um acréscimo, de nada adiantaria o "Governance Officer" configurar novas instâncias deste serviço (para melhor atender a demanda de requisições) se a infraestrutura de Serviços não estiver preparada para isso.

Diversos benefícios podem ser observados a partir deste modelo:

• O Intermediador de Serviços está fracamente acoplado em relação aos Consummidores e aos próprios Provedores de Serviços.
• Por esta razão o Intermediador é independente dos serviços, do contâiner onde os serviços estão instalados e da própria tecnologia que foi empregada para a implementação dos mesmos.
• A incorporação de novas tecnologias e novos padrões se daria de forma mais barata.
• A consolidação das requisições de serviços permite que tenhamos um controle mais apurado sobre as mesmas e, deste modo, processos de auditoria e até mesmo cobrança para casos onde os serviços são usados externamentes, são dramaticamente melhorados.

Conclusão: a dimensão de Governança é ampla e complexa. Em SOA, não seria diferente. Há uma coleção específica de questões, cobrindo todo o ciclo de vida dos serviços na arquitetura que merecem uma atenção mais do que especial e não deve ser encarada como "coadjuvante".

Há pouca literatura formal ainda sobre o assunto. Um excelente começo é "SOA Governance" de Todd Biske. A coleção gerenciada por Thomas Erl tem agendado para este ano um livro também sobre o assunto.

Governança SOA II

Para exercitar os conceitos de Governança SOA, gostaria de expor um exemplo.

Imagine que banco tenha um projeto de portal para seus clientes. É natural imaginar que este portal deva atender e fornecer informações para todas as classes de clientes do banco, sejam aqueles de conta corrente somente, investidores de bolsa de valores, etc

É natural também imaginar que, como qualquer portal, tenhamos uma seção de notícias do mercado financeiro. O banco, muito provavelmente, gostaria de personalizar o acesso a estas notícias: caso o usuário seja um cliente de conta corrente ou um pequeno investidor, as notícias exibidas seriam aquelas divulgadas por quaisquer agências. Já para grandes investidores o mesmo canal de notícias apresentaria notícias com mais profundidade e detalhamento.

Pense, agora, na implementação de tais serviços de negócio. Em um modelo simplificado, um único serviço poderia se basear no perfil do cliente que fez a requisição e assim tomar as decisões sobre quais notícias deveriam ser exibidas.

Por outro lado, dependendo do contexto, esta implementação não seria a melhor. O serviço de notícias para clientes de conta corrente ou pequenos investidores poderia se basear em "sites" como Yahoo Finance ou Google Finance. Neste caso, não haveria inovação no canal de notícias, mas simplesmente o repasse de notícias disponíveis a todos. Já o serviço de notícias para grandes investidores poderia ser baseado em "sites" com Bloomberg ou Reuters, que, além das informações já fornecidas e de livre acesso, disponibilizam textos de analistas especializados de mercado, projeções, etc. Diferentemente do serviço com informações públicas, esta nova coleção de informações é tipicamente paga. Haveria, então, um contrato comercial entre o nosso banco e essas agências de notícias.

Devido a estes fatores, o mesmo serviço de notícias possui comportamentos muito distintos quando aplicado às diferentes classes de clientes do banco. Por conta disso, o melhor seria, então, termos duas versões do mesmo serviço de notícias. Abaixo temos uma figura ilustrativa:


O cliente informa um símbolo de uma empresa (ORCL para a Oracle, JAVA para Sun, etc) e, baseado no seu perfil ("Platinum" ou "Gold"), o serviço adequado de notícias é invocado. Facilitaríamos significativamente a implementação dos mesmos, mas o maior ganho seria em relação ao controle do ciclo de vida e Governança. Alguns exemplos:

• O "Governance Officer" poderia, dinamicamente, estabelecer novas condições, além do perfil do cliente, para as quais o serviços invocados
• Um serviço poderia ter acesso durante um período do dia somente
• Posto que um número muito menor de clientes usa a versão "Platinum", haveria um uso mais racional da infraestrutura onde os serviços estão sendo executados.
• Etc, etc, etc

Governança SOA I

A dinâmica dos serviços em SOA é intensa: novos serviços são definidos a todo instante, serviços são aposentados, serviços sofrem evoluções, etc, etc, etc. A imagem é que os serviços têm vida própria. E toda vida tem um ciclo. Então, é importante controlar o ciclo de vida dos serviços. Desde o seu nascimento até o seu descarte.

Fundamentalmente, é disso que a Governança SOA trata. Acho que uma analogia ajuda. É muito comum a figura de um Administrador de Dados ("DA - Data Administrator") em uma companhia onde o conjunto de informações é complexo.

Tipicamente, um DA conhece a semântica dos dados inseridos normalmente em Gerenciadores de Bancos de Dados. Não é requerido que ele tenha um conhecimento técnico deste software como "tuning", "backups", etc. Isso é tarefa de um DBA ("Data Base Administrator"). Um DA tem como principal tarefa o conhecimento conceitual das informações armazenadas nos SGBDs: o seu significado, relacionamento entre os dados, domínios e "constraints" existentes, lógica de acesso, segurança, etc, etc, etc.

Um DA participa desde a modelagem conceitual dos dados até a confecção de novos sistemas e aplicações, fornecendo informações sobre os dados existentes para a equipe de desenvolvimento. O caminho inverso também acontece: eventualmente, a estrutura dos dados deve ser alterada para satisfazer necessidades dos desenvolvedores.

Pois bem, em Governança SOA temos necessidades semelhantes. É preciso que tenhamos um controle do serviços de negócio existentes, da mesma forma que os DAs exercem esse controle na camada de dados. Alguém deve ser responsável pelo conhecimento das qualidades funcionais e não funcionais dos serviços de negócio. Esse alguém é usualmente chamado de "SOA Governance Officer". Claro que o "Governance Officer" não possui necessariamente conhecimentos técnicos sobre a materialização e implementação dos serviços mas, mais uma vez, acompanha o ciclo de vida dos serviços de negócio conhecendo as suas qualidades e semântica.

Usualmente, os processos de Governança são classificados em dois grupos:

• Governança a Tempo de Desenho ("Design Time"). Neste momento as preocupações de Governança são focadas em, por exemplo:
• Determinar quais serviços estão disponíveis e são apropriados para serem expostos aos consumidores.
• Decidir qual versão de serviços e quais métodos de manutenção e suporte.
• Decidir qual Contrato de Governança e SLAs (“Service Level Agreements”) aplicar para cada serviço.

• Governança a Tempo de Execução ("Run Time"). Diferentemente dos DAs em relação aos dados, a arquitetura SOA pode vir a alterar características dos serviços dinamicamente. Por exemplo:
• Prover um novo mecanismo de consumo de um serviço.
• Garantir a execução do Contrato de Governança assinado com o usuário.
• Desabilitar e/ou alterar um serviço quando necessário.

Padarias e Transações

Todo domingo vou com a minha esposa tomar café da manhã em uma padaria perto de casa. Normalmente, depois do café, minha esposa aproveita para levar coisas para o lanche da tarde como pão, queijo, etc. Um dia, a fornada de pães demorou para sair e não havia aquele que gostamos. Claro que, como de costume, tomamos o nosso café assim mesmo. Não faria sentido não tomarmos o café da manhã, só porque a padaria estava atrasada com os seus produtos.

Mais tarde retornei para comprar o nosso pão favorito. No caminho, pensei que, da mesma forma, se caso a máquina de expresso tivesse algum problema pela manhã, e que se a fornada de pães tivesse saído na hora, muito provavelmente, teríamos comprado e pão e resolvido o nosso café da manhã em outro lugar.

As operações de "compra de pão" e "tomar café da manhã" não possuem um relacionamento rígido. É assim que a maioria esmagadora de atividades humanas se comporta: são fracamente acopladas umas às outras.

É assim também em SOA. As operações realizadas em um sistemas são, ou devem ser, fracamente acopladas entre si. Esse é uma dos principais características ou objetivos de uma Arquitetura Orientada a Serviços. Mais do que desejável, este nível de acoplamente baixo deve ser perseguido. Contudo, infelizmente, nem sempre é assim...

É muito comum o requerimento de "Transação" quando o assunto é SOA. Talvez até mais comum ainda em BPM. É muito comum ainda o termo "Transação" ser usado como sinônimo de "Atomicidade" de operações distribuídas. Aquele "tudo-ou-nada" normalmente implementado por Gerenciadores de Bancos de Dados. "Rollbacks" mágicos desfazendo operações previamente realizadas.

Vários entendimentos equivocados acontecem neste tema. O primeiro é usar "Transação" como sinônimo de "Atomicidade". Na verdade, esta característica é uma das diversas que uma Transação pode ter. "Atomicidade" é simplesmente o "A" do conhecido Modelo Transacional ACID:

• A - Atomicidade ("Atomicity")
• C - Consistência ("Consistency")
• I - Isolamento ("Isolation")
• D - Durabilidade ("Durability")

O Modelo ACID foi amplamente discutido e formalizado por Jim Gray e Andreas Reuter no clássico livro "Transaction Processing: Concepts and Techniques".

Eu havia dito que Atomicidade é uma das características que uma Transação pode ter. Pode ter. E não, deve ter. Uma Transação sem Atomicidade ainda é uma Transação.

Eu diria que, em um mundo real, a definição de transações distribuídas com Atomicidade, na grande maioria dos casos, não é desejável. É uma má idéia. SOA encaixa-se em uma situação como essa. Em termos de aplicações, Atomicidade promove um nível de acoplamento alto que, por definição, é ruim e deve ser evitado.

O engano, talvez, tenha vindo do uso de Atomicidade em Transações de um Gerenciador de Bancos de Dados. Como temos esse recurso nativamente oferecido pelo produto, também deveriam usá-lo em outros níveis de abstração. Como por exemplo, SOA. Mais uma vez, um grande engano. Transações com Atomicidade são razoáveis e necessárias para Bancos de Dados. Não são razoáveis para aplicações. São níveis de abstração diferentes e, por conta disso, não possuem requerimentos iguais.

Um dos modelos ou padrões de desenho usados quando estamos lidando com aplicações (e SOA é um exemplo disso) é aquele baseado em "Ações de Compensação". Isto é, se algo sai errado com uma operação, aplicamos outras operações que funcionalmente compensam aquelas que tiveram sucesso. As operações de compensação fariam com que aquelas sem erro voltassem ao seu estado original. O modelo Saga descrito por Hector Garcia-Molina, professor de Stanford, autor de "Database System Implementation" foi uma das primeiras formalizações disso.

Outra questão importante: vamos supor que haja uma situação onde uma transação distribuída com Atomicidade seja requerida. Em SOA, ela, talvez, não seja passível de implementação. Ou, se preferir, o custo de implementação seria proibitivo. Por exemplo: suponha que um Serviço tenha como responsabilidade operações em dois legados: Siebel (CRM) e SAP (ERP). A operação do Siebel ocorre sem problemas, mas, por qualquer razão, a operação com o SAP não consegue ser concluída. Em um Transação com Atomicidade, a operação do Siebel seria "desfeita" e voltaríamos à situação original. Contudo, o Siebel não possui capacidades para tornar-se uma unidade de execução de uma transação distribuída. Ele simplesmente não entende comandos como "rollback" ou "desfaça tal operação". O mesmo ocorre para o SAP e na grande maioria das aplicações caseiras e pacotes de mercado. Isto não é exatamente um problema, pois, como disse anteriormente, uma Transação com Atomicidade entre Siebel e SAP não seria desejável.

SOA Manifesto

Anúncio feito no Segundo Simpósio SOA em Roterdã na Holanda. Os autores responsáveis pela iniciativa são:

• Ali Arsanjani
• Grady Booch
• Toufic Boubez
• Paul C. Brown
• David Chappell
• John deVadoss
• Thomas Erl
• Nicolai Josuttis
• Dirk Krafzig
• Mark Little
• Brian Loesgen
• Anne Thomas Manes
• Joe McKendrick
• Steve Ross-Talbot
• Stefan Tilkov
• Clemens Utschig-Utschig
• Herbjörn Wilhelmsen

BPM e SOA

Como já dizia o sábio: "Uma coisa é uma coisa. Outra coisa é outra coisa."

Fico imaginando quais foram as razões que levaram os dois temas a serem discutidos com tanta dependência um ao outro. Ou se quiser, com tal "nível de acoplamento". ;)

Talvez uma razão para isso é que as Suites de Produtos SOA de mercado possuem nativamente recursos também para BPM. Seja um motor de execução BPEL ("Business Process Execution Language"), monitoração de processos, ou qualquer outra funcionalidade específica. Aí a confusão já está pronta: como temos o mesmo produto sendo usado para os dois momentos, então um projeto SOA deve possuir, inerentemente, BPM.

SOA tem a ver com Serviços e Funcionalidades de Negócio. BPM ("Business Process Management") tem a ver com Processos de Negócios. Um nível de abstração acima dos Serviços. Um exemplo: em uma instituição financeira, é muito razoável imaginarmos "Análise de Crédito" como um dos seus Serviços de Negócio (a propósito, este tema é suficiente complexo para necessitarmos de conhecimentos específicos dos Analistas de Negócio para a sua elaboração). Agora, é fácil imaginar também que vários Processos de Negócios farão uso deste Serviço. Um exemplo de um processo de empréstimo bancário é exibido abaixo. Note que há referência não somente ao Serviço "Obtain Credit Score" como a diversos outros.


A questão é que os Processos de Negócio possuem uma complexidade específica e, por conta disso, deveriam ter o seu desenvolvimento conduzidos distintamente. Melhor seria um projeto próprio. Afinal, tipicamente, em relação aos Serviços de Negócio do projeto SOA, os Processos de Negócio possuem:

• Requerimentos diferentes.
• Modelagem, desenho, monitoração, implementação, execução diferentes.
• Tecnologias e produtos (eventualmente) diferentes.
• Usuários finais diferentes.
• Equipes de implementação (eventualmente) diferentes.
• Agendas e orçamentos diferentes

Por tudo isso, não vejo razão para termos, em um único projeto, SOA (com nível de complexidade não desprezível) e BPM (com complexidade igualmente importante). Se tomarmos a nossa estrutura de Arquitetura Orientada a Serviços, o ideal seria:

Custos e riscos, de ambos os projetos, dramaticamente reduzidos. Note que no meu "post" sobre a "estrutura", eu comentei que a Camada de Serviços, e só ela, é que é o resultado do projeto SOA. A Camada de Processos é resultado do projeto BPM. O analista JP Morgenthal, autor de "Enterprise Information Integration", escreveu em seu "blog" um artigo chamado "Keep Your SOA and BPM Initiatives Separate" que resume muito bem a questão. Em 21/10/2009, JP Morgental deu uma entrevista a respeito do tema.

De uma outra perspectiva, podemos considerar que uma Arquitetura Orientada a Serviços é construída para atender e ser consumida por uma infinidade de clientes. Processos de Negócio em um projeto BPM simplesmente são mais um dentre estes consumidores de Serviços de Negócio. BPM não é (e não deveria ser) a razão para a implementação de SOA. Claro que SOA ajudaria imensamente na materialização dos Processos de Negócio, mas é plenamente possível termos um projeto BPM sem a existência de SOA. Da mesma forma, empresas que implementaram SOA talvez nunca tenham a necessidade de projetos BPM.

Em outras palavras: o ciclo de vida de um Serviço de Negócio deveria ser independente do ciclo de vida dos Processos de Negócio. Incluindo especificações, desenhos, implementações, etc.
Em termos tecnológicos e Arquitetura de Software também há vantagens nesta abordagem. Decisões como produtos e ambientes operacionais para cada projeto podem ser tomadas isoladamente, reduzindo novamente os riscos.

Arquiteturas e Arquitetos

Não é somente no termo "Arquitetura" que há uma profusão de significados quase sempre conflitantes e muitas vezes incompletos dentro do contexto de SOA. O mesmo ocorre para os "Arquitetos". Afinal há diversos tipos de arquitetos: Hardware, Software, Aplicação, Rede, Integração, etc, etc, etc. Para complicar os termos "SOA" e "Arquiteto SOA" encontram-se em uma quantidade enorme de currículos técnicos atualmente. Enfim, a simples palavra "Arquiteto" não indica muita coisa...

Algumas distinções são possíveis, todavia:
Arquiteto de Aplicação: preocupado principalmente com aspectos "intra" aplicação. O popular assunto "aplicação em n-camadas" é o tema aqui. As famosas camadas de "apresentação", "negócio" e "acesso a dados" normalmente são lembradas. Uma ilustração abaixo:

Os conhecimentos esperados deste Arquiteto seriam, por exemplo:

• Tecnologias Java e Java, Enterprise Edition, JBI (Java Business Integration), etc.
• "Frameworks" bem conhecidos de mercado como Struts, JSF, Seam, Spring, Hibernate, etc, etc, etc.
• Web Services
• "Software Design Patterns".
• Na maior parte do tempo, suas preocupações são de ordem funcional apenas.

Arquiteto de Software: normalmente não é o responsável pela arquitetura de aplicações. Sua atuação é voltada a aspectos "inter" aplicações, sistemas e pacotes de mercado (CRMs, ERP, etc). Lida com componentes do ecossistema tecnológico do ambiente incluindo: Servidores de Aplicação, Servidores Web, Servidores de Diretorio (LDAP, MS Active Directory, etc), Portal, ESB, BPM, RDBMS, Mainframes, "Brokers" de Mensagens, Monitores de Transações, Autenticação e Autorização de Usuários, PKI ("Public Key Infrastructure"), etc, etc, etc. Um pequeno exemplo simplificado de uma arquitetura de software está a seguir. Note que neste diagrama há os dois níveis de arquitetura descritos: "inter" e "intra" componentes.


Sua visão é muito mais ampla do ambiente e com nível de detalhe suficiente para a elaboração e evolução de Arquitetura de Sofware. Por exemplo, o fato de uma aplicação ter sido escrita em Java e ter feito uso ou não de EJB ("Enterprise Java Beans") é totalmente irrelevante. Por outro lado, a implementação dos requerimentos não funcionais é de responsabilidade do Arquiteto de Software como Balanceamento de Carga para Servidores Web e Servidores de Aplicação, Alta Disponilidade e/ou Persistência de sessão HTTP, Replicação de Dados em Servidores LDAP, etc, etc, etc.
Claro que há especializações de Arquitetos de Software para aprofundamento de cada um dos componentes. O assunto pertinente a Gerenciamento de Banco de Dados, por exempo, é tão crítico que existem arquitetos que conhecem em detalhes as questões de desenho de banco de dados, otimizações, etc. E também é importante destacar que a "visão do todo" não é uma necessidade exclusiva de projetos SOA mas sim de qualquer ambiente ou projeto.

Arquiteto SOA: Apesar dos perfis de Arquitetos acima (e além deles outros mais) serem fundamentais e igualmente importantes em quaisquer projetos críticos, um novo perfil é preciso. Espera-se que um Arquiteto SOA lide com questões de análise de requerimentos de negócio assim como o desenho técnico de sofware. Em outras palavras, que o Arquiteto SOA possa servir, dentre outras coisas, de "ponte" entre os analistas de negócio e os Arquitetos de Software e de Aplicação. Não é uma boa idéia termos em uma mesa de reunião de um lado analistas de negócio preparados para discutirem Cadeia de Suprimentos em um projeto B2B ou "billing" convergente em um projeto de Telco e de outro desenvolvedores decidindo que Struts é mais eficiente do que JSF.

Os arquitetos SOA tipicamente, então, deveriam estar preparados para a análise, desenho e especificação da Camada de Serviços, estratégias "top-down", "meet in the middle", relacionamento e composição de serviços, etc.

Em resumo, Arquitetos de Software e de Aplicação são absolutamente necessários mas não suficientes. Além deles, e principalmente em projetos críticos como é o caso de SOA, devem existir outros perfis. Os conhecimentos devem ser expandidos para tornar a implementação de SOA realmente voltada às necessidades de negócio. O analista David Linthicum, autor de diversos livros, dentre eles "Cloud Computing and SOA Convergence in Your Enterprise: A Step-by-Step Guide", escreveu em seu "blog" um artigo sobre consultores SOA chamado "Most SOA Consultants Need a Lesson in SOA". Trata justamente sobre o dano que a difusa compreensão de termos como SOA e Arquitetura causa no montagem de uma equipe para um projeto como esse.

Processo de Definição de Serviços

JBOWS ("Just a Bunch of Web Services" ou em uma tradução livre: "Só um monte de Web Services"). Foi assim que o analista Joe McKendrick chamou pela primeira vez em 20/9/05 no famoso "post" do Werservices.Org, projetos SOA conduzidos sem qualquer formalismo, gerenciamento, testes específicos e tipicamente orientados a tecnologia. JBOWS Architecture. E não Service-Oriented Architecture... Vale a pena a leitura do artigo.

Uma das conclusões diretas, então, é a necessidade de um processo formal para desenvolvimento de serviços cobrindo desde análise de requerimentos de negócio, modelagem e desenho de serviços e o próprio desenvolvimento e entrega dos mesmos.

Um exemplo de processo de desenvolvimento de serviços está abaixo:

O SDP ("Service Definition Process") possui três "inputs":

• "Blueprints", padrões de especificações, "frameworks", etc já existentes na empresa que eventualmente serão adaptados pelo Serviço em definição;
• Requerimentos de negócio para o Serviço
• Requerimentos técnicos e situação atual do legado

A análise de "gap" é feita pelo SDP. Como "output" temos:

• SLAs ("Service Level Agreements") e OLAs ("Operational Level Agreements") para o Serviço
• Custos da implementação do Serviço envolvendo por exemplo, atualização do legado, software e/ou hardware adicionais, novos desenvolvimentos, etc
• Documentos de Arquitetura: especificações técnicas para a construção e entrega do Serviço

Mais uma vez este é somente um exemplo para condução do Processo de Definição de Serviços em um nível baixo de detalhe. Há diversos outros disponíveis e que podem ser tomados como base para um processo específico à empresa. O "site" SOA Methodology de Thomas Erl descreve processos sólidos e detalhados para Análise e Desenho de Serviços. O "site" baseia-se principalmente em dois de seus livros: Service-Oriented Architecture - Concepts, Technology, and Design (mais precisamente seus capítulos 10 a 16) e SOA - Principles of Service Design.

Ambos os livros descrevem duas aproximações para especificação e entrega de serviços: "Bottom-Up" e "Top-Down". O "Principles of Service Design" possui uma ilustração confrontando os seus pontos positivos e negativos.

Em "SOA - Concepts, Techonology, and Design" há o detalhamento das estratégias. Diria que a estratégia "Top-Down" (pág. 363) é "purista": a partir do recolhimento dos requerimentos de negócio, percorre o processo de identificação e especificação de serviços, com análise de "gap" do legado, impacto nos serviços existentes e finalmente a sua implementação.

Já a estratégia "Bottom-Up" (pág. 366) não seria, na verdade, uma estratégia real para atingir SOA. Se por um lado, lança mão de tecnologias como Web Services para encapsular funcionalidades de legado e assim maximizar o seu uso, por outro, é um convite à JBOWS Architecture.

Erl propõe ainda e estratégia "Agile" (pág. 370), ou "meet-in-the-middle", com a combinação de ambas as anteriores.

Riscos potenciais:

• "Top-Down":
• Precisa de patrocínio corporativo.
• Pode resultar somente em papel.
• Pouca visibilidade tecnológica pode incorrer em análises não completas de custos
• "Bottom-Up":
• Projeto SOA transformando-se em Projeto de Integração ou SOI
• Resolução de problemas tecnológicos somente, sem aderência às demandas de negócio
• JBOWS

Por fim, é importante notar que, independentemente da estratégia adotada, um dos pólos do processo é a Governança SOA, tema complexo que fica para outro "post".

Parques de diversão e autenticação e autorização de usuários

No "post" anterior, eu comentei sobre aspectos de autenticação de usuários. Gostaria de detalhar e mostrar um visão sistêmica do assunto.

Na Arquitetura de Serviços a questão de segurança é sempre um tópico importante. Este assunto é muito amplo, podendo envolver “firewall”, criptografia, etc. Em particular, a questão envolvendo autenticação e autorização de usuário em SOA é muito relevante e pode ser melhor compreendido com uma boa analogia.

Imagino que você já tenha tido a oportunidade de entrar em um daqueles parques de diversão onde compramos um passaporte, temos a mão carimbada, e passamos um dia inteiro em rodas gigantes, trens fantasmas e em quaisquer outros brinquedos disponíveis.

Pois bem, este parque possui um processo de autenticação e autorização de usuários bem definido. A autenticação acontece, uma única vez, no momento do carimbo da mão. Já a permissão para a sua entrada em algum brinquedo é o processo de autorização. Analisando a metáfora com um pouco mais de atenção, chegamos a algumas conclusões:

• O fato de você ter usado dinheiro, cheque ou cartão de crédito é totalmente irrelevante para o funcionário do parque que verifica se você pode entrar em um brinquedo.
• Os funcionários postados na entrada de cada brinquedo se preocupam somente em verificar se você tem um carimbo na mão para autorizá-lo a brincar.
• Eventualmente, o parque de diversão pode passar a aceitar outras formas de pagamento sem que, mais uma vez, os funcionários responsáveis pela sua entrada nos brinquedos tenham conhecimento disto.
• A remoção ou inclusão de novos brinquedos no parque não altera o processo de venda de passaportes.
• É possível ainda que o parque ofereça passaportes com preços mais baratos e carimbos diferentes que possibilitem a entrada em um conjunto reduzido de brinquedos.

Na realidade, há uma completo isolamento das questões envolvendo os brinquedos, de tal forma que, caso haja a alteração de um dos processos, não ocorra impacto em outros. Eles estão fracamente acoplados entre si. É saudável a observação deste modelo para a implementação de processos de autenticação e autorização de usuários em SOA ou quaisquer outros sistemas de computação. O desenvolvimento, evolução e correção de sistemas são muito mais produtivos quando temos servidores específicos para a execução de tarefas bem definidas.

Assim, utiliza-se, por exemplo, um servidor de aplicações ou um ESB para a implementação de regras de negócio e/ou integração entre os sistemas. Já o processo de autenticação e autorização de usuários é melhor realizado por servidores de identidade específicos. A implementação das regras de autenticação e autorização de usuários envolvendo LDAP, certificados digitais, RADIUS, Kerberos, biometria, ou qualquer outro tipo de credencial não é influenciada pelas regras de negócio, e vice-versa, posto que tais questões são resolvidas, implementadas e executadas de forma independente.

A visão lógica dos servidores do "post" anterior pode ser incrementada como exibido abaixo:


Vários benefícios são atingidos com uma estrutura como esta:

• Da mesma forma que o ESB relaciona-se com o legado de sistemas, o servidor de autenticação e autorização conecta-se com o relaciona-se o seu "legado" formado pelas bancos de dados e tecnologias empregadas para armazenar as informações de usuários como LDAP, MS Active Directory, etc.
• A lógica de autenticação permite a definição de uma inteligência específica e superior àquelas encontradas nos bancos de dados de usuários. Por exemplo: classes de usuários devem ser submetidas a processos de autenticação distintos entre si (usuários internos através do par usuário/senha, usuários externos através de certificados digitais, etc)
• Mais uma vez o conceito de "Integração Distribuída" de David Chappell é usada. Um ESB pode não ser (e normalmente não é) o melhor componente tecnológico para implementar as funcionalidades de autenticação de usuários. De uma outra perspectiva: um servidor de autenticação pode ser visto como um "ESB de autenticação de usuários", ou um perfil funcional de um ESB.
• Em termos de padrões e tecnologias empregadas, usualmente os servidores de autenticação são baseados em "tokens" e suportam SAML, WS-Security, WS-Trust, etc. Em um visão específica para Web Services, os servidores de autenticação cumprem o papel de STS ("Secure Token Services"). Isso fica para um outro "post".

Resumindo, o nosso parque de diversões implementa, na vida real, os conceitos fundamentais da computação distribuída e que devem ser perseguidos bravamente em projetos SOA: fatoração de problemas. Toma-se um problema de certa magnitude e o divide em outros de nível de complexidade mais baixa, otimizando os recursos disponíveis. O que se busca no mundo dos sistemas e em SOA é que a computação, como a arte, imite a vida.

SOA e a intrusão no legado

Não há como escapar... o processo de implementação de um serviço (também chamado de "Service Enablement") é um evento intrusivo no ecossistema das aplicações existentes de uma companhia. O nível de intrusão pode ser baixo ou alto mas dificilmente deixará de ocorrer.

É claro que os Serviços de Integração tipicamente terão nível de intrusão mais alto por se tratarem de serviços de baixo nível de abstração e com responsabilidades de resolução de problemas técnicos consideráveis.

Um exemplo parece que ajuda neste caso: autenticação de usuários. Independentemente de quais sejam os propósitos e objetivos do projeto SOA, todo consumidor dos serviços expostos (usuário final, Serviços de Negócio, BPM, aplicações externas à companhia, etc) deverá ser autenticado. A autenticação de usuários é, então, um serviço corporativo e, por conta disso, um excelente exemplo para estar na Camada de Serviços. Não se trata de um Serviço de Negócio, e sim, digamos, de um Serviço Utilitário, que será usado por aqueles mais cedo ou mais tarde.

Agora, se pensarmos um pouco na implementação de tal serviço, vamos observar que se trata de uma questão complexa e bastante intrusiva nos sistemas legados. Vejamos: a questão de autenticação de usuários é quase que universalmente implementada de forma repetida por cada aplicação isoladamente. Ou seja, cada aplicação, quando foi desenvolvida, implementou do seu modo esta funcionalidade, armazenando usuários em seus bancos de dados, lidando à sua maneira com interface com o usuário, etc. Em alguns casos, há o uso de tecnologias como servidores de diretório (LDAP, MS ActiveDirectory, etc) para o repositório de dados de usuários mas a lógica da autenticação ainda está presente na própria aplicação.


O desejável é que um Serviço de Autenticação de Usuários fosse utilizado horizontalmente por todas as aplicações. Ou, pensando ao contrário: as aplicações e os Serviços de Negócio deveriam delegar a autenticação de usuários a um Serviço Utilitário específico. Em outras palavras: é preciso que isolemos a funcionalidade de autenticação de usuários em um serviço para que possa ser reusada por quaisquer consumidores.

Em última análise, as aplicações e sistemas não deveriam possuir em seus domínios funcionais a capacidade de autenticação de usuário, posto que tal questão estaria consolidada em um serviço externo. Só que esta fatoração funcional não é barata. Não que não seja factível de ser implementada. Ela é. A questão é outra: o que fazemos com as aplicações já existentes e que possuem esta lógica fortemente acoplada às suas outras funções? Este é um exemplo de intrusão que um "Service Enablement" tem que considerar. Eventualmente a fatoração tem custo alto e talvez não seja possível (por exemplo, em pacotes de mercado onde não temos o controle do código). Técnicas de mapeamento de identidades talvez devam ser usadas, por exemplo.

Outro ponto importante: em implementação usando Web Services e WS-Security, um dos modelos mais usados para o mecanismo de autenticação é aquele baseado em "tokens SAML" ("Security Assertions Markup Language"). Uma mensagem SOAP deve incorporar tais "tokens" pois para, atingir o destinatário, atravessará vários nós intermediários. Mais um motivo para termos Serviços específicos para autenticação e, neste caso, validação e consumo de "tokens".

Outro exemplo de intrusão está relacionado aos sistemas "back-end" da empresa. O ERP é um deles. Sua implementação é custosa, com cronograma de médio a longo prazo. Usualmente o seu dimensionamento é feito para atender um número específico de usuários internos à companhia. A exposição de funcionalidades através de Serviços causa efeitos colaterais importantes: o aumento de requisições por parte de novas classes de usuários (parceiros, clientes, etc) leva a possíveis redimensionamentos do ambiente operacional do ERP. Aspectos novos de segurança devem ser implementados justamente para acomodar os novos tipos de clientes: mecanismos de autenticação aplicadas na intranet para usuários internos não são recomendados para os usuários externos.

Note que o impacto e a intrusão causados no sistema "back-end" não necessariamente são de ordem funcional mas diretamente nas Qualidades Sistêmicas que foram originalmente estabelecidas nele. Eu citei os aspectos de escalabilidade e segurança. Diversos outros também deverão ser revistos.

A conclusão é que a importância da análise de "gap" aumenta de forma considerável quando analisamos o eventual nível de intrusão de um serviço. As questões sobre autenticação de usuários e ERPs foram tomadas somente como exemplos. A mesma analise deve ocorrer nas diversas outras funcionalidades, independentemente do seu nível de abstração dentro da Camada de Serviço. Por conta disso, recomenda-se mais uma vez um processo formal para a elaboração e controle do ciclo de vida de um serviço.

SOA e o legado

Em um "post" anterior eu comentei que a Camada de Serviços, não somente pelo seu nome, era a mais importante e essencial para um projeto SOA. Isso se deve a dois principais fatores:
a) A definição dos serviços desta camada.
b) O "gap" tecnológico (funcional e não funcional) entre ela e a Camada de Recurso e Dados.
Enquanto a definição dos serviços necessita da participação intensa de analistas de negócio, a análise de "gap" normalmente é conduzida pelos arquitetos de tecnologia. Alguma coisa como: em um primeiro momento, os analistas de negócio são os principais responsáveis pelo recolhimento dos requerimentos de um serviços. Posteriormente, tais requerimentos são conduzidos pela equipe de tecnologia para a respectiva implementação. Neste ponto, uma das questões mais críticas é o "gap analysis" entre "o que se quer" (serviços) e "o que se tem" (legado).
A análise de "gap" deve ser considerado como ponto crucial na específicação e consequente implementação de um serviço. Infelizmente, é bastante comum verificar que tal análise não recebe a atenção e recursos necessários por parte da equipe de tecnologia que faz parte de um projeto SOA. Simplificações do assunto levam invarialmente a problemas críticos que necessariamente deverão ser corrigidos no futuro.
Poderiamos relatar algumas questões e problemas que nascem a partir de uma análise não completa do "gap":

• É comum ouvirmos que SOA adota muito mais a postura de "wrap and reuse" do que "rip and replace". Isto é, SOA deve tomar vantagens de capacidades já existentes da camada de sistemas legado em vez de reescreve-las. Contudo, é preciso não confundir um serviço como uma "webficação" de um legado. O fato de inserirmos uma "casca" Web Services em uma transação CICS, por exemplo, pode ser necessária mas absolutamente não será suficiente. Nunca é demais lembrar que um servíço deve ser responsável, além de questões funcionais, por requerimentos não funcionais. Diria que atender os requerimentos funcionais é muito mais simples que do implementar os não funcionais.
• A "webficação" tipicamente cria uma relação 1:1 com um aspecto funcional de um legado. O exemplo acima serve para isso. Tal relação é muito improvável: é bastante razoável imaginar que serviços dependerão de mais do que um legado para cumprir o seu papel funcional. A relação então seria 1:N. A definição de escopo funcional para cada legado não possui uma resposta simples. Eventualmente, encontramos duplicidade funcional dentre os sistemas do legado.
• Como se não fosse suficiente, dentre os requerimentos de um serviços encontraríamos por exemplo, disponibilidade 24x7, escalabilidade, etc. Igualmente fácil de imaginar que há sistemas do legado que não estão em condição de atender esses requerimentos. É insuficiente termos uma camada de ESBs suprindo tais demandas se um legado não acompanhá-la. A solução não é trivial: deveriamos evoluir o legado ou reescreve-lo? Qual o custo de cada decisão? Não há uma resposta única para todas essas perguntas.
• Em uma relação 1:N entre um serviço e os sistemas legado, é possível que tenhamos uma aplicação que atendam os requerimentos não funcionais e outras que não. Mais uma vez a resposta não é direta.

Por outro lado, processos de "webficação" de legado com relacionamento 1:1, podem ser (e normalmente são), o primeiro passo da implementação da camada de serviços em uma aproximação "bottom-up". Em outras palavras, a "webficação" de um aspecto funcional de um legado, acarreta na implementação do nível mais baixo de abstração da Camada de Serviços. Outros serviços (Integração, Negócio, etc) certamente, tirarão proveito da "webficação".
Outra questões importantes:

• Um projeto SOA deve implementar níveis de abstrações novos sobre a camada do legado. Apesar de tentar enfatizar o "wrap and reuse", é a melhor ocasião para descartar sistemas obsoletos que, historicamente, não atendem os requerimentos de seus usuários finais.
• Contudo, um projeto SOA não pode ter como principal responsabilidade a "modernização" do legado. Melhor seria se a modernização fosse considerada um "projeto derivado" ou um "subprojeto" dentro de um espectro maior. Em outras palavras, um projeto SOA não deve ser encarado primordialmente como a correção de problemas crônicos de aplicações já existentes.

Como conclusão direta: um processo formal para conduzir o ciclo de vida de um serviço se faz necessário.

SOA e SOI

No "post" anterior eu comentei sobre a hierarquia de serviços envolvendo Serviços de Negócio e Serviços de Integração. Nesta estrutura, que é a essência de SOA, há outras categorias de serviços como Serviços Externos e Serviços Utilitários. Contudo, mais uma vez para a implementação de SOA na sua plenitude, é importante que o projeto atinja o nível de abstração dos Serviços de Negócio.

Este objetivo só poderá ser atingida através de um esforço corporativo que envolve, inexoravelmente, unidades de negócio. Desnecessário dizer que tal movimento não é simples tampouco barato. É muito comum projetos SOA serem conduzidos pelos departamentos de tecnologias das empresas onde não há visibilidade ampla e profunda dos requerimentos de negócio, processos, etc das unidades e linhas de negócio da empresa.

Por conta disso, projetos SOA usualmente transformam-se em projetos SOI ou "Service Oriented Integration". Apesar de semelhantes as siglas não têm muito em comum: enquanto SOA é uma arquitetura de serviços de negócio, SOI é sobre integração de sistemas. Este termo é normalmente usado para denotar projetos de integração de sistemas que usam os mesmos protocolos usados na implementação de SOA (por exemplo, Web Services e Enterprise Service Bus (ESB)). SOI cumpre um papel similar à infraestrutura EAI ("Enterprise Application Integration") que projetos no passado lançavam mão. A diferença é o uso de tecnologias mais "modernas".

Dentro da hierarquia de serviços, teríamos uma linha sutil que distinguiria os serviços de alto nível de abstração (pertencentes ao projeto SOA) dos serviços de baixo nível (de responsabilidade do projeto SOI). Abaixo uma figura ilustrativa:

Várias fontes descrevem SOI em detalhes. Dentre elas destaco o livro "Service-Oriented Architecture - A Field Guide to Integrating XML and Web Services", primeiro de uma coleção importante de Thomas Erl e outros. Apesar de, durante a leitura, termos a impressão que SOA é implementável somente com a pilha de tecnologias Web Services, há referências que ressalvam que WS-* não são a única opção para isso.

O emprego das mesmas tecnologias para a implementação de ambos os projetos leva a mais uma confusão ou engano: projetos SOI são chamados de SOA. Entretanto, por outro lado, um projeto SOI pode ser considerado como um "entry point" para o projeto SOA que compreenderá outras diversas dimensões e requerimentos. Há várias vantagens para isso:

• Um projeto SOI é tipicamente conduzido pela equipe de TI da companhia posto que o envolvimento de analistas de negócio é muito improvável. As questões a serem resolvidas normalmente têm considerações puramente técnicas.
• O projeto SOI pode ser um "laboratório" importante para especialização sobre as tecnologias WS-*, ESB, etc. Afinal, em tese, essas mesmas tecnologias seriam usadas na implementação dos Serviços de Negócio.
• Liberdade de escolha de produtos: a infraestrutura usada para a implementação de Serviços de Integracão não é necessariamente a mesma usada para os Serviços de Negócio.
• A implementação dos Serviços de Integração pode ocorrer distintamente à dos Serviços de Negócio, diminuindo os riscos.
• As infraestruturas separadas permitem que o processo de evolução dos serviços seja altamente escalável.

Uma visão da infraestrutura de software poderia ser alguma coisa como:

Uma das principais diferenças entre os famosos ESBs e EAI é aquilo que David Chappell, Vice Presidente da Oracle para SOA, definiu no seu já classico "Enterprise Service Bus" de 2004, como "Distributed Integration" ou Integração Distribuída. O grande benefício dos ESBs é a capacidade de distribuir os seus requerimentos de integração. Instâncias isoladas de ESB são responsáveis por uma coleção específica de processos de integração. A figura acima mostra isso: o ESB de nível mais baixo de abstração é responsável por questões totalmente particulares de integração e distintas ao ESB de mais algo nível. Em termos de implantação os ESB podem ser (e normalmente são) de fornecedores diferentes e rodam em ambientes operacionais (Sistemas Operacionais, Hardware, etc) também específicos. Claro que, de acordo com a demanda, novas instâncias de ESB podem ser adicionadas em cada uma dessas camadas para novamente dividirmos responsabilidades de integração.

Como conclusão, a implementação de toda e qualquer demanda de integração em um único ESB, geralmente, não é um bom negócio. Em um ambiente crítico haverá um diversidade muito grande de classes de softwares e, para cada um deles, uma coleção de instâncias de ESBs. Uma aproximação como essa é antes de mais nada escalável e consequentemente apresenta menos riscos em todos os sentidos: desenvolvimento, gerenciamento, manutenção, produção, homologação, etc.

SOA e Web Services não são sinônimos

Um dos maiores enganos em torno de SOA é o seu tratamento como sinônimo para as tecnologias e padrões Web Services (leia-se SOAP, WSDL, UDDI, WS-*, etc).

SOA trata de arquitetura e desenho de serviços de negócio. Web Services são tipicamente a primeira escolha tecnólogica para a implementação de tais serviços. Além deles, há uma infinidade de opções como CORBA, RMI, DCOM, DCE, sockets, REST, etc. Algumas não são mais usadas mas o ponto é que a escolha tecnológica para a implementação de SOA não é uma das responsabilidades em si de um projeto como esse.

Várias analogias existem: Modelos Entidade-Relacionamento - MER de Peter Chen (ou "Entity-Relationship Models" - ERM em Inglês) para representação lógica de dados e informações não definem qual a tecnologia de banco de dados será aplicada para a implementação. Usualmente, Gerenciadores de Bancos de Dados Relacionais são empregados por permitirem a implementação mais direta da lógica definida nos modelos. Entretanto quaisquer outras tecnologias poderiam ser usadas como Hierárquica, Rede, arquivos, XML, etc, etc.

O mesmo acontece com a especificação de programas. Um algoritmo não pressupõe o uso de nenhuma linguagem para a sua implantação. Seja ela Java, C#, Pascal, Cobol, etc.

Então, em resumo: SOA pode ser implementado sem Web Services. Web Services podem ser usados em projetos que não sejam de SOA.

Outro ponto a considerar é o seguinte: o uso de Java, C++ ou qualquer outra linguagem de programação não resulta em programas "orientados a objetos". É preciso que tenhamos bons desenhos de programas orientados a objetos. Mais uma vez a analogia procede: o simples uso de Web Services não implica necessariamente em Arquitetura Orientadas a Serviços. Muitas arquiteturas serão construídas com Web Services e não serão "orientadas a serviços" pelo mero fato de terem sido mal desenhadas.

O uso (e consequente confusão) de Web Services para a construção de "serviços" talvez tenha como base a maior facilidade, flexibilidade, etc proporcinadas por esta tecnologia em relação a outras. Afinal o "S" de SOAP quer dizer "simple"... Todavia os atributos de "simples" e "fáceis" para os Web Services têm sido questionados. Richard Monson-Haefel, em 22 de Abril de 2006, postou em seu "blog" o já classico "Dave Podnar’s 5 Stages of Dealing with Web Services". Reproduzo os cinco estágios no original em Inglês:

1. Denial - It’s Simple Object Access Protocol, right?
2. Over Involvement - OK, I’ll read the SOAP, WSDL, WS-I BP, JAX-RPC, SAAJ, JAX-P,… specs. next, I’ll check the Wiki and finally follow an example showing service and client sides.
3. Anger - I can’t believe those #$%&*@s made it so difficult!
4. Guilt - Everyone is using Web Services, it must be me, I must be missing something.
5. Acceptance - It is what it is, Web Services aren’t simple or easy.

Tecnologias como REST prometem "simplificar" de verdade o desenvolvimento. Isso fica prá outro "post"...
Outra típica confusão instaurada está relacionada ao Modelo de Implementação de Serviços baseado em "find-bind-execute". Abaixo temos uma figura ilustrativa.

Funciona mais ou menos assim:

1. Provedores registram seus serviços em um repositório público.
2. Consumidores procuram no repositório serviços que satisfaçam seus requerimentos.
3. Os repositórios fornecem aos consumidores o “contrato” para o uso do serviço.
4. Consumidores usam o “contrato” para interagir com o provedor.

O engano acontece imaginando que este modelo seja particular aos Web Services. Na realidade, é o contrário: os Web Services são mais uma tecnologia que também segue este paradigma. CORBA, por exemplo, baseia-se neste mesmo princípio. Em última análise, o conceito de "contrato" sendo exposto a consumidores permeia quase todas as tecnologias existentes. Um arquivo ".h" na linguagem C é um contrato sobre as funções expostas por uma biblioteca. A "novidade" em Web Services talvez seja a publicação dos contratos em servidores específicos.

Enfim, enfatizando, SOA não é sobre tecnologia. É uma arquitetura. Anne Thomas Manes, diretora de pesquisa do Burton Group escreveu em 2007 um "post" em seu "blog" chamado "When Technology Matters in SOA" que resume muito bem a questão.

SOA, acoplamento e coesão

Um das principais qualidades de um serviço de negócio deve ser o baixo acoplamento em relação a outros serviços. Este é um das mais importante características de SOA e que deve ser buscada na especificação e desenvolvimento dos serviços de negócio.

Apesar de parecerem novos, na realidade, os conceitos de acoplamento ("coupling") e coesão ("cohesion") aplicados na Ciência da Computação são bastante antigos. Os primeiros a formalizarem tais conceitos foram Edward Yourdon e Larry Constantine em seu clássico e seminal livro "Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design" de 1977.

No glossário de termos do livro Yourdon e Constantine conceituam coesão ("cohesion") como: "The degree of functional relatedness of processing elements within a single module", ou o grau de conexão funcional de elementos de processamento no interior de um módulo. Já acoplamento ("coupling") é definido como segue: "a measure of the strength of interconnection between one module and another" ou uma medida da força de interconexão entre um módulo e outro.

As noções de acoplamento e coesão estão intimamente relacionadas. Um módulo com alto grau de coesão possui um baixo grau de acoplamento e vice-versa. Um dos indicativos de bom desenho de um programa é a alta coesão de suas rotinas e o baixo acoplamento entre as rotinas. Programas com estas características tendem a ter um menor custo para manutenção, evolução, etc. Nos capítulos 6 e 7, Constantine e Yourdon descrevem métricas para a classificação dos graus de acoplamento e coesão.

Estes conceitos são aplicáveis universalmente em quaisquer ambientes computacionais. Uma classe de um programa orientado a objetos é justamente um pedaço de código com alto nível de coesão e baixo nível de acoplamento em relação a outras classes.

Em SOA, a diferença está, mais uma vez, no nível de abstração onde tais conceitos são usados. Enquanto o contexto de discussão de Yourdon e Constantine são subrotinas e módulos de um programa, SOA emprega estas mesmas noções entre sistemas. É claro que, se baixo acoplamento e alta coesão são objetivos a serem perseguidos em programas, em SOA esta importância aumenta sobremaneira em relação aos Serviços de Negócio. Basta lembrar que em SOA o ponto de discussão não é mais em relação a subrotinas, módulos, componentes ou classes mas sim entre sistemas corporativos de uma companhia. Alguns Serviços de Negócio se apoiarão no sistema ERP, outros terão como base aplicações em "mainframe", etc.

Como conclusão, não é exagero dizer que a implementação de Arquitetura de Serviços consiste no conjunto de todas as melhores práticas e conceitos para o desenvolvimento de aplicações acumulados nos últimos 40 anos. Coesão e acoplamento são somente alguns destes conceitos.

Afinal, o que é um Serviço?

Acredito que a extrema diversidade dos conceitos sobre SOA advém, dentre várias razões, de termos muito genéricos que as palavras que formam a sigla contém.
Arquitetura Orientada a Serviços. As palavras "Arquitetura" e "Serviço" são muito genéricas. Podem ser usadas para denotar uma infinidade de coisas.
Eu explorei a semântica de "Arquitetura" em SOA anteriormente. Mas o que são os "Servíços" de SOA?
Acho que uma boa definição é: "Um serviço responde por requisições através de interfaces bem definidas, padronizadas e publicadas." Uma outra: "É um componente auto-contido que implementa funcionalidades de negócio com um conjunto extenso de aspectos não funcionais".
Um diagrama exibe melhor a questão:

Como comentado anteriormente, a especificação lógica (ou requerimento) funcional de um serviço de negócio deve ser conduzida por analistas de negócios. São eles que conhecem mais profunda e amplamente as necessidades da empresa e são deles que partem as demandas por novos serviços.
Por outro lado, mesmo tendo a sua complexidade, a funcionalidade de um serviço não é nada comparada com os requerimentos não funcionais do mesmo. Alguns deles:

• Performance: garantir o número de mensagens processadas em um período de tempo
• Tempo de vida
• Bilhetagem sobre o uso
• Monitoração: Métricas, Relatórios, etc.
  
• Segurança: autenticação e autorização
• Tempo de recuperação em caso de falha
• “Compliance” e regulamentações

Não é difícil encontrar situações onde estes aspectos não funcionais são inseridos em termos contratuais para a comercialização de serviços de negócio. Portanto, a observação destas questões não deve ser vista como um "luxo" mas sim como requerimentos reais do negócio.
A coleção destas especificações funcionais e não funcionais é chamada de metadados dos serviços. Um "contrato" onde são definidos como o serviço deveria funcionar e como o serviço deveria se comportar.
Um parêntese para a tecnologia hoje disponível para os "contratos": o padrão WSDL ("Web Services Description Language") é comumente invocado. Entretanto é insuficiente para declararmos todos os aspectos do contrato. Normalmente há o uso em conjunto do WSDL com XML Schema para definição de formato de mensagens e WS-Policy para definição de capacidades do serviços.