os termos de SOA Desmistificando SOA, a arquitetura orientada a serviços, possui um

soa_ Desmistificando os termos de SOA Tire suas dúvidas a respeito dos termos mais comuns referentes a SOA Alexandre Saudate alesaudate@gmail.com @alesaudate é formado em Sistemas de Informação pela USP. Trabalha com SOA e correlatos desde 2008, e é autor do livro SOA Aplicado: Integrando com web services e além, publicado pela Casa do Código. SOA, a arquitetura orientada a serviços, possui um ecossistema vasto em termos e ferramentas próprias. Muitas vezes, problemas complexos a serem resolvidos em SOA podem requerer o conhecimento destas ferramentas. Quando isto acontece, vale a pena conhecer onde o desenvolvedor/arquiteto está se metendo. Como monitorar a performance do seu negócio eficientemente? Como estabelecer correlações entre os serviços sendo invocados, e tomar atitudes em relação a isso? Como prover uma arquitetura SOA altamente escalável? A partir do conhecimento sobre os termos que serão apresentados, você terá condições de conduzir suas próprias pesquisas a respeito destas e outras questões que poderão surgir quando estiver projetando sua própria arquitetura orientada a serviços. SOA SOA significa Service-Oriented Architecture, ou arquitetura orientada a serviços. Trata-se de um paradigma arquitetural que define técnicas para modelagem, desenvolvimento e gerenciamento de serviços. Orientar alguma coisa, em desenvolvimento de software, significa desenvolver utilizando as melhores práticas e técnicas da tecnologia à qual seu sistema é orientado. Quando desenvolvemos um software orientado a serviços, portanto, devemos utilizar as melhores práticas desta técnica. Algumas dessas práticas são:» Desenvolver os contratos antes das implementações (contratos estes que, assim como o desenvolvimento com uma linguagem orientada a objetos por exemplo representam a maneira como o cliente do serviço interage com o mesmo);» Utilizar serviços agnósticos de implementações (ou seja, desenvolver serviços que, de fato, são interoperáveis por exemplo, um serviço construído em Java que possa ser consumido em C#);» Analisar os níveis corretos de granularidade (ou seja, analisar quais as capacidades exatas que um único serviço deve ter). Em relação ao design dos serviços, estes devem seguir os seguintes princípios:» Ter contratos padronizados; / 54

Muito se fala em SOA, e tanto iniciantes quanto os mais experientes podem ficar perdidos em meio a tantos termos. O que é BPEL? O que é ESB? O que é CEP? Neste artigo, você conhecerá tanto termos SOA quanto alguns correlacionados.» Ter baixo acoplamento em relação a outros serviços;» Serem abstratos em relação às implementações;» Devem ser reutilizáveis;» Devem ser independentes de outros serviços;» Não devem armazenar estado;» Oferecer mecanismos de descoberta;» Não oferecer impedimento à utilização em uma composição. Vale lembrar que estes não são obrigatórios, porém, altamente recomendados. isso porque todos estes princípios vão ser responsáveis, cada um à sua maneira, de promover uma arquitetura eficiente e reutilizável. Vários destes princípios são seguidos por diversas tecnologias. As mais proeminentes, no entanto, são REST e SOAP (WS-*). Serviço Um serviço é um componente de lógica de negócios, ou seja, qualquer componente que ofereça uma funcionalidade do negócio. Além disso, estes componentes devem seguir os princípios de design citados acima. Em SOA, estes serviços são o centro do universo, ou seja, as aplicações devem ser pensadas em termos destes serviços. isto porque estas aplicações devem ter conhecimento de que estão em um ecossistema completo de aplicações, onde existe interação entre estas. Em uma arquitetura orientada a serviços, os serviços serão os responsáveis por prover os pontos onde as aplicações podem interagir umas com as outras. Na prática, serviços podem ser web services tradicionais, REST, EJBs etc. - sendo que os mais tradicionais, nesta área, são aqueles baseados em WS-* e SOAP. REST também tem sido uma abordagem bastante promissora, dada a capacidade de interação com serviços desse tipo. REST É um estilo de desenvolvimento de serviços proposto por Roy Fielding em sua tese de doutorado. Roy Fielding foi um dos desenvolvedores do protocolo HTTP e, como tal, uma das maiores autoridades sobre o assunto. Quando ele propôs o modelo REST, ele claramente intencionava transmitir todo o conhecimento adquirido no desenvolvimento do protocolo HTTP como diretivas para um modelo que pudesse ser utilizado no desenvolvimento de aplicações modernas (e não apenas na web, como era o caso até então). Possui uma sequência de princípios básicos:» Utilização adequada de MiME Types (como text/html, text/xml, text/json etc.) nas transferências de dados;» Utilização de URLs condizentes com o que se procura (por exemplo, /pessoa para tratar pessoas e /veiculos para tratar veículos);» Utilização de métodos HTTP (GET, POST, PUT, DELETE etc.) adequadamente;» Utilização de hiperligações entre dados;» Utilização de códigos de status do HTTP. Um dos principais impactos de REST, no entanto, foi a contraposição ao estilo RPC (Remote Procedure Call), predominante no segmento até então. Por exemplo, uma das características do RPC é informar ao servidor qual método estamos invocando. Em REST, essa prática é abolida, partindo do pressuposto de que o trio URL bem definida + método HTTP adequado + MiME type correto são suficientes para encontrar o método correto. Por exemplo, o método GET é comumente utilizado para recuperar informações. Em REST, caso o cliente queira recuperar informações de clientes, basta enviar o método GET 55 \

com a URL /clientes e o MiME type adequado para o servidor. Uma limitação do estilo, no entanto, está na modelagem de modelos mais complexos, como busca com informações complexas, re-adaptação de cenários RPC para REST, segurança (limitada ao já existente no HTTP/HTTPS ou implementações customizadas), e outros. Para estes cenários, o mais recomendado é utilizar WS-* e SOAP. WADL É um descritor para aplicações baseadas em REST. Este descritor tem por objetivo endereçar questões relacionadas à dinâmica de serviços REST, como URis não específicas, diferentes MIME types etc. Um exemplo de WADL está apresentado na Listagem 1. Listagem 1. Exemplo de WADL. <application xmlns= http://wadl.dev.java.net/2009/02 > <doc xmlns:jersey= http://jersey.java.net/ jersey:generatedby= Jersey: 1.9 09/02/2011 11:17 AM /> <grammars> <include href= application.wadl/xsd1.xsd > <doc title= Generated xml:lang= en /> </include> <include href= application.wadl/xsd0.xsd > <doc title= Generated xml:lang= en /> </include> </grammars> <resources base= http://localhost:8080/springhibernate/ > <resource path= /person > <method id= create name= POST > <request> <ns2:representation xmlns:ns2= http://wadl.dev.java.net/2009/02 xmlns= element= person mediatype= application/xml /> </request> <response> <representation mediatype= <?xml version= 1.0 encoding= UTF-8 standalone= yes?> application/xml /> </response> </method> <resource path= /{id} > <param xmlns:xs= http://www.w3.org/2001/xmlschema name= id style= template type= xs:long /> <method id= retrieve name= GET > <response> <representation mediatype= application/xml /> </response> </method> </resource> </resource> </resources> </application> No WADL, é possível observar duas seções distintas, grammars e resources. A primeira vai especificar os formatos de dados que serão utilizados como entrada e saída dos serviços. A segunda vai especificar as URLs utilizadas para consumo dos serviços (em REST, também conhecidos como recursos), URLs derivadas, tipos de dados aceitos como entrada e saída, métodos HTTP utilizados etc. Vale ressaltar que o WADL não é uma unanimidade entre a comunidade. Alguns são favoráveis ao uso do mesmo, outros são contra. Argumentos a favor dizem que o mesmo facilita no consumo destes serviços, já que não há necessidade de realizar descoberta prévia do que os serviços expõem já que tudo está especificado no WADL. Argumentos contrários dizem que o uso de um WADL poderia engessar o cliente, tirando o dinamismo pretendido por REST. SOAP / WS-* SOAP e WS-* são os elementos fundamentais dos agora chamados web services clássicos. Estes foram adotados já há vários anos pelo mercado em geral, e tiveram suas especificações definidas por vários consórcios, dentre os quais os mais proeminentes são a W3C (World Wide Web Consortium) e a OASiS (Organization for the Advancement of Structured Information Standards). SOAP significa Simple Object Access Protocol. É um protocolo de aplicação largamente utilizado em grandes empresas para realizar comunicação entre sistemas. É fortemente baseado em padrões e técnicas de XML, como XSD, XPath, Xquery e outras. Contém três partes principais: Envelope (a raiz do conteúdo), Header (utilizado para tráfego de meta-informações) e Body (utilizado para tráfego de informações de requisição, respostas e mensagens de falha). É fortemente ligado a um WSDL e a WS-* como um todo. O WSDL (Web Services Description Language) descreve o formato de entrada e saída de serviços num formato geral, e SOAP dá corpo a essa entrada e saída. O WSDL possui cinco partes principais (sendo extensível, ou seja, podendo possuir mais partes): types, message, porttype, binding e service. O WSDL pode conter apenas as três primeiras, e se assim o fizer, é chamado de WSDL abstrato. Essas três primeiras partes descrevem o formato da entrada e saída do serviço, utilizando XSDs (XML Schema Definition). Até esse momento, o WSDL é independente de SOAP, podendo também descrever outros formatos (sendo que o segundo mais formato é o que se convencionou chamar de POX Plain Old XML). Ele passa a descrever um documento SOAP apenas nas seções binding e service. Se o WSDL contém estas seções, ele é chamado de WSDL concreto. Quanto à descrição do formato do envelope SOAP, / 56

existem pelo menos cinco formatos mais conhecidos: RPC literal, RPC encoded, document literal, document encoded e document literal wrapped. No formato RPC (Remote Procedure Call) literal, a definição dos métodos a serem chamados no servidor fica descrita apenas no WSDL, e não na implementação do serviço. Neste modelo, o servidor deve se encarregar de receber a requisição do cliente, fazer parse da mesma, identificar qual é o método que está sendo invocado e, então, despachar a mensagem para a implementação. É um formato complexo, visto que as validações da mensagem geralmente são dependentes do contrato (WSDL). O formato RPC encoded é parecido com o RPC literal, com a adição de que os tipos dos dados devem ser passados na própria requisição, como o exemplo mostrado na Listagem 2. Listagem 2. Exemplo de requisição RPC. <soap:envelope> <soap:body> <mymethod> <x xsi:type= xsd:int >5</x> <y xsi:type= xsd:float >5.0</y> </mymethod> </soap:body> </soap:envelope> Note que, na maior parte dos casos, este tipo de informação é desnecessária, já que a tipagem está presente nos XSDs. Além disso, este formato foi declarado não-interoperável (ou seja, que não se adequa bem a ambientes com múltiplas linguagens de programação) pela WS-i, uma organização responsável por definir padrões de interoperabilidade entre web services. No formato document literal, não há definição formal de qual método está sendo invocado. Neste ponto, o corpo da requisição SOAP é um pouco mais semelhante ao de uma requisição REST. No entanto, pela dificuldade de se entregar esta mensagem para a implementação, geralmente algum mecanismo de endereçamento fica implícito, como o uso do header HTTP SOAPAction ou alguma especificação formal como WS-Addressing (que explicarei mais à frente). O formato document encoded é semelhante ao document literal, com a adição de exigir que a tipagem dos dados seja fornecida em conjunto (assim como acontece em RPC Encoded). Este formato também não é interoperável. O formato document literal wrapped atua de maneira que o método é, novamente, inserido na requisição, mas ao contrário do RPC, esta definição do método fica inserida em um XSD, facilitando a validação do corpo da mensagem e até mesmo melhorando o mecanismo de entrega. Este formato de dados é o padrão utilizado pelo JAX-WS (o framework padrão para definição de web services em Java), e é o que possui menos falhas, de acordo com [1]. Quanto a WS-*, trata-se de um nome comumente atribuído ao conjunto de especificações definidas para web services clássicos. Estas especificações compreendem uma série de mecanismos úteis para uso em cenários que envolvem web services, como mecanismos de segurança (WS-Security), transações (WS- -Transaction), endereçamento (WS-Addressing), e assim por diante. WS-Policy É uma especificação utilizada para definir políticas (ou seja, maneiras de utilizar) web services clássicos. Estas políticas podem envolver praticamente qualquer coisa, como o protocolo de transporte que deve ser utilizado pelo web service (HTTP/HTTPS, por exemplo); SLA do serviço etc. Em geral, é utilizada para descrever o uso de outras especificações. WS-Security É a especificação padrão para endereçar questões relacionadas à segurança. Estas questões envolvem o já citado protocolo de transporte, o sistema de autenticação/autorização etc. Pode incluir outras especificações/extensões, como WS-SecureConversation (utilizada para estabelecer contextos de segurança, ou seja, mecanismos seguros a serem utilizados em várias trocas de mensagens) e WS-Trust (utilizada para definir mecanismos de utilização de tokens seguros). WS-Transaction É uma especificação guarda-chuva para questões relacionadas a transações. Engloba WS-Atomic- Transaction (para transações de curta duração) e WS- -BusinessActivity (para transações de longa duração). WS-Addressing É uma especificação para tratar endereçamento de dados. Pode ser utilizada tanto para tratamento de requisições dinâmicas (ou seja, para especificar, em tempo de execução, o endereço de um determinado web service), quanto para tratamento de web services assíncronos (ou seja, é o mecanismo que o cliente vai utilizar para informar ao servidor o endereço para resposta de uma mensagem). MTOM / xop MTOM significa Message Transmission Optimization Mechanism, e XOP significa XML-binary Optmized Packaging. São mecanismos usados em conjunto para tratar da transmissão de dados binários em SOAP. Basicamente, o mecanismo funciona em conjunto com HTTP, de maneira que o conteúdo binário é 57 \

trafegado separado do envelope SOAP e, depois, ambos são recombinados através de um ID da mensagem. Diferenças entre REST e WS-* Para ficarem claras as diferenças entre REST e WS-*, listo aqui algumas delas: CONTExTO REST WS-* CONTRATO TIPOS DE DADOS SEGURANÇA Qualquer formato endereçado pela WS-Security ou extensões proprietárias INTEROPERABI- LIDADE FACILIDADE DE USO MODELAGEM MANUTENIBILI- DADE PERFORMANCE WADL + Interface Uniforme (padronização de métodos HTTP + códigos de status + URLs) Qualquer um que possa ser definido por um MIME Type Baseada no modelo HTTP / HTTPS ou extensões proprietárias Sim Tende a ser fácil Orientada a recursos tende a ser difícil Clientes podem deixar de funcionar silenciosamente após uma alteração no serviço Mais rápido pode trafegar apenas o estritamente necessário WSDL SOAP (baseado em XML) e binário (endereçado pela especificação MTOM/XOP) Possui variantes não-interoperáveis (ou seja, não homologadas pela WS-I) Tende a ser difícil Similar a RPC tende a ser fácil Em geral, os clientes são compilados por geradores de código fazendo com que eles deixem de funcionar caso o serviço não seja mais compatível Mais lento inclui overhead do protocolo SOAP ESB Significa Enterprise Service Bus. É um padrão de projeto SOA (catalogado por Thomas Erl em [2]) utilizado para endereçar, de uma única vez, padrões de integração de sistemas [3]. Um ESB tem uma posição central em uma arquitetura orientada a serviços. Suas atribuições incluem roteamento de mensagens, transformação, enriquecimento, composição, monitoração, entre outras. Por possuir todas estas atribuições, geralmente ele é o ponto de comunicação entre o cliente e o serviço final, sendo que este serviço final pode ser tanto um web service simples (WS-* ou REST), quanto uma composição de serviços. Em caso de uma composição, é bastante comum encontrar cenários em que a própria composição não entrega mensagens diretamente aos serviços, mas sim, invoca o ESB novamente. isso facilita o monitoramento da saúde da arquitetura como um todo. Existem várias implementações de ESB (na casa de dezenas). Para mencionar algumas, temos:» Oracle Service Bus;» ibm Websphere ESB;» Progress Sonic ESB;» Mule ESB;» Apache ServiceMix;» Fuse ESB. Um caso curioso é o do Apache Camel. Este framework contém todas as funcionalidades de um ESB, sem ser considerado um. isto porque o Apache Camel não possui um papel centralizado, ou seja, fica embutido na aplicação. Para que isto fique mais claro, veja a figura 1. A figura 1 mostra o papel de um ESB; observe que é uma posição central, ou seja, deve contar com o próprio servidor de aplicação no próprio conjunto de máquinas. O Apache Camel não tem essa posição central, sendo várias vezes embutido em outras aplicações, ao invés de ter esse papel centralizador. Quanto à forma, não existe padronização em relação a como os ESBs expõem suas regras. Cada um tem seu próprio mecanismo (e, muitas vezes, sua própria nomenclatura) para isso. Por exemplo, o Apache ServiceMix utiliza o Apache Camel para definição de suas rotas. O Apache Camel, por sua vez, trabalha com a definição das rotas tanto na forma de arquivos XML (integrados com o Spring) quanto em puro Java. Listagem 3. Fragmento de definição de rotas do Camel. <camel:route> <camel:from uri= file:src/data?noop=true /> <!--Print the message to standard out, just as a test--> <camel:convertbodyto type= java.lang.string /> <camel:to uri= stream:out /> <camel:to uri= activemq:personnel.records /> </camel:route> A Listagem 3 mostra um fragmento de definição de roteamento utilizando o Apache Camel. Nesta listagem (definida dentro de um arquivo Spring), é possível ver as tags from e to. Estas tags mostram, respectivamente, o consumo de uma mensagem (no caso, do sistema de arquivos, da pasta src/data) e a entrega da mesma a um determinado ponto. Neste / 58

Figura 1. Papel de um ESB em SOA (fonte: soasimples.com). caso, a mensagem tanto foi entregue para a saída padrão do sistema (ou seja, para ser impressa no console) quanto para uma fila JMS do ActiveMQ. BPM / BPMN / BPMS BPM significa Business Process Management. É um conceito utilizado para realizar análise de processos de negócio e otimizá-los. É comumente habilitado através de uma notação chamada BPMN (Business Process Modeling Notation), e pode ser dividido em fluxo abstrato ou concreto, sendo que o concreto é automatizado através de um BPMS Business Process Management Suite. Estas suítes geralmente recebem como entrada um fluxo BPMN e, através de extensões, permitem a um desenvolvedor programar o comportamento de cada definição no fluxo. A figura 2 mostra um exemplo de um fluxo definido no Oracle BPM Studio. Figura 2. Definição de fluxo BPM no Oracle BPM Studio (fonte: docs.oracle.com). Cada uma das caixas representa uma atividade diferente, dentro do contexto de um mesmo processo de negócios. O desenvolvedor pode receber o fluxo BPMN definido em qualquer ferramenta (como,k por exemplo, o Bizagi BPM Suite) e então, portar este fluxo para o Oracle BPM Studio, onde o processo poderá ser automatizado. Após a definição do que cada atividade deve fazer, o BPM Studio receberá um pacote com o fluxo e, geralmente, disponibilizá-lo para a empresa como um web service. Diferenças entre os ESBs Cada tipo de ESB apresenta vantagens e desvantagens que justificam o modelo de precificação. Assim como Application Servers, existem diferenças fundamentais entre cada um, em termos de funcionalidade, escalabilidade, performance, compatibilidade com outros produtos etc. BPEL Significa Business Process Execution Language. Na prática, trata-se de um XML que define um conjunto de operações a serem efetuadas com um conjunto de web services e expô-los como um único serviço. O formato deste XML é regido pela OASiS. Existem muitas comparações de BPEL com BPM. No começo, muitos acreditavam que deveria ser o BPEL quem automatizaria os fluxos BPMN, e muitos acreditaram na ideia. Com o passar dos anos (e as empresas ganhando mais maturidade em SOA), esta ideia foi descartada. Hoje, o BPEL serve apenas como motor de orquestração de serviços ou seja, uma engine centralizada capaz de atuar como máquina de estados para estas composições, realizando procedimentos complexos de comunicação entre vários web services diferentes. Vale ressaltar que a maioria das engines BPEL lida apenas com web services WS-*. Existem diversas engines BPEL atualmente. Para citar algumas, temos:» Oracle BPEL Process Manager;» Apache ODE;» Websphere Process Server. A figura 3 mostra um exemplo de definição de fluxo BPEL (no JDeveloper 11g, ferramenta utilizada para definição BPEL para o Oracle BPEL 11g). Assim como em BPM, cada caixa neste fluxo conterá a definição de uma atividade diferente. A grande diferença é que o BPEL contém atividades muito mais técnicas, que não devem sofrer interferência de analistas de negócio ou correlatos. 59 \

when Uma pessoa tem somente dor-de-cabeca. then O diagnostico e Enxaqueca end Figura 3. Exemplo de definição BPEL no Oracle BPEL (fonte: docs. oracle.com). BRMS Significa Business Rules Management Suite. É um tipo de ferramenta utilizada para gerenciar e executar regras de negócio, que são tipicamente definidas através de linguagem específicas de domínio (Domain-Specific Language - DSL). Existem várias ferramentas deste tipo disponíveis no mercado, dentre as quais alguns exemplos são o JBoss BRMS / JBoss Guvnor (respectivamente, versão paga e aberta do mesmo produto), o Websphere ilog e o Oracle Business Rules. O JBoss BRMS utiliza como mecanismo de execução o Drools. Um exemplo de arquivo Drools é o apresentado na Listagem 4. Listagem 4. Exemplo de regra Drools (fonte: docs. jboss.org). rule Hello World dialect mvel when m : Message( status == Message.HELLO, message : message ) then System.out.println( message ); modify ( m ) { message = Goodbyte cruel world, status = Message.GOODBYE }; end Esta é uma regra definida em um dos dialetos embutidos do Drools (no caso, o mvel). No entanto, é possível definir as DSLs até ficar como o exemplo mostrado na Listagem 5. Listagem 5. Exemplo de regra com DSL no Drools (fonte: www.jboss.org/drools). rule Enxaqueca Note que o uso de um BRMS, em SOA, facilita a flexibilização de fluxos de dados, dado que as regras ficam definidas num formato que é mais facilmente editável e que tem mais afinidade com o negócio em si. O BRMS é responsável por expor estas regras como web services ou algum outro formato de fácil interação, e as outras aplicações podem consumir estas regras e alterar a lógica de acordo com os resultados, transformando o BRMS num sistema que apenas acrescenta flexibilidade às aplicações como um todo. CEP Significa Complex Events Processing. São ferramentas utilizadas para habilitar a reação de uma arquitetura a eventos, ao invés de requisições puras. Estes eventos são parecidos com requisições, mas as ferramentas CEP os utilizam para realizar correlações em busca de padrões. Estes padrões podem ser utilizados para re-ordenar um fluxo de vendas, detectar intrusos, ataques DDoS, falhas de componentes etc. Um exemplo do mundo real sobre este tipo de processamento é um carro. Carros têm diversos tipos de sensores para medir velocidade, temperatura do motor, nível de combustível etc. Um sistema computadorizado poderia tirar proveito de um sensor de nível de pressão do ar nos pneus e, a partir de correlações entre as medições recebidas num determinado período de tempo, indicar se o pneu está furado ou não. Note que esta informação pode, também, ser correlacionada com outras, a fim de determinar problemas mais graves. Por exemplo, se o computador detectar que uma medição não foi disponibilizada em certo período de tempo, pode inferir que o pneu nem sequer está no carro! Alguns exemplos de ferramentas CEP:» Oracle CEP;» Esper / Nesper (versão Java e.net, respectivamente). Geralmente, as ferramentas são aderentes a uma linguagem chamada EPL Events Processing Language. Esta linguagem é bastante parecida com SQL, no sentido de filtrar eventos a partir de uma nuvem de eventos com certas cláusulas. Por exemplo, para filtrar a média de preço dos papéis da ibm na bolsa, levando em consideração um espaço de tempo de 30 segundos, pode-se utilizar o comando apresentado na Listagem 6. Listagem 6. Exemplo de query EPL (fonte: esper. codehaus.org). / 60

select avg(price) from StockTick.win:time(30 sec) where symbol= IBM Em relação a SOA, o processamento de eventos pode ser utilizado para interceptar as requisições a serviços para gerar estes eventos, que podem ser utilizados para desvendar padrões complexos e, de acordo com os resultados, invocar outros serviços. No exemplo da Listagem 6, por exemplo, o sistema de CEP pode ser utilizado para invocar um serviço de compra de papéis caso o preço médio (em certo período de tempo) atinja um valor mínimo, por exemplo. BAM Significa Business Activity Monitoring. O BAM realiza interceptação dos dados (da mesma maneira que as engines de CEP) para manter rastreamento de KPis (Key Performance Indicators - Indicadores chave de performance). Esses KPis representam números que são essenciais para o funcionamento da empresa - total de vendas em um dia, número de vendas de determinado produto no mês, rendimento bruto e líquido dessas vendas etc. Com o uso de um BAM, é possível visualizar dashboards (gráficos indicadores) desses números. Dependendo da ferramenta, estes dashboards podem ser visualizados em tempo real, ou seja, eles se movimentam de acordo com a performance do negócio. Alguns exemplos de BAM:» Oracle BAM;» Websphere Business Monitor;» WSO2 BAM. A figura 4 mostra estes dashboards no Oracle BAM. outros protocolos, como SOAP. isto facilita a exposição destes tipos de componentes em outros formatos sem a necessidade de utilizar um ESB. implementações incluem a utilizada no Oracle Fusion Middleware (que contém outros componentes, como Oracle BPEL, Oracle BAM, Oracle WebLogic), assim como implementações abertas como o Apache Tuscany. Algumas vezes, é utilizada com frameworks parecidos como o JBi Java Business Integration. Arquiteturas Correlatas SOA possui uma relação íntima com vários tipos de arquitetura. Como o leitor deve ter percebido, a arquitetura orientada a serviços em si não tem por intuito promover escalabilidade no entanto, isto é facilmente alcançado através do emprego de outras arquiteturas. A seguir, você confere algumas destas. Shared-Disk Shared-disk é uma alternativa a um sistema de clusters tradicional, onde o servidor espalha para outros nós as sessões de usuário. Em shared-disk, cada nó desconhece a própria existência dos outros nós. Tudo o que estes sistemas compartilham, uns com os outros, é o disco. Note que, neste caso, o disco pode ser qualquer coisa, desde o próprio sistema de arquivos de uma máquina, até um NAS (Network-Attached Storage). Note que isto inclui um banco de dados, ou seja, se você possui um banco de dados compartilhado entre várias máquinas que não conhecem umas às outras, você está usando uma arquitetura shared-disk. Figura 4. Exemplos de dashboards no Oracle BAM (fonte: www. oracle.com). SCA Significa Service Component Architecture. Suas implementações habilitam a exposição de componentes de serviços (como EJBs, filas JMS etc.) com Figura 5. Formato geral de uma arquitetura shared-disk. Onde isso se encaixa em SOA? No próprio fato das máquinas não conhecerem umas às outras. isso requer que a aplicação não mantenha estado ou persista o estado em locais que não no próprio servidor de aplicação - o que é um casamento perfeito com a 61 \

teoria de orientação a serviços, especificamente em relação ao princípio de design de não armazenar estado. Com máquinas que não mantêm estado, é possível distribuir componentes de uma mesma aplicação (ou várias) por várias instâncias, sem problemas de escalabilidade ou performance. Ao contrário, ao fazer isso, a escalabilidade é alcançada através da escalabilidade horizontal, ou seja, através da adição de mais máquinas no conjunto, é possível obter mais poder de processamento. Quanto à performance, a distribuição da aplicação em serviços equaliza as necessidades de processamento para todos, fazendo com que todas as máquinas ajudem umas às outras. A grande desvantagem desta é que a máquina (ou máquinas) que são responsáveis pelos bancos de dados tornam-se pontos únicos de falha, além do fato da escalabilidade do banco de dados ser limitada. Para contornar este tipo de problema, a arquitetura shared-nothing foi desenvolvida. Shared-Nothing Shared-nothing é similar a shared-disk, com a adição de que as máquinas não compartilham nada - nem mesmo o banco de dados. Perceba que é um conceito mais abstrato e substancialmente mais complexo para ser implementado. No entanto, este sistema tem a adição de não possuir um ponto único de falhas, ou seja, se um banco de dados falha, as outras máquinas não dependem de apenas um. quando se faz uso de bancos de dados que também tenham arquitetura shared-nothing, como Cassandra ou HBase. Neste tipo de arquitetura, deve ser necessário que a aplicação decida em qual (ou quais) máquinas armazenar quais dados e onde. Se os dados forem distribuídos em regiões geográficas distintas, por exemplo, diminuem as chances de indisponibilidade. Além disso, se um conjunto de dados de um tipo (por exemplo, de clientes) forem armazenados em uma máquina e de outro tipo (por exemplo, veículos) em outro, se houver indisponibilidade de uma máquina a aplicação não estará inteiramente comprometida (ou seja, se o banco que contém dados de veículos sair do ar, ainda será possível consultar clientes). Event-Driven Architecture (EDA) EDA é um tipo de arquitetura que pode complementar uma arquitetura SOA tradicional. isto é relativo ao uso que se faz de ferramentas de análise e processamento de eventos (ver CEP). Quando o uso de eventos é extensivo, o resultado é uma arquitetura orientada a eventos EDA. O que isto tem a ver com SOA? Estes eventos podem ser utilizados para disparar serviços. Ou seja, as implementações dos serviços disparam eventos que, por sua vez, alimentam engines de eventos que por sua vez invocam serviços com os resultados dos processamentos dos eventos. Conclusão O universo SOA é imensamente vasto, tendo um ecossistema rico em ferramentas com os mais diversos usos possíveis. Neste artigo, você pôde vislumbrar tanto os termos mais comuns em SOA (como REST, SOAP e WSDL) quanto termos pouco utilizados e restritos a nichos, como CEP e SCA. Vale lembrar que todas estas ferramentas têm usos distintos e todos muito importantes. Todas são ferramentas que resolvem necessidades reais de mercado. Um bom profissional, com conhecimento destas ferramentas, estará sempre apto a resolver os problemas mais complexos. /referências Figura 6. Formato geral de uma arquitetura shared-nothing. Em uma arquitetura shared-nothing, as máquinas que servem à aplicação em si decidem o local onde realizar o armazenamento das informações. isso é particularmente útil para aplicações de nível global, pois as máquinas podem decidir armazenar dados em bancos que estejam geograficamente mais próximos. Este tipo de tomada de decisão é mais simples > [1] Which style of WSDL should I use? http://www.ibm. com/developerworks/webservices/library/ws-whichwsdl/ > [2] SOA Design Patterns Thomas Erl, Prentice Hall, 2009. > [3] EAI Patterns http://eaipatterns.com / 62