UNIVERSIDADE ESTADUAL DO SUDOESTE DA BAHIA DEPARTAMENTO DE CINCIAS EXATAS CURSO GRADUAO EM CINCIA DA COMPUTAO HELDER NERES SOUZA

PRINCIPAIS CONCEITOS DE SOA E SUA IMPLEMENTAO ATRAVS DE WEB-SERVICES

VITRIA DA CONQUISTA 2011

HELDER NERES SOUZA

PRINCIPAIS CONCEITOS DE SOA E SUA IMPLEMENTAO ATRAVS DE WEB-SERVICES

VITRIA DA CONQUISTA 2011

HELDER NERES SOUZA

PRINCIPAIS CONCEITOS DE SOA E SUA IMPLEMENTAO ATRAVS DE WEB-SERVICES

Monografia apresentada ao curso de Cincia da Computao da Universidade Estadual do Sudoeste da Bahia UESB, como requisito para obteno do ttulo de Bacharel em Cincia da Computao.

Banca examinadora: Orientador: __________________________________________ Roque Mendes Prado Trindade Universidade Estadual do Sudoeste da Bahia UESB Membro: __________________________________________ Hlio Santos Lopes Universidade Estadual do Sudoeste da Bahia UESB __________________________________________ Masa Soares dos Santos Lopes Universidade Estadual do Sudoeste da Bahia UESB

Membro:

VITRIA DA CONQUISTA 2011

Agradecimentos Primeiramente agradeo a Deus, que diretamente me auxiliou no desenvolvimento deste trabalho, dando-me nimo, pacincia e no me permitindo desistir de alcanar o objetivo. Agradeo tambm aos meus pais que contriburam suficientemente, apesar de todas as dificuldades, para eu poder concluir hoje este trabalho. Agradeo tambm a minha querida Kathy, que tanto me auxiliou e incentivou na realizao do mesmo. Por fim, agradeo aos meus colegas da UINFOR por todo o apoio e suporte, principalmente, a Bruno, Fbio e Leilane, que auxiliaram-me na entrega desta monografia.

Resumo A Orientao a Servios tem se difundido consideravelmente nos ltimos anos. Grandes fornecedores de Software tem vendido solues baseadas em SOA, com a promessa de diminuir o impacto das contnuas alteraes tecnolgicas nos negcios. Este trabalho apresenta uma viso geral deste paradigma e da tecnologia mais adequada para utiliz-lo, a tecnologia de Web Services, alm de desenvolver uma soluo baseada nestas tendncias para integrar um novo sistema que est sendo desenvolvido no contexto na UESB, o sistema para avaliao de professores, ao sistema acadmico. PARAVRAS-CHAVE: SOA, Web-Services, UESB

Abstract Service orientation has been widely spread in recent years. Large software vendors have sold SOA-based solutions, with the promise of reducing the impact of ongoing technological changes in business. This work presents an overview of this paradigm and the most appropriate technology to use it, the Web Services technology, and develop a solution based on these trends to integrate a new system being developed in UESB context, the system for teacher evaluation, to academic system. Keywords: SOA, Web-Services, UESB

Lista de Figuras Figura 1: A Orientao a Servios e os paradigmas e tecnologia anteriores. Figura 2: Representao de Servio. Figura 3: Associao entre Servio e Processo. Figura 4: Relacionamento entre servios. Figura 5: Comunicao entre servios. Figura 6: Esquema de um documento WSDL. Figura 7: Esquema de mensagem SOAP. Figura 8: Ciclo de vida de um projeto de SOA. Figura 9: Exemplo de servio de tarefa. Figura 10: Exemplo de servio de entidade. Figura 11: Exemplo de servio utilitrio. Figura 12: Camadas de servios. Figura 13: Viso Geral do ambiente de sistemas da UESB. Figura 14: Diagrama de casos de uso da soluo. Figura 15: Camadas de servio e servios candidatos. Figura 16: Camadas de Servios aps o termino da fase de projeto. Figura 17: Servios e suas respectivas capacidades. Figura 18: Diagrama de classes de entidade.

Lista de Tabelas Tabela 1: Caracterizao dos principais sistemas da UESB

Lista de Abreviaturas
AOP API BPM EAI HTTP IDE Java EE RPC SOA SOAP TI TIC UESB UINFOR WSDL XML Aspect Oriented Programming Application Programming Interface Business Process Management Enterprise Application Integration Hiper Text Transfer Protocol Integrated Development Environment Java Enterprise Edition Remote Procedure Call Service Oriented Architecture Simple Object Access Protocol Tecnologia da Informao Tecnologia da Informao e Comunicao Universidade Estadual do Sudoeste da Bahia Unidade de Informtica da UESB Web Service Description Language Extensible Markup Language

Sumrio 1. Introduo........................................................................................................................12 1.1 Objetivos.........................................................................................................................12 1.1.1. Objetivo Geral.................................................................................................................12 1.1.2. Objetivos Especficos......................................................................................................13 1.2. Justificativa.....................................................................................................................13 1.3. Metodologia....................................................................................................................14 1.3.1. Classificao quanto a natureza da pesquisa...................................................................14 1.3.2. Classificao quanto a abordagem do problema.............................................................14 1.3.3. Classificao quanto aos objetivos.................................................................................14 1.3.4. Classificao quanto aos procedimentos tcnicos...........................................................15 1.3.5. Procedimentos realizadas no trabalho.............................................................................15 1.4. Organizao do trabalho.................................................................................................16 2. Conceitos de Orientao a Servios................................................................................17 2.1. Viso Geral de SOA........................................................................................................17 2.2. Arquitetura de Software..................................................................................................18 2.3. Orientao a Servios......................................................................................................19 2.3.1 Servio............................................................................................................................19 2.3.2 Servios encapsulam lgica de negcio..........................................................................21 2.3.3. Servios se relacionam....................................................................................................21 2.3.4. Servios se comunicam...................................................................................................22 2.4. Princpios da Orientao a Servios................................................................................23 2.5. Comparao entre Orientao a Servios e Orientao a Objetos..................................26 2.6. Arquitetura Orientada a Servios....................................................................................27 2.6.1. Benefcios esperados ao se utilizar SOA........................................................................29 3. A tecnologia de Web Services.........................................................................................32 3.1. Viso Geral......................................................................................................................32 3.2. Componentes da tecnologia de Web Services.................................................................33 3.2.1. Servio............................................................................................................................33 3.2.2. Descrio de Servio.......................................................................................................34 3.2.3. Mensagens......................................................................................................................35 4. Processo de entrega de SOA...........................................................................................37 4.1. Camadas de Servios......................................................................................................38 4.1.1. Servios de Tarefa...........................................................................................................39 4.1.2. Servio de Entidade........................................................................................................39 4.1.3. Servio Utilitrio.............................................................................................................40 4.2. Processos de anlise e projeto Orientados a Servio.....................................................41 5. Desenvolvimento da soluo..........................................................................................43 5.1. Contextualizao.............................................................................................................43 5.2. Anlise da soluo..........................................................................................................45 5.2.1 Requisitos.........................................................................................................................46 5.2.2. Lgica de automao j existente...................................................................................47 5.2.3. Camadas de servios e servios candidatos....................................................................47 5.3. Projeto da soluo...........................................................................................................48 5.3.1. Escolha da tecnologia......................................................................................................48 5.3.2. Projeto de camadas e de servios....................................................................................49 5.4. Construo da soluo....................................................................................................51 5.4.1. Arquitetura......................................................................................................................51 5.4.2. Testes e resultado do processo de construo.................................................................52

6. 7.

Concluso........................................................................................................................54 Referncias......................................................................................................................55

12 1. Introduo No ambiente inter organizacional atual, tornou-se essencial s empresas responderem de forma efetiva e rpida as constantes mudanas. Do ponto de vista administrativo necessrio se oferecer um produto de qualidade ao nmero mximo de clientes possvel e com baixo custo. Para sobreviverem em tal ambiente, as empresas melhoram os seus processos, investem em inovao, fazem parcerias, etc. Neste contexto, presume-se, atualmente, que a Tecnologia da Informao(TI) uma aliada estratgica dos negcios, auxiliando as organizaes a alcanarem seus objetivos. Isto normalmente conhecido como alinhamento entre TI e negcio e tem como objetivo fazer com que a TI consiga responder de maneira gil e eficaz as necessidades que o negcio venha a ter. A Arquitetura Orientada a Servios(SOA) surge neste contexto como resultado da evoluo de vrios paradigmas e de melhores prticas de TI nas organizaes. Em suma, um modo de se ver vrias solues de automao como um s sistema distribudo que deve atender as necessidades do negcio de maneira rpida, eficaz, barata e que viabilize s organizaes serem menos dependentes de aspectos tecnolgicos. A implementao de uma SOA est dissociada de qualquer tecnologia, no entanto, a tecnologia que se mostra mais adequada e relacionada aos conceitos de Orientao a Servios tecnologia de Web Services. Esta tecnologia utilizada para viabilizar a comunicao entre software desenvolvido em diferentes plataformas de desenvolvimento e cada vez mais passa a ser utilizada para desenvolvimento de sistemas distribudos. Este trabalho apresenta os principais conceitos destas duas tendncias, SOA e Web Services assim como, para exemplificar suas aplicaes, desenvolve uma soluo para a integrao entre o sistema acadmico da UESB(SAGRES) e um novo sistema, atualmente em desenvolvimento, responsvel por automatizar o procedimento de avaliao de professores por parte dos alunos. Este novo sistema referenciado no trabalho como sistema de avaliao de professores. 1.1. Objetivos Descrever os objetivos possibilita comunicar a proposta da pesquisa, ou seja, a quais resultados se quer chegar com a mesma.(SILVA e MENEZES, 2005) 1.1.1. Objetivo Geral

13

