Arquitetura Orientada a Servios

18

2 Arquitetura Orientada a Servios

Uma arquitetura de software um conceito abstrato que d margem a uma srie de definies. A definio usada pelo ANSI/IEEE afirma que uma arquitetura de software trata basicamente de como os componentes fundamentais de um sistema se relacionam intrinsecamente e extrinsecamente [ANSI/IEEE, 2000]. Uma arquitetura orientada a servios (SOA Service Oriented Architecture) tem como seu componente fundamental o conceito de servios.
PUC-Rio - Certificao Digital N 0210486/CA

O conceito de servio definido de diversas formas, principalmente na literatura no acadmica. Durante o estudo para esta dissertao este tipo de literatura apresentou algumas definies at certo ponto contraditrias. Na literatura no acadmica, o termo servio empregado para definir coisas distintas, o que acaba gerando alguma confuso. Existem artigos no acadmicos, como [Barry & Associates, 2003] e [Sonera, 2002], que chegam a atrelar servios aos XML Web Services (que sero detalhados no capitulo seguinte) por razes mercadolgicas sem nenhuma argumentao tcnica convincente. Apesar das distintas definies, na maioria das vezes, servio usado para se referenciar a um componente de software binrio baseado em um contrato [Bieber e Carpenter, 2001]. J na literatura acadmica mais difcil encontrar referncias diretas ao termo servio. Em geral o que conhecido como servio na literatura no acadmica conhecido como componentes ou contratos na literatura acadmica. Se tratarmos o servio como uma definio ou descrio de aes a serem executadas, um servio um contrato. Porm, se definirmos o servio como a implementao direta dessas aes, um servio um componente. Em [Pernici e Mercella, 2000] usado o termo e-service para referenciar componentes binrios executando em ambientes distribudos, mas no uma regra geral. Fazendo uso da literatura possvel classificar aplicaes orientadas a servios como sistemas cooperativos abertos distribudos, como veremos nas sees seguintes, pois apresentam todas caractersticas descritas para estes tipos de sistemas.

Arquitetura Orientada a Servios

19

Portanto, o conceito do que uma arquitetura orientada a servios ainda no consensual, uma vez que servio no um termo bem definido e se confunde com os conceitos de componente e de contrato. Atravs deste trabalho foi possvel identificar algumas caractersticas relevantes que todas aplicaes e frameworks que se dizem orientados a servios possuem. importante ressaltar que no necessrio que se tenha todas caractersticas listadas a seguir para denominar se uma aplicao orientada a servios; pelo contrrio, a maioria das aplicaes estudadas possui apenas um pequeno subconjunto dessas caractersticas, e so autoproclamadas como aplicaes orientadas a servios. consideradas relevantes so:
PUC-Rio - Certificao Digital N 0210486/CA

As caractersticas

Reuso Caixa-preta Distribuio Heterogeneidade Ambiental Composio Coordenao Dinamismo e Adaptabilidade Estado Sincronia Robustez de Protocolos O intuito do restante deste capitulo apresentar e discutir tais

caractersticas. 2.1. Reuso Caixa-preta O reuso de software surgiu inicialmente por uma necessidade de economizar recursos de hardware [Clements, 1995]. H algumas dcadas atrs no havia memria suficiente nos dispositivos para armazenar muitas rotinas (segmento de cdigo) e ento, foi observado que era possvel executar tarefas similares atravs de uma nica sub-rotina parametrizada, e assim no desperdiar o uso da escassa memria disponvel. Com a evoluo dos componentes de hardware e a conseqente reduo de preo, o reuso de software mudou de foco. Desde ento o principal objetivo do

Arquitetura Orientada a Servios

20

reuso economizar recursos humanos e no mais de hardware, at por que recursos humanos se tornaram muito mais dispendiosos. O reuso pode ser divido em duas vertentes principais quanto a necessidade do programador de conhecer o componente de software a ser reutilizado: o reuso caixa-branca e o caixa-preta. No reuso conhecido como caixa-branca, existe a necessidade que a implementao do componente de software a ser reusado seja exposta de alguma forma. Em linguagens orientadas a objetos, como Java e C++, muito comum o uso de herana para se atingir o reuso de software, o que um exemplo clssico do reuso caixa-branca, porm, tal uso muitas vezes equivocado. O equvoco ocorre quando o esforo do desenvolvedor para conhecer a implementao que ser reusada desperdia recursos, justamente o que o reuso tenta reduzir. Alm
PUC-Rio - Certificao Digital N 0210486/CA

