Ricardo Brito do Nascimento APLICAÇÕES DISTRIBUÍDAS COM WEB SERVICE NA PLATAFORMA LIVRE

Transcrição

1 Ricardo Brito do Nascimento APLICAÇÕES DISTRIBUÍDAS COM WEB SERVICE NA PLATAFORMA LIVRE Brasília DF 2005

2 Ricardo Brito do Nascimento APLICAÇÕES DISTRIBUÍDAS COM WEB SERVICE NA PLATAFORMA LIVRE MONOGRAFIA APRESENTADA AO CORPO DOCENTE DO CURSO DE ESPECIALIZAÇÃO EM ORIENTAÇÃO A OBJETO DO INSTITUTO CIENTÍFICO DE ENSINO SUPERIOR E PESQUISA, COMO REQUISITO PARCIAL PARA OBTENÇÃO DO TÍTULO DE ESPECIAL- ISTA EM ORIENTAÇÃO A OBJETO. Orientador: Prof. M.Sc. Wagner Castilho INSTITUTO CIENTÍFICO DE ENSINO SUPERIOR E PESQUISA CURSO ESPECIALIZAÇÃO EM ORIENTAÇÃO A OBJETO rbrito1978-pos@yahoo.com.br Brasília DF 2005

3 1 Sumário Lista de Figuras 3 Lista de Tabelas 4 1 Introdução Justificativa e Relevância do estudo Formulação do Problema Objetivos Objetivo Geral Objetivos Específicos Organização do Trabalho Referencial Teórico Tecnologia Open Source Historia da Linguagem de programação C/C História da Linguagem de Programação Java Sistemas operacionais UNIX e UNIX-LIKE Projeto GNU História do Sistema Operacional Linux Middleware para Aplicações Distribuídas DCOM - Distributed Component Object Model CORBA - Common Object Request Broker Architecture EJB - Enterprise Java Beans

4 RMI - Remote Method Invocation Web Services Principais Características Principais Vantagens Tecnologias aplicadas a Web Services Caso de Aplicação 49 4 Metodologia 50 5 Conclusão 51 Referências Bibliográficas 52

5 Lista de Figuras 3

6 Lista de Tabelas 4

7 5 1 Introdução 1.1 Justificativa e Relevância do estudo A nova era dos serviços distribuídos, tem apresentado o Web Service como uma solução simples, aplicável e econômica, onde os recursos podem ser reutilizados e fornecidos como serviços remotos, e da mesma forma consumidos localmente de servidores internos ou externos a rede. 1.2 Formulação do Problema 1.3 Objetivos Objetivo Geral Apresentar um estudo para uma solução web service, em plataforma e linguagens livres, de modo a atender pequenos nichos de mercado com soluções distribuídas Objetivos Específicos Descrever e apresentar as vantagens de um web services; Apresentar os protocolos comuns utilizados pelo web services (XML, SOAP,WSDL, UDDI); Apresentar o processo confecção de um web services utilizando recursos da plataforma livre de desenvolvimento Java em sistema operacional livre Linux; Comentar em que um web services pode ser útil aos pequenos nichos de mercado;

8 1.4 Organização do Trabalho 6

9 7 2 Referencial Teórico 2.1 Tecnologia Open Source Historia da Linguagem de programação C/C++ Segundo Deitel (2001), em 1967 foi desenvolvida a linguagem BCPL por Martin Richards como uma linguagem para escrever softwares de sistemas operacionais e compiladores. Ken Tompson modelou os recursos da linguagem B baseados na linguagem BCPL e utilizou a linguagem B, para criar as primeiras versões do sistema operacional UNIX nas dependências do Bell Labs em 1970 sobre um supercomputador DEC PDP-7. Em 1972 Dennis Ritchie, desenvolveu a linguagem C, a partir da linguagem B e originalmente implementada em um DEC PDP-11. Na linguagem C houve melhorias consideráveis em relação a sua antecessora, tornando-se popular por ser a linguagem de desenvolvimento do sistema operacional UNIX. A alta portabilidade tornou, a linguagem C, a principal linguagem de desenvolvimento de sistemas operacionais, a disponibilizando para maioria dos computadores em várias plataformas. (DEITEL, 2001) De acordo com Deitel (2001), a grande disseminação da linguagem C, nestas diversas plataformas de hardware, originou diversas variações semelhantes da linguagem, as quais freqüentemente eram incompatíveis que impossibilitavam sua portabilidade. Em 1980, Bjarne Stroustrup, começou a trabalhar numa extensão da linguagem C, denominada C++, a qual aprimorou vários recursos e sobre tudo incorporou a programação orientada a objetos na linguagem. C++ assume as características de uma linguagem híbrida, possibilitando programar tanto no estilo estruturado quanto no estilo orientado a objetos, ou ambos. Em 1983, foi criado o comitê técnico X3J11 sob o American National Standards Committee on Computers and Information Processing (ANSI) com o propósito de

10 8 fornecer uma diretiva independente de hardware e sem ambigüidade da linguagem, que foi aprovada em (DEITEL, 2001) Em 1990, foi publicado o ANSI/ISO 9899:1990, posteriormente denominada ANSI C, uma parceria entre o ANSI e a International Standards Organization (ISO) padronizando a linguagem C em escala mundial. A variante C++ também foi padronizada pelos comitês ANSI e ISO com a ANSI 92. (DEITEL, 2001) História da Linguagem de Programação Java A linguagem Java começou em Dezembro de 1990, desenvolvida nos laboratórios da Sun Microsystems, como parte do projeto Green, um pequeno trabalho de pesquisa em componentes eletrônico inteligentes, liderados por Patrick Naughton e Sun Fellow. O projeto Green trabalhava em um protótipo de dispositivo manual chamado star 7 do tipo PalmPilot, que podia se comunicar com outros do mesmo tipo. (CADENHEAD, 2001; DEITEL, 2001; HORSTMAN, 2003) O objetivo original era desenvolver o sistema operacional do protótiopo na linguagem C++, entretanto, James Gosling, membro do projeto Green, irritado com o desempenho da linguagem, desenvolveu uma nova linguagem para implementar o sistema operacional responsável por manipular o protótipo, de modo que fosse portável e que gerasse um código intermediário para uma máquina hipotética, denominada de maquina virtual, onde esse código intermediário pudesse ser usado em qualquer máquina que tivesse o interpretador correto. (CADENHEAD, 2001; HORSTMAN, 2003) Devido a vasta experiência, dos engenheiros do projeto Green, com o sistema operacional UNIX, Gosling baseou sua linguagem em C++, e batizou-a de Oak, carvalho em inglês, em homenagem a um carvalho que havia na frente da janela de seu escritório na Sun. Mais tarde o departamento jurídico da Sun Microsystems descobriu outro produto chamado Oak, rejeitando o nome escolhido, quando uma equipe da Sun visitou uma cafeteria local, onde o nome Java, que é a cidade de origem de um tipo de café importado, foi sugerido e aceito. (CADENHEAD, 2001; DEITEL, 2001; HORSTMAN, 2003) Em 1992, o projeto Green apresentou o star 7, um controle remoto extremamente inteligente, que possuía o poder de uma SPARC Station em uma caixa de 15x10x10 centímetros, entretanto não havia interessados em produzi-lo, que levou o pessoal do