Este trabalho tem como objetivo geral apresentar os principais conceitos referentes a SOA e utilizar tais conceitos no desenvolvimento de uma soluo para a integrao entre determinados sistemas na Unidade de Informtica da UESB(UINFOR). 1.1.2. Objetivos Especficos Os objetivos especficos deste trabalho so os seguintes: 1. Reviso da Literatura; 2. Descrio dos principais conceitos associados com SOA. 3. Descrio dos principais conceitos referentes a tecnologia de Web Services. 4. Desenvolvimento de uma soluo baseada em SOA e Web Services que deve permitir a interao entre o sistema acadmico e o sistema de avaliao de professores da UESB. 1.2. Justificativa A Arquitetura Orientada a Servios tem se tornado um padro na indstria, no que diz respeito a sistemas distribudos. Muitos pesquisadores da rea de SOA afirmam que as corporaes devem implantar este padro com o intuito de obterem maior capacidade de competirem no mercado atual. O SOA-Consortium(2011) apresenta uma lista de casos de sucesso de adoo de SOA, mostrando as principais caractersticas na implantao deste casos. Todos estes fatores de certa forma justificam o desenvolvimento deste trabalho pois mostram como SOA tem se tornado uma realidade concreta nas organizaes e tem auxiliado a estas organizaes terem uma TI que, realmente, est alinhada com o negcio que mantm. Abordar tal conhecimento vem a ser importante para um crescimento profissional e para a compreenso dos rumos pelo qual o desenvolvimento de sistemas tem seguido. Uma outro caracterstica que justifica o desenvolvimento deste trabalho vem a ser a dificuldade em encontrar material introdutrio, em lngua portuguesa, a respeito desse novo modelo. Existe material sobre SOA, no entanto, voltado, em sua maioria, a quem j tem um conhecimento bsico. Por fim, poder aplicar na UESB os conceitos referentes a este novo paradigma e auxiliar esta organizao com uma nova experincia em desenvolvimento de sistemas distribudos tambm um motivo pelo qual este trabalho tem sido desenvolvido.

14 1.3. Metodologia Silva e Menezes(2005) definem pesquisa como um conjunto de aes, propostas para encontrar a soluo para um problema, que tm por base procedimentos racionais e sistemticos. As mesmas autoras afirmam que existem algumas formas clssicas de se classificar as pesquisas. A seguir este trabalho ser apresentado de acordo com estas classificaes. 1.3.1. Classificao quanto a natureza da pesquisa Quanto a natureza, existem duas classificaes para a pesquisa. A pesquisa bsica aquela na qual no se tem como objetivo gerar conhecimento sem aplicao prtica prevista. J a pesquisa aplicada tem como objetivo a gerao de conhecimento que pode ser aplicado na prtica e dirigido a soluo de um problema especfico.(SILVA e MENEZES, 2005) Este trabalho, por objetivar gerar conhecimento referente a SOA e desenvolver uma soluo para um especfico problema da UESB, classificado como pesquisa aplicada. 1.3.2. Classificao quanto a abordagem do problema Quanto a abordagem do problema, existem duas classificaes para as pesquisas. A primeira a quantitativa que considera que tudo pode ser representado em nmeros. Este tipo de pesquisa requer o uso de mtodos estatsticos. J a segunda, a qualitativa, considera que existe entre o mundo objetivo e a subjetividade do sujeito um vnculo que no pode ser traduzido em nmeros. Este trabalho classificado como pesquisa qualitativa pois no tem como objetivo gerar valores quantitativos em sua anlise de SOA e no desenvolvimento do estudo de caso. 1.3.3. Classificao quanto aos objetivos

Quanto aos objetivos, este trabalho pode ser considerado de pesquisa exploratria, uma vez que busca proporcionar uma maior familiaridade com o problema tornando-o mais explcito(SILVA e MENEZES, 2005). Para isto, ele desenvolvido atravs de pesquisa bibliogrfica sobre SOA e estudo de caso, no ambiente de sistemas de informao da UESB. Existem tambm outras duas maneiras de se classificar a pesquisa do ponto de vista de

15 seus objetivos. possvel se classificar uma pesquisa como pesquisa descritiva, a qual visa descrever as caractersticas de determinada populao ou fenmeno ou o estabelecimento de relaes entre variveis, ou como pesquisa explicativa, que busca identificar os fatores que determinam ou contribuem para a ocorrncia de determinados fenmenos.(SILVA e MENEZES, 2005) 1.3.4. Classificao quanto aos procedimentos tcnicos Quanto aos procedimentos tcnicos realizados para se desenvolver, este trabalho pode ser considerado um trabalho de pesquisa bibliogrfica, pois elaborado de material j publicado sobre SOA, em sua maioria livros, e tambm um trabalho de estudo de caso pois envolve o estudo de um pequeno processo de desenvolvimento de SOA. Aps classificado o trabalho necessrio se identificar o mtodo pelo qual ele alcanar seus objetivos. De acordo com Silva e Menezes(2005), mtodo cientfico o conjunto de processos ou operaes mentais que se devem empregar na investigao. A seguir o procedimento utilizado para desenvolv-lo descrito. 1.3.5. Procedimentos realizados no trabalho Para se alcanar os objetivos esperados, este trabalho foi desenvolvido de acordo com os seguintes passos: 1. Anlise da Literatura: Foram procuradas as principais obras relacionadas a SOA, com o intuito de se obter uma firme base terica sobre o assunto. Destaca-se aqui a presena de vrias obras publicadas por Thomas Erl, pesquisador de SOA e do paradigma de Orientao a Servios, as quais fornecem considervel sustentao a este trabalho. 2. Desenvolvimento dos captulo 2, 3 e 4 do trabalho, contendo os principais conceitos referentes, respectivamente, a Orientao a Servios, Web Services e processo de entrega de SOA. 3. Com a base fornecida pelas atividades anteriores tornou-se ento vivel o desenvolvimento da soluo baseada em SOA e Web Service para a integrao entre o SAGRES e o sistema para avaliao de professores. Para isto, foi analisado contextualmente o ambiente de sistemas de informao da UESB, obtendo-se assim uma viso geral deste ambiente. Nesta contextualizao

16 buscou-se, secundariamente, a identificao de caractersticas que

justificassem ou no a adoo de SOA. Por fim, foi realizado o desenvolvimento da soluo, atravs de um processo de entrega de SOA adaptado as necessidades deste projeto, contendo anlise e projeto orientada a servios e construo efetiva da soluo. As atividades descritas neste item esto resumidamente descritas no captulo 5. 1.4. Organizao do trabalho

Para facilitar a compreenso do trabalho como um todo, a seguir est descrita a estrutura do documento. Este documento composto por 7 captulos. No captulo 1 apresentada a parte introdutria do trabalho, contendo uma introduo do mesmo, juntamente com seus objetivos, justificativa e metodologia utilizadas para desenvolv-lo. Nos captulos 2, 3 e 4 apresentada a reviso bibliogrfica realizada no trabalho. Nestes captulos so apresentados, respectivamente, conceitos de Orientao a Servios, de Web Services e o processo de entrega de SOA. O captulo 5 apresenta o desenvolvimento do estudo de caso referente a soluo desenvolvida para integrao entre o SAGRES e o sistema de avaliao de professores. O captulo 6 apresenta as concluses obtidas no trabalho assim como contribuies trazidas por ele e algumas propostas de trabalhos futuros. Por fim, o captulo 7 apresenta as referncias utilizadas para desenvolvimento da obra.

17 2. Conceitos de Orientao a Servios fundamental, para se alcanar os objetivos deste trabalho, apresentar o conjunto de ideias associadas a SOA. este sistema de ideias o meio pelo qual as corporaes esperam alcanar sustentao tecnolgica necessria para competirem no ambiente comercial atual. Sendo assim, este captulo tem como objetivo apresentar os principais conceitos associados a SOA e que se tornam necessrios para o desenvolvimento do trabalho, como um todo. 2.1. Viso Geral de SOA De acordo com Bean(2010), a origem do termo SOA no est suficientemente clarificada. Segundo o mesmo, racional admitir que SOA surgiu no meio tecnolgico, com a evoluo de arquiteturas RPC(Remote Procedure Call) e de protocolos de objetos distribudos, mas tambm necessrio admitir que SOA surgiu como um meio de se atender ao negcio, auxiliando-o a alcanar seus objetivos. Um dos requisitos de negcio mais importantes e que a TI poderia prover, em meados da dcada de 90, era a agilidade. Com o surgimento, entre outras coisas, da Web e do ecommerce, esse requisito de agilidade tornou-se um diferencial. Empresas que se adaptam rapidamente as mudanas no ambiente tem maior capacidade de vencerem na luta do mercado global.(JOSUTTIS, 2007) SOA surge neste contexto como a evoluo da tecnologia associada ao negcio. Um padro da indstria que permite as organizaes alcanarem nveis adequados de qualidade nas atividades de desenvolvimento de solues de automao, por meio de um conjunto de requisitos tcnicos de desenvolvimento, como reusabilidade e baixo acoplamento. Atualmente, SOA tem se difundido de modo considervel e muitas das grandes empresas de desenvolvimento de plataformas computacionais fornecem solues baseadas neste modelo. Outros requisitos surgiram, como a necessidade de comunicar com software de organizaes parceiras(federao) e a independncia de plataformas de fornecedores(neutralidade de fornecedor), mas a ideia bsica, a TI estar intimamente associada ao negcio, a mesma. Erl(2005) lista o conjunto das caractersticas atuais de SOA, as quais denomina SOA Contemporneo: SOA est no centro da plataforma de computao orientada a servios. SOA aumenta a qualidade de servio.

