F UNDAMENTOS DE SOA E WEB SERVICES

Relatrio Tcnico

Nmero do relatrio pegar com o gerente!

A implementao de uma arquitetura distribuda envolve diversas variantes, que so determinadas, entre outras coisas, pela situao da empresa onde ser implementada a soluo. Porm, independentemente dessas variantes, os conceitos bsicos da arquitetura, bem como os fundamentos de sua estrutura, sempre devem ser o alicerce de qualquer implementao. Nesse relatrio so descritos os fundamentos de uma arquitetura orientada a servios, bem como uma introduo ao desenvolvimento de seus servios e a web services, que so a principal forma de implementao desses servios.

Felipe de Castro Santana Abril de 2009

Grupo de Estudos em interao do LTS Escola Politcnica da Universidade de So Paulo

Abril de 2009

FUNDAMENTOS DE SOA E WEB SERVICES

Relatrio Tcnico

CONTROLE DE REVISES

No. 00 01 02 03 04 05

Data 03/03/2009 23/03/2009 06/04/2009 25/04/2009

Reviso Flavio Myiamaru Flavio Myiamaru Flavio Myiamaru Flavio Myiamaru

Proj.RT.NNN.vv

Abril de 2009

INTRODUO
Objetivo: Esse documento possui como objetivo ilustrar e resumir os conhecimentos adquiridos durante as etapas de estudo iniciais sobre web services e arquitetura orientada servios. Esses estudos tiveram vital importncia na construo dos conhecimentos necessrios para a implementao de uma arquitetura distribuda que atendesse s necessidades do framework. A partir de um contedo terico foi possvel saber quais seriam os passos iniciais para projetar e implementar a soluo SOA para o projeto XGov.

Justificativa: O projeto X-Gov visa a construo de um framework para o desenvolvimento de aplicaes do governo na plataforma de mdias cruzadas. Seu principal objetivo vencer as barreiras impostas entre o usurio e os servios de governo eletrnico, de modo que a falta de acesso internet no impedir que qualquer cidado possa dispor de todos os servios de governo. Assim, utilizando as mdias cruzadas em favor do governo, o projeto X-Gov possibilitar que cidado tenha sua disposio diversas maneiras e opes de transies a serem feitas para utilizar qualquer servio, o que aumentar o acesso do governo ao cidado e vice-versa. No framework X-Gov, os servios do governo sero disponibilizados atravs dos componentes criados pela equipe; estes foram desenvolvidos em diferentes plataformas para diferentes canais de comunicao, e devem se intercomunicar de modo que possa haver troca de dados entre eles. Alm disso, a arquitetura do framework deve possibilitar as transies entre componentes de diferentes canais, sem que haja conflitos de dados durante a transio; de modo que os dados do usurio e do processo devem ser mantidos quando ele desejar sair do computador e continuar a preencher um formulrio pelo celular (1). Dessa maneira importantssimo para o funcionamento do framework que haja uma arquitetura que possibilite essa intercomunicao entre os componentes, bem como a troca de dados entre eles, de modo que os componentes possam obter dados do sistema atravs de uma interface comum sua funcionalidade, ou realizar processos independentemente da tecnologia utilizada para desenvolv-los ou da sua estrutura interna. Nesse contexto, os estudos desenvolvidos puderam fornecer os conhecimentos sobre os fundamentos de SOA e web services, de maneira que a implementao da arquitetura citada acima pudesse ser modelada a partir do desenvolvimento de uma soluo orientada a servios, implementados atravs dos web services a serem desenvolvidos.

Conteudo: Esse relatrio contm alguns o contedo de alguns resumos feitos durante as etapas de pesquisa; abrangendo assuntos como os fundamentos de SOA e web services, bem como o desenvolvimento dos servios para uma arquitetura SOA. Na primeira parte, so abordados os principais conceitos que envolvem

Proj.RT.NNN.vv

Abril de 2009 arquitetura orientada a servios (SOA). Na segunda h uma introduo a web services, de maneira que so abordados web services SOAP e REST separadamente, com seus principais conceitos e caracetrstica; e posteriormente, uma comparao entre os dois tipos. Por fim, na terceira e ultima parte, so apresentados os aspectos do desenvolvimento dos servios de uma arquitetura SOA, como o ciclo de vida dos servios, no qual so descritos com enfoque mais prtico a classificao e a identificao desses servios. Esse documento apresenta os conceitos fundamentais que envolve SOA e web services, o se contedo no apresenta nenhum enfoque s tecnologias utilizadas, nem a outros conceitos que envolvam situaes mais especficas de algumas implementao da arquitetura SOA. Porm ele apresenta um fundamento terico que sobre arquitetura orientada a servios, bem como oferece um enfoque prtico nos primeiros passos do desenvolvimento desse tipo de arquitetura. Portanto ele oferece os requisitos fundamentais para os primeiros passos do desenvolvimento de uma arquitetura SOA, que foi at onde se seguiu, at o momento, no projeto. O contedo apresentado aqui segue a seguinte ordem:

1. Tpicos bsicos e principais conceitos de SOA. 2. Ciclo de vida de um servio e aspectos prticos sobre a classificao e identificao de servios. 3. Conceitos bsicos sobre web services SOAP e REST, e uma breve comparao entre os dois tipos.

1. Introduo ao SOA
Neste resumo sero passados tpicos bsicos de SOA, bem como caractersticas bsicas de sua implementao, a base do seu funcionamento e alguns dos aspectos bsicos de servios. Muitos sistemas de grandes empresas, hoje em dia, so legados de antigas geraes de gerncias de TI, que viviam em um mundo onde os sistemas eram projetados com o nico intuito de funcionar. Eles conseguiram, pois os sistemas funcionam at hoje; porm cada parte do sistema se comunica diretamente uma com a outra, e a medida que o sistema cresce essa rede de comunicaes torna-se um emaranhado confuso e ilegvel; e a qualquer necessidade de mudana, todo o sistema deve ser modificado, tornando-se indisponvel e trazendo grandes prejuzos. Nesse cenrio, Arquitetura orientada a servios (SOA) um modelo conceitual de arquitetura que prope a representao das funcionalidades de um sistema atravs de servios, que podem ser consumidos por aplicaes diferentes atravs de interfaces bem definidas, legveis do ponto de vista dos negcios e independente da plataforma de desenvolvimento das aplicaes. SOA possibilita que as funcionalidades de um sistema possam ser divididas em tarefas e abstradas como servios, que sero consumidos pelas aplicaes do sistema. Esses diferentes servios so entidades que podem se intercomunicar, ser combinadas para formar processos mais complexos, ou utilizadas em diversas tarefas atravs de uma interface comum, independentemente da plataforma de desenvolvimento das aplicaes. Esse funcionamento acrescenta muito ao sistema em termos de interoperabilidade, reusabilidade, flexibilidade e baixo acoplamento. Como dito acima, SOA uma modelo conceitual de arquitetura, ou seja, SOA no ferramenta de desenvolvimento, ou um produto de software que voc compre. SOA um paradigma, um estilo de desenvolvimento largamente utilizado para sistemas distribudos de grande porte. Portanto, a maneira com a qual SOA implementado depende apenas do gerenciamento de TI da empresa ou de um projeto (como o

Proj.RT.NNN.vv

Abril de 2009 xgov), que vai determinar a infraestrutura e a arquitetura que melhor se adaptaro s suas necessidades de negcios. Segundo JOSUTTIS, N[1], o funcionamento de SOA baseia-se em trs conceitos: servios, interoperabilidade e baixo acoplamento: Assim como SOA, o conceito de servio possui diversas definies. Segundo a wikipedia (26 de janeiro de 2009)[2], servio refere-se a um conjunto de funcionalidades de negcio; segundo OASIS[3], servio um mecanismo para permitir o acesso a uma ou mais funcionalidades de um sistema, onde esse acesso feito atravs de uma interface bem definida. Portanto, servio pode ser dito como um conjunto de funes, abstraes de funcionalidades de negcios de um sistema com uma interface bem definida. Uma das principais preocupaes em um ambiente de computao distribuda a comunicao entre diferentes sistemas, de modo que esses possam agir conjuntamente sem que haja conflitos na troca de informaes entre eles. Essa comunicao entre as diferentes partes de um sistema chamada de interoperabilidade; qualquer implementao de SOA deve levar em conta esse conceito. Existem diversas tecnologias que visam prover interoperabilidade em um sistema distribudo; uma das mais utilizadas o Enterprise Service Bus (ESB) que prope um barramento servindo de intermedirio entre os servios e os consumidores de servios, no existindo mais as comunicaes ponto-a-ponto que diminuem a flexibilidade do sistema. O ESB disponibiliza recursos para localizar e coordenar servios, bem como para mediar a comunicao entre os servios e os consumidores. Baixo acoplamento um conceito vital para o funcionamento de um sistema distribudo. Esse conceito determina que diferentes partes e funcionalidades de um sistema sejam independentes umas das outras, dessa maneira, alteraes ou problemas em certas partes do sistema no traro grandes conseqncias para o resto do sistema, trazendo grandes benefcios como escalabilidade, flexibilidade e tolerncia a falhas.

Funcionamento do SOA:

Proj.RT.NNN.vv Figura1 Funcionamento de SOA

Abril de 2009 O mecanismo representado na figura 1 funciona da seguinte maneira: O consumidor de servios busca um servio atravs do service broker, este encontra o servio procurado atravs de suas especificaes, depois disso o consumidor faz a requisio ao provedor de servios seguindo os protocolos especificados, essa relao representada pelo bind da figura. O service broker tem o papel de fazer o intermdio entre o consumidor (cliente) e o provedor de servios; ele identifica os servios requisitados pelo cliente. Dessa maneira o cliente no precisa saber sempre qual a localidade do servio desejado, o que diminui a dependncia entre o consumidor e o provedor de servio. Em muitas implementaes de SOA, quem faz o papel do broker o ESB, citado anteriormente.

