INSTITUTO CIENTÍFICO DE ENSINO SUPERIOR E PESQUISA

INSTITUTO CIENTÍFICO DE ENSINO SUPERIOR E PESQUISA CURSO ESPECIALIZAÇÃO EM ORIENTAÇÃO A OBJETO APLICAÇÕES DISTRIBUÍDAS COM WEB SERVICE NA PLATAFORMA LIVRE Ricardo Brito do Nascimento BRASÍLIA - DF 2005

1 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 ESPECIALISTA EM ORIENTAÇÃO A OBJETO. Orientador: Prof. M.Sc. Wagner Castilho BRASÍLIA - DF 2005

2 APLICAÇÕES DISTRIBUÍDAS COM WEB SERVICE NA PLATAFORMA LIVRE Ricardo Brito do Nascimento 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 ESPECIALISTA EM ORIENTAÇÃO A OBJETO. Aprovada por: Prof. M.Sc. Wagner Castilho (Presidente) Prof. M.Sc. (titulação) Prof. M. Sc. (titulação) BRASÍLIA - DF 2005

A Jesus Cristo meu Senhor e a meus pais, Braulo e Leni. 3

4 Agradecimentos Primeiramente agradeço a Deus que me proporcionou saúde, animo e vigor para chegar até aqui, aos meus pais pela compreensão, dedicação, colaboração e apoio dispensados a mim durante todo este período de estudos, a meus irmãos Rodrigo e Braucileny, a minha namorada Eliana e aos amigos por compreenderem minha ausência.

5 Filho meu, não te esqueças dos meus ensinos, e o teu coração guarde os meus mandamentos; porque eles aumentarão os teus dias e te acrescentarão anos de vida e paz. Confia no Senhor de todo o teu coração e não te estribes no teu próprio entendimento. Reconhece-o em todos os teus caminhos, e ele endireitará as tuas veredas. Não sejas sábio aos teus próprios olhos; teme ao Senhor e aparta-te do mal; Feliz o homem que acha sabedoria, e o homem que adquire conhecimento; O temor do Senhor é o princípio da sabedoria; bom entendimento tem todos os que obedecem aos seus preceitos. (...) ; Adquire a sabedoria, adquire a compreensão; não te esqueças das palavras da boca da Minha boca, nem delas te apartes. Não desampares a sabedoria, e ela te protegerá; ama-a, e ela te guardará. A sabedoria é suprema; portanto, adquire a sabedoria. Sim, com tudo o que possuir adquire o entendimento. O que adquire sabedoria ama a sua própria alma; o que conserva o entendimento prospera. Demais disto, filho meu, atenta: Não há limite para fazer livros e o muito estudar é enfado da carne. Pv 3.1-2, 5-7, 13; Sl 111.10a; Pv 4.5-7; 19.8 e Ec 12:12.

6 RESUMO Este Trabalho apresenta a evolução das tecnologias aplicadas a serviços distribuídos, e a nova tendência de aplicações distribuídas, que evoluiu a ponto de tornar-se independente de hardware, sistemas operacionais e protocolos proprietários, voltados aos web services e com a possibilidade de ser utilizado adotando tecnologias abertas e livres. Apresenta também como configurar um servidor web service utilizando a linguagem de programação aberta Java e o sistema operacional livre Linux.

7 ABSTRACT This work showed the evolution of technologies, and a new tendence Este Trabalho apresenta a evolução das tecnologias aplicadas a serviços distribuídos, e a nova tendência de aplicações distribuídas, que evoluiu a ponto de tornar-se independente de hardware, sistemas operacionais e protocolos proprietários, voltados aos web services e com a possibilidade de ser utilizado adotando tecnologias abertas e livres. Apresenta também como configurar um servidor web service utilizando a linguagem de programação aberta Java e o sistema operacional livre Linux. Tradução para o inglês do Resumo. Apresentação concisa dos pontos relevantes da dissertação, capaz de informar o seu conteúdo de forma suficiente ao leitor, para que este possa decidir sobre a conveniência da leitura do texto inteiro. Descreve, em cerca de 350 a 450 palavras, o objetivo, o referencial teórico, a metodologia, principais resultados e conclusões.