disso, existe o problema da classe base frgil (fragile base class problem) [Mikhajlov e Sekerinski, 1998], onde uma pequena alterao em uma classe do topo de uma hierarquia pode comprometer toda rvore de derivao e alterar substancialmente o funcionamento de toda a aplicao. J o reuso caixa-preta visa eliminar a necessidade do desenvolvedor de um conhecimento da implementao de algum componente de software que far parte do processo de reuso. Em vez disso, o reuso caixa-preta se d atravs da descrio de interfaces ou contratos bem definidos que devem ser respeitados pela implementao a ser elaborada. O esforo sempre usado na nova implementao e nunca ocorre um desperdcio tentando entender implementaes de terceiros. O uso de linguagens de programao que dem suporte explcito descrio de interfaces, como Java e C#, facilita o reuso caixa-preta. Em outras linguagens este tipo de reuso fica muito mais difcil, pois so necessrios alguns subterfgios (como as classes virtuais puras de C++) para se atingir tal objetivo, o que acaba levando os desenvolvedores a no adotarem esta opo. Ainda no existe uma linguagem robusta e disseminada que d suporte completo ao conceito de contratos, o que facilitaria ainda mais o reuso caixa-preta, pois alguns outros elementos como pr e ps-condies poderiam ser utilizados. Atualmente a disseminao do reuso caixa-preta, principalmente por causa de linguagens de programao como Java, que fornecem suporte adequado, tem causado o surgimento de aplicaes containers, que recebem componentes em tempo de execuo (tambm conhecidos como plug-ins) atravs de uma

Arquitetura Orientada a Servios

21

poltica

prpria

de

composio

assim

alteram

dinamicamente

significativamente seu comportamento. O tema composio ser abordado mais profundamente em outra seo. Aparentemente, com o reuso caixa-preta o esforo maior, pois existe uma necessidade de se escrever cdigo maior do que no reuso caixa-branca, uma vez que nenhuma parte do cdigo inicial ser reaproveitada. Isso pode at ser verdade para o custo inicial, porm a grande vantagem do reuso caixa-preta em mdio prazo, pois as dependncias entre os componentes de software da aplicao esto explicitadas em um contrato facilitando adaptaes e manutenes que se faam necessrias ao longo do tempo. J no reuso caixa-branca, as ligaes entre os componentes (no caso de herana, entre classe e superclasse) so quase sempre obscuras e implcitas, diretamente no cdigo da implementao [Meijler e
PUC-Rio - Certificao Digital N 0210486/CA

Nierstrasz, 1997]. Ao longo do tempo, principalmente em aplicaes altamente adaptativas, o reuso caixa-preta se torna mais eficaz. Arquiteturas orientadas a servios so essencialmente dirigidas atravs de contratos. Todos relacionamentos entre os componentes que fazem parte de uma aplicao devem estar descritos de alguma forma em um contrato (seja ele uma interface Java, um arquivo XML ou outra forma qualquer), explicitando assim as dependncias e facilitando a manuteno e adaptao. 2.2. Distribuio Sistemas abertos (open-systems) so definidos como sistemas onde novas entidades podem dinamicamente passar a compor o sistema, deixar de existir ou ainda evoluir [Kielmann, 1996]1 . J um sistema aberto distribudo parte do mesmo principio s que leva em considerao o fato das entidades poderem estar localizadas em mquinas diferentes. O conceito de orientao a objetos para programao distribuda (OODP Object Oriented Distributed Programming) trata de encapsular o estado de um

Existe uma outra definio para sistemas abertos que tambm comumente usada. Por

esta outra definio sistema aberto um sistema composto por diferentes plataformas de hardware e software. Neste trabalho, este tipo de sistema tratado na questo de heterogeneidade de um ambiente.