Aspectos importantes:
importante notar que se a estrutura da soluo no for bem projetada, estaremos diante de uma arquitetura muito distante da SOA. Um dos principais fatores para que o projeto de uma soluo SOA seja bem feito, como os servios so projetados. Ao projetar os servios, deve se levar em conta alguns aspectos bsicos que determinaro o seu comportamento e o da aplicao.

Interface do servio:
Primeiramente, como dito na prpria definio de servios, eles devem ter uma interface bem definida. A interface define as funcionalidades que um servio possui, sem ela seria impossvel que o broker identificasse os servios para um consumidor. Em SOA, definir a interface de um servio, bem como o seu funcionamento chamado de choreography. Alm disso, outra coisa que deve ser bem especificada contrato de servio, que determina quais so os parmetros que o consumidor deve seguir para consumir um servioe quais so os dados retornados pelo servio. Essas especificaes do contrato de um servio definem as chamadas pre-conditions e pos-conditions de um servio. Ainda pensando na interface do servio, uma coisa que se deve levar em conta que ela deve ser projetada de modo que seja legvel de um ponto de vista dos negcios, ou seja, um consumidor no precisa conhecer os detalhes tcnicos da interface de um servio para poder us-lo, separando a interface da implementao do servio; a isso se da o nome de business-driven design, oposto ao technical-driven design. Essa interface um dos principais fatores que colaboram para o baixo acoplamento de uma soluo SOA, pois elas estabelecem um modelo uniforme pelo qual o consumidor vai interagir com um servio. De maneira que mesmo se houver uma mudana na implementao do servio, no precisar haver mudana alguma na aplicao consumidora para usar o servio modificado; separando a implementao do servio de sua interface.

Granularidade:
Outro aspecto muito importante o grau de granularidade do servio, ou seja, a especificidade da funcionalidade que ele representa; esse fator influencia em muitos outros fatores importantes como a reusabilidade dos servios e a sua chamada composabilidade(explicados a seguir). Em relao granularidade, existem dois termos muito comuns usados para definir esse conceito; a grossa glanularidade (coarse-granularity) e a fina granularidade (fine-granularity). A primeira se refere a servios mais abrangentes, que englobam funes complementares de um sistema, sua principal vantagem que para consumi-los necessrio apenas uma requisio, o que aumenta a performance do sistema; porm, eles comprometem a flexibilidade do sistema, visto que no podem ser recombinados para outras tarefas. A

Proj.RT.NNN.vv

Abril de 2009 segunda se refere aos servios mais especficos, que representam tarefas mais bsicas que podem ser combinadas para formar tarefas mais complexas de um sistema; esses servios so essenciais para a flexibilidade do sistema, porm, o maior numero de requisies necessrias prejudica a sua performance.

Reusabilidade e composabilidade:
O termo reusabilidade de um servio refere-se ao fato de ele poder ser reutilizado em outras funcionalidades diferentes. Um dos principais focos de SOA aumentar a reusabilidade de um sistema; como dito acima, quanto mais granulares (especficos) so os servios, mais reutilizveis eles so, porm nem sempre isso til para o sistema. Quanto composabilidade, refere-se ao fato de um servio poder se relacionar de modo que ambos tornem-se um nico servio composto. Servio compostos um servio compostos por vrios servios contidos em diferentes sistemas, de maneira que eles sejam consumidos em uma tarefa. Por exemplo, um servio de cadastramento de usurio chamado em um sistema, para manter a confiabilidade do sistema esse servio composto com outros servios de cadastramento de usurio de outros sistemas, de modo que todos sejam acionados tambm. Quanto mais granulares so os servios, maior a sua composabilidade.

Arquitetura e infraestrutura:
Segundo JOSUTIS. N[1], arquitetura e infraestrutura so dois dos chamados ingredientes da SOA. Arquitetura a maneira como voc implementa SOA, ou seja, como voc define os fatores importantes para SOA, como voc define os servios de seu sistema, sua granularidade e classificao; bem como outras configuraes como o baixo acoplamento. Infraestrutura a maneira como voc vai implementar a arquitetura do sistema, como a configurao das comunicaes dos sistemas e servios, bem como sua interoperabilidade, em muitos casos, a infraestrutura definida a partir do ESB, citado anteriormente. importante destacar que o fato de uma aplicao ser baseada em servios no quer dizer que uma aplicao com SOA, para isso teria de obedecer tambm aos outros dois conceitos bsicos, interoperabilidade e baixo acoplamento. Por isso deve se tomar cuidado ao implementar a arquitetura SOA, muitas vezes passa-se simplesmente a representar as funcionalidades como servio e acha-se que uma soluo SOA. Porm se, pelo menos, os fatores acima no forem levado em conta, a soluo implementada no traz os benefcios da SOA (agilidade,flexibilidade e escalabilidade), ento no uma soluo SOA. Pelo que foi dito, deve-se perceber que implementar SOA pode trazer muitos benefcios a sistemas distribudos, porm demanda um investimento muito grande projetar a arquitetura de modo que atenda s necessidades do sistema. Por tanto, importante ter certeza de SOA a soluo e de que poder ser bem implementada na empresa, do contrrio ela no ser uma soluo, e sim mais um grande problema.