18 SOA fundamentalmente autnoma. SOA baseada em padres abertos. SOA suporta diversidade de fornecedor. SOA promove capacidade de descoberta. SOA promove federao. SOA promove composabilidade arquitetural. SOA promove reusabilidade nativa. SOA enfatiza a extensibilidade. SOA suporta um paradigma de modelagem de negcio orientado a servio. SOA promove baixo acoplamento por toda a organizao. SOA promove agilidade organizacional. SOA um bloco de construo. SOA uma evoluo. SOA est ainda em estado de maturao. SOA um ideal alcanvel.

Estas so as caractersticas que SOA possui. Por conta de sua extenso, analisar cada uma destas est alm do escopo deste trabalho. No entanto, as caractersticas mais importantes presentes nesta listagem sero analisadas, em geral, com o desenvolver do mesmo. 2.2. Arquitetura de Software: importante, para se ter ideia do que SOA, compreender de fato o que significa o termo arquitetura quando aplicado ao contexto da Cincia da Computao e da Engenharia de Software. De acordo com Hurwitz et. al.(2007), quando aplicado a cincia da computao, o termo arquitetura descreve a concepo global e a estrutura de um sistema de computador. J Bass(2003) afirma que: The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. Estas definies associam a arquitetura de software a uma viso geral das estruturas que compe o sistema computacional ou, mais especificamente, o sistema de software. Ser este o sentido do termo arquitetura para o restante do trabalho.

19 2.3. Orientao a Servios O conceito de Orientao a Servios essencial para a compreenso da nova plataforma de aplicaes que est se desenvolvendo atualmente, onde organizaes se comunicam, interna e externamente, atravs de software, principalmente por meio da infraestrutura da Web.
Service-orientation is a design paradigm intended for the creation of solution logic units that are individually shaped so that they can be collectively and repeatedly utilized in support of the realization of the specific strategic goals and benefits associated with SOA and service- oriented computing. (ERL, 2008a)

tambm do mesmo autor, a definio de Computao Orientada a Servios:

Service-oriented computing is an umbrella term that represents a new generation distributed computing platform. As such, it encompasses many things, including its own design paradigm and design principles, design patterns, a distinct architectural model, and related concepts, technologies, and frameworks. (ERL, 2008a)

Logo, a Orientao a Servios um paradigma de projeto que busca a consecuo de objetivos estratgicos especficos atravs da criao de unidades de soluo lgica conhecidas como servios e que podem ser coletiva e repetidamente utilizadas. Erl(2007) afirma que um paradigma de projeto, dentro do contexto de automao de negcio, uma abordagem que rege o projeto de lgica de soluo. Sendo um paradigma de projeto, a Orientao a Servios pode ser comparada a outros paradigmas, como por exemplo, a Orientao a Objetos ou a Orientao a Aspectos. No entanto, a Orientao a Servios no compete com os paradigmas anteriores, ela se aproveita da experincia obtida com estes paradigmas e de padres utilizados na indstria para formular seus princpios. Na Figura 1 apresentado um esboo do relacionamento entre a Orientao a Servios e os paradigmas anteriores. Segundo Erl(2008a) a Orientao a Servios focada, primariamente, em oito princpios. Estes princpios sero descritos no item 2.3 deste trabalho. A seguir sero apresentadas as entidades bsicas da Orientao a Servios. 2.3.1 Servio O conceito de servio o conceito base para o paradigma de Orientao a Servios. De acordo com o SOA Work Group(2011), um servio a logical representation of a repeatable business activity that has a specified outcome. Esta definio segue direo

20 semelhante a de Hurwitz et. al.(2007), que afirma que um servio the logical encapsulation of business function. Nestas definies, percebe-se o enfoque na abstrao que fornece o conceito de servio. Tal abstrao necessria ao se pensar em um modelo para representao de um mini-mundo. inevitvel fazer uma analogia de servios em SOA, com a ideia de servio disponvel atualmente no dia a dia. Em uma cidade, pessoas e organizaes disponibilizam servios das mais variadas formas, formando uma grande cadeia. Em outras palavras, atividades repetitivas so efetuadas com o intuito de prover um resultado especfico. Exemplos so inmeros: servio de correio, servios bsicos, como o de provimento de energia, de gua, luz, saneamento e transporte, servio de internet, servio de contabilidade, servio de supermercado, servio de lavanderia, etc.
Figura 1 A Orientao a Servios e os paradigmas e tecnologia anteriores Fonte: (ERL, 2008a)

Uma terceira definio de servio encontrada na Literatura a definio de Erl(2007), que afirma que servios so colees de capacidade. O termo capacidade, nesta definio, pode ser utilizado em seu sentido mais comum. Logo, definir servios est diretamente associado a tarefa de relacionar capacidades em um contexto funcional. Por conta da simplicidade e objetividade desta definio, este ser o conceito de servio utilizado para o restante do texto, quando este termo estiver relacionado a SOA e ao paradigma de Orientao a Servios. A Figura 2 representa bem esta definio. A seguir, sero descritas algumas das caractersticas mais importantes de servios.

21
Figura 2 Representao de Servio

2.3.2. Servios encapsulam lgica de negcio Para manterem sua independncia, servios encapsulam lgica dentro de um contexto distinto. Tal lgica pode representar uma tarefa de negcio, uma entidade do mesmo, ou ter outro agrupamento(ERL, 2005). Ao representar tarefas de negcio, um servio pode ser associado ao conceito de processo. Assim como um processo tem a capacidade de representar um conjunto variado de tarefas, sendo que uma parte destas tarefas podem ser vistas tambm como processos, o servio tem a mesma caracterstica, ou seja, servios podem ser compostos por outros servios. A Figura 3 representa essa flexibilidade inerente ao conceito de servio. Segundo o SOA Work Group(2011), uma outra propriedade dos servios que eles espelham atividades de negcio do mundo real. Essa associao entre processos e servios fundamental para SOA atingir um dos seus principais objetivos alinhar a TI ao negcio. Estando os conceitos utilizados para a modelagem da soluo to bem relacionados e parecidos com os reais conceitos do negcio, torna-se possvel a TI se adequar aos requisitos de tempo e agilidade existentes e as mudanas que ocorrem no negcio, sendo possvel ela, at mesmo, direcionar tais mudanas em busca de reduo de custos, melhorias de processos organizacionais, maior qualidade nos produtos gerados, etc. 2.3.2. Servios se relacionam Segundo Erl(2005), servios podem ser utilizados por outros servios ou programas. Para que servios interajam, necessrio que um servio que necessite relacionar-se com outro conhea o que este outro servio dispe. O meio pelo qual torna-se possvel a um

22 servio expor suas capacidades e outros servios tomarem conhecimento destas a descrio de servio. A partir do momento em que um cliente tem acesso a uma descrio de servio, torna-se possvel a ele se utilizar das capacidades do servio, com algum objetivo. Pode-se perceber que o acoplamento gerado no relacionamento baixo. No caso da Figura 4, o servio B no sabe que o servio A que lhe fornece uma operao, pois tem acesso somente a descrio do servio.
Figura 3 Associao entre Servio e Processo

2.3.3. Servios se comunicam Para servios interagirem e realizarem algo significativo, eles devem trocar informaes(ERL, 2005). Para manterem um nvel de acoplamento o mais baixo possvel, as mensagens devem ter a capacidade de operarem independentemente do contexto que encontram-se. Essa necessidade de baixo acoplamento representada na Figura 5. Ao enviar uma mensagem a seu destino, um servio perde o controle sobre o que acontece com ela. Uma analogia interessante a se fazer aqui com o servio de correio. Ao se enviar uma carta, o emissor perde o controle sobre o que ocorre com a mesma. Para que o correio possa entregar a carta a seu destino necessrio se preencher um envelope contendo somente a informao necessria para a entrega, sendo que o contedo da mensagem est encapsulado dentro deste. Servios que forneam descries e que se comunicam atravs de mensagens formam

23 uma arquitetura bsica para SOA. No entanto, possuir tais componentes em uma arquitetura no significa possuir uma arquitetura deste tipo. O que define uma arquitetura como SOA a forma pela qual estes componentes bsicos vo ser projetados.(ERL, 2005)
Figura 4 Relacionamento entre servios

Figura 5 Comunicao entre servios

So os princpios da Orientao a Servios que iram fornecer meios para se desenvolver SOAs. 2.4. Princpios da Orientao a Servios: Um princpio presente nas Engenharias o dividir para conquistar. Ao se deparar com um problema grande e complexo necessrio dividi-lo em problemas menores para resolv-lo. A Engenharia de Software se baseia demasiadamente neste princpio, sendo que

24 seus mtodos focam em como dividir o problema e como reutilizar as solues. O princpio da diviso e conquista utilizado em vrios paradigmas de desenvolvimento. Erl(2005) afirma que a Orientao a Servios uma nova forma de se aplicar este princpio, afirmando tambm que ao se analisar individualmente as caractersticas de SOA, pode-se perceber direta ou indiretamente a aplicao deste princpio. Tais caractersticas, de acordo com Erl(2007), esto descritas nos oito princpios da Orientao a Servios. Estes princpios, que permitem arquiteturas geradas em um projeto orientado a servios possurem as caractersticas de SOA, so descritos a seguir: Servios compartilham contratos padronizados: Servios dentro do mesmo inventrio esto em conformidade com os mesmos padres de projeto de contrato. Os servios, suas capacidades e suas mensagens so formalmente definidas atravs de contratos. De acordo com o autor, um inventrio de servios is an independently standardized and governed collection of complementary services within a boundary that represents an enterprise or a meaningful segment of an enterprise(ERL, 2007). Como consequncia deste princpio, servios podem inter-operar dentro de um determinado contexto, pois existe um contrato pelo qual fornecedores de servio e consumidores de servio baseiam-se. Servios so fracamente acoplados: Contratos de servio impe requisitos de baixo acoplamento para os consumidores e eles mesmo so desacoplados do ambiente que os circundam. Aos consumidores de determinado servio somente necessrio conhecer o contrato de servio. Como consequncia, se o fornecedor for alterado, mas o contrato continuar o mesmo, no ser necessrio ocorrer nenhuma alterao no consumidor. Informao de servio no essencial abstrada: Contratos de servios contm apenas informaes essenciais e a informao sobre os servios limitada ao que publicado nos contratos de servios. atravs deste princpio que um servio pode se comportar como uma caixa-preta, escondendo do ambiente externo a lgica que implementa. Portanto, pode-se desenvolver um servio para realizar uma tarefa extremamente complexa, de alta granularidade, como por exemplo a execuo de um processo de autorizao de uso de um carto de crdito, assim como possvel desenvolver um servio para um tarefa mais simples, como por exemplo, informar se a data de validade do mesmo carto no se passou.

