Vis\u00e3o geral<\/b>
\nA programa\u00e7\u00e3o baseada em componentes tornou-se mais popular do que nunca. Atualmente, dificilmente se constr\u00f3i uma aplica\u00e7\u00e3o que n\u00e3o envolva a utiliza\u00e7\u00e3o de componentes de alguma forma, normalmente de diferentes fornecedores. \u00c0 medida que as aplica\u00e7\u00f5es se tornaram mais sofisticadas, a necessidade de utilizar componentes distribu\u00eddos em m\u00e1quinas remotas tamb\u00e9m aumentou.<\/p>\n
<\/p>\n
Um exemplo de aplica\u00e7\u00e3o baseada em componentes \u00e9 uma solu\u00e7\u00e3o de com\u00e9rcio eletr\u00f3nico de ponta a ponta. Uma aplica\u00e7\u00e3o de com\u00e9rcio eletr\u00f3nico alojada numa farm de servidores Web precisa de enviar encomendas para uma aplica\u00e7\u00e3o de planeamento de recursos empresariais (ERP) de back-end. Em muitos casos, a aplica\u00e7\u00e3o ERP est\u00e1 alojada em hardware diferente e pode ser executada num sistema operativo diferente.<\/p>\n
O Modelo de Objetos Distribu\u00eddos da Microsoft (DCOM), uma infraestrutura de objetos distribu\u00eddos que permite que uma aplica\u00e7\u00e3o invoque componentes do Modelo de Objetos Componentes (COM) instalados noutro servidor, foi adaptado para v\u00e1rias plataformas que n\u00e3o s\u00e3o Windows. No entanto, o DCOM nunca obteve uma aceita\u00e7\u00e3o generalizada nessas plataformas, pelo que raramente \u00e9 utilizado para facilitar a comunica\u00e7\u00e3o entre computadores Windows e n\u00e3o Windows. Os fornecedores de software ERP criam frequentemente componentes para a plataforma Windows que comunicam com o sistema de back-end atrav\u00e9s de um protocolo propriet\u00e1rio.<\/p>\n
Alguns servi\u00e7os utilizados por uma aplica\u00e7\u00e3o de com\u00e9rcio eletr\u00f3nico podem nem sequer residir no centro de dados. Por exemplo, se a aplica\u00e7\u00e3o de com\u00e9rcio eletr\u00f3nico aceitar pagamentos com cart\u00e3o de cr\u00e9dito para bens adquiridos pelo cliente, ter\u00e1 de recorrer aos servi\u00e7os do banco comercial para processar os dados do cart\u00e3o de cr\u00e9dito do cliente. No entanto, para todos os efeitos pr\u00e1ticos, o DCOM e as tecnologias relacionadas, como o CORBA e o Java RMI, limitam-se a aplica\u00e7\u00f5es e componentes instalados no centro de dados da empresa. Duas raz\u00f5es principais para isso s\u00e3o o facto de, por predefini\u00e7\u00e3o, estas tecnologias utilizarem protocolos propriet\u00e1rios e de esses protocolos serem, por natureza, orientados para a liga\u00e7\u00e3o.<\/p>\n
Os clientes que comunicam com o servidor atrav\u00e9s da Internet enfrentam in\u00fameras barreiras potenciais \u00e0 comunica\u00e7\u00e3o com o servidor. Administradores de rede preocupados com a seguran\u00e7a em todo o mundo implementaram routers e firewalls empresariais para bloquear praticamente todos os tipos de comunica\u00e7\u00e3o atrav\u00e9s da Internet. Muitas vezes, \u00e9 preciso um acontecimento extraordin\u00e1rio para que um administrador de rede abra portas para al\u00e9m do m\u00ednimo indispens\u00e1vel.<\/p>\n
Se tiver a sorte de conseguir que um administrador de rede abra as portas necess\u00e1rias para suportar o seu servi\u00e7o, \u00e9 prov\u00e1vel que os seus clientes n\u00e3o tenham a mesma sorte. Consequentemente, os protocolos propriet\u00e1rios, como os utilizados pelo DCOM, CORBA e Java RMI, n\u00e3o s\u00e3o pr\u00e1ticos para cen\u00e1rios na Internet.<\/p>\n
O outro problema, como j\u00e1 referi, com estas tecnologias \u00e9 que s\u00e3o, por natureza, orientadas para a liga\u00e7\u00e3o e, por isso, n\u00e3o conseguem lidar adequadamente com interrup\u00e7\u00f5es na rede. Como a Internet n\u00e3o est\u00e1 sob o seu controlo direto, n\u00e3o pode fazer quaisquer suposi\u00e7\u00f5es sobre a qualidade ou a fiabilidade da liga\u00e7\u00e3o. Se ocorrer uma interrup\u00e7\u00e3o na rede, a pr\u00f3xima chamada que o cliente fizer ao servidor poder\u00e1 falhar.<\/p>\n
A natureza orientada para as liga\u00e7\u00f5es destas tecnologias tamb\u00e9m torna dif\u00edcil construir as infraestruturas com equil\u00edbrio de carga necess\u00e1rias para alcan\u00e7ar uma elevada escalabilidade. Assim que a liga\u00e7\u00e3o entre o cliente e o servidor \u00e9 interrompida, n\u00e3o \u00e9 poss\u00edvel simplesmente encaminhar o pedido seguinte para outro servidor.<\/p>\n
Os programadores t\u00eam tentado superar estas limita\u00e7\u00f5es recorrendo a um modelo denominado sem nacionalidade <\/i>programa\u00e7\u00e3o<\/i>, mas o seu sucesso tem sido limitado, uma vez que as tecnologias s\u00e3o bastante pesadas e tornam dispendioso restabelecer uma liga\u00e7\u00e3o com um objeto remoto.<\/p>\n
Uma vez que o processamento do cart\u00e3o de cr\u00e9dito de um cliente \u00e9 realizado por um servidor remoto na Internet, o DCOM n\u00e3o \u00e9 a solu\u00e7\u00e3o ideal para facilitar a comunica\u00e7\u00e3o entre o cliente de com\u00e9rcio eletr\u00f3nico e o servidor de processamento de cart\u00f5es de cr\u00e9dito. Tal como numa solu\u00e7\u00e3o ERP, \u00e9 frequente que um componente de terceiros seja instalado no centro de dados do cliente (neste caso, pelo fornecedor da solu\u00e7\u00e3o de processamento de cart\u00f5es de cr\u00e9dito). Este componente funciona basicamente como um proxy que facilita a comunica\u00e7\u00e3o entre o software de com\u00e9rcio eletr\u00f3nico e o banco do comerciante atrav\u00e9s de um protocolo propriet\u00e1rio.<\/p>\n
Consegue ver aqui um padr\u00e3o? Devido \u00e0s limita\u00e7\u00f5es das tecnologias existentes no que diz respeito \u00e0 facilita\u00e7\u00e3o da comunica\u00e7\u00e3o entre sistemas inform\u00e1ticos, os fornecedores de software t\u00eam recorrido frequentemente \u00e0 cria\u00e7\u00e3o da sua pr\u00f3pria infraestrutura. Isto significa que os recursos que poderiam ter sido utilizados para melhorar as funcionalidades do sistema ERP ou do sistema de processamento de cart\u00f5es de cr\u00e9dito foram, em vez disso, dedicados \u00e0 cria\u00e7\u00e3o de protocolos de rede propriet\u00e1rios.<\/p>\n
Num esfor\u00e7o para melhor dar resposta a esses cen\u00e1rios da Internet, a Microsoft adotou inicialmente a estrat\u00e9gia de ampliar as suas tecnologias existentes, incluindo os COM Internet Services (CIS), que permitem estabelecer uma liga\u00e7\u00e3o DCOM entre o cliente e o componente remoto atrav\u00e9s da porta 80. Por v\u00e1rias raz\u00f5es, os CIS n\u00e3o foram amplamente aceites.<\/p>\n
Ficou claro que era necess\u00e1ria uma nova abordagem. Por isso, a Microsoft decidiu abordar o problema de baixo para cima. Vejamos alguns dos requisitos que a solu\u00e7\u00e3o tinha de cumprir para ser bem-sucedida.<\/p>\n
Tendo em conta o t\u00edtulo deste livro, n\u00e3o \u00e9 de admirar que a solu\u00e7\u00e3o criada pela Microsoft seja conhecida como Servi\u00e7os Web<\/i>. Um servi\u00e7o Web disponibiliza uma interface para invocar uma atividade espec\u00edfica em nome do cliente. Um cliente pode aceder ao servi\u00e7o Web atrav\u00e9s da utiliza\u00e7\u00e3o de normas da Internet.<\/p>\n
Elementos b\u00e1sicos dos servi\u00e7os Web<\/b>
\nO gr\u00e1fico seguinte mostra os elementos fundamentais necess\u00e1rios para facilitar a comunica\u00e7\u00e3o remota entre duas aplica\u00e7\u00f5es.<\/p>\n
Vamos analisar a finalidade de cada um destes elementos constitutivos. Uma vez que muitos leitores est\u00e3o familiarizados com o DCOM, irei tamb\u00e9m referir o equivalente em DCOM de cada elemento constitutivo.<\/p>\n
Sem uma forma padronizada de formatar as mensagens, \u00e9 praticamente imposs\u00edvel desenvolver um conjunto de ferramentas que isole o programador dos protocolos subjacentes. A cria\u00e7\u00e3o de uma camada de abstra\u00e7\u00e3o entre o programador e os protocolos subjacentes permite que este se concentre mais no problema empresarial em quest\u00e3o e menos na infraestrutura necess\u00e1ria para implementar a solu\u00e7\u00e3o.<\/p>\n
Decis\u00f5es relativas \u00e0 conce\u00e7\u00e3o de servi\u00e7os web<\/b><\/p>\n
Vamos analisar algumas das decis\u00f5es de conce\u00e7\u00e3o subjacentes a estes elementos fundamentais dos servi\u00e7os Web.<\/p>\n
Escolha dos protocolos de transporte<\/b><\/p>\n
O primeiro passo consistiu em determinar como o cliente e o servidor se comunicariam entre si. O cliente e o servidor podem estar na mesma LAN, mas \u00e9 poss\u00edvel que o cliente comunique com o servidor atrav\u00e9s da Internet. Por conseguinte, o protocolo de transporte deve ser igualmente adequado tanto para ambientes de LAN como para a Internet.<\/p>\n
Como referi anteriormente, tecnologias como o DCOM, o CORBA e o Java RMI n\u00e3o s\u00e3o adequadas para suportar a comunica\u00e7\u00e3o entre o cliente e o servidor atrav\u00e9s da Internet. Protocolos como o Protocolo de Transfer\u00eancia de Hipertexto (HTTP) e o Protocolo Simples de Transfer\u00eancia de Correio (SMTP) s\u00e3o protocolos de Internet comprovados. O HTTP define um padr\u00e3o de mensagens de pedido\/resposta para enviar um pedido e obter uma resposta associada. O SMTP define um protocolo de mensagens rote\u00e1vel para comunica\u00e7\u00e3o ass\u00edncrona. Vamos analisar por que raz\u00e3o o HTTP e o SMTP s\u00e3o adequados para a Internet.<\/p>\n
As aplica\u00e7\u00f5es Web baseadas em HTTP s\u00e3o, por natureza, sem estado. N\u00e3o dependem de uma liga\u00e7\u00e3o cont\u00ednua entre o cliente e o servidor. Isto torna o HTTP um protocolo ideal para configura\u00e7\u00f5es de alta disponibilidade, como as firewalls. Se o servidor que tratou do pedido original do cliente ficar indispon\u00edvel, os pedidos subsequentes podem ser automaticamente encaminhados para outro servidor sem que o cliente se aperceba ou se preocupe com isso.<\/p>\n
Quase todas as empresas disp\u00f5em de uma infraestrutura que suporta o SMTP. O SMTP \u00e9 particularmente adequado para a comunica\u00e7\u00e3o ass\u00edncrona. Se o servi\u00e7o for interrompido, a infraestrutura de e-mail gere automaticamente novas tentativas. Ao contr\u00e1rio do que acontece com o HTTP, \u00e9 poss\u00edvel enviar mensagens SMTP para um servidor de correio local, que tentar\u00e1 entregar a mensagem em seu nome.<\/p>\n
A outra vantagem significativa tanto do HTTP como do SMTP \u00e9 a sua generaliza\u00e7\u00e3o. Os colaboradores passaram a depender tanto do e-mail como dos seus navegadores da Web, e os administradores de rede sentem-se bastante \u00e0 vontade a dar suporte a estes servi\u00e7os. Tecnologias como a tradu\u00e7\u00e3o de endere\u00e7os de rede (NAT) e os servidores proxy permitem aceder \u00e0 Internet atrav\u00e9s do HTTP a partir de LANs empresariais que, de outra forma, estariam isoladas. Os administradores costumam disponibilizar um servidor SMTP que reside dentro da firewall. As mensagens enviadas para este servidor s\u00e3o ent\u00e3o encaminhadas para o seu destino final atrav\u00e9s da Internet.<\/p>\n
No caso do software de processamento de cart\u00f5es de cr\u00e9dito, \u00e9 necess\u00e1ria uma resposta imediata do banco do comerciante para determinar se a encomenda deve ser enviada para o sistema ERP. O HTTP, com o seu padr\u00e3o de mensagens de pedido\/resposta, \u00e9 adequado para esta tarefa.<\/p>\n
A maioria dos pacotes de software ERP n\u00e3o tem capacidade para processar grandes volumes de encomendas que possam vir a ser geradas pela aplica\u00e7\u00e3o de com\u00e9rcio eletr\u00f3nico. Al\u00e9m disso, n\u00e3o \u00e9 imprescind\u00edvel que as encomendas sejam enviadas para o sistema ERP em tempo real. Por conseguinte, o SMTP pode ser utilizado para colocar as encomendas em fila, de modo a que possam ser processadas sequencialmente pelo sistema ERP.<\/p>\n
Se o sistema ERP suportar transa\u00e7\u00f5es distribu\u00eddas, outra op\u00e7\u00e3o \u00e9 recorrer ao Microsoft Message Queue Server (MSMQ). Desde que a aplica\u00e7\u00e3o de com\u00e9rcio eletr\u00f3nico e o sistema ERP se encontrem na mesma LAN, a conectividade atrav\u00e9s de protocolos que n\u00e3o sejam da Internet representa um problema menor. A vantagem do MSMQ em rela\u00e7\u00e3o ao SMTP \u00e9 que as mensagens podem ser colocadas e removidas da fila no \u00e2mbito de uma transa\u00e7\u00e3o. Se uma tentativa de processar uma mensagem retirada da fila falhar, a mensagem ser\u00e1 automaticamente colocada de volta na fila quando a transa\u00e7\u00e3o for abortada.<\/p>\n
Escolher um esquema de codifica\u00e7\u00e3o<\/b><\/p>\n
Os protocolos HTTP e SMTP permitem o envio de dados entre o cliente e o servidor. No entanto, nenhum deles especifica como os dados contidos no corpo da mensagem devem ser codificados. A Microsoft precisava de uma forma padronizada e independente da plataforma para codificar os dados trocados entre o cliente e o servidor.<\/p>\n
Uma vez que o objetivo era tirar partido dos protocolos baseados na Internet, a Linguagem de Marca\u00e7\u00e3o Extens\u00edvel (XML) foi a escolha natural. A XML oferece muitas vantagens, incluindo compatibilidade multiplataforma, um sistema de tipos comum e suporte para conjuntos de caracteres padr\u00e3o da ind\u00fastria.<\/p>\n
Os esquemas de codifica\u00e7\u00e3o bin\u00e1ria, como os utilizados pelo DCOM, CORBA e Java RMI, t\u00eam de resolver problemas de compatibilidade entre diferentes plataformas de hardware. Por exemplo, diferentes plataformas de hardware t\u00eam diferentes representa\u00e7\u00f5es bin\u00e1rias internas dos n\u00fameros multibyte. As plataformas Intel ordenam os bytes de um n\u00famero multibyte utilizando a conven\u00e7\u00e3o \u00ablittle endian\u00bb; muitos processadores RISC ordenam os bytes de um n\u00famero multibyte utilizando a conven\u00e7\u00e3o \u00abbig endian\u00bb.<\/p>\n
O XML evita problemas de codifica\u00e7\u00e3o bin\u00e1ria, uma vez que utiliza um esquema de codifica\u00e7\u00e3o baseado em texto que recorre a conjuntos de caracteres padr\u00e3o. Al\u00e9m disso, alguns protocolos de transporte, como o SMTP, s\u00f3 podem conter mensagens baseadas em texto.<\/p>\n
Os m\u00e9todos bin\u00e1rios de codifica\u00e7\u00e3o, como os utilizados pelo DCOM e pelo CORBA, s\u00e3o pesados e exigem uma infraestrutura de suporte para isolar o programador dos pormenores. O XML \u00e9 muito mais leve e f\u00e1cil de manusear, uma vez que pode ser criado e utilizado recorrendo a t\u00e9cnicas padr\u00e3o de an\u00e1lise de texto.<\/p>\n
Al\u00e9m disso, existe uma variedade de analisadores XML dispon\u00edveis para simplificar ainda mais a cria\u00e7\u00e3o e a utiliza\u00e7\u00e3o de documentos XML em praticamente todas as plataformas modernas. O XML \u00e9 leve e conta com um excelente suporte de ferramentas, pelo que a codifica\u00e7\u00e3o em XML permite um alcance incr\u00edvel, uma vez que praticamente qualquer cliente, em qualquer plataforma, pode comunicar com o seu servi\u00e7o Web.<\/p>\n
Escolher uma conven\u00e7\u00e3o de formata\u00e7\u00e3o<\/b><\/p>\n
\u00c9 frequentemente necess\u00e1rio incluir metadados adicionais no corpo da mensagem. Por exemplo, poder\u00e1 querer incluir informa\u00e7\u00f5es sobre o tipo de servi\u00e7os que um servi\u00e7o Web precisa de fornecer para satisfazer o seu pedido, tais como a participa\u00e7\u00e3o numa transa\u00e7\u00e3o ou informa\u00e7\u00f5es de encaminhamento. O XML n\u00e3o disponibiliza qualquer mecanismo para diferenciar o corpo da mensagem dos dados que lhe est\u00e3o associados.<\/p>\n
Os protocolos de transporte, como o HTTP, proporcionam um mecanismo extens\u00edvel para os dados de cabe\u00e7alho, mas alguns dados associados \u00e0 mensagem podem n\u00e3o ser espec\u00edficos do protocolo de transporte. Por exemplo, o cliente pode enviar uma mensagem que precise de ser encaminhada para v\u00e1rios destinos, potencialmente atrav\u00e9s de diferentes protocolos de transporte. Se as informa\u00e7\u00f5es de encaminhamento fossem colocadas num cabe\u00e7alho HTTP, teriam de ser convertidas antes de serem enviadas para o pr\u00f3ximo intermedi\u00e1rio atrav\u00e9s de outro protocolo de transporte, como o SMTP. Uma vez que as informa\u00e7\u00f5es de encaminhamento s\u00e3o espec\u00edficas da mensagem e n\u00e3o do protocolo de transporte, devem fazer parte da mensagem.<\/p>\n
O Protocolo Simples de Acesso a Objetos (SOAP) proporciona uma forma independente do protocolo para associar informa\u00e7\u00f5es de cabe\u00e7alho ao corpo da mensagem. Todas as mensagens SOAP t\u00eam de definir um envelope. O envelope tem um corpo que cont\u00e9m a carga \u00fatil da mensagem e um cabe\u00e7alho que pode conter metadados associados \u00e0 mensagem.<\/p>\n
O SOAP n\u00e3o imp\u00f5e restri\u00e7\u00f5es quanto \u00e0 forma como o corpo da mensagem pode ser formatado. Isto constitui uma potencial preocupa\u00e7\u00e3o, pois, sem uma forma consistente de codificar os dados, \u00e9 dif\u00edcil desenvolver um conjunto de ferramentas que permita abstrair-se dos protocolos subjacentes. Poder\u00e1 ter de dedicar bastante tempo a familiarizar-se com a interface do servi\u00e7o Web, em vez de resolver o problema empresarial em quest\u00e3o.<\/p>\n
O que era necess\u00e1rio era uma forma padronizada de formatar uma mensagem de chamada de procedimento remoto (RPC) e de codificar a sua lista de par\u00e2metros. \u00c9 exatamente isso que a Sec\u00e7\u00e3o 7 da especifica\u00e7\u00e3o SOAP prev\u00ea. Descreve uma conven\u00e7\u00e3o de nomenclatura e um estilo de codifica\u00e7\u00e3o padronizados para mensagens orientadas a procedimentos.<\/p>\n
Uma vez que o SOAP fornece um formato padr\u00e3o para a serializa\u00e7\u00e3o de dados numa mensagem XML, plataformas como o ASP.NET e o Remoting podem ocultar esses detalhes para si.<\/p>\n
Escolha de mecanismos de descri\u00e7\u00e3o<\/b><\/p>\n
O SOAP fornece uma forma padronizada de formatar as mensagens trocadas entre o servi\u00e7o Web e o cliente. No entanto, o cliente necessita de informa\u00e7\u00e3o adicional para poder serializar corretamente o pedido e interpretar a resposta. O XML Schema permite criar esquemas que podem ser utilizados para descrever o conte\u00fado de uma mensagem.<\/p>\n
O XML Schema fornece um conjunto b\u00e1sico de tipos de dados integrados que podem ser utilizados para descrever o conte\u00fado de uma mensagem. Tamb\u00e9m \u00e9 poss\u00edvel criar os seus pr\u00f3prios tipos de dados. Por exemplo, o banco comercial pode criar um tipo de dados complexo para descrever o conte\u00fado e a estrutura do corpo de uma mensagem utilizada para enviar um pedido de pagamento com cart\u00e3o de cr\u00e9dito.<\/p>\n
Um esquema cont\u00e9m um conjunto de defini\u00e7\u00f5es de tipos de dados e de elementos. Um servi\u00e7o Web utiliza o esquema n\u00e3o s\u00f3 para indicar o tipo de dados que se espera que constem numa mensagem, mas tamb\u00e9m para validar as mensagens recebidas e enviadas.<\/p>\n
No entanto, um esquema por si s\u00f3 n\u00e3o fornece informa\u00e7\u00e3o suficiente para descrever eficazmente um servi\u00e7o Web. O esquema n\u00e3o descreve os padr\u00f5es de mensagens entre o cliente e o servidor. Por exemplo, um cliente precisa de saber se deve esperar uma resposta quando uma encomenda \u00e9 enviada para o sistema ERP. Um cliente tamb\u00e9m precisa de saber atrav\u00e9s de que protocolo de transporte o servi\u00e7o Web espera receber pedidos. Por fim, o cliente precisa de saber o endere\u00e7o atrav\u00e9s do qual o servi\u00e7o Web pode ser acedido.<\/p>\n
Esta informa\u00e7\u00e3o \u00e9 fornecida por um documento na Linguagem de Descri\u00e7\u00e3o de Servi\u00e7os Web (WSDL). O WSDL \u00e9 um documento XML que descreve na \u00edntegra um determinado servi\u00e7o Web. Ferramentas como o WSDL.exe do ASP.NET e o SOAPSUDS.exe do Remoting podem processar o WSDL e criar automaticamente proxies para o programador.<\/p>\n
Tal como acontece com qualquer componente utilizado na cria\u00e7\u00e3o de software, um servi\u00e7o Web tamb\u00e9m deve ser acompanhado de documenta\u00e7\u00e3o escrita destinada aos programadores que desenvolvem aplica\u00e7\u00f5es com base nesse servi\u00e7o. A documenta\u00e7\u00e3o deve descrever o que o servi\u00e7o Web faz, as interfaces que exp\u00f5e e alguns exemplos de como utiliz\u00e1-lo. Uma boa documenta\u00e7\u00e3o \u00e9 especialmente importante se o servi\u00e7o Web for disponibilizado a clientes atrav\u00e9s da Internet.<\/p>\n
Escolha dos mecanismos de descoberta<\/b><\/p>\n
Depois de desenvolver e documentar um servi\u00e7o Web, como \u00e9 que os potenciais clientes podem localiz\u00e1-lo? Se o servi\u00e7o Web for concebido para ser utilizado por um membro da vossa equipa de desenvolvimento, a vossa abordagem pode ser bastante informal, como, por exemplo, partilhar o URL do documento WSDL com o vosso colega que fica a algumas cabines de dist\u00e2ncia. Mas quando os potenciais clientes est\u00e3o na Internet, promover o seu servi\u00e7o Web de forma eficaz \u00e9 uma hist\u00f3ria completamente diferente.<\/p>\n
O que \u00e9 necess\u00e1rio \u00e9 uma forma comum de divulgar servi\u00e7os Web. O Universal Description, Discovery, and Integration (UDDI) fornece exatamente esse mecanismo. O UDDI \u00e9 um servi\u00e7o de diret\u00f3rio centralizado, padr\u00e3o da ind\u00fastria, que pode ser utilizado para divulgar e localizar servi\u00e7os Web. O UDDI permite aos utilizadores pesquisar servi\u00e7os Web utilizando uma s\u00e9rie de crit\u00e9rios de pesquisa, incluindo o nome da empresa, a categoria e o tipo de servi\u00e7o Web.<\/p>\n
Os servi\u00e7os Web tamb\u00e9m podem ser anunciados atrav\u00e9s do DISCO, um formato de documento XML propriet\u00e1rio definido pela Microsoft que permite aos s\u00edtios Web anunciar os servi\u00e7os que disponibilizam. O DISCO define um protocolo simples para facilitar a localiza\u00e7\u00e3o de recursos atrav\u00e9s de hiperliga\u00e7\u00f5es. O principal utilizador do DISCO \u00e9 o Microsoft Visual Studio.NET. Um programador pode selecionar um servidor Web espec\u00edfico e navegar pelos v\u00e1rios servi\u00e7os Web disponibilizados por esse servidor.<\/p>\n
O que falta nos servi\u00e7os Web?<\/b><\/p>\n
Talvez tenha reparado que alguns elementos-chave presentes numa infraestrutura de componentes distribu\u00eddos n\u00e3o s\u00e3o definidos pelos servi\u00e7os Web. Duas das omiss\u00f5es mais evidentes s\u00e3o uma API bem definida para a cria\u00e7\u00e3o e utiliza\u00e7\u00e3o de servi\u00e7os Web e um conjunto de servi\u00e7os de componentes, tais como o suporte a transa\u00e7\u00f5es distribu\u00eddas. Vamos analisar cada uma destas lacunas.<\/p>\n
Num esfor\u00e7o para garantir que os servi\u00e7os Web sejam independentes da linguagem de programa\u00e7\u00e3o, a Microsoft deixou a cargo de cada fornecedor de software a decis\u00e3o de vincular o suporte aos servi\u00e7os Web a uma plataforma espec\u00edfica. Abordarei duas implementa\u00e7\u00f5es de servi\u00e7os Web para a plataforma .NET, o ASP.NET e o Remoting, mais adiante neste livro.<\/p>\n
Alguns servi\u00e7os, como o suporte a transa\u00e7\u00f5es distribu\u00eddas, podem ser introduzidos posteriormente, \u00e0 medida que a tecnologia amadurece. Outros, como o pool de objetos e, possivelmente, a gest\u00e3o do ciclo de vida dos objetos, podem ser considerados um pormenor de implementa\u00e7\u00e3o da plataforma. Por exemplo, o Remoting define extens\u00f5es para fornecer suporte \u00e0 gest\u00e3o do ciclo de vida dos objetos, e o Microsoft Component Services fornece suporte ao pool de objetos.<\/p>\n
Resumo<\/b><\/p>\n
A programa\u00e7\u00e3o baseada em componentes revelou-se uma mais-valia para a produtividade dos programadores, mas alguns servi\u00e7os n\u00e3o podem ser encapsulados por um componente que resida no centro de dados do cliente. Tecnologias antigas, como DCOM, CORBA e Java RMI, n\u00e3o s\u00e3o adequadas para permitir que os clientes acedam a servi\u00e7os atrav\u00e9s da Internet, pelo que a Microsoft considerou necess\u00e1rio come\u00e7ar do zero e criar uma forma, que se tornasse um padr\u00e3o da ind\u00fastria, de aceder a servi\u00e7os remotos.<\/p>\n
Servi\u00e7os Web<\/i> \u00e9 um termo gen\u00e9rico que descreve um conjunto de protocolos e servi\u00e7os padronizados pela ind\u00fastria, utilizados para facilitar um n\u00edvel b\u00e1sico de interoperabilidade entre aplica\u00e7\u00f5es. O apoio da ind\u00fastria aos servi\u00e7os Web tem sido sem precedentes. Nunca antes tantas empresas l\u00edderes no setor tecnol\u00f3gico se tinham mobilizado para apoiar uma norma que facilitasse a interoperabilidade entre aplica\u00e7\u00f5es, independentemente da plataforma em que estas s\u00e3o executadas.<\/p>\n
Um dos fatores que contribuem para o sucesso dos servi\u00e7os Web \u00e9 o facto de estes se basearem em normas da Internet j\u00e1 existentes, como o XML e o HTTP. Consequentemente, qualquer sistema capaz de analisar texto e comunicar atrav\u00e9s de um protocolo de transporte padr\u00e3o da Internet pode comunicar com um servi\u00e7o Web. As empresas tamb\u00e9m podem tirar partido do investimento que j\u00e1 realizaram nestas tecnologias.<\/p>","protected":false},"excerpt":{"rendered":"
Overview Component-based programming has become more popular than ever. Hardly an application is built today that does not involve leveraging components in some form, usually from different vendors. As applications have grown more sophisticated, the need to leverage components distributed on remote machines has also grown.<\/p>","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-231","post","type-post","status-publish","format-standard","hentry","category-smtp-servers"],"_links":{"self":[{"href":"https:\/\/www.smtp-server.net\/pt\/wp-json\/wp\/v2\/posts\/231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.smtp-server.net\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.smtp-server.net\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.smtp-server.net\/pt\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.smtp-server.net\/pt\/wp-json\/wp\/v2\/comments?post=231"}],"version-history":[{"count":1,"href":"https:\/\/www.smtp-server.net\/pt\/wp-json\/wp\/v2\/posts\/231\/revisions"}],"predecessor-version":[{"id":232,"href":"https:\/\/www.smtp-server.net\/pt\/wp-json\/wp\/v2\/posts\/231\/revisions\/232"}],"wp:attachment":[{"href":"https:\/\/www.smtp-server.net\/pt\/wp-json\/wp\/v2\/media?parent=231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.smtp-server.net\/pt\/wp-json\/wp\/v2\/categories?post=231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.smtp-server.net\/pt\/wp-json\/wp\/v2\/tags?post=231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}