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.