25 Servios so reusveis: Servios contm e expressam lgica agnstica e podem ser classificados como recursos empresarias reutilizveis. Segundo o SOAGlossary(2011) uma lgica agnstica uma logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task. Servios tem requisitos de reusabilidade e, portanto, devem ser projetados para se tornar o mximo possvel independentes de contexto. Servios so autnomos: Servios exercem um alto nvel de controle sobre suas plataformas, em tempo de execuo. Este princpio garante que servios possam executar sua lgica independentemente de fatores externos ou mesmo de outros servios. Segundo Erl(2005), a autonomia uma das consideraes primarias ao se dividir a lgica de aplicao e as capacidades entre os servios. Servios minimizam a manuteno de estado: Servios minimizam o consumo de recursos por retardarem o gerenciamento de informaes de estado at que este seja necessrio. Minimizar informao referente ao estado permite aos servios estarem mais disponveis aos seus consumidores quando um servio solicitado. Isto , em si, resultado de um aumento na escalabilidade no provimento do servio. Alm disso, ao minimizarem as informaes de estado que armazenam, servios tornam-se mais reutilizveis. Servio so descobrveis: Servios so complementados com metadados de comunicao pelos quais eles podem ser efetivamente descobertos e interpretados. Consumidores de servio podem encontrar em um inventrio algum servio que fornea a capacidade que buscam. Para isso, servios possuem informaes complementares sobre o que fazem e onde esto. Servios so componveis: Servios so efetivamente participantes de composies, independentemente do tamanho e da complexidade destas. Este princpio permite a um servio se utilizar de outros com o intuito de executar sua lgica. Como consequncia, servios podem ser projetados e implementar lgica complexa atravs de capacidades de outros servios. Estes so os oito princpios da Orientao a Servios, como proposto por Erl(2007). Vale a pena ressaltar que aquilo que este autor descreve como princpios da Orientao a Servios, Jossuttis(2007) descreve como atributos adicionais dos servios. Erl quer destacar ao definir tais princpios que apesar de se usar tecnologias orientadas a servio, como o caso

26 de Web Services, no necessariamente o produto de software desenvolvido pode ser considerado orientado a servios. Outro ponto que este autor quer por em destaque que para se obter, de fato, uma arquitetura orientada a servios, obtendo completamente seus benefcios, necessrio que o projeto de servios seja direcionado por estes princpios. 2.5. Comparao entre Orientao a Servios e Orientao a Objetos Aps a apresentao dos princpios da Orientao a Servios, torna-se possvel uma comparao entre este paradigma e o paradigma mais difundido nos dias atuais, o da Orientao a Objetos. Como j visto anteriormente, alguns princpios e melhores prticas da Orientao a Objetos foram adotados pela Orientao a Servios, at por se tratar de uma evoluo de paradigmas. Portanto, uma boa comparao entre estes paradigmas tende a ser aquela que destaca onde a Orientao a Servios foi alm da Orientao a Objetos e desenvolveu algo de novo. Para tanto, logo a seguir, cada um dos princpios da Orientao a Servios ser posto em uma perspectiva da Orientao a Objetos.(ERL, 2005) Servios compartilham contratos padronizados: Este princpio da Orientao a Servios bastante anlogo ao princpio de projeto da Orientao a objetos de programar para interfaces. Tendo se tornado uma melhor prtica no contexto da Orientao a Objetos, por facilitar o desenvolvimento e manuteno de sistemas, esta abordagem foi reaproveitada na Orientao a Servios. Servios so fracamente acoplados: A Orientao a Objetos tambm fornece Orientao a Servios a experincia de se desenvolver unidades de lgica que sejam fracamente acopladas entre si. No entanto, a Orientao a Servios eleva este princpio a um patamar maior que o paradigma anterior o faz. Utilizar de interfaces em Orientao a Objetos reduz o acoplamento entre objetos em sistema, no entanto, outros princpios deste paradigma, como a herana, acabam por tornar esse relacionamento acoplado. A Orientao a Servios desvia desta perspectiva e estabelece, como um objetivo inicial de servios, serem o mximo possvel desacoplados de outros servios no ambiente em que existem. Informao de servio no essencial abstrada: Assim como na Orientao a Objetos, onde o princpio do encapsulamento permite que um objeto esconda do ambiente a lgica que executa para operar e fornece a este ambiente, somente uma interface, pela qual outros objetos podem trocar mensagens, a Orientao a Servios possibilita a um servio abstrair a lgica que opera e fornece a outros servios atravs do seu contrato de servios. Servios so reusveis: observado na Orientao a Objetos que o desejo de se

27 desenvolver unidades de processamento de lgica altamente reusveis buscado. Isso perceptvel nos princpios da modularidade e do encapsulamento, encontrado neste paradigma. A Orientao a Servios mantm este desejo, afirmando que servios, desde o seu projeto, devem ser reusveis. Servios so autnomos: A autonomia mais enfatizada na Orientao a Servios do que na Orientao a Objetos. O fraco acoplamento entre servios permite alcanar um nvel de independncia maior entre os servios, quando se comparado com objetos, uma vez que dependncias relacionadas a herana, entre outras, diminuem a autonomia de determinado objeto em relao ao ambiente. Servios minimizam a manuteno de estado: Diferentemente de objetos, que so um agregado de operaes e dados e como consequncia quase sempre mantm o seu estado, servios evitam ao mximo manter esse tipo de informao. Apesar de ser possvel criar servios que sempre armazenem o estado e objetos que nunca fazem isso, a Orientao a servios apresenta neste princpio, um enfoque consideravelmente diferente do paradigma anterior. Servio so descobrveis: Projetar interfaces que sejam consistentes e auto-descritivas uma outra melhor prtica da Orientao a Objetos que a Orientao a Servios estende. Contratos de servios tambm so desenhados para serem facilmente compreendidos e encontrados, no entanto, esta preocupao no se restringe ao projeto, ocorrendo tambm durante a execuo de servios em um inventrio. Servios so componveis: A Orientao a Servios, em contexto fracamente acoplado, suporta conceitos de associao, como a Orientao a Objetos faz atravs da agregao e da composio. Logo, possvel utilizar de vrios servios para se implementar determinada lgica, como feito em Orientao a Objetos. Atravs da anlise dos princpios da Orientao a Servios e de sua comparao com a Orientao a Objetos, foi demonstrado como a Orientao a Servios , em suma, uma extenso deste outro paradigma. Logo, eles no so paradigmas que esto em competio, muito pelo contrrio, as solues orientadas a servios desenvolvidas so, tipicamente, uma mistura de componentes orientados a objetos e servios.(ERL, 2005) 2.6. Arquitetura Orientada a Servios: O termo Arquitetura Orientada a Servios tem sido utilizado das mais variadas formas nos ltimos anos. Existem muitas definies disponveis para SOA, no entanto, muitas delas

28 so imprecisas ou at mesmo equivocadas. Erl et. al.(2008b) argumenta que o termo Arquitetura Orientada a Servios, historicamente, foi to difundido na literatura de marketing de fornecedores de tecnologia e na mdia que quase tornou um sinnimo de computao orientada a servios. O mesmo autor define SOA da seguinte maneira:
Service-oriented architecture represents an architectural model that aims to enhance the agility and cost-effectiveness of an enterprise while reducing the overall burden of IT on an organization. It accomplishes this by positioning services as the primary means through which solution logic is represented. SOA supports service-orientation in the realization of the strategic goals associated with service-oriented computing. (ERL et. al., 2008b)

do mesmo autor esta outra definio de SOA:

"Service-oriented architecture" is a term that represents a model in which automation logic is decomposed into smaller, distinct units of logic. Collectively, these units comprise a larger piece of business automation logic. Individually, these units can be distributed. (ERL, 2005)

O Open Group(2011) define SOA de forma bem simples, sendo um estilo arquitetural que suporta orientao a servios. Uma outra definio, mais abstrata de SOA dada por Josuttis:
SOA is not a concrete architecture: it is something that leads to a concrete architecture. You might call it a style, paradigm, concept, perspective, philosophy, or representation. That is, SOA is not a concrete tool or framework you can purchase. It is an approach, a way of thinking, a value system that leads to certain concrete decisions when designing a concrete software architecture. (JOSUTTIS, 2007, p 29)

Analisando-se as definies, pode-se notar como o conceito de SOA est vinculado a Orientao a Servios. Servios so os meios bsicos pelos quais pode-se construir uma SOA. Sendo assim, uma arquitetura orientada a servios aquela desenvolvida tendo servios como unidades que encapsulam lgica para automao de tarefas e tendo aplicados princpios prprios da Orientao a Servios. Est a concepo de SOA tomada para este trabalho. Ao se utilizar estes princpios, so esperados benefcios por toda a arquitetura de software de uma organizao.

