Desenvolvimento de uma Aplicação utilizando SOA: um Estudo de Caso

Desenvolvimento de uma Aplicação utilizando SOA: um Estudo de Caso Roberto Felipe Caliendo, Daniel Luís Notari Centro de Ciências Exatas e Tecnologia Universidade de Caxias do Sul (UCS) Rua Francisco Getúlio Vargas, 1130 Bloco 71 95.070-560 Caxias do Sul RS Brasil {rfcalien, daniel.notari}@ucs.br Categoria do trabalho: Trabalho de Graduação Resumo. O objetivo deste artigo é apresentar o desenvolvimento de uma aplicação utilizando SOA (Arquitetura Orientada a Serviços). Um estudo de caso apresenta uma arquitetura de software para uma aplicação acessar os serviços de notícias disponibilizadas na web através de feeds RSS. Um protótipo do estudo de caso foi implementado, o qual contém um cadastro de usuários com as suas preferências de categorias de notícias. Estas informações são utilizadas para realizar pesquisas em sites de notícias na web. O protótipo permite que os serviços sejam acessados por um cliente web e por um cliente desktop. Com isto, o usuário pode acessar as suas preferências de notícias de duas formas diferentes, demonstrando desta maneira, o consumo do mesmo serviço implementado como um WebService. Palavras-chaves: SOA, WebServices, RSS Abstract. The purpose of this paper is to present the development of a SOA (Software Oriented Architecture) application. A case study shows a software architecture for an application to access news available on the web through RSS feeds. The case study has a prototype implementation that contains user registers with their favorite news categories. These informations are used to search website news. The prototype's services can be accessed by both a web and a desktop thin client. In this way, users can access their news preferences by two different ways, consuming the same service implemented as a WebService. Keyworks: SOA, Web Services, RSS 1. Introdução O uso de tecnologias novas como SOA e WebServices em aplicações é uma realidade. Contudo, as organizações não podem simplesmente descartar as aplicações existentes. Uma vez que, reconstruir uma aplicação legada com o uso de novas tecnologias exige pessoal especializado, tempo e, em geral, é muito custoso e demorado. As aplicações existentes são usadas diariamente e, geram uma quantidade enorme de dados. Acessar estes dados por outras aplicações, por exemplo para visualizações de maneira diferente dependendo do perfil do usuário, requer a construção de softwares que façam isto. Esta tarefa também é custosa e demorada. Por isto, é necessário pesquisar maneiras novas de acessar os dados destas aplicações com os investimentos existentes feitos nas organizações (SAMPAIO, 2006). Neste cenário, a diversidade de sistemas de informação existentes também causa um problema para os profissionais da área de TI (Tecnologia da Informação) administrarem: sistemas heterogêneos desenvolvidos por fornecedores e com linguagens de programação diferentes. Isto resulta em aplicações que não estão aptas a trocarem informações. Um exemplo