8 Sumário 1. INTRODUÇÃO... 16 1.1. JUSTIFICATIVA E RELEVÂNCIA DO ESTUDO...16 1.2. FORMULAÇÃO DO PROBLEMA...16 1.3. OBJETIVOS...16 1.3.1. Objetivo Geral... 16 1.3.2. Objetivos Específicos...16 1.4. ORGANIZAÇÃO DO TRABALHO... 16 2. REFERENCIAL TEÓRICO... 17 2.1. TECNOLOGIA OPEN SOURCE...17 2.1.1. Historia da Linguagem de programação C/C++...17 2.1.2. História da Linguagem de Programação Java...18 2.1.3. Sistemas operacionais UNIX e UNIX-LIKE...20 2.1.4. Projeto GNU...25 2.1.5. História do Sistema Operacional Linux... 26 2.2. MIDDLEWARE PARA APLICAÇÕES DISTRIBUÍDAS...29 2.2.1. DCOM - Distributed Component Object Model...31 2.2.2. CORBA - Common Object Request Broker Architecture... 33 2.2.3. EJB - Enterprise Java Beans... 35 2.2.4. RMI - Remote Method Invocation...37 2.3. WEB SERVICES... 39 2.3.1. Principais Características...46 2.3.2. Principais Vantagens...47 2.3.3. Tecnologias aplicadas a Web Services...47 2.3.3.1. XML - Extended Markup Language...48 2.3.3.1.1. Analizadores XML...49 2.3.3.2. SOAP Simple Object Access Protocol...50 2.3.3.3. WSDL Web Services Description Language...54 2.3.3.3.1. Mapeamento nos termos de WSDL para termos Java...57 2.3.3.4. UDDI Universal Description, Discovery and Integration...58

9 2.3.4. Segurança em Aplicações distribuídas...62 2.3.4.1. Criptografia...63 2.3.4.1.1. Algoritimos Criptográficos...63 2.3.4.1.2. Assinaturas Digitais...64 2.3.4.1.3. Certificados Digitais...65 2.3.4.2. Segurança aplicada a Web Services...65 2.3.4.2.1. Autenticação...66 2.3.4.2.2. Autorização...66 2.3.4.2.3. Integridade de Dados...66 2.3.4.2.4. Garantia de Confiabilidade...67 2.3.5. Modelo de web services...67 2.3.5.1. Tipos de chamadas a Web Services...68 2.3.5.2. Aplicação...69 2.3.6. Relações Comerciais com Utilização de Web Services...69 2.3.6.1. Microsoft Alerts...70 2.3.6.2. MS Passport...72 2.3.6.3. SPB - Sistema de Pagamentos Brasileiro...80 2.3.6.4. MobMed Sistemas Móveis de Informação Médica8...86 3. CASO DE APLICAÇÃO... 88 3.1. PROCEDIMENTOS...88 3.1.1. Instalando e configurando o Java...88 3.1.1.1. Persistente a usuário:...89 3.1.1.2. Persistente ao Sistema:...91 3.1.2. Instalando e configurando o Tomcat...96 3.1.2.1. Persistente a usuário:...96 3.1.2.2. Persistente ao Sistema:...99 3.1.3. Instalando e configurando o Axis...105 3.1.3.1. Persistente a usuário:...106 3.1.3.2. Persistente ao Sistema:...108 3.1.4. Instalando e configurando o eclipse...114 3.1.5. Integrando jdk 1.5 com o as bibliotecas AXIS via console...120 3.1.6. Variaveis de Ambiente... 120 4. METODOLOGIA... 123

10 5. CONCLUSÃO... 124 6. REFERÊNCIAS... 125

11 Índice de Figuras FIGURA 1 - CRONOLOGIA DE TECNOLOGIAS PARA DISTRIBUIÇAO DE SERVIÇOS...30 FIGURA 2 - COMUNICAÇÃO ENTRE PROCESSOS EM COM...32 FIGURA 3 - INTERAÇÃO DE OBJETOS COM TECNOLOGIA DCOM...33 FIGURA 4 - ESTRUTURA ORB...35 FIGURA 5 - COMUNICAÇÃO RMI-IIOP DO EJB...37 FIGURA 6 - INTERAÇÃO DE OBJETOS COM TECNOLOGIA RMI...39 FIGURA 7 - INTERFACE DO USUÁRIO...44 FIGURA 8 - TECNOLOGIAS APLICADAS A MIDDLEWARE...44 FIGURA 9 - INTERAÇÃO CLIENTE/SERVIDOR COM WEB SERVICE...46 FIGURA 10 - CHAMADAS SOAP RPC...51 FIGURA 11 - FUNCIONAMENTO PROTOCOLO SUPERFICIAL DE COMPUTAÇÃO SOAP...51 FIGURA 12 - ARQUITETURA NÃO HIERÁRQUICA SOAP...52 FIGURA 13 - ESTRUTURA DE ENVELOPE SOAP...53 FIGURA 14 - ESTRUTURA DE INVOCAÇÃO DE UM WEB SERVICES...53 FIGURA 15 - ESTRUTURA BÁSICA DE UM WEB SERVICE...67