11 9 projeto a procurar outras formas para comercializá-lo. Em 1993, o nome do projeto Green foi alterado para First Person Inc, e tentaram vender a tecnologia por todo ano de 1993 e metade de (CADENHEAD, 2001; HORSTMAN, 2003) Em 1994, a web já estava despontando e o departamento Word Wide Web (www) da Sun crescia cada vez mais, e o navegador de maior utilização era o Mosaic, parcialmente escrito por Marc Andreessen, em um projeto acadêmico de pós-graduação, Andreessen posteriormente tornou-se co-fundador da Netscape. Gosling e os desenvolvedores da Sun perceberam que no porcesso cliente/servidor da arquitetura web, se encaixava perfeitamente a neutralidade de arquitetura, que englobava o tempo real, a confiabilidade e a segurança que a linguagem Java oferecia. Então Patrick Naugton e Jonathan Payne elaboraram o navegador Hotjava, escrito em Java, que podia executar applets Java, interpretando os bytecodes intermediários, para mostrar o poder da linguagem. (CADENHEAD, 2001; DEITEL, 2001; HORSTMAN, 2003) O navegador foi apresentado na SunWorld 95 em 23 de maio de 1995 e inspirou a moda Java. Em agosto do mesmo ano, a Netscape se tornou a primeira empresa a licenciar a linguagem Java, incorporando o interpretador em seu porduto, navegador Navigator, que o tounou líder do setor. Posteriormente foi seguido de várias empresas tais como MS, IBM, Symantec, Inprise e outras, que possibilitou que milhões de pessoas pudessem executar programas iterativos direto de seus navegadores pela primeira vez, que impulsionou o crescimento da linguagem Java entre os anos de 1995 e No inicio de 1996 a Sun lançou a primeira versão da linguagem Java e começou a distribui-la livremente no URI (CADENHEAD, 2001; DEITEL, 2001; HORSTMAN, 2003) Sistemas operacionais UNIX e UNIX-LIKE Iniciado em 1965, para mainframes, com codinome de Multiplexed Information and Computing Service ou simplesmente MILTICS, foi o primeiro sistema operacional a propor modo multiusuário, desenvolvido em conjunto entre a Bell Telephone Labs da ATT, Massachusetts Institute of Technology (MIT) e a General Electric. (MCCARTHY, 2000; JANG, 2003; ANONYMOUS, 2000) Em 1969, Bell labs se retirou do projeto, devido aos vários insucessos, e dois de seus engenheiros de software, Ken Thompson e Dennis Richie, permaneceram trabalhando independentemente no projeto, com o ardente objetivo de transformar

12 10 o MULTICS em um sistema operacional de múltiplos usuários. (MCCARTHY, 2000; JANG, 2003; ANONYMOUS, 2000) No inicio da década de 70, eles implementaram um sistema operacional rudimentar, portado para os supercomputadores da Digital Equipment Corporation (DEC) PDP-7, com o nome de UNICS, que mais tarde passou a chamar-se de UNIX e o kernel mostrou notável portabilidade de hardware, se comparado com os sistemas operacionais da época, que eram construídos em assembly especificamente para cada arquitetura. (MCCARTHY, 2000; JANG, 2003; ANONYMOUS, 2000) Esta portabilidade é devida a linguagem de programação C utilizada que permite ao programador acessar recursos de baixo nível, assim como a linguagem assembly. Thompson e Ritchie criaram a linguagem de programação de alto nível C para multiplataforma. (DEITEL, 2001; MCCARTHY, 2000; JANG, 2003; ANONYMOUS, 2000) Ao perceberem a amplitude e interesse crescente por seu trabalho, disponibilizaram gratuitamente copias do UNIX a programadores em todo o mundo, com o objetivo de retornarem suas revisões para aprimoramento do UNIX. Esta atitude claramente não comercial gerou disputas jurídicas e nesta época a ATT era um monopólio nos Estados Unidos da América, onde diversas decisões judiciais e reguladoras mantiveramna afastada de negócios financeiros da área computacional. (MCCARTHY, 2000; JANG, 2003) Como a ATT estava proibida de lucrar a partir do software, ela manteve a licença do UNIX e em 1974 decidiu distribuir o sistema operacional com código-fonte para universidades, por uma taxa nominal, em troca os advogados da ATT insistiram que a licença declarava explicitamente, que o UNIX não tinha garantias. Esta técnica de lançamento passou a ser chamada, no que conhecemos hoje de open source, com isso rapidamente popularizou-se em uma série de universidades, que tornou o UNIX a base de várias classes de sistemas operacionais e de projetos de pesquisas no meio acadêmico, entretanto a ATT não teve permissão jurídica para obter lucro. (NEMETH, 2004; MCCARTHY, 2000; JANG, 2003; ANONYMOUS, 2000; BALL, 2004) Em 1976, a ATT distribuiu o UNIX para a Universidade da Califórnia em Berkeley, ao custo dos manuais e fitas. Em 1977 a Universidade da Califórnia em Berkeley iniciou o projeto Computer Systems Research Group (CSRG), como o objetivo de criar o próprio sistema operacional e em longo prazo eliminar todo código-fonte de propriedade da ATT. Um processo árduo e lento, iniciado no mesmo ano com o 1BSD para supercomputadores PDP-11 da DEC. (NEMETH, 2004; MCCARTHY, 2000; JANG,

13 ; ANONYMOUS, 2000; FERREIRA, 2003) Em 1978 destacou-se uma das variantes do UNIX, escrito na Universidade da Califórnia, Berkeley, o projeto Berkeley Softwares Distribution (BSD) do CSRG, um dos diretores do projeto Bill Joy, tornou-se em 1982, co-fundador da Sun Microsystems, responsável pelo SunOS e o Solaris, que são variantes do UNIX e pela plataforma de programação Java. O CSRG foi abandonado antes que o trabalho pudesse ser finalizado, devido Berkeley perder as verbas para a pesquisa em sistemas operacionais, e culminando em 1993 com o 4.4BSD, deixando como produto final um conjunto de código-fonte isento de propriedade da ATT denominado 4.4BSD-Lite. Conseqüentemente a Universidade da Califórnia e ATT tornaram-se os maiores centros de desenvolvimento do Unix. (NEMETH, 2004; MCCARTHY, 2000; JANG, 2003; ANONY- MOUS, 2000; FERREIRA, 2003) Com o advento das estações de trabalho na década de 1980, surgiram muitas versões comerciais do Unix, como SunOS e o Solaris da Sun Microsystems, AIX da IBM, digital Unix (OSF/1) da DEC, IRIX da Silicon Graphics e HP-UX da Hewlett Packard. ATT reteve a licença através dos anos e no início da década de 80 o governo norte americano processou a empresa por antitruste, e em 1982, uma das provisões permitiu a entrada da ATT no ramo comercial da computação, autorizando a venda do sistema operacional e código-fonte em todas proteções associadas aos direitos autorais. (NEMETH, 2004; MCCARTHY, 2000; JANG, 2003; MORIMOTO, 2004; ANONYMOUS, 2000; BALL, 2004; VEIGA, 2004; FERREIRA, 2003) Em 1984, a ATT, detentora da empresa Bell Labs, iniciou a venda da distribuição UNIX chamada de System V. Infelizmente não foram bem sucedidos com a comercialização do UNIX, e venderam os direitos autorais a Caldeira, que atualmente é conhecida como SCO group, após a fusão com a SCO, em À medida que o UNIX ganhava aceitação no mercado, os preços das licenças aumentavam rapidamente. (NEMETH, 2004; INFO, 2002; NUNES, 2003) Devido às limitações acarretadas pelos direitos autorais, os acadêmicos não podiam compartilhar seus dados em pesquisas. Com o objetivo de reconquistar a liberdade acadêmica, em 1983, Douglas Comer desenvolveu o XINU, UNIX escrito ao contrário. Em meados da década de 80 o MIT desenvolveu o X Window System, sistema de janelas que atribui uma interface gráfica cliente/servidor, para sistemas operacionais Unix, independente da arquitetura de hardware. Em 1986, Andrew Tannenbaum desenvolveu o MINIX, como alternativa educacional, não baseado no projeto