Arquitetura Orientada a Servios

22

determinado objeto e faz-lo acessvel atravs de uma interface bem definida [Landis e Maffeis, 1997]. Usando este conceito possvel acessar diferentes plataformas de hardware e implementaes em diferentes linguagens de programao usando um protocolo bem definido, como por exemplo IIOP (de CORBA), desde que a interface esteja descrita em uma linguagem portvel, no caso de CORBA a IDL (Interface Definition Language). importante ressaltar que o conceito de acesso a um estado atravs de uma interface bem definida no est restrito a linguagens de programao com suporte a orientao a objetos. Linguagens procedurais, como C ou Pascal, possuem implementaes de portes de protocolos como IIOP, possibilitando que o mesmo conceito seja aplicado, porm sem que o estado esteja encapsulado em um objeto. Tipicamente, o cliente possui de alguma maneira um identificador (endereo
PUC-Rio - Certificao Digital N 0210486/CA

IP, porta, entre outros) esttico para o servidor que dever receber suas requisies e as envia diretamente ao servidor. Isso caracteriza um sistema distribudo fechado devido a ser altamente esttico, onde novas entidades no podem passar a compor o sistema. O principal exemplo para este tipo de sistema a implementao de RPC (Remote Procedure Call) da Sun Microsystems, que data dos anos 70. J no caso de sistemas distribudos abertos, o cenrio mais complexo. preciso, como dito anteriormente, prever a entrada e sada de componentes de maneira transparente para os clientes. O identificador no mais esttico e sim dinmico, pois o servidor pode ser alterado, desde a sua implementao at sua localizao. A maneira usada atualmente de resolver esta questo atravs de um registro de servios (Service Provider). Antes da execuo o cliente sabe apenas que tipo de servio ele deseja acessar, ou seja, qual interface deve ser implementada para satisfazer as suas necessidades. O processo de execuo ento segue os seguintes passos: 1. O cliente acessa o registro de servios atravs de um protocolo especifico, requisitando alguma implementao para uma determinada interface. Neste caso estamos considerando o acesso ao registro como um acesso esttico; mais frente veremos que possvel ter acesso dinmico para registros de servios tambm.

Arquitetura Orientada a Servios

23

2. O registro responde dando uma identificao para o servidor que implementa tal interface. 3. Finalmente, o cliente acessa o servio fazendo uso de seu identificador e recebe os resultados, caso existam.

Service Consumer
Find

Bind and Execute

Interface/ Contract

Registry

PUC-Rio - Certificao Digital N 0210486/CA

Service Provider

Publish

Figura 1- Esquema do paradigma find , bind e execute Este processo conhecido como o paradigma find, bind and execute. A Figura 1 apresenta um esquema para este paradigma. Existem algumas implementaes deste paradigma como o servio de trading do CORBA e o UDDI (Universal Descriptor, Discovery and Integration) [Oasis, 2002]. Tipicamente, quando um servio entra em funcionamento ele se registra no registro de servios, informando quais interfaces ele implementa para que possa ser contactado no futuro. Esta etapa conhecida como publicao (publish). Algumas implementaes ainda possibilitam que a identificao para o registro de servios seja obtida dinamicamente (ex. JINI). Para tanto, o cliente precisa obter uma identificao para o registro de nomes antes de cham-lo. colocada na rede uma requisio usando broadcast e todos servios de nomes que estiverem ativos devem responder. O cliente ento armazena esta identificao para chamadas posteriores. Esse processo conhecido como descoberta (discover) e s funciona de maneira adequada em redes locais devido ao uso de broadcast (onde no existem firewalls barrando esse tipo de requisio). Aplicaes orientadas a servios so por natureza aplicaes distribudas que fazem uso exaustivo dos conceitos de distribuio, seja por que so formadas

Arquitetura Orientada a Servios

24