disso é a troca de dados entre um sistema de CRM (Customer Relationship Management) e um sistema ERP (Enterprise Resource Planning) com a intenção de minimizar o cadastro de informações comuns aos dois sistemas. A troca de informações entre as aplicações, ou seja, a interoperabilidade é um dos objetivos de SOA. A comunicação dos sistemas é o ponto chave para estabelecer a relação entre sistemas de diferentes fornecedores (SAMPAIO, 2006). Apesar do desenvolvimento de sistemas estar em constante evolução, ainda não existe um padrão para o reuso de componentes de software. SOA possui também como objetivo maximizar o reuso dos seus componentes (serviços), para que em médio prazo, a tarefa do desenvolvimento de uma aplicação seja primordialmente a tarefa da composição e coordenação dos serviços já implementados, aumentando o reuso e diminuindo o dispêndio de recursos (MCCOY, 2003). Atualmente, a abordagem de SOA, de maneira simplificada, é uma camada de software que permite um sistema publicar suas funcionalidades como serviços, e estes podem ser consumidos por qualquer outra aplicação (SAMPAIO, 2006). O objetivo deste artigo é desenvolver uma aplicação baseada em SOA visando a reutilização dos serviços definidos através da sua invocação por uma aplicação web e por uma aplicação desktop. A validação deste objetivo é apresentada através do desenvolvimento e implementação de um estudo de caso. A aplicação desenvolvida no estudo de caso apresenta um cenário e um protótipo para o cadastro de usuários com as suas preferências de categorias de notícias para pesquisa em sites de notícias na web. O usuário pode acessar as suas preferências de notícias de duas formas diferentes (web e desktop), demonstrando desta maneira, o consumo do mesmo serviço implementado como um WebService. As categorias de notícias e as notícias são acessadas via feeds RSS. A partir dos resultados obtidos com este estudo de caso, será possível planejar o uso de SOA para aplicações reais existentes para a troca de informações através do uso da tecnologia de WebServices em uma empresa real. Este artigo esta organizado da seguinte maneira. A seção 2 apresenta uma breve introdução sobre arquitetura orientada a serviços, serviços e WebServices. A seção 3 mostra o cenário para o desenvolvimento de uma aplicação utilizando SOA, trabalhos relacionados e a arquitetura de software do protótipo implementado. A seção 4 apresenta o estudo de caso. E, por fim, a seção 5 apresenta as conclusões e trabalhos futuros deste artigo. 2. Arquitetura Orientada a Serviços A OASIS (Organization for the Advancement of Structured Information Standards) é a comunidade responsável pela especificação de SOA. SOA representa uma coleção dos melhores princípios, das melhores práticas e dos melhores padrões relacionados aos serviços, as empresas e a computação distribuída (OASIS, 2008). Em um ambiente corporativo SOA é definida como uma configuração de um software multi-camadas que ajudam as organizações a compartilhar lógica e dados através de múltiplas aplicações e modelos de uso (PACHECO, 2005). Para CIO (2007), a conceituação de SOA apresenta dois aspectos distintos: as duas primeiras palavras (Arquitetura e Orientada) expressam uma metodologia para desenvolvimento de software, enquanto que a terceira palavra (Serviço) é um panorama de todos os ativos de software 1 de uma empresa. Com isto, entende-se SOA como parte da estratégia para a divulgação de todos os ativos de software de uma empresa, através de uma metodologia de programação orientada a serviços. 1 Ativo de software é tudo aquilo que pode ser reutilizado em termos de software, de qualquer fase de desenvolvimento, até mesmo os sistemas finais.

Para W3C (2008), a orientação a serviços modulariza os recursos de TI, criando os processos de negócios interligados e que integram informações entre sistemas. Desta forma, os serviços são pequenas porções de software, construídas de tal forma, que possam ser vinculadas a outros componentes de software. A idéia central é que a tecnologia expresse resultados de forma que analistas de negócio possam entender facilmente o seu propósito e poder reutilizar os serviços já definidos e implementados (MICROSOFT, 2006). Um serviço, no contexto de SOA, é um mecanismo para permitir o acesso a um conjunto de regras de negócio. O acesso é provido através de uma interface 2 descrita com restrições e políticas como especificados pela descrição de serviço (OASIS, 2008). Um WebService é a implementação de um serviço. É importante destacar que um WebService não é a única alternativa para implementação e publicação de serviços. Outras alternativas possíveis são o uso de serviços de objetos remotos, tais como, CORBA (Common Object Request Broker Architecture), RMI (Remote Method Invocation), DotNET, etc. Todos estas tecnologias permitem a publicação de serviços e, conseqüentemente, a invocação deste permitindo a interoperabilidade entre aplicações. A Figura 1 apresenta a arquitetura básica de um WebService. Uma aplicação servidora registra um serviço (1) através de um documento WSDL (Web Service Description Language). Este documento fornece as características operacionais do serviço (ENDREL, 2004; ORT, 2005; W3C, 2008). Figura 1: Arquitetura Básica de WebService (SAMPAIO, 2006) O serviço é registrado no repositório UDDI (Universal Description, Discovery and Integration). Este é o padrão para registro de serviços onde é especificado a forma de armazenamento e recuperação das informações dos serviços, tais como, nome, descrição, URL (Uniform Resource Locator) e a interface do serviço (ENDREL, 2004; ORT, 2005). Após a publicação e registro do serviço, este pode ser consumido por uma aplicação. A invocação do serviço (3) ocorre através do protocolo SOAP (Simple Object Access Protocol). Este é um protocolo de comunicação baseado em XML que permite a troca de informações em um ambiente distribuído. O protocolo define um formato comum de mensagens para troca de dados entre aplicações clientes e servidores (ENDREL, 2004; ORT, 2005; W3C, 2008). Se tudo estiver correto com a invocação do serviço, a resposta (4) é enviada para a aplicação. 3. Cenário para o desenvolvimento de uma aplicação utilizando SOA A Figura 2 apresenta um cenário para o desenvolvimento de uma aplicação utilizando os conceitos de SOA. A aplicação visa cadastrar usuários e as suas preferências de categorias de notícias. A partir disto, a aplicação irá acessar feeds RSS e pesquisar as categorias de notícias cadastradas e apresentar estas para os seus usuários. 2 Interface é composta por um cabeçalho com o nome de um método e um conjunto de parâmetros.