14 12 BSD e livre de qualquer código-fonte do UNIX da ATT, e o tornou disponível em seu livro, Sistemas Operacionais: Projeto e Implementação. Em 1988, o XConsortium, uma organização sem fins lucrativos, foi criada para garantir a evolução do X Window System. (NEMETH, 2004; MCCARTHY, 2000; JANG, 2003; ANONYMOUS, 2000; FERREIRA, 2003) Devido a este grande crescimento, houve a necessidade de padronização, que em 1990 o Instituto de Engenheiros Elétricos e Eletrônicos (IEEE), desenvolveu o padrão Portable Operating System Interface Unix (POSIX), com o objetivo de uniformizar as características dos sistemas operacionais Unix. (NEMETH, 2004; MCCARTHY, 2000; JANG, 2003; ANONYMOUS, 2000; FERREIRA, 2003) A maioria das distribuições UNIX da família *BSD (BSD/OS, FreeBSD, NetBSD e OpenBSD), são baseados no 4.4BSD-Lite, os demais UNIX (HP-UX, Solaris e Írix) descendem da linhagem original da ATT. (NEMETH, 2004; MCCARTHY, 2000; JANG, 2003) Projeto GNU Em 1983, o cientista do MIT Richard Stallman, programador no laboratório de inteligência artificial na área de melhorias para sistemas operacionais de supercomputadores DEC PDP-10, lançou o projeto GNU not Unix (GNU), que tinha como objetivo criar um sistema operacional padrão Unix gratuito, o qual como o primeiro Unix, teria seu código-fonte distribuído de forma livre, de modo que os programadores pudessem ler, modificar e redistribui-lo sem restrições. (INFO, 2002; FERREIRA, 2003; MC- CARTHY, 2000; JANG, 2003) A experiência de Stallman no MIT ensinou-lhe que a internet é um meio de comunicação incrível, o qual poderia ser utilizado para aprimorar e adaptar o software em velocidades deslumbrantes, superando a melhor taxa apresentada pelo modelo tradicional de desenvolvimento. (MCCARTHY, 2000; JANG, 2003; ANONYMOUS, 2000) Com intuito de organizar o projeto GNU, baseado no dinamismo da internet, Stallman, em 1984, criou a Free Software Foundation (FSF), uma corporação sem fins lucrativos que busca promover o o uso do software gratuito e eliminar restrições à cópia, redistribuição, entendimento e modificação de software, imposto pelo corphight. (INFO, 2002; FERREIRA, 2003; NEMETH, 2004; MCCARTHY, 2000; JANG, 2003) O objetivo de Stallman era organizar um grupo onde o livre compartilhamento de

15 13 software fosse ativamente encorajado, entretanto era necessário um sistema operacional de código-fonte livre que não tivesse sob os direitos autorais da ATT. (INFO, 2002; FERREIRA, 2003; MCCARTHY, 2000; JANG, 2003) Para garantia da liberdade a FSF desenvolveu a General Public License (GPL), com a finalidade de proteger o corpo do software gratuito daqueles que poderiam utilizá-lo para criar sistemas de propriedade com código-fonte fechado. (INFO, 2002; FERREIRA, 2003; MCCARTHY, 2000; JANG, 2003) Jang (2003), afirma que a GPL garante três princípios básicos: 1. Todo Software GPL precisa ser distribuído com uma copia completa do código-fonte, devidamente documentado; 2. Qualquer software acrescentado a Software GPL também precisa estar claramente documentado. Se o novo software interagir com o Software GPL, todo o pacote, precisa ser distribuído como Software GPL; 3. Qualquer Software GPL será distribuído sem garantias. Estas regras da GPL, disponíveis no anexo B, fundamentam os conceitos de copyleft, que se opõem ao copyright, cujo propósito é proteger os direitos de propriedade intelectual sobre software de fornecedores comerciais. No início da década de 90 a FSF já tinha obtido ou escrito todos os componentes importantes para o sistema operacional GNU, totalmente compatíveis com Unix, exceto o kernel. (INFO, 2002; FERREIRA, 2003; NEMETH, 2004; MCCARTHY, 2000; JANG, 2003) História do Sistema Operacional Linux O Sistema Operacional Linux foi criado em 1991, pelo finlandês, Linus Trovalds, que na época era estudante de computação na Universidade de Helsinque na Finlândia, quando resolveu melhorar o MINIX, uma variante do sistema operacional Unix concebida para fins didáticos, que possui seu código fonte no livro Sistema Operacional: Projeto e Implementação, de Andrew Tanenbaum. Aos poucos Trovalds aperfeiçoava o MINIX de modo a atribuir características melhoradas ao sistema operacional. (FERREIRA, 2003; INFO, 2002) No inicio Trovalds acreditava que este projeto seria apenas um substituto para o MINIX com melhorias onde ele achava ruim ou insuficiente, quando percebeu já havia criado um novo Shell, termo UNIX direcionado à interface texto entre o usuário e o sistema operacional. Este Shell muito semelhante ao Bourne Shell original do UNIX, foi finalizado em agosto de 1991 e tornou menos difícil a criação e compilação de