por sistemas legados executando em diferentes mquinas ou por questes de escalabilidade, onde o desempenho do sistema vital para a resoluo do problema proposto. Mais do que isso, geralmente aplicaes orientadas a servios so aplicaes distribudas abertas que fazem uso do registro de servios. 2.3. Heterogeneidade Ambiental O fenmeno da Internet apresentou uma nova realidade para os desenvolvedores de sistemas, principalmente os sistemas de informao cooperativos onde diferentes fontes de informao so agregadas com o objetivo de aumentar a quantidade de informaes disponveis para o usurio (vide Figura 2). Por ser uma rede de escala gigantesca existem uma infinidade de recursos distintos que podem ser acessados atravs da rede. Tais recursos podem ser no s
PUC-Rio - Certificao Digital N 0210486/CA

informaes puras mas tambm na forma de acesso a outros sistemas de informao [Meijler e Nierstrasz, 1997]. Como atualmente at mesmo pequenas redes locais so heterogneas, pois so compostas de plataformas de hardware e software distintas, a dificuldade da criao de sistemas de informao cooperativos aumenta consideravelmente.

Information Bus

Figura 2 - Sistemas de Informao Cooperativos

O cenrio traado tenta mostrar a necessidade de um sistema se comunicar mesmo em ambientes altamente heterogneos. Alm disso, os ambientes podem ser dinmicos, onde no possvel saber durante a elaborao do sistema quais sero os componentes (e em que plataformas estaro sendo executados) que iro compor o sistema no futuro. Sistemas baseados em uma arquitetura orientada a servios so tipicamente sistemas cooperativos abertos. Dessa natureza decorre a necessidade de que sistemas baseados em SOA ofeream suporte a ambientes heterogneos. Em geral

Arquitetura Orientada a Servios

25

os componentes dos sistemas (ou servios) esto executando em mquinas distintas, ainda que sejam mquinas virtuais distintas (no caso de linguagens interpretadas como Java), e precisam se comunicar de alguma forma. Esta comunicao pode ser feita atravs de um protocolo padronizado ou sobre um protocolo proprietrio, o importante que esteja bem definido. Atualmente tem se optado por usar protocolos padronizados sobre TCP/IP. Ainda neste capitulo sero mais aprofundadas as questes de distribuio e de protocolos. Uma das reas onde arquitetura orientada a servios mais vem sendo empregada a integrao de aplicaes corporativas (EAI Enterprise Application Integration), onde as aplicaes legadas j constitudas esto executando em diversas plataformas, desde linux em micro computadores at OS/390 em mainframes. Para tanto, criam-se adaptadores que acessem as
PUC-Rio - Certificao Digital N 0210486/CA

aplicaes legadas e se comuniquem atravs do protocolo definido pelo sistema. O sistema por sua vez, disponibiliza as informaes agregadas fornecidas pelas diversas aplicaes legadas, preferencialmente sem ter que reescrever uma s linha de cdigo do legado. 2.4. Composio Os sistemas desenvolvidos at pouco tempo eram tipicamente fechados, de maneira que caso fosse necessria uma extenso era preciso criar outra aplicao e comp-la de maneira a ficar transparente ao usurio [Szyperski, 1996]. Mas esta outra aplicao era de fato uma outra aplicao independente. O conjunto de aplicaes independentes podia ser visto como um sistema, tipicamente unidas por um menu nico. Com o uso da orientao a objetos e o encapsulamento, passou a ser possvel compor distintas aplicaes com alguma alterao de cdigo (alterao menos significativa que no desenvolvimento com linguagens procedurais). Como atualmente os requisitos de um sistema mudam muito rapidamente [Schneider e Nierstrasz, 1999], a orientao a objetos por si s no resolve o problema da composio de aplicaes. Mesmo uma pequena alterao de cdigo pode causar um grande impacto no sistema. O ideal perseguido compor ou recompor aplicaes sem tocar em cdigo j constitudo e devidamente testado.

Arquitetura Orientada a Servios

26

Desenvolvimento orientado a componentes disponibiliza uma maior flexibilidade, separando claramente algumas partes de uma aplicao (componentes) atravs de interfaces bem definidas (caixa-preta). Os primeiros casos de sucesso da composio de componentes foram os construtores de aplicao visuais como Delphi e Visual Basic, porm eles geralmente eram restritos a um certo domnio de aplicao. Delphi, por exemplo, focava em aplicaes de banco de dados para o sistema operacional Windows [Schneider e Nierstrasz, 1999]. Como compor esses componentes de maneira simples e eficiente com a menor quantidade de cdigo passou a ser uma rea da cincia da computao bastante explorada. Alguns modelos formais e frameworks conceituais foram propostos e deram origem a uma srie de linguagens especificas para composio
PUC-Rio - Certificao Digital N 0210486/CA

