cada operacao. Veja na figura 1.1 o WSDL pode ficararmazenado tanto no provedor de web services quanto no UDDI.Obs.: WSDL descreve web services e nao servicos SOAP.UDDI(universal description, Discovery and integration): o UDDI e um mecanismo quevisa atender tanto o cliente quanto ao provedor. Ele tem de fornecer aoprovedor de web services meios para que os web services sejam registrados epublicados. Isso permitira que os web services sejam pesquisados e localizadospelos clientes. Outra finalidade do UDDI e o armazenamento de arquivos WSDL.Obs.: o UDDI e um diretorio de servicos webdescrito por WSDL.Cliente:software que consumira web services, ou seja, utilizara as operacoesdisponibilizadas por um determinado web service. No entanto, e importante quese deixe claro que, na figura 1.1, o cliente esta sendo representado em variasetapas de seu ciclo de vida. Ali, vemos desde sua preexistencia, quando um determinadodesenvolvedor obtem o arquivo WSDL, ate o momento em que o software ja esta em operacao fazendo solicitacoes erecebendo os resultados dos web services, ambos no formato XML.Provedorde web services: e um servidor de aplicacoes ou um web container,dependendo do caso, em que o web service ficara armazenado. Ele pode armazenartambem arquivos WSDL.Obs.: qualquer informacao trocada entre as partes e emformato XML.Sequencia das operacoes dos componentes:Registrae publica o web service: web services ficam armazenados junto com osdescritores WSDL. Quando criamos um web service, iremos disponibiliza-lo parauso em um provedor de web services. O web service e o WSDL devem ser publicadospara que os clientes o localizem, ou seja, o cliente precisa saber o enderecodo web service ou seu URI (uniform resource identifier), que e um enderecosemelhante ao URL. Assim, depois de criar, devemos registrar e publicar o webservice em um diretorio de registro web, tambem conhecido como UDDI.Obteminformacoes sobre o web service: quando um desenvolvedor precisa de um webservice, ele pesquisara em diretorios de registro de web services (UDDI) pelotipo de web service que deseja. Em outras palavras, o UDDI fornece o enderecoURI do web service e de seu WSDL.Efetuadownload do WSDL: o WSDL pode estar disponivel para download tanto no UDDIquanto no provedor de web services. De posse do WSDL e do URI do web service,voce pode criar um cliente para fazer chamada ao web service.Enviasolicitacao XML: a chamada sera feita por meio do URI do web serviceenviando solicitacoes no formato XML.Receberesposta XML: o web service pode ou nao enviar um resultado ao solicitante,se enviar sera em XML.A explicacao dada, baseia-se na orientacao do W3C, noentanto, na pratica, nao funciona desta maneira. Normalmente a figura do UDDInao existe, a comunicacao entre cliente e provedor ocorre sem intermediacoes.A arquitetura projetada pelo W3C especifica que assolicitacoes e respostas XML possam trafegar por meio de qualquer protocolocomo HTTP, FTP, SMTP, TCP puro. Mas o que vemos na pratica e o XML trafegandosomente atraves do HTTP. HTTP e dominante na web, qualquer plataforma suportaele.Existem duas formas de envio de mensagens para que o clientepossa efetuar solicitacoes a um web service:One-Waymessaging: forma de envio de mensagem unilateral. O cliente envia asolicitacao sem se preocupar com a resposta. Web service executara oprocessamento e nao respondera.Request-responsemessaging: o envio e bilateral. Cliente faz