29 2.6.1. Benefcios esperados ao se utilizar SOA Os benefcios mais comumente obtidos atravs de SOA so listados a seguir. Estes benefcios so sensivelmente perceptveis no momento em que a organizao alcana um certo grau de maturidade no desenvolvimento e utilizao desta arquitetura. No entanto, mesmo em nveis iniciais de implantao, alguns destes benefcio j podem ser parcialmente observados.(ERL, 2008) Melhor integrao: SOA pode resultar na criao de solues que consistem naturalmente de servios inter operveis. Inter operabilidade vem a ser a capacidade que um conjunto de solues de automao possui de se comunicar para a execuo de suas operaes. Como SOA permite a utilizao de frameworks de mensagens independentes de fornecedor, existe potencial para as empresas implementarem descries de servio e estruturas de mensagens altamente padronizadas. O resultado geral desta atividade vem a ser, ao passar do tempo, uma diminuio considervel nos esforos para desenvolvimento de solues de integrao, tornando-se esta tarefa mais semelhante a uma tarefa de modelagem. Reuso nativo: A Orientao a Servios promove o projeto de servios que sejam nativamente reutilizveis. Como servios so projetados para serem reusveis, existe grande possibilidade de se aproveitar solues orientadas a servios j existentes. Como consequncia, a medida que a organizao vai alcanando maturidade com o uso de SOA, os esforos e custos associados ao desenvolvimento de novas solues tende a diminuir. Arquiteturas e solues racionalizadas: O princpio da composabilidade da Orientao a Servios, quando aplicada a um nvel de infra estrutura, permite a criao de ambientes de automao altamente otimizados onde somente as tecnologias necessrias tornam-se parte da arquitetura. Aproveitamento do investimento legado: Como SOA promove o desenvolvimento de solues fracamente acopladas, independentes de tecnologia de implementao e que so naturalmente inter operveis, torna-se possvel se reutilizar solues legadas, fornecendo a lgica de negcio presente nestas, atravs de servios. O custo e o esforo para se integrar a soluo legada so consideravelmente diminudos, assim como a necessidade

30 de se substituir software deste tipo. Estabelecimento de uma representao de dados padronizada em XML: Nos nveis mais fundamentais SOA construdo e dirigido por XML. Com isso, SOA leva a um grande aproveitamento da plataforma de representao de dados desta tecnologia. A medida que as representaes de dados so construdas atravs de XML, o modelo vai sendo refinado, obtendo-se um padro para toda a organizao. Neste caso, o que descrito como XML vai se transformando em ontologia referente ao domnio da empresa. Isto diminui os esforos com desenvolvimento, tanto em anlise, como em projeto e documentao. Investimento focado em infra estrutura de comunicao: SOA permite, por meio de sua inter operabilidade, que as organizaes invistam somente em uma tecnologia para fazer comunicao entre os sistemas que possui. O custo do escalamento da infra estrutura de comunicao diminudo, pois somente um padro tecnolgico necessrio para o provimento de uma federao. Heil(2009) referindo-se a um artigo da Sun no mais disponvel, define federao como 'groups of devices and software components organized into a single, dynamic distributed system '. Melhores alternativas de desenvolvimento: Como SOA se utiliza de um framework de comunicao independente de fornecedor, a TI torna-se independente de determinada plataforma de middleware ou de tecnologia proprietria. A inter operabilidade de SOA tambm promove a utilizao da melhor alternativa em determinado contexto, podendo-se considerar a tecnologia em si, polticas da organizao, questo de licenciamento, etc. SOA permite a TI ter maior flexibilidade e, consequentemente, capacidade para atender os requisitos organizacionais. Agilidade Organizacional: Talvez este seja o benefcio mais esperado ao se implantar SOA. A inter operabilidade, a composabilidade, a reusabilidade e o baixo acoplamento promovidos pela Orientao a Servios auxiliam bastante na agilidade que a organizao precisa ter com sua TI. SOA promove o desenvolvimento de uma arquitetura em camadas, onde os dois principais domnios da organizao, o de lgica de negcio e o de aplicao esto fracamente acoplados. Como consequncia, desenvolver novas solues tende

31 a ser um processo mais gil, com reutilizao de lgica de negcio encapsulada em servios de negcio, ou mesmo, em servios de aplicao j existentes. Sendo SOA um paradigma, um conjunto de ideias, necessrio um meio concreto pelo qual ela pode ser implementada. Existem algumas tecnologias pelas quais isto possvel. Este trabalho ir abordar a mais utilizada, difundida e adequada delas, a tecnologia de Web Services conforme Erl(2005).

32 3. A tecnologia de Web Services Como j referido anteriormente, o sucesso obtido pela Internet e pela Web trouxe a necessidade de um meio mais homogneo, pelo qual aplicaes disponibilizadas por diferentes pessoas e organizaes pudessem se comunicar sem a necessidade de adaptao entre as tecnologias utilizadas pelas partes. Algumas tentativas de se resolver esse problema foram pensadas e desenvolvidas mas nenhuma alcanou tanto sucesso como a tecnologia de Web Services. Esta tecnologia tem sido amplamente utilizada para permitir inter operabilidade entre plataformas de software desenvolvidas por diferentes fornecedores. Erl(2005) afirma que a tecnologia de Web Service a mais adequada e bem sucedida em se aplicar SOA: The term "service-oriented" and various abstract SOA models existed before the arrival of Web services. However, no one technology advancement has been so suitable and successful in manifesting SOA than Web services. De fato, os conceitos, modelos e estruturas disponibilizadas pela tecnologia de Web Services podem ser facilmente adaptados para refletirem os princpios da Orientao a Servios. Este capitulo tem como objetivo apresentar os principais conceitos relacionados a esta tecnologia. 3.1. Viso Geral A tecnologia de Web Service desenvolvida e padronizada pelo W3C e disponibilizada como um framework contendo modelos, arquiteturas, conceitos e subframeworks(ERL 2005). Tidwell , Snell e Kulchenko(2001) afirmam que o framework de Web Services representa a evoluo dos princpios que guiam a Internet h anos. Este framework foi amplamente aceito pela indstria e tornou-se um padro de fato. Inmeras corporaes se utilizam dele para desenvolvimento de solues de automao tanto em ambiente interno como em ambiente externo. Ele tem sido utilizado em uma srie de aplicaes e muitas plataformas fornecem suporte nativo a ele. Como exemplo, pode-se citar o Java EE e o .NET, talvez as plataformas de desenvolvimento mais utilizadas no mercado corporativo. O W3C(2004) define um web service como a software system designed to support interoperable machine-to-machine interaction over a network. No mesmo documento, a W3C afirma que um web service uma noo abstrata que deve ser implementada por

33 determinado agente. Um agente vem a ser um software ou hardware que envia e recebe mensagens, enquanto que o conjunto de funcionalidades fornecidas vem a ser o web service. Essa considerao permite um fraco acoplamento entre a interface provida pelo web service e sua implementao, atravs do agente. Pode-se ver aqui uma aplicao do princpio mais bsico da Orientao a Servios. A seguir, sero abordados os principais componentes que compe esta tecnologia. 3.2. Componentes da tecnologia de Web Services O framework de Web Services foi desenvolvido, basicamente, sobre duas tecnologias padronizadas para o ambiente Web: o HTTP, protocolo utilizado para transferncia de Hiper Texto e o XML, uma meta linguagem de marcao muito utilizada, entre outras coisas, para a definio de metadados. Ao se desenvolver uma aplicao de Web Services ir se utilizar muito do XML para se definir os componentes da aplicao. De um ponto de vista estrutural, a tecnologia de Web Services semelhante ao modelo proposto pela Orientao a Servios. Uma aplicao em Web Services composta por servios disponibilizados atravs de descries e que se comunicam atravs de mensagens. Estes componentes sero descritos na sequncia. 3.2.1. Servio O W3C(2004) define que um servio is an abstract resource that represents a capability of performing tasks that represents a coherent functionality from the point of view of provider entities and requester entities. Logo, um servio disponibiliza certa quantidade de lgica, que capaz de operar, a seus consumidores. Erl et. al.(2008b) define o componente de servio para o framework de Web Service como a body of solution logic that provides a physically decoupled technical contract consisting of a WSDL definition and one or more XML Schema and/or WS- Policy definitions. Por ser um corpo de soluo lgica e por fornecer um contrato fisicamente desacoplado, o conceito de servio em Web Services muito semelhante ao conceito de servio na Orientao a Servios, estando diretamente vinculado a este. Como consequncia, ao se utilizar Web Services como tecnologia de implementao para SOA, pode-se intercambiar os conceitos de servio sem maiores prejuzos. Assim, as caractersticas de servio aplicadas a SOA so refletidas no framework de Web Services.

34 3.2.2. Descrio de Servios De acordo com o W3C(2004) um descrio de servios a set of documents that describe the interface to and semantics of a service. As descries de servio permitem a um relacionamento entre fornecedor e consumidor de servio ser de fraco acoplamento. O fornecedor publica uma descrio, ou contrato de servio, na qual define um conjunto de metadados sobre o servio. Estes metadados incluem(ERL 2008b): A proposta e funes de suas operaes. As mensagens que necessitam ser trocadas. Modelos de dados usados para definir a estrutura das mensagens. Um conjunto de condies sobre as quais as operaes so fornecidas. Informao sobre como e onde o servio pode ser acessado.

Estas informaes so descritas atravs de documentos WSDL(Web Service Description Language), XML Schema e WS-Policy. O documento WSDL passa a ser o ponto de contato entre o provedor e o consumidor do servio. Em um documento WSDL existem dois tipos de descrio, uma abstrata, independente de implementao e outra concreta contendo detalhes especficos desta. Atravs desta separao obtm-se baixo acoplamento entre a interface que o servio disponibiliza e sua implementao em determinada plataforma. A Figura 6 contm um esboo de um documento WSDL.(ERL, 2005)
Figura 6 Esquema de um documento WSDL Fonte: (ERL, 2005)