12 Índice de Tabelas e Quadros TABELA 1.CRONOLOGIA DO LINUX...28 TABELA 2.ESQUELETO DE UM WSDL...55 TABELA 3.NAMESPACES UTILIZADOS EM DOCUMENTOS SOAP...56 TABELA 4.MAPEAMENTO ENTRE TERMOS WSDL PARA TERMOS JAVA 58 TABELA 5.UDDI BUSINESS REGISTRY NODE URLS...59 TABELA 6.UDDI V2 TEST NODE URLS...59 TABELA 7.UDDI V3 BETA TEST NODE URLS...60 TABELA 8.ARQUIVO ~/.BASH_PROFILE...90 TABELA 9.CONFIGURANDO JAVA DE MANEIRA PERSISTENTE AO USUÁRIO 91 TABELA 10.ARQUIVO /ETC/PROFILE...91 TABELA 11.CONFIGURANDO JAVA DE MANEIRA PERSISTENTE AO SISTEMA 93 TABELA 12.ARQUIVO ~/.BASH_PROFILE...96 TABELA 13.CONFIGURANDO O TOMCAT USANDO O ARQUIVO ~/.BASH_PROFILE...98 TABELA 14.CONFIGURANDO O TOMCAT USANDO O ARQUIVO /ETC/PROFILE...100 TABELA 15.RESULTADO DO COMANDO NETSTAT...103

13 TABELA 16. CONFIGURAÇÃO DE PORTA PARA O TOMCAT...104 TABELA 17.ARQUIVO ~/.BASH_PROFILE...106

14 Lista de símbolos e abreviaturas SIGLA SIGNIFICADO API Application Program Interface BC Banco Central do Brasil BDE Base Data Enviropment BSD Berkeley Standard Distribution (JANG, 2002) Berkeley Software Distribution (NEMETH, 2002) CDB CIP CLR COM CORBA CPMF CSRG CTS DCOM DEC DOC DOT NET DTD EJB FTP HTML HTTP IDE IL IOF IP J2EE JIT JVM LAN MIME ODBC OLE OMG ORB ORPC PE RAD RCP RDB RMI SGML SMTP Berkeley Systems Division (MCCARTY, 2002) certificado de depósito bancário Câmara Interbancária de pagamentos Common Language Runtime Component Object Model Common Object Request Broker Architecture Contribuição Provisória sobre Movimentação ou Transmissão de Valores e de Créditos e Direitos de Natureza Financeira Computer Systems Research Group Common Language System Distributed Component Object Model Digital Equipment Corporation Documento de Credito Nome coringa utilizado para definir linguagens da família.net Document Type Definition Enterprise Java Beans File Transfer Protocol Hyper Text Markup Language Hyper Text Transfer Protocol Integrated Development Environment Intermediate Language Imposto sobre Operações Financeiras Internet Protocol Java to Emprise Edition Just-it-Time Java Virtual Machine Local Area Network Multipurpose Internet Mail Extensions Object Data Base Client Object Link Embed Object Management Group Object Request Broker Object Remote Procedure Call Portable Executable Rapid Application Development Remote Call Procedure Recibo de Depósito Bancário Remote Method Invocation Standard Generalized Markup Language Simple Message Transfer Protocol

15 SOAP SQL SSL TCP TED TI UDDI URL W3C WAN Web WSDL WWW XLINK XML XPOINTER XSD XSL GPL GNU DES RSA DNS Simple Object Access Protocol Structured Query Language Secure Socket Layer Transmission Control Protocol Transferência Eletrônica Disponível Technology Industry Universal Description, Discovery and Integration Uniform Resource Locator World Wide Web Consortium World Area NetWork Rede mundial de computadores Web Service Description Language Word Wide Web XML Link Language Extended Markup Language XML Pointer Language XML Schema Definition Extensible Style Language General Public License GNU is not Unix Data Encryption Standard Rivest, Shamir and Adleman Algorithm Dinamic Name Service

16 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 1.3.1. 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. 1.3.2. 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; 1.4. Organização do Trabalho

17 2. Referencial Teórico 2.1. Tecnologia Open Source 2.1.1. 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

18 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 fornecer uma diretiva independente de hardware e sem ambigüidade da linguagem, que foi aprovada em 1989. (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) 2.1.2. 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