de componentes como Piccola [Schneider e Nierstrasz, 1999], CLAM [Sample et al, 1999] e MANIFOLD [Arbab et al, 1993]. Com o uso cada vez maior de linguagens reflexivas, como Java ou C#, a tarefa de composio de componentes tornou-se menos complexa, pois passou a ser razovel em tempo de execuo carregar novos componentes e atravs de reflexo invocar mtodos especficos de uma interface definida anteriormente. 2.5. Coordenao Em uma arquitetura orientada a servios, to importante quanto a composio a coordenao. A diferena entre composio e coordenao que a coordenao est mais intimamente ligada com sincronizao, ordenao e temporizao, enquanto composio trata mais da combinao de elementos em um todo. Porm, a composio apropriada dos elementos um pr-requisito para a coordenao [Sample et al, 1999]. Em sistemas abertos e distribudos, como tipicamente so os ditos orientados a servios, um modelo de coordenao altamente recomendvel, facilitando o dinamismo e a adaptabilidade (sero vistos mais adiante). Para facilitar a criao do modelo de coordenao, foram criadas algumas linguagens de coordenao. Uma linguagem de coordenao tem o propsito de permitir que duas ou mais partes (componentes) se comuniquem com

Arquitetura Orientada a Servios

27

o objetivo de coordenar operaes visando um mesmo objetivo compartilhado por ambas as partes. Na literatura acadmica, as linguagens de coordenao tm sido usadas principalmente para a coordenao de agentes paralelos e concorrentes. Exemplos de tal aplicao so linguagens como Linda [Carriero e Gelenter, 1989] ou Bonita [Rowstron e Wood, 1997] Na indstria, coordenao est mais relacionada a modelagem de processos de negcios (BPM Business Process Management), onde a linguagem usada tenta descrever intimamente como funciona o processo da corporao, sempre executando uma coordenao entre os agentes que executam cada passo no processo todo. A Figura 3 apresenta um exemplo de um processo de negcios. Exemplos de linguagens com esse intuito so BPEL/BPEL4WS [IBM, 2003].
PUC-Rio - Certificao Digital N 0210486/CA

Iniciar processo de compra

Verifica estoque

Possui Item ?

Cancela processo de compra

Finaliza processo de compra

Figura 3 - Exemplo simplificado de um processo de negcio.

Esse tipo de linguagem trata principalmente de questes como distribuio de tarefas e sincronia na execuo das mesmas. Geralmente, todas requisies enviadas para um determinado sistema so endereadas a um controlador (engine) que utiliza a descrio do processo (na linguagem apropriada) para coordenar as requisies enviadas aos servios, bem como receber as respostas e repass-las ao cliente que iniciou o processo.

Arquitetura Orientada a Servios

28

2.6. Dinamismo e Adaptabilidade Criar sistemas dinmicos sempre foi um dos grandes desafios tecnolgicos encontrados por desenvolvedores. O isolamento de parte das aplicaes em bibliotecas de ligao dinmicas, como DLLs e SOs, foi um grande passo para dinamizao dos sistemas. Caso algum requerimento fosse alterado, alteravam-se estas bibliotecas e o sistema estava evoludo. O uso da carga dinmica de bibliotecas, aliado a informaes de tipo em tempo de execuo, como RTTI (Runtime Type Information) de C++, sempre possibilitou um dinamismo e adaptabilidade. Porm, a complexidade de escrever cdigo para sistemas com carga dinmica praticamente exclua esta possibilidade. muito difcil encontrar sistemas aptos a se adaptar a diferentes bibliotecas em
PUC-Rio - Certificao Digital N 0210486/CA

