Codemountain, Paulo Suzart's Blog

Archive for the ‘soa’ Category

(E)AI x SOA

with 2 comments

Eu bem que gostaria de ter estado de férias todo esse tempo pra justificar minha falta de posts. Mas isso não é verdade. Estou de volta desde janeiro!

Durante as férias tive o prazer de ler sobre a Teoria das Cordas durante visita à Salvador – BA e Medellín – CO. Não, não escreverei nada sobre o tema. Pode se tranquilizar. Então vamos lá…

SOA não é mais novidade, não é mais utópico. A bem da verdade resolve uma série de questões que eu me indagava há tempos. Pra mim soa mesmo como uma evolução natural de TI, ou talvez como meio de trasformar em realidade a visão de TI como diferencial competitivo.

Mas antes de SOA alguns arriscaram EAI, principalmente o A e o I sem o E. O resultado da falta do E gera, e gerou, cenários onde há uma preocupação em prover conexões entre sistemas e não funções de negócio. Algumas das consequencias são:

  • Esforço repetido de integração
  • Conexões point-point apenas mudaram de lugar
  • Alto acoplamento entre aplicações, legados e soluções proprietárias
  • Reuso baixo ou nulo
  • Lógica de negócio replicada
  • Lógica de acesso replicada entre integrações
  • Número excessivo de serviços de integração
  • Alto custo de manutenção
  • Difícil justificativa nos investimentos de TI

Nestes cenários a falta de foco no negócio e sim em integrar aplicações leva a um entrave na evolução de TI para um modelo SOA.

Case: Obtendo informações de um cliente

Para ilustrar melhor a situação, considere um case onde duas aplicações necessitam obter dados  de Cliente. Ao longo do tempo, é natural que haja mais de uma fonte de dados de cliente. É comum também que aplicações distintas operem sobre tipos de clientes diferentes, pessoa física e pessoa jurídica, clientes com contratos diferentes, são exemplos. Num cenário (E)AI, seriam construídas duas integrações para atender cada uma das requisições das aplicações.

A primeira integração que atende a aplicação que opera com clientes, digamos, pessoa física, necessita integrar uma base de dados de uma aplicação que cadastra apenas endereços, acessar uma aplicação legada provinda da aquisição de uma companhia menor, conexão com o SAP e acessar o CRM via Webservices para obter dados mais atualizados de clientes.

Já a segunda integração para pessoas física, demanda acesso apenas ao SAP e por limitações no webservice do CRM, um acesso direto à base deste sistema. O ambiente deve ficar como no diagrama a seguir.

A falta de padronização no acesso e talvez alguma lógica de checkagem  ou  limpeza dos dados do cliente traz um grande risco para a empresa que está sempre exposta a novas conexões, novo ciclo de integração,  testes, etc.

Pensemos agora em SOA. Relembre que SOA prima por serviços como meio de entregar funções corporativas. Relembre também do post “ESB? Até que ponto?”  e vai ver que falei sobre a divisão, ou melhor, categorização de serviços por camada. Que nada mais é o que Erl[01] chama de Services Layer. Uma abordagem SOA incorreta poderia levar ao mesmo engano do cenário anterior, com lógica de acesso, tratamento, validação espalhada por vários serviços. Mas uma visão em camadas vai ajudar a especializar cada serviço de acordo com o tipo tarefa que ele executa.

Não só isso, observe bem que um serviço não só precisa ser especializado no que faz, mas também deve ser o único a executar aquela tarefa, ou funcionalidade específica[02]. Uma das atividades que o negócio precisa executar para atender a algum processo de negócio ou mesmo atender uma linha de negócio (LOB – Line-of-Business) é: Obter Informações de Cliente, e este será o nosso serviço.

Num cenário SOA, notamos a presença de um Serviço de Dados (Data Service) que concentra todo o conhecimento na obtenção e provisionamento de informações de cliente. Vejamos o diagrama.

Note que até modifiquei o diagrama para colocar todos os legados e aplicações existentes à direita. Os serviços de conectividade, muitas vezes chamados de adapters, são conhecedores da interface específica das aplicações que proveem dados de cliente, mas expõe para outras aplicações e serviços SOA uma interface padronizada pelo time de arquitetura SOA.