16 14 outros programas no linux. (FERREIRA, 2003; INFO, 2002) Em 17 de setembro de 1991 o linux passou a ser distribuído gratuitamente num servidor da web com a versão 0.01 contendo aproximadamente 10 mil linhas de código, em outubro do mesmo ano veio à versão 0.02 e evoluindo gradativamente, quando em novembro foi apresentada a versão Os internautas apareciam com dúvidas para instalar e melhorar o sistema operacional, que começava a fazer barulho na comunidade underground de tecnologia, onde rapidamente substituiu o MINIX. (FERREIRA, 2003; INFO, 2002) Hoje o linux é um sistema operacional completo na versão 2.6.X com mais de 10 milhões de linhas de código, 180 mil programadores, espalhados pelo mundo, trabalhando em suas melhorias, e utiliza diversos pacotes do projeto GNU, tais como utilitários, ferramentas de desenvolvimentos e aplicativos, sem os quais o linux não seria como se conhece hoje. (FERREIRA, 2003; INFO, 2002) Segundo ANONYMOUS (2000), durante muitos anos o UNIX foi executado em hardware cujo preço era muito alto. O linux é executado em quase qualquer plataforma, incluindo os processadores: Advanced Micro Device (AMD): Família k6, Athlon, Duron, Opteron, Semprom ; International Business Machines Corporation (IBM): Cyrix e PowerPC; Digital Equipment Corporation (DEC): Alpha; Intel Corporation (Intel): Família 80x86, Celeron, Xeon, Família Pentium; Sparc International Inc: Família Sparc. Cronologia do linux Tabela 1. ANO EVENTO 1969 Ken Thompson criaram o Unix, executado em um supercomputador PDP- 7 da DEC 1970 Thompson e Dennis Richie instalaram o Unix em um PDP-11. Richie cria a linguagem de programação C para ser portável em arquiteturas de hardware diferentes Foi lançada a 1a versão do Unix, escrita na linguagem Assembly 1973 Richie e Thompson escreveram o primeiro compilador C para Unix. e a 4a versão do Unix é escrita na linguagem C A ATT autoriza a distribuição do código-fonte do Unix para as universidades Foi lançada a 6a versão do Unix. Sua distribuição é ampliada nas universidades. a Universidade da Califórnia, em Berkeley, começa a trabalhar no BSD Unix Foi lançada a 7a versão do Unix, sob taxas de licensas A ATT lançou o Unix System III 1983 A ATT lançou o Unix System V. A Universidade da Califórnia, em Berkeley, lança o BSD Unix 4.2, que foi utilizado pela Sun Microsystems para base de criação do SunOS; Stallman cria a FSF O servidor de janelas X Window começa a ser desenvolvido no MIT 1986 Primeira versão comercial do X Window, executado no VAXstation- II/GPX,

17 15 o X10R Foi lançado o BSD 4.3; A ATT lança o Unix System V release 3; a Sun e a ATT concordam em fundir o BSD Unix e o Unix System V Foi Criado a organização aberta, Xconsortium, para garantir a evolução do X; Lançamento o X11R3; Minix foi criado por Tannembaum A ATT lança o Unix System V release 4, que promove relativa unificação do BSD Unix e do Unix System V; O MINIX é colocado à disposição na internet; Trovalds assiste sua primeira aula de C Trovalds iniciou o desenvolvimento do Linux A Sun lança o Solaris, baseado no Unix System V resease 4; o kernel 0.01 é discutida na internet. Em dezembro foi lançado do Linux 0.99pl Foi lançada a 1a distribuição Linux em um CD-ROM, e distribuída pela Yggdrasil Foi Lançada versão livre do X Windows, o Xfree Project; Surgem outras distribuições Linux, tais como Red Hat, Slackware e outras Surgem as primeiras versões modularizadas do Linux A Caldeira lança a versão 1.0 com o Netscape e o WordPerfect for X, inclusos. FERREIRA, 2003 com adaptações. Fonte: 2.2 Middleware para Aplicações Distribuídas As aplicações distribuídas existem há vários anos, e o seu objetivo principal é fornecer componentes de softwares remotos. Dentre os middleware para tecnologias de aplicações distribuídos, dos mais conhecidos e utilizados, tem-se: Component Object Model (COM) e Distributed Component Object Model (DCOM), tecnologias da Microsoft Corporation (MS), Enterprise Java Beans (EJB) e Java Remote Method Invocation (RMI), tecnologias da Sun MicroSistems, e Common Object Request Broker Architecture (CORBA), tecnologia do Object Management Group (OMG). Cronologia de tecnologias para distribuiçao de serviços Fi gura 1 - Ogbuhi, Fonte: Estas tecnologias para distribuição de serviço são apresentadas por GOMES (2002) como modelos de componentes que trazem novas oportunidades para distribuição de regras de negócio. Todas as aplicações distribuídas em objetos necessitam dos seguintes requisitos, como exposto por SUN (2005): Localizar objetos remotos; Comunicação com os objetos remotos, Recuperar dados passados por parâmetros ou retorno de valores dos respectivos objetos remotos.