tempo de execuo. O advento das linguagens reflexivas alterou o panorama da dinamicidade dos sistemas. A invocao de mtodos de forma dinmica, e a introspeco dos dados de um objeto e dos metadados de uma classe, facilitou e muito a construo de sistemas dinmicos. Claro que essa mgica no ocorre sozinha. preciso que o sistema seja construdo sabendo da possibilidade da alterao em tempo de execuo. Um exemplo simples de um sistema elaborado levando em considerao a possibilidade de evoluo pode ser alcanado usando uma linguagem como Java onde existe o conceito de interfaces implementado diretamente na linguagem. Neste caso necessrio que o desenvolvedor sempre utilize as interfaces como tipos de dados, em vez da prpria classe que implementa a interface referida.
public void doSomething() { Vector vet = new Vector(); vet.add(2); } public void doSomething2() { List vet = new Vector(); vet.add(2); } public void doSomething3() { List vet = (List)getDesiredClass().newInstance();

Arquitetura Orientada a Servios

29

vet.add(2); } Quadro 1 Uso de Interfaces em Java

O Quadro 1 mostra um exemplo de como se aplicar o conceito de interfaces usando a linguagem Java. Neste exemplo existem trs mtodos distintos que fazem a mesma ao. O primeiro instancia um objeto da classe Vector e tem seu tipo amarrado. O segundo usa omo tipo a interface List e instancia um objeto da classe Vector. J o ltimo, busca a classe que implemente a interface List atravs de um mtodo. Para efeito de evoluo o ltimo mtodo mais razovel. Por questes de desempenho os dois primeiros so mais recomendveis. Os sistemas abertos so dinmicos por definio. Como aplicaes
PUC-Rio - Certificao Digital N 0210486/CA

orientadas a servios so sistemas abertos, pode-se dizer que tambm so dinmicas. Aplicaes orientadas a servios conseguem se adaptar s mudanas de requerimentos com facilidade. Os servios podem entrar e sair do sistema em tempo de execuo, tipicamente se comunicando com o registro de servios atravs de mensagens de publicao ou de despublicao. Alm disso, geralmente os sistemas nunca fazem referncia direta ao servio e sim a uma interface para o servio, possibilitando dinamismo. 2.7. Estado O estado de um componente pode ser dividido em duas classes distintas: persistente ou de sesso. Estado Persistente definido quando existe a possibilidade de pelo menos uma das partes de persistir dados trocados na comunicao entre as partes. Quando dados de uma mensagem enviada a um determinado componente podem ser recuperados aps a troca de mensagens em qualquer instante de tempo, esse dado foi persistido. Um exemplo clssico uma mensagem enviada a um servidor de banco de dados. Um cliente pode enviar uma mensagem contendo alguns dados, que posteriormente podem ser recuperados atravs de uma outra mensagem em um outro momento. No Quadro 2 so apresentadas dois tipos de mensagens na forma de comandos em SQL, uma para persistncia de dados e outra para recuperao dos mesmos dados.

Arquitetura Orientada a Servios

30

INSERT INTO Tabela VALUES(1, 25, Joao, 1200) SELECT * FROM Tabela WHERE is = 1 Quadro 2 Exemplo de duas mensagens (comandos em SQL).

J o Estado de Sesso diz respeito ao estado dos componentes somente durante a comunicao ou sesso. Uma vez finalizada a sesso entre os componentes, o estado desfeito e seus dados so liberados. Este tipo de estado importante para manter o andamento de operaes mais complexas como, por exemplo, troca de mensagens assncronas (a prxima seo ir explicar melhor este tema). O estado de sesso tipicamente obtido atravs da gerao de um identificador nico para a sesso, compartilhado as partes. Ao se iniciar a sesso,
PUC-Rio - Certificao Digital N 0210486/CA