O serviço de dados agora é a “fonte de ouro”  da entidade cliente. Toda lógica de extração, segurança, auditoria, data redaction e transformação dos dados provindos de diversas fontes fica a cargo deste serviço. Isso vai permitir que outras aplicações e serviços tirem proveito desta fonte existente. As vantagens são:

  • Foco em funcionalidade, não conexão
  • Baixo acoplamento. Clientes do serviço estão acoplados apenas a seu contrato
  • Solução orientada ao negócio e não a aplicações existentes
  • Alto reuso. Reduzindo o custo de novas aplicações
  • Ponto único de manutenção e adição de novas funcionalidades
  • Redução no custo de integração. Aplicações fontes de dados de cliente já integradas.
  • Redução de risco ao negócio. Depois de construído e testado uma vez, o serviço reusado é mais confiável que a criação de um novo

Estas são vantagens do SOA em si, aplicadas a este case.

O que fazer para chegar lá?

Não é tão fácil, rápido e barato chegar nesse nível que até parece óbvio. É tema para uma consultoria responder.

Existem vários artigos e pesquisas que tratam dos motivos do fracasso na adoção SOA. Você precisa conhecer estes fatores de fracasso, evitá-los e se concentrar em montar uma Arquitetura bem definida, padronização, definir políticas e processos, criar estruturas organizacionais focadas em SOA bem como definir seus papéis e responsabilidades.

Algo que deve ser observado é que um serviço é concebido como um software ou aplicação qualquer, o que demanda engenharia correta.

Além do técnico, ferramental, infraestrutura e ter uma visão clara de onde se quer chegar, é preciso ter um patrocínio forte do negócio. SOA veio transformar o modo com que TI é entregue ao negócio, ou seja, é preciso ter apoio dos executivos para enfrentar as barreiras encontradas como custos iniciais, educação e treinamento, mudanças culturais, consultoria, dentre outros.

Espero ter contribuido com a visão SOA, mas ratifico que o melhor que você pode fazer é estudar, e muito.

Fontes:

[01] SOA Design Patterns by Thomas Erl, Pattern Service Layers, p. 143.

[02] SOA Design Patterns by Thomas Erl, Pattern Logic Centralization, p. 136.

Anúncios

Written by paulosuzart

março 14, 2010 at 1:33 pm

Publicado em soa

Tagged with

ESB? Até que ponto?

with one comment

Olá a todos. Desde que fiz a primeira fase da Certificação SOA Architect da BEA em 2008, não escrevi nada sobre SOA aqui no blog.
Infelizmente não vou começar falando do Paradigma de design Service-Orientation [01], tão pouco como ela se Encaixa em Service-Oriented Computing [01] até chegar em SOA de fato. Dois termos, alias, completamente desconhecidos por quem imagina que trabalha com SOA.

Não vai dar pra postar nada introdutório neste artigo, tão pouco tratar SOA por completo. Mas vou falar de um dos enganos mais comuns quando se trata de SOA dentre  muitos  que já presenciei, a saber:

“Um Webservice é um seviço”, “Ter um ESB é ter SOA”, “Ter Webservices é fazer SOA”, “ESB deve ser o responsável por fazer Service Orchestration“, “Meu sistema X ‘chama’ o BUS que ‘chama’ o sistema Y”. Bom, dá pra fazer uma lista vasta aqui, mas paremos por aqui.

E o engano que trato neste post é: “Todo e qualquer serviço deve ser exposto no barramento de serviço ESB”. Mas por quê? Existem alguns outros blogs que já falaram sobre quando usar ou não um ESB adotando uma abordagem diferente desta aqui.

Primeiro vamos ao Papa Thomas Erl [01] para a definição de ESB:

“An enterprise service bus represents an environment designed to foster sophisticated interconectivity between services. It estabilishes an intermediate layer of processing that can help overcome problems associated with reliability, scalability, and communications disparity“.

É um bonto de partida. Podemos agregar outras e outras definições e ter uma definição mais completa ou à contento.