18 16 Segundo BOND (2002), Um componente de software é uma unidade funcional que pode ser usada dentro de uma estrutura específica, onde as estruturas de componentes têm evoluído para dar suporte ao desenvolvimento de aplicativos simplificados. Usando uma estrutura de componentes, um contêiner fornece aos componentes certos serviços padrões, como comunicação e persistência, estes mecanismos são usados para definir os componentes e a comunicação entre eles, o que torna possível escrever ferramentas que examinem componentes e exibam suas informações para um gerador de aplicativos, como uma ferramenta visual para Rapid Application Development (RAD). Os princípios de componentes se aplicam também a componentes não visuais. Aplicativos distribuídos inteiros podem ser criados a partir de componentes. Uma das vantagens das estruturas de componentes distribuídos é que elas fornecem independência de linguagem. (SEI, 2005) DCOM - Distributed Component Object Model A tecnologia COM apresentada pela MICROSOFT (2005), utilizada nos sistemas operacionais da família Windows, como ferramenta para habilitar comunicação de componentes de softwares que é usado por seus desenvolvedores para re-usabilidade, unindo os componentes para construir as aplicações, e favorecer os serviços oferecidos pela plataforma Windows. A família de tecnologia COM inclui COM+, DCOM, e controles ActiveX. A família de tecnologia COM, segundo SEI (2005), refere-se a especificações e implementações desenvolvidas pela Microsoft Corporation que prove um framework para integrar os componentes. Este framework suporta interoperabilidade e re-usabilidade de objetos distribuídos permitindo aos desenvolvedores construir sistemas reunindo componentes reutilizáveis de diferentes fabricantes que se comunicam via COM em redes heterogêneas. DCOM é usada em aplicações como a família de produtos MS-Office. E a tecnologia COM OLE, permite vincular dados de documentos Word dinamicamente em planilhas excel e a automação COM permite usuários construir scripts em suas aplicações para efetuar repetitivas tarefas ou controlar aplicações diferentes. (MICROSOFT, 2005) O artigo publicado por SEI (2005), considera a família COM como apenas uma tecnologia que prover um gama de serviços para interação de componentes, promovendo

19 17 integração de componentes em uma simples plataforma sobre redes heterogêneas. E ainda diz que as extensões COM e DCOM são simplesmente unidas em tempo de execução, tanto para acesso local quanto remoto, que pode ser observada na figura abaixo. Comunicação entre processos em COM Fi gura 2 - SEI, Fonte: Em seu artigo RAJ (2005) apresenta o protocolo Object Remote Procedure Call (ORPC), como protocolo de chamada para tecnologia COM, como apresentada na figura seguinte. O ORPC estabelece uma camada que interage entre os componentes COM e os serviços em tempo real. Onde o servidor DCOM é o corpo do código capaz de servir os objetos de maneira particular em tempo de execução. Cada servidor de objetos DCOM pode suportar múltiplas interfaces representando diferentes comportamentos dos objetos. Interação de objetos com tecnologia DCOM Fi gura 3 - SEI, Fonte: CORBA - Common Object Request Broker Architecture CORBA é apresentado por RAVAGNANI JUNIOR (2001) como uma especificação de arquitetura desenvolvida para ambientes heterogêneos distribuídos que utiliza a tecnologia de orientação a objetos. Essa especificação foi criada pelo Object Management Group (OMG), que é uma organização internacional da indústria de software independente, fundada em maio de 1989, suportada por seus próprios membros associados. O objetivo primário consiste em alcançar sistemas baseados em objetos que dispõem de ambientes distribuídos heterogêneos com características de re-usabilidade, portabilidade e interoperabilidade, permitindo que as aplicações façam solicitações a objetos, de uma forma transparente, independente, indiferente à linguagem, sistema operacional ou considerações de localização. Segundo OGBUJI1 (2002), a tecnologia CORBA surgiu de um esforço fora da industria para padronizar os processos na tecnologia distribuída. Nesta época o OMG focalizou as requisições em objetos remotos para atravessar plataformas de aplicações distribuídas. Por este motivo tenta-se emitir como um objeto estado e gerenciar um ciclo de vida transparente. Em seu artigo RAJ (2005) apresenta o Internet Inter-ORB Protocol (IIOP), como protocolo confiável para chamadas a objetos remotos em CORBA. Toda arquitetura CORBA depende de um Object Request Broker (ORB). O ORB age como um barra-

20 18 mento de objetos central sobre o qual cada objeto CORBA interage transparentemente com outros objetos CORBA locais ou remotos. Cada servidor de objetos CORBA tem uma interface que divulga o conjunto de métodos disponíveis. Para requisitar um serviço, um cliente CORBA adquire uma referência ao servidor de objetos CORBA, como apresentado na figura abaixo. Estrutura ORB Fi gura 4 - RAVAGNANI JUNIOR, 2001 Fonte: O ORB é responsável por procurar implementações um objeto CORBA, preparandoo para receber e transmitir requisições, e retornar as respostas aos clientes. Uma iteração de objetos CORBA com uma interface ORB ou uma Interface Object Adapter, ambas com igual valor EJB - Enterprise Java Beans Os autores KURNIAWAN (2002) e BOND (2002) concordam que EJB é um componente do lado servidor que encapsula a lógica comercial e dados corporativos, também apresentam o EJB como solução para robustez, escalabilidade, gerenciamento de ciclo de vida e gerenciamento de estados em objetos componentizados. GALVÃO (2002) acrescenta que a especificação EJB define um padrão e genrencia os componentes de negócio distribuídos, seguindo uma especificação própria. Os EJB s são executados em um runtime, simplimente um ambiente de execução, que fornece serviços básicos de gerenciamento de transações. O runtime é geralmente implementado por softwares sofisticados, chamados de Application Servers, ou simplimente servidores de aplicações. (GALVÃO, 2002) Para BOND (2002), um EJB é uma estrutura empacotada contendo informações de configuração, que é basicamente um componente gerenciado, criado, controlado e destruído pelo contêiner Java 2 Emprise Edition (J2EE). Esse controle permite que o contêiner gerencie o numero de EJB s existentes e os recursos que estão usando, como memória e conexões de banco de dados. Cada contêiner manterá um conjunto de instâncias de EJB s disponibilizados e prontos para serem atribuídas a um cliente. Neste relacionamento os EJB s tiram o máximo proveito de serviços oferecidos pelo contêiner J2EE, em segurança, transações e ciclo de vida. Há três tipos diferentes de EJB, apresentados por BOND (2002): EJB de sessão, útil para mapear fluxo de regras de negócios, subdividido em EJB de sessão com