esse identificador gerado e deve ser usado em chamadas subseqentes. O final da sesso deve ser explicitado para que o estado possa ser desfeito. Em ambientes distribudos esse tipo de estado bem mais complicado de ser implementado, pois envolve a questo da coleta de lixo distribuda, uma vez que no possvel garantir que ambas as partes estejam conectadas at o final da conversao. Tipicamente, sistemas baseados em arquiteturas orientadas a servios so construdos apenas com componentes que no possuem estado de sesso. Um dos motivos para essa escolha que geralmente essas aplicaes so distribudas e por isso quanto menos mensagens forem trocadas entre os componentes, melhor desempenho o sistema vai obter. Em uma aplicao que possui estado de sesso, a quantidade de mensagens trocadas tipicamente maior. Outro fator essencial para que os servios no possuam estados, o acoplamento. Uma sesso com estado implica em um acoplamento maior, uma vez que mais mensagens so trocadas. Como atualmente grande parte das aplicaes SOA so construdas por XML Web Services, o uso do estado de sesso pequeno. Isto por que normalmente os componentes destes sistemas se comunicam atravs de SOAP sobre HTTP, que um protocolo sem suporte a conexo. Com isso, para se obter estado atravs desse protocolo necessrio uma terceira parte envolvida na comunicao para controlar, se possvel de forma transparente, a identificao das sesses que possam estar acontecendo. Alm disso, como citado anteriormente, o

Arquitetura Orientada a Servios

31

problema da coleta de lixo distribuda afeta diretamente a escalabilidade desses sistemas que so por natureza construdos para serem escalveis. 2.8. Sincronia A troca de mensagens, seu modo de transmisso e a semntica so partes fundamentais em sistemas distribudos, pois so a nica maneira que os componentes possuem de se comunicar e sincronizar suas aes [Charron-Bost et al, 1996]. possvel classificar a troca de mensagens quanto a sincronia entre os componentes em: comunicao assncrona e comunicao sncrona. Comunicao Assncrona usualmente definida quando o processamento do componente que enviou a mensagem (sender) no bloqueado (non-blocking)
PUC-Rio - Certificao Digital N 0210486/CA

a espera do desfecho da mensagem. J Comunicao Sncrona ocorre quando o processamento bloqueado (blocking) at que o desfecho ou retorno da mensagem seja completado. Nenhuma das abordagens pode ser considerada superior a outra. Apesar da comunicao assncrona ter menos possibilidade de deadlocks, e em geral oferecer maior paralelismo (pois no h bloqueio do processamento), ela precisa de tratamento de fluxo e buferizao de dados complexos, o que dificulta sua implementao. Alm disso, possvel simular um tipo de comunicao usando a outra, usando buffers intermedirios (simulao de comunicao assncrona) ou bloqueando explicitamente o processamento at o recebimento da resposta (simulao de comunicao sncrona) A discusso de sincronia em ambientes distribudos passa pela necessidade da existncia de um estado de sesso (como definido na seo anterior). As aplicaes orientadas a servios atuais so geralmente sncronas devido inexistncia do estado de sesso na maioria dos protocolos usados para comunicao, principalmente protocolos sobre HTTP. Existem algumas aplicaes que usam comunicao assncrona simulada por comunicao sncrona, onde geralmente um servidor atua como intermedirio criando um buffer de mensagens e identificando de uma forma proprietria (isto no padronizada) a conversao. O problema neste caso que esta intermediao e identificao proprietria acabam restringindo o uso dos componentes por terceiros, diminuindo

Arquitetura Orientada a Servios

32

assim a heterogeneidade que uma das caractersticas importantes de sistemas baseados na arquitetura orientada a servios. 2.9. Robustez de Protocolos Recorrendo definio de arquitetura de software descrita no incio deste captulo, vemos que o relacionamento entre os componentes, tanto interna quanto externamente ao sistema, fundamental para o desenvolvimento de um software. Este relacionamento tipicamente ocorre atravs de uma comunicao entre as partes baseadas em um protocolo de comunicao. Um protocolo um conjunto de regras formais que definem como os dados devem ser transmitidos de uma parte para a outra [Webmaster, 2003]. Qualquer tipo de comunicao entre partes
PUC-Rio - Certificao Digital N 0210486/CA

