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] -------------------------------------------------------------------------