35 A descrio abstrata composta por elementos portType(ou interface), operation e message. O elemento portType agrupa as operaes que so disponibilizadas pelo servio. O elemento operation tambm um encapsulamento, s que de mensagens que podem ser trocadas entre o fornecedor e o consumidor do servio. J o elemento message define uma forma pela qual possvel aos servios se comunicarem. Em suma, mensagens so agrupadas em operaes que so agrupadas em interfaces. A descrio concreta composta por elementos binding, port(ou endpoint) e service. O elemento binding detalha a tecnologia de comunicao que pode ser utilizada pelo consumidor para se conectar ao provedor do servio. O elemento port est associado com o elemento binding, definindo o endereo fsico pelo qual o servio pode ser acessado em determinado protocolo. J o elemento service torna possvel se agrupar vrios elementos port para o servio. O XML Schema utilizado para formalizar a estrutura das informaes trocadas pelo provedor e pelo consumidor dos servios. Em outras palavras, utilizado para definir como so estruturados os dados esperados como entrada e enviados como sada pelo fornecedor do servio. O WS-Policy permite definir polticas para o servio. Polticas podem fornecer regras, preferncias e processar detalhes que no podem ser efetuados atravs da descrio de servio. 3.2.3. Mensagens O W3C(2004) define mensagem como the basic unit of data sent from one Web services agent to another in the context of Web services. Servios trocam mensagens com o intuito de se comunicarem. Assim como esperado que as mensagens na Orientao a Servios auxiliem no baixo acoplamento entre fornecedores e consumidores de servio, este um objetivo de mensagens no framework de Web Service. Para isto, as mensagens encapsulam certos metadados que, juntamente com um protocolo para esta comunicao, o SOAP(Simple Object Access Protocol), possibilitam-nas serem independentes de contexto. Tais mensagens, trocadas atravs deste protocolo, possuem a estrutura descrita na Figura 7. Em SOAP, o contedo das mensagens encapsulado por um envelope, no qual existem duas partes. A primeira, o cabealho, contem meta informao sobre a comunicao. Assim possvel se retirar dos servios a responsabilidade de manter determinados estados da comunicao, assim como lgica de roteamento, de controle de acesso, de transao, etc. Esta

36 caracterstica possibilita implementar, atravs de Web Services, princpios da Orientao a Servios como baixo acoplamento e reusabilidade. A segunda parte do envelope, o corpo, contm os dados da comunicao, em si, que ocorre entre fornecedores e consumidores de servio. No corpo tambm existe uma seo, chamada fault, que mantem informao de lgica de controle de exceo. SOAP flexvel ao ponto de possibilitar a insero de tal lgica.
Figura 7 Esquema de mensagem SOAP Fonte: (ERL, 2005)

Aps a explanao dos principais conceitos relacionados a Web Services mostra-se como esta tecnologia se apresenta como a mais adequada para se implementar SOA. Pode-se perceber como a associao entre servios, descrio de servios e mensagens em SOA direta com estes mesmos conceitos em Web Services. Essa naturalidade com a qual possvel intercambiar os conceitos do paradigma e da tecnologia auxilia muito a compreenso e o projeto de servios SOA atravs desta tecnologia.

37 4. Processo de entrega de SOA

O paradigma de Orientao a Servios tem seus prprios conceitos e princpios. Por conta disto, necessrio que o processo de entrega de SOA considere estas caractersticas e seja dirigido por elas. Assim, os projetos pelo qual uma arquitetura orientada a servios desenvolvida utilizam uma verso orientada a servios do processo normal de desenvolvimento de software. Erl(2005) aborda este processo de desenvolvimento de SOA, destacando as fases deste processo. A Figura 8 um esboo destas fases.
Figura 8 Ciclo de vida de um projeto de SOA Fonte: (ERL, 2005)

Cada uma das fase do ciclo sero sucintamente apresentadas, de acordo com as descries de Erl(2005). Anlise Orientada a Servios: O objetivo da anlise orientada a servios representar atravs da Orientao a Servios os requisitos de automao que o negcio possui. Para isso, no processo de anlise busca-se responder as duas seguintes questes: Quais os servios que precisam ser construdos? Que lgica deve ser encapsulada por qual servio?

Projeto Orientado a Servios: O objetivo do projeto orientado a servios vem a ser utilizar o que descoberto na anlise para determinar de que forma deve ser construda a soluo orientada a servios. No processo de projeto, muitos padres que incorporam convenes da indstria e princpios da orientao a servios so analisados e utilizados, gerando servios concretos atravs de definies abstratas de servio geradas na anlise. Para

38 isso, algumas questes so respondidas, tais como: Como pode-se gerar definies de interfaces fsicas de servio atravs de candidatos de servios modelados na fase de anlise? Quais as caractersticas de SOA se quer implementar e suportar? Que padres da indstria e extenses sero necessrias para que a SOA desenvolvida implemente o projeto de servio planejado e as caractersticas de SOA desejadas? Desenvolvimento de Servios: Nesta fase ocorre a construo dos servios. O que foi projetado na fase anterior vinculado a uma especfica plataforma de desenvolvimento. Teste de Servios: Nesta fase, o que foi construdo testado de acordo com os requisitos da anlise e as consideraes sobre quais caractersticas de SOA seriam suportadas, realizadas na fase de projeto. Implantao de Servios: Nesta fase, a soluo desenvolvida integrada ao restante da estrutura de computao j existente. Administrao de Servios: Nesta fase, aps implantado o servio, busca-se mant-lo em funcionamento de acordo com requisitos preestabelecidos na anlise. As fases de anlise e projeto so as fases onde a Orientao a Servios essencialmente ocorre. So nestas fases que mtodos especficos deste paradigma so realizados com o intuito de se desenvolver SOA. O subcaptulo a seguir ir fornecer uma ideia bsica sobre camadas de servio para que no prximo sejam apresentados os processos de anlise e projeto Orientados a Servios propostos por Erl(2005). 4.1. Camadas de Servios necessrio, antes de se fazer anlise e projeto orientado a servios, ter uma ideia de como conseguir adicionar a uma determinada arquitetura de computao, as caractersticas de SOA. Erl(2005) afirma que, mesmo se utilizando os princpios da Orientao a Servios e a tecnologia de Web Services, com o intuito de se construir SOA, ainda necessrio se efetuar trabalho para que todas as caractersticas de SOA sejam vistas na arquitetura. Para tal, o mesmo autor relata a necessidade de existir um modelo de camadas, onde os servios sejam agrupados de acordo a determinado critrio. O modelo em camadas utilizado em vrias arquiteturas de plataformas computacionais, at mesmo a nvel de hardware, com o intuito de se abstrair complexidade. O critrio utilizado em SOA para

39 realizar esta abstrao , normalmente, uma classificao baseada nas caractersticas que os servios devem possuir de um ponto de vista geral da arquitetura. Isto conhecido, em SOA, como modelo de servio. O mesmo autor(2007) afirma, ainda, que os servios podem ser classificados de acordo aos seguintes critrios: Tipo de lgica que eles encapsulam. A potencial quantidade de reuso da lgica que possui. Como essa lgica se relaciona a domnios existentes dentro da corporao. Servio de tarefa Servio de entidade Servio utilitrio.

Desta forma, possvel definir trs modelos de servio:

Estes modelos de servios so conhecidos como modelos de servios primrios, por existirem, praticamente, em qualquer arquitetura orientada a servios. A seguir as caractersticas de cada um sero melhor descritas. 4.1.1. Servio de Tarefa Para Erl(2007), um servio de tarefa vem a ser um servio com uma fronteira funcional diretamente associada a uma especfica tarefa ou processo pai de negcio. Processo pai aquele relacionado a vrias entidades de negcio. Este tipo de servio tende a ter um menor potencial de reuso e geralmente posicionado como um controlador de composio, sendo assim responsvel por agrupar outros servios, servios estes, mais independentes de uma determinada tarefa ou processo. Uma composio de servios, para o mesmo autor, um agregado coordenado de servios. A Figura 9 a seguir d um exemplo deste modelo. Neste exemplo, AnaliseDeMatricula um servio de tarefa. 4.1.2. Servio de Entidade Um servio de entidade um servio centrado no negcio, que baseia sua fronteira funcional e seu contexto em uma ou mais entidades de negcio relacionadas. considerado um modelo altamente reusvel pois agnstico para a maioria dos processos de negcio. Sendo assim, um nico servio pode ser utilizado para automatizar vrios processos

40 organizacionais. A seguir apresentado um exemplo, atravs da Figura 10:

Figura 9 Exemplo de servio de tarefa

Figura 10 Exemplo de servio de entidade

4.1.3. Servio Utilitrio Um servio utilitrio aquele que fornece funcionalidades de utilidade transversal e reusvel, tais como log de eventos, notificao e tratamento de exceo. Ele idealmente agnstico, pois no especfico de qualquer aplicao em si, consistindo de uma srie de capacidades genricas que vrios sistemas necessitam. A Figura 11 traz um exemplo de um servio utilitrio. Aps definidos os principais modelos de servio, que podem ser adaptados as necessidades organizacionais, interessante se apresentar uma estrutura em camadas

41 fornecendo uma viso geral de como, normalmente, SOA pode ser implementado. Isto realizado na Figura 12.
Figura 11 Exemplo de servio utilitrio

Figura 12 - Camadas de servios (Fonte: ERL, 2007)

A estrutura em camadas caracterstica de SOA. Dependendo da complexidade do negcio possvel se criar mais camadas e obter assim uma maior reusabilidade e abstrao por toda a arquitetura. 4.3. Processos de Anlise e Projeto Orientados a Servios Erl(2005) prope um processo para anlise e outro para projeto orientados a servios. Como j mencionado anteriormente, estas so as fases do processo de entrega de SOA onde sero utilizados princpios prprios do paradigma de Orientao a Servios. A seguir estes processos so apresentados. Analisar cada uma das etapas est alm do escopo deste trabalho. O processo de anlise composto pelas seguintes etapas: 1. Definir requisitos dos negcios.