O cenário está dividido nas seguintes camadas: clientes (front-end), servidores, serviços de aplicação e serviços de domínio. A camada cliente permite consumir os serviços através de uma aplicação desktop e de uma aplicação web. Os serviços disponíveis são de consultas as informações dos usuários, consulta as categorias de notícias e, consulta as notícias propriamente ditas. Figura 2 : Cenário para integração de aplicações A camada de servidores fornece os serviços de um servidor web para acesso aos websites de notícias e de um SGBD para armazenar as informações dos usuários. A camada de serviços de aplicação contém a implementação dos serviços para cadastramento dos usuários e de suas preferências de categorias de notícias. Quando um usuário é cadastrado, uma mensagem eletrônica é enviada para confirmação do cadastro. A camada de serviços de domínio é responsável pelo acesso remoto a outros aplicativos disponíveis na web. Os serviços disponíveis são o envio de mensagem de correio eletrônico, de acesso as categorias de notícias dos usuários e de acesso a notícias via feeds RSS. A seguir são apresentados alguns trabalhos relacionados com a proposta deste artigo, bem como, a arquitetura de software da implementação do protótipo. 3.1. Trabalhos Relacionados Os trabalhos relacionados nesta seção possuem a característica de terem desenvolvido estudos de casos com aplicações baseadas em SOA. O estudo de caso apresentado por GROSSI (2005) teve como objetivo mostrar os passos necessários para a concepção e o desenvolvimento de aplicações baseadas em serviços que fazem parte desse novo modelo de programação. A aplicação, desenvolvida no estudo de caso, pretendeu construir um sistema de mineração de dados em um ambiente distribuído. A mineração de grandes bases inclui diversos requisitos interessantes, como a localização e o uso dinâmico de serviços remotos, que podem ser mapeados no modelo de SOA. O resultado foi um sistema baseado em WebServices que atende aos requisitos necessários para a mineração de

dados distribuída. A extensibilidade e escalabilidade da plataforma foram medidas para demonstrar a viabilidade e as potencialidades do uso de um modelo baseado em SOA. O estudo de caso de CUADRADO et. al. (2008) demonstra a evolução de um sistema legado existente para uma sistema baseado em SOA. O objetivo principal do estudo de caso é obter uma melhor manutenabilidade do sistema como um todo. O processo proposto inclui a recuperação da arquitetura do sistema legado. Esta arquitetura foi utilizada para planejar a evolução do sistema legado para uma concepção baseada em SOA, além de definir como as mudanças seriam executadas e validadas. O estudo de caso foi aplicado para um sistema de imagens médicas, desenvolvido como um modelo de serviços implementados como WebServices. O estudo de caso de CANFORA et. al. (2008) diz que a modernização de sistemas de software usando SOA e WebServices representa uma valiosa opção para prolongar o tempo de vida de sistemas de missão crítica. CANFORA et. al. apresentam uma abordagem de modernização usando um estilo arquitetural caixa-preta para expor funcionalidades interativas de sistemas legados como serviços. O problema de transformar uma interface de usuário original do sistema em uma interface de requisição/resposta de SOA é resolvido por um wrapper que é capaz de interagir com o sistema em benefício do usuário. 3.2. Arquitetura de Software do Protótipo O cenário proposta na Figura 2 foi implementado conforme a arquitetura de software apresentada na Figura 3. A implementação 3 deste protótipo utilizou a ferramenta de desenvolvimento Turbo Delphi for DotNET da Borland, o SGBD SqlServer 2005 e a ferramenta de disponibilização dos serviços IIS (Internet Information Services). Para testar o cliente web foi utilizado o navegador Internet Explorer 7. Para o cliente desktop foi utilizado o sistema operacional Windows XP. Figura 3: Arquitetura de Software 3 A implementação deste protótipo foi realizada na disciplina de Trabalho de Conclusão do Curso de Ciência da Computação da Universidade de Caxias do Sul. O ambiente de desenvolvimento utilizado foi em uma empresa de desenvolvimento de software local. Esta empresa utiliza as ferramentas da plataforma da Microsoft. Por esta razão estas ferramentas foram utilizadas.