21 19 estado e EJB de sessão sem estado; EJB de entidade usado para mapear uma combinação de dados e a funcionalidade associada, e fundamentado em repositório de dados subjacentes; e EJB dirigido por mensagens que conceitualmente se parece com o EJB de sessão, mas somente é ativado quando chega uma mensagem assíncrona. A tecnologia EJB além de ser desenvolvida em J2EE, a tecnologia mais complexa da plataforma Java, depende de outras tecnologias para funcionar adequadamente,graficamente apresentado na figura abaixo, como afirma KURNIAWAN (2002), tal como Java Remote Method Invocation (RMI), ou sobre o Internet Inter-ORB Protocol (RMI-IIOP), onde ORB é o mesmo protocolo apresentado por RAJ (2005) para um funcionamento confiável do CORBA. Comunicação RMI-IIOP do EJB Fi gura 5 - Almeida, 2004 Fonte: O protocolo RMI-IIOP é apresentado por KURNIAWAN (2002) como a versão mais portátil de RMI que pode ser usada com o IIOP e é especialmente utilizada entre comunicações enterprise bean e um cliente RMI - Remote Method Invocation A documentação Java/RMI disponibilizada pela SUN (2005), apresenta o servidor de interface remota como identificador de interfaces, cujos métodos podem ser invocados de uma máquina virtual não local. GALVÃO (2002) apresenta Java/RMI como uma solução simples para a distribuição de aplicações Java, permitindo a comunicação entre objetos em máquinas virtuais diferentes, e afirma que o código usado para chamar um método de um objeto remoto é praticamente o mesmo que na chamada de um método de objeto local. As aplicações RMI contêm estruturas distintas para representação cliente/servidor. Um servidor de aplicações típico cria uma determinada quantidade de objetos remotos, tornando-os acessíveis, e aguardando as requisições de métodos por clientes a estes objetos remotos. Uma aplicação cliente típica obtém uma ou mais referências de objetos remotos em um servidor e invoca seus métodos. RMI prove um mecanismo que o servidor e o cliente comunicam-se trocando informações entre si, tal como proposto para aplicações de objetos distribuídos. (SUN, 2005) A figura abaixo representa uma aplicação RMI distribuída que usa o registro para

22 20 obter referência ao objeto remoto. O servidor chama o registro para associar um nome com o objeto remoto. O cliente procura o objeto remoto pelo nome registrado no servidor e invoca um de seus métodos. A figura também mostra que o sistema RMI usa um servidor web existente para carregar bytecodes das classes escritas na linguagem de programação Java, do servidor para o cliente e vice-versa, dos objetos quando necessário. RMI pode carregar as classes bytecodes usando qualquer protocolo URL (HTTP, FTP, file e outros) que é suportado pela plataforma Java. (SUN, 2005) Interação de objetos com tecnologia RMI Fi gura 6 - SUN, 2005 Fonte: RAJ (2005) em seu artigo apresenta o Java Remote Method Protocol (JRMP), como protocolo confiável para serialização de objetos na tecnologia Java/RMI. O qual permite objetos serem controlados ou transmitidos como um fluxo, desde que a serialização de objeto seja especificado em Java, ambos, tanto o servidor de objetos Java/RMI quanto o cliente de objetos devem ser escritos em Java. Cada servidor de objetos Java/RMI define uma interface que pode ser usada para acessar o servidor de objetos fora da Java Virtual Machine (JVM) e em outras JVM s. 2.3 Web Services Para EWALD (2002) o modelo de desenvolvimento para aplicações distribuído tem sido rapidamente adotado e desenvolvido, em tal escala como o modelo web. O sucesso fenomenal do modelo de programação web pode ser atribuído a uma característica central: o fraco acoplamento. O fraco acoplamento é bem maior que o modelo tradicional de programação distribuída, baseada em RPC. As interações entre clientes e servidores são simples, trocam mensagens, entre si, que transportam dados do tipo Multipurpose Internet Mail Extensions (MIME-type), que a semântica das mensagens podem ser modificadas usando seus próprios cabeçalhos. O destino da mensagem especificada indiretamente usando URL, e este nível de caminho indireto pode ser alavancado para implementar o carregamento balanceado, rastreamento de sessões e outras características. Na própria alta plataforma UNIX, como afirma OGBUJI (2002), HP tentou uma remarcação da estrutura de diretórios para mini computares da era de computação distribuída para o modernos Web Services. Na primeira metade dos anos 90, os Laboratórios HP começaram a pesquisar como reduzir as técnicas bem conhecidas e custos com problemas em sistemas distribuídos. Os principais resultados desenvolvi-

23 21 dos guiaram o projeto da HP para e-speak, realizado após 1999, e e- Speak surgiu provavelmente como a primeira tecnologia Web Service, e certamente a primeira tecnologia Web Service desenvolvida comercialmente. Ele usa protocolos genéricos tal como HTTP e representação XML de dados para negociar toda espécie de sistemas em redes como serviços eletrônicos dentro do qual pode rapidamente conectar fluxo de dados. Infelizmente, por causa da visão distante de fluxo do estado atual dos Web Services, a HP recentemente suprimiu o projeto e- Speak em favor de um maior objetivo final oferecido pelos Web Services. A simplicidade das interações em um modelo de programação web torna possível a construção incremental de sistemas. Diferente dos firmemente acoplados RPC e aplicações de objetos distribuídos com os middleware atualmente comercializados. O qual requer todas as peças de um sistema para ser desenvolvido em massa, Você pode adicionar clientes e servidores a sistemas baseados na web à medida que necessário podendo estabelecer conexões a novas aplicações razoavelmente fáceis e ainda fazer deste uma maneira descentralizada sem nenhum ntro de coordenação além do registro de domínio do Dinamic Name Service (DNS), com um grau de interoperabilidade, escalabilidade e gerenciamento que é altamente notável.(ogbuji, 2002) Como afirma OGBUJI (2002), o CORBA prove menos escalabilidade de mensagens que em algumas outras tecnologias. O mesmo problema importuna as tecnologias COM e DCOM para protocolos de objetos remotos. Ao mesmo tempo, e- mail e web têm sempre apresentado um maior sucesso em relação a arquitetura de desenvolvimento distribuído, e o programador segue a tecnologia de desenvolvimento distribuído que fornece um fraco acoplamento às mensagens e está presente em todo lugar da internet. Padrões que são adotados por todos os principais fornecedores, que possuem diferentes desejos, com o objetivo de reduzir o risco associado com a escolha de tal tecnologia. Durante este periodo outras tecnologias distribuídas mais especializadas emergiram. A popularidade da plataforma Java com sua especialização no protocolo RMI, e o nicho de sucesso da tecnologia MQSeries para Microsoft codimenta a Java messaging. O Web Service atua no modelo de desenvolvimento Web englobando o melhor de ambas técnicas para tecnologias de serviços distribuídos, e para NASCIMENTO (2005), é uma tecnologia idealizada para comunicação entre sistemas, sendo muito usada em aplicações B2B, padronizando a comunicação entre os serviços, possibili-