42 2. Identificar sistemas de automao. 3. Modelar servios candidatos. Por sua vez, o processo de projeto possui as seguintes etapas: 1. Compor SOA. 2. Projetar servios de negcio centrados em entidades. 3. Projetar servios de aplicao. 4. Projetar servios de negcio centrados em tarefas. 5. Projetar processos de negcio orientados a servios.

43 5. Desenvolvimento da soluo Este captulo tem como objetivo descrever o processo de desenvolvimento da soluo baseada em SOA e desenvolvida atravs de Web Services com o intuito de prover a um novo sistema que est sendo desenvolvido no ambiente da UESB, o sistema para avaliao de professores, um meio de se utilizar lgica de negcio presente no sistema acadmico(SAGRES). Este processo de desenvolvimento ocorreu de modo iterativo, como proposto por Erl(2005). Para isso, ser descrita a contextualizao do ambiente de sistemas da universidade e o que de mais importante ocorreu durante os processos de anlise, projeto e construo da soluo. 5.1. Contextualizao A UESB possui um conjunto de sistemas de informao pelos quais algumas partes de alguns dos inmeros processos que ocorrem em seu ambiente interno e externo so automatizadas. Estes sistemas tem suas funcionalidades agrupadas de acordo a critrios administrativos e organizacionais desta instituio. A maioria destes sistemas so desenvolvidos e mantidos pela prpria universidade, atravs da UINFOR, setor responsvel, entre outras coisas, pela construo dos sistemas de informao necessrios. Estes sistemas encontram-se implementados em diferentes arquiteturas e em diferentes plataformas de desenvolvimento. Alguns possuem arquitetura desktop(stand alone) utilizandose a plataforma de desenvolvimento Delphi, outros possuem arquitetura Web, utilizando-se Java EE. Existem alguns sistemas que podem ser considerados hbridos, como o caso do sistema acadmico, que no desenvolvido na universidade, sendo fornecido como produto por uma organizao externa. Este sistema tem mdulos desktop e mdulos web. A estrutura de software corporativo da UESB tem sido desenvolvida desde o final da dcada de 90 at hoje. Consequentemente, muito se mudou na maneira pela qual os primeiros sistemas foram desenvolvidos e so desenvolvidos hoje. As atuais necessidades da universidade tambm so bem distintas daquelas iniciais, com relao a TI. Como consequncia desta conjuntura, praticamente todos os sistemas desenvolvidos do incio ao meio deste perodo devem ser classificados como sistemas legados. Uma outra caracterstica que fortalece essa classificao que a maioria destes foi desenvolvida em plataforma Delphi, sendo que o plano da UINFOR descontinuar, aos poucos, o uso desta plataforma. Encontrase aqui uma boa justificativa para a adoo de SOA.

44 A Figura 13 exibe uma viso geral do ambiente de sistemas encontrado atualmente na universidade. Destaca-se que, apenas os principais sistemas aparecem no esboo:
Figura 13 Viso Geral do ambiente de sistemas da UESB

Nesta figura, as elipses representam os sistemas e os conectores representam dependncia de lgica de negcio. O conector sai do sistema que necessita da lgica e vai quele que o fornece. Conectores contnuos tem essa dependncia de alguma forma j implementada e os tracejados necessitam de implementao. No caso dos sistemas que necessitam de lgica de negcio de outro e esto com os conectores tracejados, provvel que exista redundncia na implementao desta lgica, ou seja, a lgica implementada nos dois sistemas e possvel tambm que ela esteja gerando resultados diferentes para entradas iguais. Esse tipo de redundncia malfica a estrutura de sistemas, pois torna mais onerosa qualquer alterao feita em um sistema que tenha lgica redundante. Uma outra consequncia neste cenrio a possibilidade de um dos sistemas, ou mais, estarem gerando resultados errados. Uma outra caracterstica deste ambiente a necessidade de desenvolvimento de novas solues de software. Existe grande demanda de sistemas para atender a diversos clientes na UESB. Vale a pena ressaltar o dinamismo que pode ser visto na universidade. Existem inmeros relacionamentos internamente na UESB e desta com o ambiente externo. Isto torna a realidade da UESB muito complexa e, consequentemente, de difcil anlise. Assim, a UESB

45 tem grande necessidade de ter seu aparato de TI alinhado a suas atividades meio e atividades fim, podendo ela dessa forma melhor aproveitar as oportunidades e sobressair nas dificuldades. Essa outra justificativa para se adotar SOA. Com o intuito de complementar as informaes j fornecidas, a tabela apresentada a seguir exibe informaes referentes a caractersticas importantes associadas com os principais sistemas utilizados na UESB.
Tabela 1 Caracterizao dos principais sistemas da UESB Sistema Sistema Acadmico (Sagres) Sistema de RH (Populus) Sistema de Protocolo (Lupus) Sistema de Gesto de Bens (Ajax) Sistema de Compras Sistema de Biblioteca(Pergamun) Sistema de Transportes Sistema de controle do processo de seleo de vestibular Delphi Delphi + Java EE Delphi + Java EE Delphi + Java EE Delphi Delphi Plataforma Arquitetura Hbrida Hbrida Hbrida Desktop Desktop Hbrida Desktop Hbrida Cliente Pr-Reitoria da Graduao Pr-Reitoria de Administrao e Recursos Humanos Pr-Reitoria de Administrao e Recursos Humanos Gerncia Administrativa Gerncia Administrativa Setor de Biblioteca Setor de Transportes Comisso permanente para o vestibular

necessrio observar que as clulas na coluna plataforma que esto em branco referem-se a sistemas fornecidos por terceiros e que, portanto, esto fora do controle da universidade. Na sequncia, sero apresentados os pontos mais importantes associados ao desenvolvimento da soluo baseada em SOA e implementada com Web Services, j referenciada no trabalho. O termo soluo, na sequncia do trabalho, far referncia ao conjunto de web services desenvolvido. 5.2. Anlise da soluo Assim como recomenda Erl(2005), o processo de anlise seguido para se desenvolver a soluo possui 3 etapas. Na primeira etapa foram analisados os requisitos do negcio, que de certa forma esto representados tambm na contextualizao efetuada no subcaptulo anterior. Esta contextualizao trouxe uma viso mais ampla e genrica das necessidades da organizao, no caso a UESB, assim como deu base para se definir as camadas de servio,

46 que serviro de estrutura base para o desenvolvimento desse projeto e de outros, caso desejado. Ainda na primeira etapa foram desenvolvidos os casos de uso que permitiram a modelagem da soluo, tanto no restante da anlise quanto no projeto. Estes casos de uso sero apresentados a seguir. 5.2.1. Requisitos Os casos de uso da soluo desenvolvida esto listados no diagrama de casos de uso, apresentado na Figura 14.
Figura 14 Diagrama de casos de uso da soluo

Estes so os seis casos de uso que compe a soluo a ser desenvolvida. O ator Sistema Externo, inicialmente, vem a ser o sistema que est sendo desenvolvido para avaliao de professores. Uma outra tarefa realizada na primeira etapa da anlise a definio do escopo do

47 projeto de SOA desenvolvido. Sendo este o primeiro projeto onde se aplica tais conceitos na UINFOR, foi escolhido um escopo bem pequeno e definido e que deve atender as necessidades do sistema de avaliao de professores. Aps estas necessidades serem atendidas, possvel se projetar os servios, sempre que possvel, buscando as caractersticas de SOA, desde que no torne a soluo tecnicamente muito complexa. 5.2.2. Lgica de automao j existente A segunda etapa do processo de anlise(identificar lgica de automao j existente) foi de certa forma comprometida, uma vez que a propriedade do cdigo do sistema acadmico no pertence a UESB. No entanto, a universidade tem um contrato de manuteno com a empresa que fornece o sistema e atravs deste, possvel se ter acesso pelo menos aos dados que so referentes ao SAGRES. A forma pelo qual a UINFOR tem acesso a estes dados atravs de vises no banco. Sendo assim, no existe a possibilidade de reutilizao de lgica de aplicao, restando somente as vises como meio de acesso aos dados j cadastrados na base. Essas vises sero utilizadas para que os web services que constituem a soluo forneam os dados, inicialmente ao sistema de avaliao de professores e depois aos outros que necessitarem. 5.2.3. Camadas de servio e servios candidatos Inicialmente existiria somente uma camada de servios, que iria conter os modelos de servios de tarefa. Esta camada faria uma fronteira entre o sistema acadmico e os outros sistemas da universidade. No entanto, aps refinamento, tornou-se interessante a existncia de um modelo com mais camadas, surgindo ento a camada de servios de entidade e a camada de servios utilitrios. Dessa forma aumenta-se a reusabilidade do soluo, pois quem necessitar de servios de entidade ou servios utilitrios relacionados ao sistema acadmico, pode utilizar os servios j existentes. Como j afirmado no captulo 4, servios de entidade e servios utilitrios tendem a ser amplamente reutilizveis no contexto de SOA. A Figura 15 apresenta o modelo de camadas de servios desenvolvido e os servios candidatos. Percebe-se tambm pela figura que existem 6 candidatos de servios. O AcademicoService um servio de tarefa que far uma fronteira entre o consumidor do servio(normalmente uma aplicao da UESB) e o restante das camadas. Os servios de entidade permitiro que operaes relacionadas a cada um dos conceitos de domnio, no caso,

48 Perodo Letivo, Aluno, Professor e Classe, estejam acessveis aos consumidores. Por fim, localizado na camada de servios utilitrios, estar o SecurityService, que encapsular lgica agnstica referente a controle de permisses.
Figura 15 Camadas de servio e servios candidatos

5.3. Projeto da soluo O processo de projeto utilizado para desenvolvimento da soluo uma adaptao do processo proposto por Erl(2005). Este adaptao contem trs etapas, a saber: Compor SOA. Projetar camadas de servio. Projetar os servios em cada camada.

