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.