Um pouco da minha humilde vivência em SOA concorda com isso e diz que o ESB é puramente um mediador e deve ser visto como um componente da infra estrutura de serviços de uma corporação, não como o “ambiente soa” (outro engano).  Um Service BUS deve prover algumas características como capacidade de roteamento de mensagem, transformação de mensagem, tradução de protocolos, virtualizaçao de serviço, balanceamento de carga, message throttling, dentre outros.

Mas aí o engano que diz que um webservice é um serviço aparece por aqui. E essa é uma das maiores falácias que a humanidade já conheceu, tal como 2+2 = 5.

Um serviço dentro do contexto SOA, segundo a Wikipedia é: “… the term service refers to a set of related software functionality, together with the policies that should control their usage.” [02]

Logo, um serviço é acessível por sua interface [03] que expõe sua implementação*, que por sua vez obedece a um contrato bem definido para o serviço (funcionalidade). O contrato é o descritor, comumente não técnico, das capabilidades [01]  de um serviço. Estas capacidades por sua vez foram derivadas de alguma necessidade do negócio, ou seja, um Serviço existe pois uma necessidade (requerimento funcional) corporativa existe. Vamos parar por aqui, não vamos chegar ao ponto de onde uma necessidade corporativa (Business Requirement) é derivada. Por tanto temos (de forma resumida, e me perdõem meus amigos conhecedores da ESEF pela simplicidade aqui) os seguintes elementos que compõe um serviço:

Agora que chegamos a um ponto onde sabemos o que é um serviço e (mais ou menos) de onde ele brotou, voltemos aos Requisitos Funcionais Corporativos, ou seja, funções desenpenhadas pela corporação.

Uma funcionalidade corporativa pode não ser justificável como um Serviço compartilhado, que embora obedeça a definição de um serviço (Acima), o seu uso deve ocorrer apenas no escopo de uma aplicação. Quando isso acontece, diz-se que um serviço X é pertencente ao escopo de Aplicação pois é acessível somente por esta. Frequentemente os demais escopos são: Aplicação, Inter-departamental, Empresarial e público. Escopo está diretamente ligado a que tipo de consumidor o serviço atende.

STOP! Aqui temos uma boa razão  para não expor um serviço na infraestrutura SOA corporativa da empresa: O serviço tem um escopo tão reduzido (De aplicação) que se restringe a atender uma única aplicação. (escrevi o post basicamente pra mostrar isso, outras razões para não expor um serviço em um ESB vem de bom senso e prática, além de depender do cenário em questão).

Seguindo a idéia de classificar um serviço quanto ao seu uso, temos uma segunda forma de classificação, comumente chamada de categorização, onde um serviço pertence a uma categoria, ou camada, dada sua capabilidade. Ou seja, serviços capazes de acessar uma função de um sistema legado e expor tal para o ambiente SOA (dentro de algum escopo acima) como ela é, é comumenta categorizado (ou reside na camada de) serviço de conectividade.