Para o escopo deste trabalho, compor SOA vem a ser definir a tecnologia que dar suporte aos princpios de SOA. Os critrios utilizados na escolha da tecnologia para desenvolvimento da soluo so informados na sequncia. 5.3.1. Escolha da tecnologia SOA, conforme listado no capitulo 2, suporta diversidade de fornecedor. Isso

49 essencial no ambiente da UESB e ao desenvolvimento do sistema de avaliao de professores, uma vez que este sistema est sendo implementado fora da UINFOR. No entanto, para o desenvolvimento desta soluo em especfico, a plataforma Java EE a nica escolha aceitvel. Os motivos pelos quais isto ocorre so os seguintes: A UINFOR tem como padro desenvolver para essa plataforma. Essa plataforma possui um conjunto de benefcios que auxiliam no desenvolvimento da soluo, tais como: Suporte de vrias IDEs, diminuio considervel do trabalho de se criar arquivos XML, frameworks disponveis, etc. J existe, na UINFOR, um servidor web em ambiente de produo no qual a soluo ser implantada. Ainda argumentando sobre escolhas tecnolgicas, apesar de se escolher Java EE, existem vrias escolhas mais especficas a se fazer pois Java EE tambm suporta diversidade de fornecedores. A mais importante destas vem a ser a escolha da verso desta plataforma. A verso escolhida foi o Java EE 5, quando comparado ao Java EE 6. O motivo principal desta escolha a necessidade de se utilizar o framework Spring, um outro padro tecnolgico da UINFOR. Alm disso, o Spring possui um mdulo para desenvolvimento de web services muito flexvel e que deixa o desenvolvimento destes mais adequado a plataforma Java. A seguir, so listados os principais componentes tecnolgicos utilizados no desenvolvimento do projeto: Java EE 5 Spring Framework Spring Web Services Hibernate Netbeans IDE

Depois de mostrar os critrios pelos quais a tecnologia foi escolhida, momento de apresentar as consideraes realizadas durante as duas prximas etapas do processo de projeto. 5.3.2. Projeto de camadas e de servios Como sada da anlise, foi gerado um modelo de camadas e um conjunto de servios candidatos. Este modelo de camadas, assim como os servios candidatos pode sofrer alteraes da anlise para o projeto. Dos requisitos mostrados no diagrama de casos de uso,

50 foram retiradas seis capacidades que devem estar no inventrio de servios que constitui a soluo. Estas capacidades so as listadas a seguir: checkLogin getAlunoFromLogin getProfessorFromLogin getPeriodoLetivoAtual getClassesFromAlunoAndPeriodoLetivo getClassesFromProfessorAndPeriodoLetivo

As camadas desenvolvidas na anlise continuaram as mesmas no projeto, uma vez que estes trs nveis de camadas trazem um alto grau de flexibilidade para a arquitetura e no foi necessrio nenhuma mudana nesta estrutura. As capacidades foram atribudas aos servios, no entanto por questo de reusabilidade, em alguns casos a mesma capacidade foi adicionada a mais de um servio. O resultado desse processo apresentado a seguir:
Figura 16 Camadas de Servios aps o termino da fase de projeto

Observando-se as diferenas nas apresentaes das camadas, na fase de anlise e de projeto, percebe-se que na fase de projeto os relacionamentos entre os servios so formados. A Figura 17 exibe cada um dos servios com suas respectivas capacidades. Vale a pena

51 ressaltar que o servio acadmico(AcademicoService) engloba todas as capacidades listadas anteriormente. Essa foi uma escolha de projeto e tem como objetivo abstrair em um s servio as capacidades de determinado agrupamento lgico de servios. Dessa forma, ser muito mais fcil para o sistema de avaliao de professores utilizar os servios que necessita. Este tambm um claro exemplo de uma composio de servios. 5.4. Construo da soluo Depois de concludo o projeto orientado a servios, o prximo passo para a concluso da aplicao vem a ser a construo, em si, do agente do web service. Para tanto, foi utilizado o ambiente de desenvolvimento integrado NetBeans, que fornece algumas ferramentas que auxiliam o desenvolvimento de web services com Java EE. O primeiro passo para a construo, que em si uma tarefa de projeto, s que orientado a objetos, vem a ser a criao de um modelo de classes, abstrado na Figura 18 por meio de um diagrama do mesmo tipo. Este modelo de classes possui as entidades aluno, professor, perodo letivo, classe e disciplina. Estas classes formam a estrutura bsica que o sistema de avaliao de professores necessita para operar. Alm disso, so as entidades chave para todo o sistema acadmico, logo, a possibilidade de que a estrutura delas seja reutilizada em uma outra necessidade muito grande. necessrio destacar que este modelo de classes passa a ser vlido em todo o ambiente de sistemas da UESB. Isto mostra como o benefcio prometido por SOA, que diz respeito a um direcionamento em sentido a uma representao padronizada de dados, realmente alcanvel. 5.4.1. Arquitetura A arquitetura utilizada na soluo composta por duas camadas, uma de negcios e outra de persistncia. A camada de negcio contm as entidades e os componentes relacionados com lgica de negcio no contexto da aplicao. Aqui entram os componentes de infraestrutura do Spring Web Services, que abstraem considervel parte do trabalho em se desenvolver estes artefatos. J a camada de persistncia implementada, em sua maior parte atravs do framework Hibernate. Os objetos que se encontram nesta camada tem responsabilidades associadas a

52 manipulao de dados no banco do SAGRES.

Figura 17 Servios e suas respectivas capacidades

5.4.2. Testes e resultado do processo de construo Durante o processo de construo foram efetuados testes dos servios, com o intuito de garantir uma certa confiabilidade aos dados obtidos. Como o sistema de avaliao ainda est em desenvolvimento, no pode ocorrer, de fato a integrao entre a soluo desenvolvida. No entanto, por conta do escopo bem delimitado e dos resultados dos testes, realmente no esperado nenhum problema na integrao entre a soluo desenvolvida e o novo sistema. Os servios encontram-se implantados e acessveis atravs do ambiente de sistemas da

53 universidade.
Figura 18 Diagrama de classes de entidade

54 6. Concluso Atravs da anlise realizada durante todo o trabalho aliado ao desenvolvimento do estudo de caso e da experincia com outros paradigmas de desenvolvimento de sistemas distribudos possvel se afirmar que SOA alcana seus principais objetivos. Pde-se perceber que os conceitos associados ao paradigma de Orientao a Servios realmente permitem o desenvolvimento de um ambiente de sistemas onde mais fcil se reutilizar e alterar o que j foi desenvolvido. Um outro benefcio que pode ser observado atravs do trabalho foi a agilidade obtida atravs da arquitetura, que permite alteraes em processos e regras de negcio serem facilmente refletidos nos sistemas. O nvel de abstrao fornecido por camadas de servio tambm pode ser observado, sobretudo, no estudo de caso, onde foi visvel a flexibilidade ganhada ao se adicionar camadas de servios a arquitetura desenvolvida. A tecnologia de Web Services tambm mostrou-se muito adequada ao se trabalhar com SOA. Muitas das caractersticas de SOA, como baixo acoplamento, neutralidade de fornecedor e federao so suportadas nativamente por esta tecnologia. Aumentar o escopo do trabalho, abordando tambm cada uma das caractersticas de SOA e descrever em maior grau os processos de anlise e projeto orientados a servios poderiam ser algumas melhorias propostas a reviso bibliogrfica realizada no trabalho. Algumas melhorias a serem feitos no estudo de caso esto relacionadas a aumentar o escopo de SOA que foi utilizado no projeto, inicialmente a uma maior parte do sistema acadmico, com o intuito de se verificar a arquitetura desenvolvida em um contexto maior. Espera-se que este trabalho d uma boa introduo a SOA e o estudo de caso sirva de experincia para a UINFOR, caso venha a adotar este paradigma no seu ambiente de sistemas.

55

7. Referncias:
BASS, L. Software Architecture in Practice. 2 ed. [S.l.]: Addison Wesley, 2003 BEAN, J. SOA and Web Services Interface Design: Principles, Techniques and Standards. [S.l.]: Elsevier, 2010 ERL, T. SOA: Principals of Service Design. Crawfordsville : Prentice Hall , 2007. ERL, T. Service-Oriented Architecture: Concepts, Technology, and Design.

Crawfordsville: Prentice Hall , 2005. ERL, T., 2008a. SOA Design Patterns . Crawfordsville: Prentice Hall , 2008a. ERL, T. Et al., 2008b. Web Service Contract Design and Versioning for SOA. Crawfordsville: Prentice Hall , 2008. HEIL , Maiara. Uma Proposta De Guia De Referncia Para Provedores De Software Como Um Servio . 2009. 134p. Dissertao(Mestre em Engenharia de Automao e Sistemas ) - Universidade Federal de Santa Catarina, Florianpolis. 2009 HURWITZ, J. Et al. Service Oriented Architecture For Dummies. Indianapolis: Willey, 2007 SILVA, E. L. D.; MENEZES, E. M. Metodologia da Pesquisa e Elaborao de Dissertao. Editora da UFSC, 2005. SOA CONSORTIUM, 2008a. Disponvel em http://www.soa-consortium.org. Acesso em: 03/09/2011 SOA WORK GROUP, The SOA Source Book. 4 ed. Disponvel em

http://www.opengroup.org/soa/source-book/soa/index.htm. Acesso em 03/09/2011 SOA GLOSSARY, Definitions for Service-Oriented Computing Terms. 2011. Disponvel em http://www.w3.org/TR/ws-arch/#service, Acesso em 06/09/2011. TIDWELL , D.; SNELL , J.; KULCHENKO , P. Programming Web Services with SOAP .

56 [S.l.]: O'Reilly 2001. WORLD WIDE WEB CONSORTIUM, Web services architecture. Technical report. 2004. Disponvel em http://www.w3.org/TR/ws-arch/#service, Acesso em 26/08/2011.