necessita de um protocolo, at mesmo a invocao de um mtodo local regida por um protocolo (neste caso trata questes como ordem dos parmetros na pilha, localizao do valor de retorno, etc...). Porm, em ambientes distribudos (principalmente se forem heterogneos), onde as partes esto conectadas atravs de uma rede de comunicao, os protocolos so mais relevantes. Questes como desempenho, robustez e segurana so muito importantes de serem consideradas nestes cenrios. Esta seo ir se ater a questes da robustez dos protocolos. Robustez de protocolos definida neste trabalho como a liberdade dada aos componentes envolvidos em uma comunicao de evoluir sem quebrar a comunicao. Por exemplo, um cliente acessando um determinado dado em um servidor deve continuar a funcionar mesmo que o servidor evolua e passe a fornecer mais informaes, ou altere um ou mais dados. Protocolos baseados em texto, como XML-RPC ou SOAP, levam vantagem em relao a protocolos binrios, como IIOP ou JRMP (um dos protocolos usados pelo RMI de Java), na questo da robustez. Uma pequena alterao em uma mensagem binria pode levar a uma mudana total no entendimento da mesma. No caso de protocolos baseados em texto, isso tambm pode acontecer, mas a probabilidade bem menor. Os protocolos binrios so ditos mais sensveis a pequenos rudos em suas mensagens. Alm disso, protocolos baseados em texto tipicamente so autodescritivos no que diz respeito a tipagem dos seus dados, tornando mais fcil uma alterao no tipo dos dados. O Quadro 3 mostra uma

Arquitetura Orientada a Servios

33

mensagem XML-RPC, totalmente tipada que exemplifica isso. Nesta mensagem, o tipo do parmetro descrito pelo tag <i4>, que define o dado (41) como um inteiro de quatro bytes com sinal.
<methodCall> <methodName>examples.getStateName</methodName> <params> <param> <value><i4>41</i4></value> </param> </params> </methodCall> Quadro 3 - Exemplo de mensagem XML-RPC.
PUC-Rio - Certificao Digital N 0210486/CA

Pedido
<QUERY> <ISBN>0595250777</ISBN> </QUERY>

Resposta 1
<RESPONSE> <TITLE>Realities of Foreign Service Life</TITLE> </RESPONSE>

Resposta 2
<RESPONSE> <TITLE>Realities of Foreign Service Life</TITLE> <AUTHOR>Patricia Linderman</AUTHOR> </RESPONSE>

Figura 4 Exemplo da possibilidade de evoluo de protocolos baseados em texto com mensagens descritas por XML.

Outro ponto a ser considerado, no que diz respeito evoluo, a incluso ou excluso de dados (e no somente a alterao de tipo). Metalinguagens de descrio de dados como XML auxiliam neste ponto. Usando XML para a troca de informaes, possvel evoluir um servidor de maneira que os clientes

Arquitetura Orientada a Servios

34

continuem acessando normalmente sem que notem qualquer diferena. A Figura 4 apresenta esta possibilidade de evoluo, a partir de um protocolo baseado em XML. O pedido para o componente que ir fazer uma consulta a um banco de dados sobre livros sempre o mesmo. passado como parmetro um identificador nico para um livro. Em determinado instante o servidor devolve como resultado da consulta o ttulo do referido livro (resposta 1). Eventualmente, o componente que executa tal ao evolui de forma a passar a retornar como resultado da consulta, alm do ttulo, o autor do livro (resposta 2). Os clientes que foram construdos para receber a resposta 1 iro continuar a funcionar normalmente, e novos clientes podem ser construdos para que considerem a resposta 2, onde consta o autor do livro. Esta possibilidade de evoluo que
PUC-Rio - Certificao Digital N 0210486/CA

torna os protocolos autodescritivos mais robustos. importante ressaltar que protocolos autodescritivos possuem o grande problema da falta de desempenho, pois as mensagens so necessariamente maiores que em protocolos no autodescritivos. Por tal razo, para aplicaes onde o desempenho relevante, a escolha de protocolos descritos externamente mais apropriada. Tipicamente, protocolos binrios no so autodescritivos e recomendveis para aplicaes que necessitam de desempenho. Aplicaes orientadas a servios necessitam que os protocolos de comunicao sejam robustos, pois so altamente dinmicas e podem ser alteradas constantemente. A grande maioria das aplicaes orientadas a servios atuais utiliza como protocolo de comunicao o SOAP, que um protocolo baseado em XML, o que comprova a preferncia desta classe de protocolos apesar do baixo desempenho.