24 22 tando a independência de plataforma e de linguagem de programação. Romin Irani, em sua contribuição ao livro Profissional Java web services, em parceria com HENDRICKS (2002), relata que os web services são o que há de mais recente em desenvolvimento de aplicações, e vem atraindo o interesse de desenvolvedores que trabalham em todas as plataformas, embora os Web Services não sejam a primeira e nem a única tecnologia a permitir composição de RPC s, de um objeto pela rede, eles diferem das tecnologias existentes, pelo fato de usarem padrões neutros de plataforma, como HTTP e XML, que permite ocultar as particularidades relativas à implementação e plataforma de hardware do cliente. A idéia dos Web Services é permitir que aplicações sejam criadas compondo funcionalidades de diversos Web Services. Como são disponibilizados por comunicação via código podem ser implementados em diversas linguagens, tais como, C++,C, COBOL, Component Pascal, Curriculum, Eiffel, Fortran, Haskell, Java, Microsoft JScript, Mercury Mondrian, Oberon, Oz, Pascal, Perl, Python, RPG, Scheme, SmallTalk, Standard ML, Microsoft Visual Basic e outras. Atualmente há duas grandes plataformas que facilitam o desenvolvimento de um Web Service, dotnet e JAVA. A plataforma dotnet possue Microsoft Visual Studio dotnet, que atualmente é a melhor solução para desenvolvimento em dotnet, mas além desta tem-se iniciativas livres como o Projeto DotGNU que é uma iniciativa da comunidade GNU liderada por Richard M. Stallman, fundador do Projeto GNU e presidente da Fundação para o Software Livre e também o Projeto Mono que é outra alternativa para implementação livre de desenvolvimento da plataforma dotnet sua principal caracteristica é trazer a plataforma dot- Net para os sistemas livres e permitir que os desenvolvedores criem aplicações dotnet que as execute sobre qualquer plataforma suportada pelo Mono. O Projeto Mono é liderado pela Ximian, a empresa de Software Livre co-fundada por Miguel de Icaza, que levou o desktop GNOME a um grande sucesso. A plataforma Java possui um grande conjunto de API s para suportar Web Services, fornecidas livremente por empresas de destaque no mercado como Sun e IBM, estas podem ser atualmente encontradas no Java XML Pack e no Web Services Developer Pack (WSDP). O fato de estarem incorporados a J2EE é importante para efeito de padronização e depende da estabilização destas API s, que ainda estão em processo de evolução. (DOEDERLEIN, 2001; DOEDERLEIN, 2002) O Web Service pode criar aplicações modulares e independentes que são distribuídas facilmente em qualquer estrutura de redes TCP/IP, pois esse foi um dos

25 23 princípios fundamentais de sua implementação. Um grande ponto positivo desta tecnologia é na criação de servidores e clientes, que independem da tecnologia utilizada, tais como linguagem de programação e sistema operacional. São aplicações modulares auto-descritivas e podem ser publicadas, localizadas e invocadas de qualquer local na rede (LAN, WAN ou WEB), porta-se como um site que não tem uma interface com o usuário, projetado para ser acessado via programação, como apresentado na figura abaixo. (LOPES, 2002; DOEDERLEIN, 2001) Interface do Usuário Fi gura 7 - Fonte: Os Web Services são uma idéia velha dentro de uma proposta nova de arquitetura. Assim como CORBA que utiliza um repositório internacional de objetos distribuídos de tal forma que fosse possível solicitar serviços pela rede, sem importar-se por quem e como este serviço estaria sendo provido. Entretanto a tecnologia não foi aderida pelo mercado, devido as características proprietárias. Além do CORBA isto também aconteceu com as outras tecnologias para distribuição de serviços e objetos remotos em rede, tais como COM, DCOM, EJB e Java/RMI. Estas tecnologias para distribuição de serviço são modelos de componentes que trazem novas oportunidades para a distribuição de regras de negócio, mas o mercado ainda não conseguiu consolidar nenhuma delas como padrão de cooperação entre ambientes corporativos, devido a incompatibilidade de seus protocolos proprietários. Como no quadro comparativo abaixo. (GOMES, 2002; GOMES, 2001; DOEDERLEIN, 2001) Tecnologias aplicadas a middleware Fi gura 8 - GOMES, 2002 Fonte: A utilização em massa de qualquer nova tecnologia implica em mudanças de costumes e paradigmas. E todas estas tecnologias citadas possuem complexidades a mais que precisam ser assimiladas pelo mercado, embora estas interfaces, middleware como são conhecidas, suportem acesso via programação, nenhuma delas atua como um site Web. Atualmente o diferencial da antiga arquitetura de componetização e os Web Services está na Meta-informação, informação sobre informação, que deixou de seguir um formato proprietário para aderir a uma estrutura universal. Esta nova proposta de tecnologia é um modelo de componentes para aplicações distribuídas em rede, usando protocolos comuns como HTTP ou SMTP para transporte, e extended Markup Language (XML) para representação de dados. As vantagens desta seleção de protocolos estão na facilidade de passar por firewalls e o suporte universal, resolvendo os problemas que bloquearam e dificultam a disseminação das atuais tecnologias para distribuição de serviços populares para comunicação em rede local

26 24 e na internet. (GOMES, 2002) As vantagens da tecnologia XML já são bem conhecidas, sendo possível desenvolvêla com êxito no contexto Web Services através dos novos protocolos. O novo protocolo Simple Object Access Protocol (SOAP) nada mais é do que um padrão de Remote Procedure Call (RPC), utilizando XML sobre HTTP em comunicação síncrona ou SMTP em comunicação assíncrona. É exatamente neste ponto que os Web Services ganha vantagem. Todos os middleware que penetraram anteriormente no mercado sofreram restrições devido a sua complexidade ou a utilização de tecnologias proprietárias. (GOMES, 2002) Os Web Services buscam a integração de uma gama de aplicações já existentes no mundo legado através da XML, que é uma tecnologia já aceita no cenário internacional. A idéia dos Web Services é permitir que aplicações sejam criadas compondo funcionalidades de diversos Web Services, e a integração dinâmica de serviços e aplicações baseada nos requisitos de negócios e não na tecnologia em que os serviços estão implementados. Neste sentido, a proposta dos Web Services é criar um ambiente distribuído no qual aplicações e componentes possam interoperabilizar independentemente de linguagem e plataforma, semelhante às idéias já desenvolvidas por CORBA, mas agora focando a utilização de padrões bastante difundidos em comunicação corporativa, de maneira descentralizada, sem coordenação central, com notável grau de interoperabilidade, escabilidade e gerenciabilidade, fornecendo alto grau de abstração entre o código do cliente e o código da aplicação servidor, pode ser esclarecido na próxima figura. (LINS, 2002; LOPES, 2002) interação Cliente/Servidor com Web Service Fi gura 9 - LOPES, 2002 Fonte: Principais Características Para atingir as metas propostas, um Web Services deve possuir as seguintes características básicas (NASCIMENTO, 2005): 1. Ser fracamente acoplado; 2. Suportar chamadas remotas de procedimentos (RPC Remote procedure call); 3. Serviços de alto nível, ou seja, o cliente não precisa conhecer como o serviço foi implementado; 4. Garantir todas estas características, baseando-se em XML;