As próximas seções descrevem as camadas da arquitetura 4 de software: aplicação, WebServices e regras de negócio. 3.2.1. Camada de Aplicação A camada de aplicação representa a interface de comunicação com as aplicações clientes, ou seja, o cliente pode ser uma camada de apresentação, outra camada de negócio ou outra aplicação. Desta forma, esta camada necessita acessar os serviços da camada de negócio desta arquitetura. Esta camada é responsável por controlar o fluxo do trabalho, conforme o conceito de SOA, quem realiza este papel é o orquestrador (SAMPAIO, 2006), assim os clientes instanciarão os WebServices necessários para realização do trabalho desejado. Nesta arquitetura, os clientes web e desktop são considerados leves, pois não possuem regras de negócio e, esta camada possui um servidor de informações (IIS) que contêm os serviços a serem consumidos. Desta forma, as tarefas mais relevantes de sua lógica interna, exigem um mínimo de hardware e software presentes na máquina cliente, levando-se em consideração que o processamento mais pesado é realizado em um servidor apropriado (SAMPAIO, 2006). 3.3. Camada de WebServices Esta camada tem como finalidade principal a publicação dos serviços, não ficando sob sua responsabilidade, a execução das solicitações realizadas aos seus métodos publicados. Para tanto, nesta camada foram utilizados dois padrões de projeto, tendo em vista um melhor reaproveitamento do código escrito nas demais camadas. O padrão de projeto delegate define que um objeto pode enviar uma mensagem para outro objeto, em resposta a uma mensagem (LARMAN, 2004). Os WebServices desenvolvidos executam as chamadas recebidas e delegam a execução para a próxima camada da arquitetura (fachada). O padrão de projeto proxy evita a execução desnecessária de funcionalidades custosas de maneira transparente para os clientes (BRAUDE, 2005). Com isto, quando um WebService recebe um documento XML, este repassa-o para o fachada com a finalidade de interpretar esta informação de maneira transparente ao cliente, não necessitando fornecer dados no formato esperado para a plataforma interna. Todos os protocolos de WebServices foram criados a partir das definições apresentadas na seção 2. Os serviços desenvolvidos foram publicados como WebServices para serem consumidos por esta ou outra aplicação de maneira padrão e, contemplar as premissas de uma arquitetura SOA que visa a exposição dos serviços, podendo estes serem consumidos em qualquer plataforma e potencialmente acessados de qualquer lugar do mundo (SAMPAIO, 2006). 3.3.1. Camada de Negócio Esta camada é responsável por receber as solicitações de chamadas dos serviços publicados, executar este serviço e devolver a resposta ao solicitante. Para realizar estas tarefas, esta camada está organizada em camadas internas. A primeira camada interna é a fachada. Esta camada é a mais importante do ponto de vista gerencial. A principal atribuição desta camada é receber uma solicitação de serviço e delegar a sua execução para o objeto correto (LARMAN, 2004; BRAUDE, 2005). A segunda camada interna é a de serviços. Esta camada é a responsável por mapear os serviços que provêm as funcionalidades básicas, técnicas e de negócio. A terceira camada interna é a camada de sistemas. Esta camada é responsável por gerenciar toda a persistência de dados independente do SGBD utilizado. A quarta camada interna é a camada de acesso aos dados que implementa o padrão de projeto DAO (Data Access 4 O diagrama de classes das camadas não será apresentado por causa da limitação do número de páginas deste artigo. Os mesmos podem ser obtidos com os autores deste artigo.

Object). Este padrão é responsável pela manipulação da estrutura física de armazenamento dos dados (LARMAN, 2004). A camada de negócio utiliza os serviços desta camada para modificar ou consultar os dados. A implementação deste módulo independerá do banco de dados a ser utilizado, devido o uso da plataforma DotNet. 4. Estudo de Caso Nesta seção será apresentado um estudo de caso para validar o protótipo implementado. Inicialmente, o usuário da aplicação poderá utilizar as duas aplicações clientes independentes ou simultaneamente. A Figura 4 apresenta o cliente web com a relação dos usuários já cadastrados, sendo permitida a inclusão de um novo usuário, a edição e exclusão do usuário, bem como, acessar as notícias selecionando-se a categoria desejada. 1234 1234 1234 1234 Figura 4: Cliente Web 5 A Figura 5 apresenta o cliente desktop da aplicação onde pode ser visualizada a relação de usuários cadastrados. 1234 1234 Figura 5: Cliente Desktop 3 A Figura 6 apresenta as notícias selecionadas para uma categoria de um usuário. As informações são as mesmas mostradas no cliente web (Figura 4). Note que a mesma informação na web foi disposta de maneira diferente na aplicação desktop. O que na interface web está organizada em uma página, na interface desktop tem-se guias que representam a informação dos usuários cadastrados mais as notícias de seu interesse. 5 O número do CPF e o número do telefone foram alterados por questões de segurança.