2. Desenvolvimento de servios em SOA:

Nesse captulo sero abordados o ciclo de vida dos servios, bem como os aspectos prticos da identificao e classificao dos servios.

Proj.RT.NNN.vv

Abril de 2009 Em uma soluo orientada a servios, uma das principais preocupaes para o seu funcionamento adequado a maneira como os servios so desenvolvidos. Por isso existem muitos estudos abrangendo novas estratgias para que eles sejam projetados de maneira com que possam atender s necessidades do sistema. Neste resumo sero abordadas as principais etapas do ciclo de vida dos servios de uma aplicao SOA, como a classificao, modelagem e design de servios.

Ciclo de vida:
Primeiramente muito importante conhecer o chamado ciclo de vida de um servio. Um servio uma abstrao de um conjunto de funcionalidades de negcios, e como qualquer outra entidade de um sistema, possui um ciclo de vida prprio, onde ele projetado, criado, utilizado e depois descartado. Os temas abordados nesse texto se referem modelagem de servios, que est presente na primeira etapa do ciclo (identificao); porm importante ter um conhecimento sobre as fases pelas quais um servio passa antes de ser utilizado. A figura a seguir ilustra o ciclo de vida dos servios de um sistema SOA.

Pela figura , o ciclo de vida de um servio pode ser dividido da seguinte maneira, segundo JOSUTIS.N[1]:

1.

Identificao:

nessa etapa que os servios so projetados; as funcionalidades do sistema so dividas em servios, estes so separados e classificados de acordo com as suas caractersticas e utilidades. a etapa mais importante para um servio em relao sua atuao no sistema, pois nela so definidos atributos muito importantes como a granularidade, funo do servio no sistema e sua relao com outros servios. Mais adiante a identificao e classificao de servios sero abordados nesse documento.

Proj.RT.NNN.vv

Abril de 2009

2.

Design:

Essa a etapa posterior identificao dos servios; aps definir quais sero os servios de um sistema, preciso definir como ele se comunicar com o resto do sistema e com as aplicaes consumidoras. Nessa etapa sero definidos protocolos de comunicao entre os servios e a aplicao consumidora; alm disso, so definidas as interfaces do servio e atributos no-funcionais, como a durao do servio. Nenhum procedimento feito nessa etapa ser abordado no documento.

3.

Implementao:

Nessa etapa os servios so construdos e implementados no sistema atravs de uma determinada tecnologia. Na grande maioria dos casos, os web services so utilizados para implementar os servios. Alm disso, nessa etapa so identificados alguns erros, que possam ter sido cometidos durante o design dos servios.

4.

Teste e integrao:

Essa a fase onde os servios implementados so integrados ao sistema SOA, aqui que se verifica na prtica se o servio foi realmente bem projetado. muito comum que testes feitos nessa fase levem novamente s etapas 1 ou 2, e s depois disso que os servios estaro realmente bem projetados.

Classificao de servios:
Um dos principais passos a modelagem de uma soluo SOA a classificao dos servios. Em uma arquitetura orientada a servios, existem inmeros servios com caractersticas e funes muito distintas; alguns tm a funo de apenas ler dados, outros de apenas escrever, outros de processar informaes, e assim por diante. Portanto, no faria sentido que todos os servios fossem tratados da mesma maneira, logo preciso que os servios sejam qualificados de acordo com as caractersticas mais relevantes no caso. Porm, importante notar que maneira como se classifica os servios de uma soluo SOA no deve seguir uma receita de bolo, os responsveis pela modelagem dos servios devem desenvolver a classificao que mais se adapte s necessidades do sistema e da empresa; o que ser passado aqui apenas um guideline para a modelagem de servios. Nesse resumo, sero abordadas duas das principais maneiras de se classificar servios.

Classificao de Thomas Earl[4]:

A classificao usada por Thomas Earl divide os servios segundo suas funcionalidades; segundo ele, os servios devem ser divididos em trs camadas, que contm diferentes tipos de servios cujo escopo da funcionalidade o mesmo; ou seja, em uma camada existem diferentes tipos de servio com diferentes funcionalidades, porm todos eles agem em um determinado setor do sistema. As camadas Application service layer, Business service layer e Orchestration service layer so listadas a seguir com uma breve descrio dos tipos de servio nelas encontrados. Application Service layer: A camada de servios de aplicao contm os servios cuja funcionalidade se aplica lgica de uma aplicao, ou seja, representam funes de um determinado back-end (toda e qualquer aplicao que

Proj.RT.NNN.vv

Abril de 2009 funciona em um sistema distribudo, com suas funes dispostas por servios) do sistema. Os servios presentes nessa camada so chamados de servios de aplicao, suas principais caractersticas so a sua reusabilidade e generalidade. Quando a camada de business services (explicada a seguir) implementada, esses servios podem ser compostos em outros servios pelos chamados controller services (Usados para a composio de diferentes servios, localizados normalmente na camada de4 servios de negcios (business service layer). Do contrrio, alguns servios da prpria camada (servios de aplicao) exercem o papel de um controller service, esses servios so conhecidos como servios hbridos. Existem outras classificaes de servios para essa camada, porm ns vamos nos ater aos casos mais simples. Business service layer: Nessa camada esto contidos os servios que implementam lgicas de negcios em suas funcionalidades; eles formam o principal tipo de servio em SOA, j que servios por si prprios representam funcionalidades de negcios. Esses servios podem ser divididos em dois grupos, task-centric business services e entity-centric business services. Task-centric business services: So servios que implementam uma lgica de negcios voltada para um a tarefa especfica, como cadastrar uma conta ou retirar dinheiro de uma conta. Uma caracterstica desses servios que eles no so muito reutilizveis, pois so projetados para atender a um processo no sistema, fazendo com que pequenas mudanas na lgica desse processo se tornem grandes mudanas na implementao do servio. Geralmente esses servios so gerados da quebra dos processos do sistema em casos de uso simples, como verificar a validade de um documento ou autenticar um usurio. Entity-centric business services: So servios que representam funcionalidades voltadas para uma entidade do sistema, como um usurio ou conta-corrente. Devido a serem baseados na lgica das entidades do sistema, esses servios promovem maior agilidade ao sistema do que os task-centric services, pois a sua implementao no depende da lgica dos processos do sistema.

Orchestration service layer: Nessa camada esto presentes os servios utilizados na orquestrao de servios, um termo muito importante em SOA que representa a combinao de diferentes servios mais granulares, formando um workflow para realizar uma funcionalidade determinada. Os servios presentes nessa camada so chamados de process services.

Classificao de JOSUTIS. N[1]:

A classificao a seguir divide os servios de uma aplicao SOA de uma maneira mais simples do que a descrita anteriormente; nessa classificao so apresentados as trs fases de expanso de uma arquitetura SOA em relao aos servios implementados, cada uma delas possui um conjunto de servios. Nessas trs fases de expanso os servios so classificados em Basic services, Composed services e Business services; a figura abaixo mostra um diagrama sobre as fases de expanso de SOA e os tipos de

Proj.RT.NNN.vv

Abril de 2009 servios presentes (para mais informaes sobre as fases de expanso de SOA, ver SOA in practice capitulo 6, JOSUTIS. N[1]).

Basic services: Como o prprio nome diz, so os servios que implementam as funcionalidades mais bsicas de uma aplicao SOA, so servios stateless e que possuem o menor grau de granularidade, por tanto, no h sentido em decomp-los em outros servios. Esses servios encapsulam os detalhes tcnicos da plataforma de execuo de tecnologias especficas de implementao, ou seja, eles podem ser comparados com os Application services da classificao anterior, apesar de representarem apenas funes bsicas do sistema, no podendo ser atribudos combinao de servios. Os basic services fazem parte da fase de expanso de SOA chamada de Fundamental SOA, que contm apenas servios bsicos. Eles podem ser subdivididos em dois outros tipos de servios: Basic Data services: So, basicamente, servios que possuem a finalidade de ler e gravar informaes em um determinado back-end do sistema. Exemplos desses servios so: Retornar uma lista de entidades com uma determinada propriedade. Criar uma nova conta de usurio. Modificar o registro de um hospital.

Basic Logic services: So servios que implementam funcionalidades bsicas de negcios do sistema. Geralmente eles esto em muito menor nmero em relao aos basic data services; exemplos desses servios so: Get track id Create invoice

Composed services:

Proj.RT.NNN.vv

10

Abril de 2009 Servios compostos so aqueles formados por diferentes servios bsicos atravs de uma medida chamada de Orchestration (como em uma orquestra, onde necessrio coordenar o funcionamento simultneo de diferentes instrumentos).Esses servios so stateless e compostos por diferentes servios, pertencentes a diferentes sistemas, que se tornam dependentes um do outro. A fase de expanso que contm esse tipo de servio chamada de Federated SOA, que engloba a Fundamental SOA. Uma das principais utilidades desses servios a manuteno da integridade de dados em diferentes sistemas; como no caso de haver um mesmo registro em dois diferentes sistemas, o servio chamado para fazer a alterao nesse registro ter de manter a consistncia dos dados em ambos os sistemas, fazendo com que a mesma funcionalidade seja executada no s diferentes sistemas atravs de servios dependentes a ele. Alm disso, os servios compostos podem implementar novas funcionalidades que possam ser desmembradas em funcionalidades bsicas j existentes. Esses servios so de muita importncia para uma arquitetura, pois eles aproveitam os recursos fornecidos por servios bsicos para compor funcionalidades mais complexas. Process services: Segundo JOSUTIS. N[1], process services so servios que realizam fluxo de atividades de grande durao, que no podem ser interrompidas por interveno humana. Esto presentes na fase processenabled SOA, que engloba as duas ultimas fases. A caracterstica que distingue esses servios dos servios compostos o fato de eles terem um estado (statefull services), ou seja, eles armazenam o estado do processo corrente de maneira com que este possa continuar do ponto de parada. Um cliente est tentando fazer um agendamento mdico; porm, no meio do processo ele teve de sair do servio. Em um servio stateless o cliente teria de mandar todos os seus dados novamente para comear uma nova requisio para o incio de um novo processo, mas em servios statefull ele no precisa fazer isso, basta recomear o processo de onde tinha parado.

Comparao e Concluso:
A partir das duas classificaes abordadas, pde-se perceber as diferenas entre as duas; principalmente que a classificao especificada por Thomas Erl[4] possui critrios de classificao muito mais detalhados do que a classificao dada por Nicolai Josutis[1]. Mas isso no quer dizer que a primeira classificao melhor que a segunda; como foi dito anteriormente, o mtodo de classificao de servios no uma receita de bolo; deve ser escolhido de forma que atenda s necessidades do sistema. Pelo seu nvel de detalhamento, a classificao de Thomas Erl[4], torna-se inapropriada para o caso de um sistema pouco complexo, que no necessita de tanto detalhamento da soluo. Porm a simplicidade da classificao de Nicolai Joustis[1] leva a uma classificao incompleta dos servios em um sistema. Portanto, em relao ao projeto X-Gov, a melhor escolha em relao classificao que as duas classificaes possam ser usadas conjuntamente, aproveitando a vantagem de cada uma. Ou seja, a classificao de Josutis ser utilizada para descrever os servios de uma maneira mais superficial, ao passo que a classificao de Thomas Erl ser usada para detalhar mais a soluo, em caso de necessidade.

Modelagem de servios (passo a passo):

Proj.RT.NNN.vv

11

Abril de 2009 A modelagem de servios importantssima para o desenvolvimento de uma aplicao SOA, nela os servios so identificados e classificados de maneira que a estrutura da arquitetura atenda s suas necessidades. A seguir falaremos de como deve ser feita a modelagem de servios de um sistema, baseando-se nos passos descritos por Thomas Erl[4]. Nos passos a seguir sero identificados os candidatos a servios de um sistema; importante destacar que os servios identificados aqui no sero necessariamente os servios finais de um sistema, pois durante as fases seguintes do projeto muitos servios so criados ou excludos. Passo 1: Dividir os processos identificados em tarefas. Nesse passo, os processos do sistema sero divididos em tarefas fundamentais, ou seja, elas devem ter a maior granularidade possvel. Deve-se tomar os processos de um sistema e dividi-lo nas tarefas mais bsicas e unitrias possveis; de maneira com que sejam funcionalidades que no possam ser separadas em outras funes menores.

Passo 2: Identificar potenciais operaes de servio. Nesse passo, as tarefas que foram destacadas anteriormente sero analisadas com o intuito de retirar aquelas que no fazem parte da lgica de negcios encapsulada pelo servio, como por exemplo, tarefas automticas do sistema que no necessitam de um servio para a sua realizao, ou processos manuais que no devem ser automatizados pelo sistema.

Passo 3: Criar candidatos a servios. Nesse passo sero criados contextos, nos quais tarefas com caractersticas em comum so agrupadas; cada contexto ser um candidato a servio. O critrio utilizado para a separao das tarefas depende das necessidades do sistema; os critrios mais utilizados na separao so as entidades com as quais as tarefas esto relacionadas, ou um processo formado por diferentes tarefas (esses dois mtodos so citados por Thomas Erl[4], eles se referem classificao dos servios em task-centirc business services e entity-centric business services)

Passo 4: Refinamento e aplicao dos princpios de orientao a servios Neste passo feito um refinamento com os candidatos a servios, identificados anteriormente. Aqui so aplicados dois princpios bsicos da orientao a servios, reusabilidade e autonomia de servios; ou seja, nesse passo vamos transformar os candidatos a servios obtidos, de forma com que eles possa se tornar mais reutilizveis e mais autnomos. Nesta seo no foram abordados todos os passos recomendados por Thomas Erl[4], pois alguns deles so especficos para a sua forma de classificao de servios, especificada aqui; e o objetivo desse resumo passar uma viso geral do processo de modelagem de servios, sem se limitar a solues especficas.

Proj.RT.NNN.vv

12

Abril de 2009

3. Introduo a Web services

Segundo JOSUTIS. N[1], a Microsoft lanou em 2000 o termo web service para se referir a um conjunto de padres que permitem a comunicao entre dois computadores em uma rede. Desde ento muitos padres foram desenvolvidos e os web services passaram a ser uma tecnologia muito utilizada, tronando-se o principal meio de implementao de arquiteturas orientadas a servio (SOA). Neste resumo sero abordadas as principais caractersticas de web services, bem como uma explicao sobre SOAP e REST e seu funcionamento. Web services usam de dois principais protocolos para a estabelecer a comunicao entre diferentes sistemas: XML (extensible markup language), utilizada para descrever os dados trafegados; e HTTP protocolo de troca de mensagens usado pela internet. Ou seja, a comunicao acontece atravs da troca de mensagens e do envio de dados atravs de XML. Porm esse dois protocolos definem apenas a maneira como ocorre a comunicao, por isso surgiram padres desenvolvidos por empresas como IBM e Microsoft para tornar o uso de web services mais eficiente, dentre eles esto SOAP, WSDL e UDDI.

WSDL:
WSDL (web service description language) uma linguagem baseada em XML, que foi criada em 2000 pela IBM logo aps o surgimento dos web services. Um arquivo WSDL contm a descrio da interface do web service, indicando parmetros de entrada e sada para o consumo do web service; bem como o endereo do web service, pelo seu URL. Segundo um artigo do Watson research Center[2], as informaes em um arquivo WSDL se dividem naquelas que descrevem os web services de maneira mais abstratas, como o vocabulrio e interao das mensagens; e naquelas que descrevem o funcionamento do web service, como o protocolo.

UDDI:
UDDI (Universal description, Discovery and innovation) tambm criada pela IBM em 2000, responsvel pela locallizao dos web services. Funciona como um repositrio dos registros dos web services; e rene especificaes sobre como as informaes do weeb service devem ser vistas, acessadas e/ou modificadas. Segundo [5], um arquivo UDDI guarda trs tipos de informaes sobre os servios:

1. 2. 3.

White pages contm o nome e outros detalhes do servio. Yellow pages contm classificao dos web services com base no tipo de servio Green pages contm detalhes tcnicos dos web services.

SOAP:
SOAP (Simple Object Access Protocol) contm informaes sobre o uso do web service, como o formato da transferncia de dados e informaes sobre a requisio e resposta. A estrutura de um arquivo SOAP dividida em um elemento chamado <Envelop>, que contm outros elementos como um <Header> (opcional) e um <Body> (obrigatrio). Enquanto que no <Body> so colocadas informaes sobre a requisio ou resposta, no <Header> so colocadas informaes que ajudam no processamento da mensagem, como o formato dos dados e o tamanho. A verso mais recente do SOAP a 1.2.

Web services RESTful:

Proj.RT.NNN.vv 13

Abril de 2009 REST significa Representationl State Transfer, foi introduzido primeiramente na dissertao de doutorado de Roy Fielding (ver FIELDING. R[6]) como um estilo de arquitetura para sistemas distribudos de hipermdia. Em sua dissertao Roy Fielding destaca as caractersticas mais importantes do estilo REST, algumas delas descritas a seguir:

Stateless:
Ser um servio stateless significa que nenhum dado sobre uma transao entre ele e o consumidor guardado no servidor, ou seja, toda e qualquer requisio tem de conter as informaes necessrias para a realizao do servio, no podendo se aproveitar dos dados j usados em uma outra transao, ou tendo que guardar esses dados no cliente. Essa caracterstica traz benefcios como visibilidade e escalabilidade, pois todas as informaes necessrias para a realizao do servio esto na prpria requisio, evitando que o servio tenha de obter as informaes necessrias. Porm, ao mesmo tempo, ela diminui a performance do sistema, pois muitas vezes sero trafegados os mesmos dados para requisies idnticas, diminuindo a eficincia do sistema.

Cache:
Outra caracterstica de REST o fato de as respostas s requisies serem guardadas em cach, ou seja, e, um determinado perodo de tempo (especificado pelo desenvolvedor) ser dada a mesma resposta a uma determinada requisio, mesmo que os dados devessem ser diferentes. Isso aumenta o desempenho do sistema, porm reduz a confiabilidade; pois os dados trafegados podem ser inconsistentes.

Uniform interface:
A principal caracterstica dos web services RESTful a sua interface uniforme; a aplicao consumidora se comunica com o web service atravs dos mtodos bem definidos no protocolo HTTP. Ou seja, o consumo do web service se baseia no uso dos quatro verbos GET,PUT, POST , DELETE; diferentemente dos web services SOAP onde a interface varia de acordo com o desenvolvimento dos recursos.

Recurso, Representao e ROA.

Quando se fala de web services RESTful, um dos principais conceitos abordados o conceito de recurso. Segundo RICHARDSON[7], recursos so todos as informaes do sistema que so interessantes o suficiente para podermos oferec-las e apresent-las para a aplicao cliente. A maneira como apresentamos esses recursos chamada de representao; uma representao de um recurso no precisa necessariamente ser o prprio recurso, pode ser um conjunto de dados que descrevem o recurso ou suas informaes. Uma das primeiras e principais etapas do desenvolvimento de web services RESTful a transformao do conjunto de dados do sistema em recursos, e posteriormente, decidir quais sero as representaes para cada recurso. Nesse contexto a arquitetura de um ambiente de desenvolvimento REST muitas vezes chamada de arquitetura orientada a recursos(ROA). A seguir so descritos dois principais conceitos relacionados a uma arquitetura orientada a recursos.

Addressability:

Proj.RT.NNN.vv

14

Abril de 2009 O termo addressability refere-se endereabilidade de um recurso, ou seja , se determinado recurso pode ser acessado atravs de um endereo bem definido, identificado atravs de URIs (Uniform Resource Identifier). Os recursos de uma arquitetura ROA so endereveis quando a sua representao pode ser acessada diretamente atravs de uma URI, sem que seja necessrio percorrer um caminho na aplicao. muito importante em uma arquitetura ROA que todos os recursos sejam endereveis.

Connectedness:
A conectividade em uma arquitetura ROA definida analisando-se a maneira como os recursos e suas representaes se interconectam, ou seja, se a representao de um recurso da acesso (atravs de um hyperlink, por exemplo) representao de um outro recurso. Todos os recursos de uma arquitetura ROA devem estar interconectados, de maneira que nenhum recurso esteja isolado dos outros recursos do sistema. A seguir feita uma breve comparao entre web services RESTful e web services SOAP, levando em conta a suas respectivas vantagens, desvantagens e suas prinicipais caractersticas,descritas aqui.

SOAP vs REST:
Em muitos lugares existe a discusso sobre qual a melhor maneira de se desenvolver web services REST ou SOAP. Hoje em dia os web services REST vem sendo usados largamente por empresas como Yahoo, ao passo que SOAP tem perdido sua popularidade; porm empresas como a Google ainda preferem essa tecnologia. A seguir dada uma breve comparao entre SOAP e REST Um das vantagens que REST oferece sobre SOAP a sua simplicidade, principalmente em relao ao protocolo de comunicao. Pois enquanto o SOAP baseia-se no velho estilo de RPC (Remote Procedure Call) impondo a necessidade de atender a diversos protocolos para realizar a chamada a um servio; REST baseia-se unicamente nos mtodos HTTP e nas URIs, para identificar um servio. REST apia-se na tecnologia web, j desenvolvida, enquanto que SOAP desenvolve protocolos para a comunicao entre o consumidor e o provedor de servios, que aos olhos de quem desenvolve em REST, apenas a reinveno da roda. Alm da vantagem da simplicidade, o fato de REST no utilizar arquivos de configurao como SOAP e WSDL diminui o fluxo de dados em formato XML no sistema, o que aumenta o desempenho do sistema. Isso nos leva a crer que aproveitar os protocolos da web ao invs de criar uma srie de protocolos para realizar uma requisio, aumenta a agilidade e simplicidade do sistema. Por outro lado SOAP est h muito mais tempo no mercado que REST, por isso existe muito mais suporte para tecnologia SOAP do que para REST. Um exemplo disso segurana; web services REST no oferecem suporte WS-Security, uma das maiores diretrizes de segurana para web services. Apesar de muitas empresas, como Google e a Amazon, aplicarem outras diretivas de segurana aos web services RESTful, o estilo REST acaba perdendo muito em questo segurana. Alm disso, segundo JOSUTIS. N[1], um web service REST no d suporte composabilidade e granularidade (explicadas no outro documento) de servios, nem a atributos no funcionais (como tempo de durao do servio e sua finalidade), prejudicando aspectos muito importantes da arquitetura orientada a servios, como reuso e orchestration; vitais para uma infraestrutura SOA mais sofisticada.

Proj.RT.NNN.vv

15

Abril de 2009 A partir dessa breve comparao entre SOAP e REST possvel concluir que REST uma soluo inteligente, pois promove mais agilidade e escalabilidade a um sistema. Porm, deixa a desejar quando se trata de segurana, ou assuntos mais especficos ao SOA; ou seja, REST a escolha mais adequada quando se trata de sistemas distribudos de baixa complexidade, limitados a troca de dados entre diferentes pontos; no entanto, quando se trata de uma arquitetura mais complexa onde so necessrios recursos mais especficos de SOA e mais segurana, SOAP (pelo menos por enquanto) a melhor opo. Apesar dessa breve discusso de onde implementar SOAP e onde implementar REST, existem possibilidades de que ambos coexistam, devido ao fato de SOAP muitas vezes se aproximar de REST em alguns aspectos. Porm ainda no existe nada concreto sobre isso, devido a algumas dificuldades que se pode encontrar ao tentar combinar SOAP e REST (ver PRESCOD. P- seo 6.3[8]).

REFERNCIAS
[1] JOSUTIS. N. SOA in practice the art of distributed systems. OReilly Media, Inc. 1005 Gravenstein Highway North, Sebastopol, CA 95472 . United States. 2007 [2] Wikipedia. Definition of service for distributed systems. 26 de Janeiro de 2009. [3] OASIS. Modelo de referncia para arquitetura orientada a servio 1.0. seo 3.1. Comit de especificao 1, 19 de Julho de 2006 [4] ERL. T. Service Oriented Architecture Concepts, technology and design. Prentice Hall PTR . August 04, 2005. [5] CUBERA. F; DUFTLER. M; KHALAF. R; NAGY. W; MUKHI. N and WEERAWARANA. S. Unraveling the Web services Web: An introduction to SOAP, WSDL and UDDI. IBM T.J Watson Research Center. Maro/Abril de 2002. [6] FIELDING. R. Architectural Styles and the Design of Network-based Software Architectures. Dissertation. University of California Irvine. 2000. [7] RICHARDSON. L, RUBY. S. RESTful web services. OREILLY Media Inc. United States Of America. May 2007. [8] PRESCOD. P. Roots of the REST/SOAP debate. Seo 6.3. ConstantRevolution Consulting. Vancouver. BC. CANADA. [9] PRZYBILSKI. M. REST Representational State Transfer

Proj.RT.NNN.vv

16