27 Principais Vantagens As vantagens obtidas com Web Services são (NASCIMENTO, 2005): 1. Padrão de mercado; 2. Interage com outras técnogias abertas padronizadas pelo W3C, tal como HTTP, WSDL, SOAP; 3. Interoperabilidade; 4. Portabilidade; 5. Reuso; 6. Flexibilidade, mostrando melhor adaptação a mudanças Tecnologias aplicadas a Web Services GOMES (2002) diz que os Web Services buscam a integração de uma gama de aplicações legadas através de tecnologias neutras já aceita no cenário internacional. Com os padrões baseados em XML SOAP, WSDL e UDDI e os padrões amadurecidos naturalmente no mercado HTTP e SMTP, afirmando que os Web Services ganham espaço por sua simplicidade e robustez. Um Web Service é mais que apenas um objeto de negócio com relação a rede, e trabalha sobre padrões, atualmente em desenvolvimento na industria. Por ser um novo modelo de desenvolvimento de software, muita coisa ainda se encontra em fase de concepção. Entretanto, alguns padrões já se destacam, tais como: O protocolo Universal Description, Discovery and Integration (UDDI), a Web Services Description Language (WSDL), o Simple Object Access Protocol (SOAP), todos baseados em extended Markup Language (XML). (GOMES, 2002) XML - Extended Markup Language Segundo HOLZNER (2001) a XML é uma metalinguagem que especifica uma metamarcação, personalizável que supera as outras linguagens de marcação existentes, como Hyper Text Markup Language (HTML). As linguagens de marcação referemse a forma que o documento deve ser interpretado. A XML é uma variação simplificada da Standard Generalized Markup Language (SGML). Para JORGENSEN (2002), a XML está rapidamente se tornando o protocolo universal para a transferência de informações entre sites via HTTP, e os desenvolvedores estão começando a utilizar a eficácia da linguagem para transmitir, trocar e manipular dados. KOPELEVITCH (2002) diz que atualmente a XML é a linguagem mais usada na

28 26 internet e fora dela, onde os Web Services são escritos basicamente em estruturas baseadas em XML, como SOAP e WSDL. A XML é um protocolo padrão para troca de dados em diferentes sistemas, sua grande vantagem em relação a outras alternativas é que os dados estão descritos em formato de arquivos texto, tornando a troca de informações muito mais robusta, mesmo em sistemas operacionais diferentes. (SANT ANNA, 2001; LOPES, 2002) VELOSO (2003) apresenta como uma das principais vantagens da XML, justamente a interoperabilidade ou troca de dados de maneira simples, barata e rápida entre os diversos tipos de plataformas computacionais e sistemas operacionais. O uso do XML como meio de diálogo entre componentes viabiliza um modelo homogêneo para a distribuição e a composição de componentes, dando aos Web Services um papel fundamental na colaboração entre sistemas business to business (B2B) em construção de serviços inteligentes. (LINS, 2002; LOPES, 2002) Analizadores XML Com estas excelentes vantagens apresentadas pela XML, foram criados pacotes de softwares que simplificam sua confecção para interligá-la a apliações de mercado. E HOLZNER (2001) destaca: Simple API for XML (SAX) escrito por David Megginson e proporciona uma analise voltada a eventos; Expart escrito na linguagem C por James Clark, este analizador é usado no Netscape Navigator 6 e no modulo XML::Parser da linguagem Perl, que é mantido por Clark Cooper; TclExpart desenvolvido por Steve Ball, baseado no expart para linguagem Tcl; LT XML um kit ferramentas para desenvolvimento, criado pelo Language Technology Group na Universidade de Edinburgh; XML for Java (XML4J) desenvolvido pela IBM Alpha Works, é o mais famoso analizador XML, e segue os padrões ditado pelo W3C; Processador XML de validação da Microsoft Este analizador requer o Internet Explorer 4.01-SP1, ou posterior; Lark processador escrito em Java por Tim Bray, estando entre os mais conhecidos. XP processador XML escrito em Java por James Clark, sem validação;

29 27 Silfide XML Parser (SXP) é uma Application Programming Interface (API) completa desenvolvida em Java e bastante popular; Java Standard Extension for XML pacote da Sun voltado para manipulação de arquivos XML; SOAP Simple Object Access Protocol O Simple Object Access Protocol (SOAP) desenvolvido em 1998, com o propósito original de transmitir documentos XML que contivessem comandos capazes de disparar operações ou respostas em sistemas remotos, ou Chamadas Remotas a Procedimentos (RPC), como representado na figura abaixo, garantindo esse objetivo, foi necessário desenvolver uma linguagem de esquema ou um sistema de tipos baseado em SGML, portanto o grupo de pesquisa centralizou seus esforços em definir um sistema de tipos, elementar que contivesse os principais tipos primitivos, hoje chamado de SOAP. (HENDRICKS, 2002) Chamadas SOAP RPC Fi gura 10 - HENDRICKS, 2002 Fonte: Inicialmente concebido com a tecnologia para transpor a brecha entre plataformas baseadas em comunicação RPC, o SOAP se tornou um dos mais conhecidos formatos de mensagens e protocolos utilizados por web services baseados em XML. Por este motivo, o acrônimo SOAP é referido frequentemente como Service Oriented Architecture Protocol ao invés de Simple Object Access Protocol.(THOMAS, 2005) O SOAP é um protocolo superficial de computação, pois contém menos recursos do que outros protocolos de computação distribuídos aplicados a middlewares, que o torna menos complexo, e permite a troca de informações em um ambiente descentralizado e distribuído, não vinculado a uma plataforma de hardware, independente de sistema operacional, linguagens de programação e hardware de rede. Completamente capaz de realizar chamadas de procedimento remoto entre os nós de uma rede não-hierarquica. (HENDRICKS, 2002) Funcionamento protocolo superficial de computação SOAP Fi gura 11 - HEN- DRICKS, 2002 Fonte: Arquitetura não hierárquica SOAP Fi gura 12 - HENDRICKS, 2002 Fonte: O SOAP consiste no encapsulamento de mensagens e RPC, permitindo que sistemas distribuídos se comuniquem diretamente sem intermediários e não define um