Figura 6: Notícias via RSS do Terra no Cliente desktop Para cadastrar um usuário na aplicação web deve ser preenchido o formulário apresentado na Figura 7 e, após clicar no botão de Inserir. Havendo sucesso, o usuário será remetido para a página de preenchimento do perfil do usuário. Em caso de erros existentes na postagem das informações no servidor, o mesmo responderá com uma lista de erros que será exibida abaixo do botão de inserir. Os campos indicados com (*) são obrigatórios. Figura 7: Cadastramento de Usuários WEB 6 A Figura 8 mostra o cliente web com a opção para definir as preferências de visualização de notícias para um usuário cadastrado. No exemplo, a categoria esportes foi selecionada e, o WebService buscou as opções da categoria esportes via RSS 7. Figura 8: Definição do Perfil do Usuário no cliente web. 6 A mesma tela para a aplicação desktop não será mostrada por causa do número de páginas. 7 Para o desenvolvimento do estudo de caso, foi utilizado o feed RSS do site Terra (www.terra.com.br)

5. Considerações finais e trabalhos futuros Durante a elaboração deste trabalho surgiram muitas dificuldades técnicas para a montagem do ambiente de desenvolvimento necessário para atender a arquitetura especificada. Os problemas foram decorrentes da complexidade dos softwares utilizados no que tange a suas aquisições, instalações e configurações. Isto porque a característica deste trabalho previu o seu funcionamento completo com a integração entre banco de dados (Sql Server 2005), ferramenta de disponibilização dos serviços (IIS) e ferramenta de desenvolvimento Turbo Delphi for DotNET. Durante o desenvolvimento do trabalho notou-se a real interoperabilidade entre aplicações heterogêneas que a SOA oferece, utilizando-se clientes leves que consomem os mesmos serviços em clientes completamente diferentes. Com este trabalho mostra-se que a implementação dos serviços por uma aplicação é tão importante quanto a publicação dos mesmos. A organização da aplicação torna os serviços mais eficientes, podendo desde diminuir o tráfego da rede, até ter formas de persistência mais eficientes e rápidas para diminuir o tempo de resposta para o cliente do serviço, além de transferir a carga de processamento para o lado do servidor. O uso de WebServices mostra-se como tendência para comunicação e troca de informações entre aplicações e disponibilização de informações em diferentes contextos. Porém deve-se ter um cuidado todo especial ao consumir serviços de terceiros, exigindo sempre qual a garantia de que o referido WebService esteja disponível e acessível. Um exemplo disto, foi a utilização da consulta as informações de endereço através do CEP (Código de Endereçamento Postal). Neste caso foi assumido o risco em consumir um serviço qualquer disponível na Internet que não especifica garantia de acesso as informações, sob pena de ficar inacessível de uma hora para outra, estabelecendo-se assim uma relação de confiança. E isto aconteceu, pois os Correios passaram a cobrar para usar o seu serviço de consulta aos CEP dos logradouros. A decisão do desenvolvimento de um sistema completo baseado em WebServices é avaliada como interessante e viável. Tendo-se em vista as possibilidades que se pode atingir com o uso de WebServices os quais podem ser consumidos por aplicações diferentes tais como: web, desktop, palmtops, celulares, etc. A experiência adquirida com o desenvolvimento e testes do estudo de caso irá permitir o planejamento de novas funcionalidades ao sistema da empresa (na qual o protótipo foi desenvolvido) através do compartilhamento de informações utilizado WebServices sem o desenvolvimento de uma aplicação completamente nova. Como trabalhos futuros sugere-se a adaptação de uma metodologia de testes com a finalidade de garantir a qualidade e permanente funcionamento das camadas de uma arquitetura SOA, pois deve-se considerar a manutenção nestes fontes no momento em que se pretende fazer melhoria e ou ampliar seus limites. O uso de sistemas implementados em larga-escala com WebServices deve ser exaustivamente testado antes de ser disponibilizado aos clientes finais. Além disto, é necessário submeter os serviços implementados a uma carga maior de dados para saber a real possibilidade de uso dos WebServices e do tráfego de rede utilizado. Por fim, e talvez mais importante de tudo, será qualificar a equipe de planejamento (analistas de negócio e de sistemas) e desenvolvimento (programadores e testadores) de software para obter uma produtividade considerável no uso das tecnologias de SOA e WebServices.