Tal categoria pertence a um conjunto mairo de categorias, ou camadas, que facilitam a abstração e auxiliam nas decisões de design. Outra camadas, não menos importante são:

  • Serviços de Dados – Requisitos Corporativos frequentemente tratam de entidades corporativas a exemplo de Cliente, Contrato, Endereço, etc. Serviços que provêem acesso unificado, bem como uma visão única entre os diversos formatos de diversas fontes em uma corporação, residem nesta camada.
  • Serviços de Negócio – São comumente subdivididos em serviços que executam atividades corporativas atômicas (ex: validar cartão de crédito) e serviços de granularidade mais espessa, também chamados de processos de negócio (ex: Processar pedido em e-commerces)
  • Serviços de Apresentação – São serviços que permitem a reutilização de uma interface com o usuário (ex: portlets e mash-ups.
  • Serviços utilitários – São serviços que não estão associados a um contexto específico dentro do negócio (ex: Serviços de Notificação).

De fato, dada uma combinação Categoria x Escopo, tem-se uma série de boas práticas aplicáveis aqui. E considerando um serviço de acesso a dados que atende exclusivamente a uma aplicação, não há a necessidade de mediação pelo ESB, ou ainda, não há necessidade de que este serviço resida na infraestrutura da companhia.

Numa abordagem simplista, temos a distribuição de camadas/categorias de serviços como exemplifiquei ano passado aqui [04]. Pra ficar mais coerente com este post e a minha modesta evolução em SOA no último ano, considere a camada vertical vermelha como a camada de serviços utilitários. Ah! Vamos imaginar uma última camada abaixo da camada de serviços de dados, de acesso ou conectividade.

O bom senso ajuda muito, mas ter noção de onde um serviço nasce, é tão importante quanto isso. Decidir cegamente se um serviço, e sua interface física (WSDL em caso de uso de webservices) deve residir no barramento de serviços é um equívoco. Definir nomes, tipos, escopos, quantidade e relacionamento entre serviços sem uma justificativa é algo que leva ao erro e uma frustração no programa SOA do cliente. E quando isso acontece, todos nós que acreditamos em SOA, pagamos por isso. Agindo assim, fazemos SOA perder credibilidade e estar fadado ao fracasso.

Toda essa história de Requisito Funcional, Serviços e seu componentes, Escopo, Camada de serviços vêm de uma metodologia, de uma engenharia de serviço. SOA também precisa de uma metodologia, e governança. Por favor, nada de empirismo 😉

ESB faz parte da infraestrutura SOA e deve ser tratado como tal. E considerando as novas tendências e o uso de Composite Applications baseadas em SCA, teremos uma ajuda para colocarmos o ESB em seu devido lugar. Ou então SCA vai terminar de confundir mais algumas pessoas que imaginam fazer SOA.

*existem outras definições para os componentes de um serviço e como eles se relacionam.

Referências:

[01] SOA Design Patterns by Thomas Erl

[02] SOA in Practice: The Art of Distributed System Design (Theory in Practice) by Nicolai M. Josuttis

[03] Service (systems architecture) from Wikipedia

[04] Rasea e SOA – Parte I by Paulo Suzart

Written by paulosuzart

agosto 26, 2009 at 12:22 am

Publicado em soa

Um projeto Open Source

leave a comment »

Desde o final de 2007 tenho focado meu trabalho em SOA. Após atuar em um projetos cuja abordagem era SOA, e ser um consumidor de serviços e montador de composed applications, passei pro outro lado do time e nos últimos 6 meses tenho atuado no lado arquitetural da coisa.

Com o passar do tempo (estes pobres 6 meses, embora intensos) vamos enxergando as necessidades que uma abordagem SOA demanda de TI. Passando pela padronização assegurada por uma equipe de excelência SOA, a implantação de um barramento de serviços, integração entre diversas aplicações, estudo de muitos padrões, chegamos a um quesito que sempre nos acompanhou nosso dia-a-dia e, confesso, que muitas vezes ignorado: Segurança.

A oportunidade de me aprofundar no assunto surgiu da tese de mestrado de um amigo, Cleverson Sacramento, que no final acabou virando um projeto opensource publicado no sourceforge.net, o Rasea. O site do projeto no SF é rasea.sourceforge.net.

Rasea blogA ideia do projeto está muito bem descrita no blog, e convido você a fazer uma visita ao blog e ao site do projeto. Reumidamente, a ideia é permitir o desenvolvimento de aplicações sem se preocupar com segurança/autorização, colocando estes aspectos onde devem estar, na infraestrutura de software.

Como produto final, devemos fornecer uma ferramenta de gestão de usuários, roles e permissões a recursos corporativos. O projeto deve entregar uma interface de gerenciamento, um conjunto de serviços e uma quantidade de agentes para diversas tecnologias bem conhecidas.

Por hora estou me concentrando na elaboração dos serviços disponibilizados pela ferramenta. E após a primeira entrega, pretendo focar na padronização da ferramenta para especificações Oasis (SAML e XACML).

O objetivo a partir da segunda entrega é tornar o Rasea, naquele momento com algum secto de usuários, compatível com os padrões de mercado, podendo então competir com grandes ferramentas pagas como o Aqualogic Enterprise Security,   ou mesmo outras ferramentas open source como o Enterprise Sign on Engine.

Aguardem novidades!

Written by paulosuzart

janeiro 5, 2009 at 5:45 pm

Publicado em Java, security, soa

Tagged with ,