Simplificando a Arquitetura Orientada a Serviços
Service Technology Magazine
A antiga “SOA Magazine” agora é “Service Technology Magazine“. Segundo o autor, Thomas Erl, a mudança reflete a necessidade de expandir o conceito de Serviços que, de fato, não pode ficar restrito à discussões em torno da Arquitetura Orientada a Serviços (SOA, Service-oriented Architecture).
Em Outubro/2009 eu fiz uma apresentação para uma grande empresa de desenvolvimento de software. O tema era Como Gerar Valor com SOA ou Como Vender SOA na Crise.
Fiz um resumo desta apresentação e disponibilizei no SlideShare.net para visualização e/ou download. São apenas 10 slides de conteúdo (12 no total).
Se você encontrar seu (sua) chefe no elevador, mostre apenas os slides 4 e 5 (“Como Vender SOA na Crise“). Se ele(a) ficar convencido, peça uma reunião de 30 minutos e apresente o restante.
Diferente do que se recomenda para as apresentações, não inclui muitos gráficos (perdoem-me pelo excesso de textos nos slides).
O objetivo desta apresentação é compartilhar com todos vocês algumas dicas de como é possível “vender” SOA. Estas notas são resultado da experiência prática de tentar mostrar o valor de SOA e como ela pode ajudar no nosso desafio diário de construir soluções de software e integrá-las.
Este post traz duas boas notícias para o mundo da “Cloud Computing”. A primeira é o anúncio da empresa de soluções SOA open-source, WSo2, já citada várias vezes neste blog, e a outra vem da Microsoft e de sua plataforma de Cloud, Azure.
Para quem não conhece, a WSo2 é uma companhia que desenvolve soluções para a arquitetura orientada a serviços (SOA) no modelo open-source. Tem escritório no longíquo Sri Lanka (terra natal do seu fundador) e nos EUA e Europa.
A plataforma de “Cloud Computing” que eles lançaram permite que as empresas criem sua própria “nuvem”, as chamadas “Private Clouds“, com um custo (direto) de software bastante reduzido.
A solução de Governance as a Service é um dos serviços já disponíveis para serem utilizados (veja restrições abaixo).
A idéia é que sua empresa possa fazer o setup de uma solução de Governança para o ambiente SOA (SOA Governance Registry) diretamente na “nuvem” da WSo2.
Veja o que é possível implementar:
- Armazenar services, WSDLs, Schemas e policies, facilitando a descoberta (discovery) dos serviços e suas restrições
- Gerenciar o ciclo de vida dos serviços
- Manter múltiplas versões dos serviços
- Acompanhar as dependências e associações entre os WSDLs e os Schemas
- Dar permissões apropriada para os usuários
As restrições para utilização são:
E estão preparando o lançamento do 2o. produto: “Indentity as a Service”!
Importante: como informou esta notícia da InformationWeek USA, o WSO2 suporta o uso de seu produto como uma “Amazon Machine Image“, o formato de máquina virtual do EC2/Amazon Cloud. É compatível também com “VMware ESX Server virtual machine” e, claro, no open source Linux KVM virtual machine.
A notícia vem do blog da Mary-Jo Foley. No final de Novembro (25/11/2009) o arquiteto da Microsoft, Simon Davies, anunciou que já tinha um exemplo do “Ruby on Rails” rodando em uma “nuvem” do Microsoft Azure (veja aqui “ao vivo”).
Em um movimento acertado, a Microsoft tem feito um esforço para que sua “nuvem” tenha compatibilidade com vários produtos e soluções open-source. Alguns exemplos de “Azure compatible” são:
e claro, o seu “Service Bus and Access Control services”, antes conhecido como “.NET Services”, agora roda diretamente no Windows Azure e é chamado agora de “Windows Azure platform AppFabric Service” (nome nada fácil…). Mais detalhes aqui e aqui.
Como na discussão levantada no post da Mary-Jo, não imagino que exista motiva de desconfiança por trás desta iniciativa da Microsoft em suportar soluções open-source em sua “nuvem”.
No meu ponto de vista, não importa para o usuário, e até mesmo para o desenvolvedor, em que “nuvem” sua sua aplicação baseada no “Ruby on Rails” ou seu open-source SugarCRM, está sendo executado.
O que você acha?
Carol é uma arquiteta de software, recém-casada, sem filhos, está prestes a receber seu 6o. certificado Java. Formada em análise de sistemas, é autodidata e adora música (não desgruda do seu iPod).
Yto é o gerente de desenvolvimento. Filho de japoneses, ele é casado, tem 1 filha, e está cursando uma pós-graduação em engenharia de software. Foi desenvolvedor por muito tempo e este é seu primeiro cargo como gerente.
São 17:52 (veja o relógio) quando Yto chega próximo da mesa da Carol e pergunta:
[Yto] – Carol?
[Carol] – (ouvindo “Bangers and Mash”, do Radiohead, não ouve a pergunta)
[Yto] – (chegando mais perto) Carol, eu sei que já está tarde, mas preciso da sua ajuda para pensarmos sobre a Ontologia e a Taxonomia dos serviços que já construímos.
[Carol] – “Taxo” o que Yto? (ao mesmo tempo em que pensava, “O Yto não tem mesmo o que inventar, perguntar desta tal de ‘taxo-não sei-o-que’ quase 6 da noite…”)
Os termos parecem difíceis para quem nunca ouviu falar mas o conceito é relativamente simples. Carol não precisa se preocupar mas, claro, às 06:00 PM não é a hora do Yto solicitar um planejamento de como classificar os serviços que eles já desenvolveram.
Quando se tem poucos Serviços – um número entre 20 e 100, então pode-se assumir que uma pessoa será envolvida no trabalho de entender e descrever a semântica deste Serviço.
Entretanto quando temos centenas de ou milhares de serviços, e estes estão sendo constantemente atualizados, é difícil ou mesmo impossível manter a semântica de cada um destes Serviços atualizado. Em algum momento se faz necessário uma representação formal, um padrão para representar a semântica destes Serviços.
(Evolução da Taxonomia para a Ontologia, SOASimples.com a partir de várias fontes)
Taxonomia são esquemas básicos, primários, de classificação através de hierarquia. A Taxonomia entretanto é uma estrutura muito simples para se utilizar em sistemas com muitas mudanças. Algumas vantagens:
Introduzir o conceitos de novos Serviços em uma ambiente de constante mudança (como o de uma operadora de telefonia) é uma das desvantagens desta classificação “horizontal”. Surgiu então necessidade de algo mais resiliente a mudanças, e a Ontologia tem esta característica importante.
Pode ser utilizada para capturar visões alternativas dentro de um arcabouço único, uma classificação “vertical”. Algumas vantagens:
Acompanhe aqui como a estória se desenrola. Abcs!
Existe existia uma idéia pré-concebida na minha mente que SOA e BPM devem ser iniciativas “casadas”, parte de um processo único. O resultado pode ser catastrófico. Algumas razões:
A utilização de uma arquitetura orientada a serviço pode ser parte de um esforço, de uma estratégia de BPM, porém ter as duas iniciativas de forma concorrente é um forte indício de que você esteja utilizando a abordagem “Big Bang” (que deve ser evitada).
SOA e BPM tem objetivos diferentes e métricas diferentes. Como afirmou J P Morgenthal em seu blog, “The Tech Evangelist“:
…SOA and BPM each have their own metrics of success and their ownbarriers to success. Combining them into one, well, the words “boilingthe ocean” comes to mind
Ele precisa entender de arquitetura orientada a serviço? Não! Seu foco deve ser localizar e extrair dos stakeholders as informações necessária para capturar o “as is” (hoje) e ajudar a definir o “to be” (amanhã). Acredite, é a parte mais difícil.
Para ganhar agilidade no processo e evitar entrevistas desnecessárias com os clientes (internos ou externos), um(a) arquiteto(a) SOA deve acompanhar o(a) analista de negócio.
Se você quiser saber quais as oito competências que todo Analista de Negócios deve ter, eu aconselho a leitura deste artigo: “Eight Competencies a Business Analyst Needs to Know“.
Geralmente (isto não é regra) as equipes com foco na arquitetura SOA utilizam a abordagem “bottom-up“, em que os arquitetos especificam Serviços com base em “capacidades” (capabilities) que já existem. O risco desta abordagem é resultar em implementação de Serviços que não correspondem com os requisitos do processo. É o problema da “visão de poço” ou “visão de profundidade” em que coloca-se muito foco na tecnologia e, por vezes, esquecemos o objetivo maior, que faz parte de um processo de negócio.
Do outro lado, analistas de negócio (BPM), que geralmente utilizam excessivamente abordagens “top-down” irão tentar otimizar processos sem levar em conta o detalhamento que permitirá a implementação de um Serviço.
Qual a solução? A que eu recomendo é a utilização de iterações em que visita-se do topo (“top“) até a base (“bottom“), ou seja, verifica-se o processo “to be” mapeado pela equipe de BPM e a definição do(s) Serviço(s) projetado(s) pela equipe de arquitetos SOA.
Avançando nesta discussão o ideal seria ter definidos objetivos (“Goals“) factíveis e de curta duração, com grande visibilidade, e adotar esta ação conjunta “bottom-up”+”top-down” com um Goal de negócio como meta. A isto eu defino como “Goal-oriented“.
Abraços,
Davi
(atualizado às 08:10 PM para atualização do tópico “Bottom-up, Top-down, “Goal-oriented”?)
Alguns meses atrás, eu preparei a arquitetura simplificada acima para um trabalho no meu MBA no IBMEC São Paulo/INSPER. É apenas um exemplo de como uma arquitetura orientada a serviços (SOA) pode auxiliar em diversas aplicações de RFID. O objetivo foi apresentar uma solução para o rastreamento de cargas e bagagens aéreas utilizando tags RFID. Este tipo de solução já é utilizada em vários aeroportos e companhias aéreas no mundo. Veja um exemplo da United Airlines (Chicago, EUA) e da Air New Zealand (Nova Zelândia).
A International Air Transport Association (IATA) estima que, por ano, as companhiam aéreas perdem US$ 3 a 4 bilhões/ano devido aos custos por extravio de bagagens. Em um cenário de pressão por redução de custos nas passagens, concorrência acirrada, reclamação dos clientes das longas filas nos balcões de check-in, eficiência operacional etc, fica claro que alguma ação precisa ser tomada para diminuir estes custos. É um investimento perdido e, pior, com “retorno negativo”, porque além dos problemas causados aos passageiros que tiveram sua bagagem extraviada, as empresas correm o risco de não ver nunca mais aquele passageiro em seus aviões.
Números, números…:
A presão por redução de custos operacionais é tão grande que lá fora as empresas cobram de US$ 15 a US$ 100 adicionais simplesmente para despachar a bagagem dos seus clientes. Se esta moda pega por aqui…
Uma das soluções pode ser a utilização de RFID. Na minha opinião os custos iniciais podem até serem relativamente altos, porém os ganhos em eficiência, confiabilidade e até mesmo retenção de clientes são enormes. Você volta a utilizar os serviços de uma companhia aérea se, frequentemente, sua bagagem é extraviada? Pouco provável, certo?
Importante: não se trata apenas de imprimir tags RFID e colocar nas bagagens (sim, hoje temos impressoras que imprimem as etiquetas de RFID). Existe todo um ambiente de sistemas tais como ERP, CRM, despacho de bagagens, que precisam ser integrados e em tempo real.
As tecnologias e decisões de arquitetura para estas situações envolvem o uso de:
Não se assuste com a “sopa de letras” acima. Todas as tecnologias são correlatas, se complementam para a construção de um “meio-ambiente” que permita operar de forma eficiente uma solução baseada em eventos.
A Air Zealand foi além do simples controle. Ela implantou kiosks (vide foto acima) onde os passageiros despacham suas bagagens devidamente identificada com tags RFID.
O investimento foi US$ 16.5 milhões. Com este valor a empresa:
Com isto ela foi a 1a. companhia aérea a oferecer RFID-enabled self-scanned check-in. Você prefere isto ou enfrentar a fila nos balcões? Isto influenciaria a escolha da sua companhia aérea? Quanto tempo você economizaria?
A questão central é o controle mais eficiente das bagagens e cargas, agilidade, integração dos vários sistemas, e uma grande redução de custos. Todos ganham no processo, a companhia aérea, a empresa que administra os aeroportos mas, principalmente, o cliente.
Existem middlewares utilizados em arquitetura SOA que são específicos para tratar centenas de milhares de eventos como estes gerados por etiquetas RFID. SOA é uma abordagem ideal para tratar de eventos complexos e integração de ambientes heterogêneos, com custo relativamente baixo, sem necessidade de reescrever o legado. Por tudo isto SOA é uma excelente escolha.
No próximo post vou tratar dos middlewares que são específicos para tratamento de CEP em uma arquitetura SOA. Não perca!
Se você é familiar com os produtos da JBoss/Red Hat, já deve ter ouvido falar do JBoss Messaging (v 1.x). Como o nome diz é um middleware orientado a mensagens (ou MoM – Message-oriented Middleware), que era a solução de mensageria padrão do JBoss Enterprise Application Platform, JBoss SOA Platform e JBoss Application Server version 5.0.
O produto evoluiu e a versão 2.x ficou tão diferente do projeto original que eles decidiram dar um novo nome para o produto: HornetQ.
Principais características
Arquitetura (high-level view)
Documentação
MoM – Definição
Por fim, mas não menos importante, vamos a uma definição básica de um Message-oriented middleware (MOM).
Basicamente é uma solução de infraestrutura de software que recebe e envia mensagens. A arquitetura destas soluções tem um grande foco em questões relacionadadas a confiabilidade da entrega/envio das mensagens, interoperabilidade (“conversam” com vários protocolos) e portabilidade (ambientes altamente heterogêneos).
Na minha opinião, do ponto de vista de arquitetura de software, são soluções “elegantes” que reduzem a dependência e a complexidade das suas aplicações e/ou componentes. Como arquiteto(a), por exemplo, você não precisa se preocupar como uma mensagem vai sair do ambiente mainframe, ser persistida, transformada e roteada para, finalmente, ser entregue no formato de um SMS para seu cliente. Isto permite que você mantenha o foco no desenho, na arquitetura da solução, que é o mais importante.
Tudo indica que Mensageria será um dos elementos-chave em Cloud Computing. A JBoss sabe disto e lançou o HornetQ com este objetivo ambicioso: ser o provedor de mensagens preferido no ambiente de cloud computing.
Boa sorte!
Uma discussão recorrente no mundo da arquitetura orientada a serviços (SOA) é como o Business Intelligence (BI) se integra neste cenário e, no caso da empresa onde trabalho (operadora telecom), como disponibilizar dados em tempo real para o BI.
Antes de mais nada sabemos que o Business Intelligence não tem a premissa de tratar dados em tempo real. Utilizamos para consolidar dados de várias fontes, gerar gráficos e relatórios para os vários níveis da empresa (operacional, tático e estratégico), como um dashboard para os tomadores de decisão etc, mas quase nunca como uma ferramenta de análise de dados em real time.
BI
Falando em BI, em uma pesquisa realizada alguns anos atrás, mostrou os principais motivadores que levavam as empresas a adotar esta solução:
(fonte: http://www.information-management.com/issues/20040201/8034-1.html)
Análise de Dados em Tempo Real
Soluções do tipo BAM (Business Activity Monitoring), e mesmo os já conhecidos BI, podem demandar a apresentação de dados e gráficos de dados com uma latência menor. Alguns exemplos simples: vendas realizadas na última hora, ligações telefônicas completadas com sucesso nos últimos 45 minutos, lotes produzidos nas últimas 2 horas, transações com cartão de crédito no últimos 5 minutos etc.
Se o volume for considerável, milhões de transação no caso de uma operadora de telecom ou de cartão de crédito, é um desafio disponibilizar estas informações através do BI ou BAM. Não apenas estes dois mercados, mas todas as operações onde temos eventos em real-time que precisam ser capturados, correlacionados e apresentados para monitoramento em tempo real.
Estes cenários são típicos de Complex Event Processing (CEP) e Event-driven Architecture (EDA). Detalhes adicionais neste link.
Oracle e Integração de Dados em Tempo Real
Ontem (23/Jul/2009) a Oracle anunciou a compra da GoldenGate, uma empresa de San Francisco, Califórnia, que possui uma solução de integração de dados em tempo real. Veja a imagem abaixo que consta na apresentação oficial da Oracle:
Verifique que a solução da GoldenGate alega que extrai e disponibiliza os dados em “tempo real” para vários “consumidores”, entre eles: Message Bus típicos de arquitetura SOA/EDA e o que eles denominam “Operational BI“.
Veja uma arquitetura simplificada de onde como a solução da GoldenGate disponibiliza dados em tempo real para ferramentas de análise e BI:
A apresentação detalha ainda alguns cases de sucesso da implantação solução da empresa de San Francisco. Mesmo sendo um material com viés promocional de como os produtos da Oracle serão integrados com o da GoldenGate, a leitura vale a pena.
Por ocasião do 2o. SOA International Symposium (Holanda, Outubro/2009), será lançado oficialmente o “SOA Manifesto“.
Nas palavras de Thomas Erl, um dos líderes do movimento “Towards and SOA Manifesto”, SOA já atingiu um nível de maturidade em que seus princípios, intenções e objetivos por trás da filosofia de orientação a serviços, já podem ser formalizados em um Manifesto.
The service-oriented architectural model and the service-orientation paradigm have reached a stage of maturity where the principles, intentions, and ambitions that embody their underlying philosophy and goals can be expressed in a formal manifesto. On October 23, 2009 at this year’s 2nd International SOA Symposium in Rotterdam, the “Towards and SOA Manifesto” working group will be following in the footsteps of the agile community by announcing the SOA Manifesto for the first time
Reproduzo parte do web site http://www.soa-manifesto.com/ :