Referências BRAUDE, Eric. Projeto de Software. Porto Alegre: Bookman, 2005. CANFORA, Gerardo; FASOLINO, Anna Rita; FRATTOLILLO, Gianni; TRAMONTANA, Porfirio. A wrapping approach for migrating legacy system interactive functionalities to Service Oriented Architectures. Journal of Systems and Software, Volume 81, Issue 4, April 2008, Pages 463-480. Selected papers from the 10th Conference on Software Maintenance and Reengineering (CSMR 2006). Elsevier Inc., 2007. Disponível em: <http://dx.doi.org/10.1016/j.jss.2007.06.006>. Acessado em 11 de fevereiro de 2008. CIO. O Tsunami SOA. Disponível em: <http://cio.uol.com.br/estrategias/2007/06/13/idglead.2007-06- 13.4412423781/>. Acessado em julho de 2007. CUADRADO, Félix; GARCÍA, Boni; DUEÑAS, Juan; PARADA, Hugo. A Case Study on Software Evolution towards Service-Oriented Architecture," ainaw,pp.1399-1404, 22nd International Conference on Advanced Information Networking and Applications - Workshops (aina workshops 2008), 2008. Disponível em: <http://doi.ieeecomputersociety.org/10.1109/ WAINA.2008.296>. Acessado em 11 de fevereiro de 2008. ENDREL, M. et al. Patterns: Service-Oriented Architecture and Web Services. RedBooks, IBM, Apr. 2004. Disponível em: <http://www.redbooks.ibm.com/redbooks/pdfs/sg246303.pdf>. Acessado em outubro de 2007. GAMMA, Erich, et al. Padrões de projeto. Soluções Reutilizáveis de Software Orientado a Objetos. Porto Alegre: Bookman, 2000. GROSSI, Bruno Estolano. Estudo do modelo de computação orientada a serviços e sua aplicação a um sistema de mineração de dados. Dissertação de Mestrado, Curso de Pósgraduação em Ciência da Computação, UFMG, 2005. Disponível em: <http://dspace.lcc.ufmg.br/dspace/bitstream/1843/rvmr-6eafwy/1/brunoestolanogrossi.pdf>. Acessado em 11 de fevereiro de 2008. LARMAN, Graig. Utilizando UML e padrões. São Paulo: Bookman, 2004. MCCOY, David W., Yefim V. Natis; Service-Oriented Architecture: Mainstream Straight Ahead. Disponível em: <http://www4.gartner.com/displaydocument?doc_cd=114361>. Acessado em setembro de 2007. MICROSOFT, Conheça a Arquitetura Orientada a Serviços (SOA - Service Oriented Architecture). Disponível em: <http://www.microsoft.com/brasil/servidores/biztalk/solutions/soa/overview.mspx#eeb>. Acessado em julho de 2007. PACHECO, Xavier. Guia do Desenvolvedor de Delphi for.net. São Paulo: Pearson Makron Books, 2005. SAMPAIO, Cleuton. SOA e Web Services em Java. Brasport, 2006. OASIS, Reference Model for Service Oriented Architecture. Disponível em : <http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=soa-rm>. Acessado em dezembro de 2008. ORT, E. Service-Oriented Architecture and Web Services: Concepts, Technologies, and Tools. Article, Sun Microsystems, April 2005. Disponível em: <http://java.sun.com/developer/technicalarticles/webservices/soa2/soa2.pdf>. Acessado em outubro de 2007. W3C, Working Group Note. Web Services Architecture. Disponível em: <http://www.w3.org/tr/ ws-arch>. Acessado em dezembro de 2008.