19 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 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 1994. (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.

20 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 1996. No inicio de 1996 a Sun lançou a primeira versão da linguagem Java e começou a distribui-la livremente no URI http://java.sun.com. (CADENHEAD, 2001; DEITEL, 2001; HORSTMAN, 2003) 2.1.3. 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 AT&T, Massachusetts Institute of Technology (MIT) e a General Electric. (MCCARTHY, 2000; JANG, 2003; ANONYMOUS, 2000)

21 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 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 AT&T era um monopólio nos Estados Unidos da América, onde diversas decisões judiciais e

22 reguladoras mantiveram-na afastada de negócios financeiros da área computacional. (MCCARTHY, 2000; JANG, 2003) Como a AT&T 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 AT&T 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 AT&T não teve permissão jurídica para obter lucro. (NEMETH, 2004; MCCARTHY, 2000; JANG, 2003; ANONYMOUS, 2000; BALL, 2004) Em 1976, a AT&T 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 AT&T. Um processo árduo e lento, iniciado no mesmo ano com o 1BSD para supercomputadores PDP-11 da DEC. (NEMETH, 2004; MCCARTHY, 2000; JANG, 2003; 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

23 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 AT&T denominado 4.4BSD-Lite. Conseqüentemente a Universidade da Califórnia e AT&T tornaram-se os maiores centros de desenvolvimento do Unix. (NEMETH, 2004; MCCARTHY, 2000; JANG, 2003; ANONYMOUS, 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. AT&T 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 AT&T 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 AT&T, 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 2001. À medida que o UNIX ganhava aceitação no mercado, os preços das licenças aumentavam rapidamente. (NEMETH, 2004; INFO, 2002; NUNES, 2003)

24 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 BSD e livre de qualquer código-fonte do UNIX da AT&T, 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 AT&T. (NEMETH, 2004; MCCARTHY, 2000; JANG, 2003)

25 2.1.4. 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; MCCARTHY, 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 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 AT&T. (INFO, 2002; FERREIRA, 2003; MCCARTHY, 2000; JANG, 2003)

26 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) 2.1.5. 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

27 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 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 0.10. 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)

28 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. Tabela 1. Cronologia do linux 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. 1971 Foi lançada a 1ª versão do Unix, escrita na linguagem Assembly 1973 Richie e Thompson escreveram o primeiro compilador C para Unix. e a 4ª versão do Unix é escrita na linguagem C. 1974 A AT&T autoriza a distribuição do código-fonte do Unix para as universidades. 1975 Foi lançada a 6ª versão do Unix. Sua distribuição é ampliada nas universidades. a Universidade da Califórnia, em Berkeley, começa a trabalhar no BSD Unix. 1978 Foi lançada a 7ª versão do Unix, sob taxas de licensas. 1979 A AT&T lançou o Unix System III 1983 A AT&T 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. 1984 O servidor de janelas X Window começa a ser desenvolvido no MIT

29 1986 Primeira versão comercial do X Window, executado no VAXstation- II/GPX, o X10R3. 1987 Foi lançado o BSD 4.3; A AT&T lança o Unix System V release 3; a Sun e a AT&T concordam em fundir o BSD Unix e o Unix System V. 1988 Foi Criado a organização aberta, Xconsortium, para garantir a evolução do X; Lançamento o X11R3; Minix foi criado por Tannembaum. 1990 A AT&T 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. 1991 Trovalds iniciou o desenvolvimento do Linux. 1992 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.99pl5. 1993 Foi lançada a 1ª distribuição Linux em um CD-ROM, e distribuída pela Yggdrasil. 1994 Foi Lançada versão livre do X Windows, o Xfree Project; Surgem outras distribuições Linux, tais como Red Hat, Slackware e outras. 1995 Surgem as primeiras versões modularizadas do Linux. 1996 A Caldeira lança a versão 1.0 com o Netscape e o WordPerfect for X, inclusos. Fonte: FERREIRA, 2003 com adaptações. 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).

30 Fi gura 1 - Cronologia de tecnologias para distribuiçao de serviços Fonte: Ogbuhi, 2002. 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. 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

31 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) 2.2.1. 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.

32 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 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. Fi gura 2 - Comunicação entre processos em COM Fonte: SEI, 2005. Em seu artigo RAJ (2005) apresenta o protocolo Object Remote Procedure Call (ORPC), como protocolo de chamada para tecnologia COM, como apresentada

33 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. Fi gura 3 - Interação de objetos com tecnologia DCOM Fonte: SEI, 2005. 2.2.2. 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

34 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 barramento 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.

35 Fi gura 4 - Estrutura ORB Fonte: RAVAGNANI JUNIOR, 2001 O ORB é responsável por procurar implementações um objeto CORBA, preparando-o 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. 2.2.3. 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

36 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 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.

37 Fi gura 5 - Comunicação RMI-IIOP do EJB Fonte: Almeida, 2004 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. 2.2.4. 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çao 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

38 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 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)

39 Fi gura 6 - Interação de objetos com tecnologia RMI Fonte: SUN, 2005 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),

40 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 minicomputares 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 ploblemas em sistemas distribuídos. Os principais resutados desenvolvidos 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

41 centro 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, possibilitando 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

42 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 dotnet 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

43 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 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)

44 Fi gura 7 - Interface do Usuário 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) Fi gura 8 - Tecnologias aplicadas a middleware Fonte: GOMES, 2002 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