Vou tentar ser curto e grosso. Temo ser meio vago, mas vamos lá........ Webservices é uma idéia velha dentro de uma proposta nova de arquitetura. Quem já ouviu falar de CORBA, deve-se lembrar da grande promessa que a tecnologia trazia.... criar-se um repositório internacional de objetos distribuídos de tal forma que eu pudesse solicitar serviços pela rede e pouco me importava quem, quando e como este serviço estava sendo provido. Infelizmente, a tencologia não pegou como se esperava.
Assim tmb aconteceu com muitas tecnologias para distribuição de serviços, como EJB. É indiscutível a qualidade de aplicações desenvolvidas sobre a plataforma J2EE, mas ainda não existe um consenso internacional sobre sua adoção. Muitos serviços já estão em produção, o que implicaria na reescrita de uma série de legados, para a utilização de J2EE em seus lugares. Além do mais, a interoperabilidade entre os mundos Java e .NET é dificultada ao máximo e utilizar qualquer uma dessas tecnologias forçosamente implica no acréscimo de um middleware para gerenciar este ambiente disperso de componentes. Estes são os principais fatores que dificultam a unificação do modelo global de desenvolvimento. A utilização em massa de qualquer nova tecnologia efetivamente implica numa mudança de costumes e paradigmas. Migrar da programação local para o mundo distribuído CORBA de objetos implica na criação de interfaces IDL e posterior geração de stubs e skeletons. Utilizar EJBs significa assimilar o funcionamento de algum servidor de aplicações. É exatamente neste ponto que os webservices ganham vantagem. Todos os produtos que penetraram anteriormente no mercado sofreram restrições devido à sua complexidade, detalhes proprietários, suporte de softwares, dentre outros. Webservices buscam a integração de uma gama de aplicações já existentes no mundo legado através de uma tecnologia de fato já aceita no mercado internacional, o XML. Neste sentido, a proposta dos webservices é a de criar um ambiente distribuído no qual aplicações e componentes possam se interoperabilizar de uma forma independete de linguagem e plataforma, semelhante às idéias já desenvolvidas pelas especificações de CORBA e EJB, mas agora focando na utilização de um idioma já bastante difundido para a comunicação entre diferentes corporações. Com isso, seremos capazes de montar facilmente um novo serviço a partir do assemble de outros webservices menores já disponibilizados no mundo por empresas especializadas naquele tipo de serviço. Basicamente, um webservice deve contemplar algumas características: - Serem fracamente acoplados - De preferêcia, com serviços de alto nível - Síncronos ou assíncronos - Suportar chamadas remotas de procedimentos - Garantir todas as características acima através de configurações XML Webservices é um ramo muito novo, e muita coisa ainda está sendo bolada. Até o momento, as peças que melhor caracterizam o funcionamento de um web service são: - SOAP. Simple Object Access Protocol. Simples estrutura para a realização de RPCs através da troca de documentos XML independente do protocolo de transporte. - WSDL. Web Service Description Language. Exterioriza as características de um web service. É através do WSDL que os clientes podem descobrir dinamicamente o tipo de serviço provido por um webservice, os parâmetros necessários, etc - UDDI. Universal Description, Discovery and Integration. É aonde os webservices se registram para poderem ser encontrados pelos clientes. Em resumo, podemos exmplificar a integração destes 3 protocolos da seguinte forma: um cliente que deseja encontrar um webservice que está em algu, lugar da rede. Ele então procura este webservice no UDDI pelo seu nome, categoria ou alguma outra informação que o identifique. Após encontrá-lo, o UDDI fornece ao cliente o WSDL relativo àquele webservice, onde será possível ao cliente compreender na hora como interagir com aquele serviço. Uma vez compreendida a estrutura de requisição do serviço, o cliente cria uma mensagem SOAP de acordo com o XML Schema encontrado no WSDL e a envia ao host que hospeda o webservice. Simples assim! Fazendo uma analogia com o CORBA: SOAP -> CORBA, WSDL -> IDL, UDDI -> ORB. Agora com RMI: SOAP -> RMI, WSDL -> interface Remote, UDDI -> RMI Registry. Viu ? A idéia não é nova. A grande jogada está na utilização de XML em todos os pontos, o que possibilita que uma aplicação COBOL ou Fortran seja um webservice que atenda a requisições de qualquer tipo de cliente webservice. Era isso que eu tinha pra dizer. Fiquem ligados pois 50% do JavaOne falou sobre isso. No mínimo, muitas grandes empresas vão especular nesse sentido.......... Bem, em linhas tortas, é isso. Quem quiser saber mais, assita a palestra de Kentaro Takahashi, dia 26, na Fenasoft. []s By Ale! ----- Original Message ----- From: "SILVA Rafael P CONFAB" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, April 18, 2002 8:20 AM Subject: RES: [java-list] Web Service!!!! Daniel, Verifique em: http://www.mundooo.com.br <http://www.mundooo.com.br> lá tem vários links para este assunto. []´s Rafael Pioli -----Mensagem original----- De: Daniel Felipe (Bonão) [mailto:[EMAIL PROTECTED]] Enviada em: segunda-feira, 15 de abril de 2002 23:14 Para: [EMAIL PROTECTED] Assunto: [java-list] Web Service!!!! E ai pessoal...tudo bem com vc's.... Alguém sabe de algum tutorial e mesmo um artigo sobre "Web Services" ? Por favor se alguém sabe algo sobre isto me envie...... Um grande abraço, Bonão ------------------------------ LISTA SOUJAVA ---------------------------- http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP dúvidas mais comuns: http://www.soujava.org.br/faq.htm regras da lista: http://www.soujava.org.br/regras.htm historico: http://www.mail-archive.com/java-list%40soujava.org.br para sair da lista: envie email para [EMAIL PROTECTED] ------------------------------------------------------------------------- ------------------------------ LISTA SOUJAVA ---------------------------- http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP dúvidas mais comuns: http://www.soujava.org.br/faq.htm regras da lista: http://www.soujava.org.br/regras.htm historico: http://www.mail-archive.com/java-list%40soujava.org.br para sair da lista: envie email para [EMAIL PROTECTED] -------------------------------------------------------------------------
