Visão geral
A programação baseada em componentes tornou-se mais popular do que nunca. Atualmente, dificilmente se constrói uma aplicação que não envolva a utilização de componentes de alguma forma, normalmente de diferentes fornecedores. À medida que as aplicações se tornaram mais sofisticadas, a necessidade de utilizar componentes distribuídos em máquinas remotas também aumentou.
Um exemplo de aplicação baseada em componentes é uma solução de comércio eletrónico de ponta a ponta. Uma aplicação de comércio eletrónico alojada numa farm de servidores Web precisa de enviar encomendas para uma aplicação de planeamento de recursos empresariais (ERP) de back-end. Em muitos casos, a aplicação ERP está alojada em hardware diferente e pode ser executada num sistema operativo diferente.
O Modelo de Objetos Distribuídos da Microsoft (DCOM), uma infraestrutura de objetos distribuídos que permite que uma aplicação invoque componentes do Modelo de Objetos Componentes (COM) instalados noutro servidor, foi adaptado para várias plataformas que não são Windows. No entanto, o DCOM nunca obteve uma aceitação generalizada nessas plataformas, pelo que raramente é utilizado para facilitar a comunicação entre computadores Windows e não Windows. Os fornecedores de software ERP criam frequentemente componentes para a plataforma Windows que comunicam com o sistema de back-end através de um protocolo proprietário.
Alguns serviços utilizados por uma aplicação de comércio eletrónico podem nem sequer residir no centro de dados. Por exemplo, se a aplicação de comércio eletrónico aceitar pagamentos com cartão de crédito para bens adquiridos pelo cliente, terá de recorrer aos serviços do banco comercial para processar os dados do cartão de crédito do cliente. No entanto, para todos os efeitos práticos, o DCOM e as tecnologias relacionadas, como o CORBA e o Java RMI, limitam-se a aplicações e componentes instalados no centro de dados da empresa. Duas razões principais para isso são o facto de, por predefinição, estas tecnologias utilizarem protocolos proprietários e de esses protocolos serem, por natureza, orientados para a ligação.
Os clientes que comunicam com o servidor através da Internet enfrentam inúmeras barreiras potenciais à comunicação com o servidor. Administradores de rede preocupados com a segurança em todo o mundo implementaram routers e firewalls empresariais para bloquear praticamente todos os tipos de comunicação através da Internet. Muitas vezes, é preciso um acontecimento extraordinário para que um administrador de rede abra portas para além do mínimo indispensável.
Se tiver a sorte de conseguir que um administrador de rede abra as portas necessárias para suportar o seu serviço, é provável que os seus clientes não tenham a mesma sorte. Consequentemente, os protocolos proprietários, como os utilizados pelo DCOM, CORBA e Java RMI, não são práticos para cenários na Internet.
O outro problema, como já referi, com estas tecnologias é que são, por natureza, orientadas para a ligação e, por isso, não conseguem lidar adequadamente com interrupções na rede. Como a Internet não está sob o seu controlo direto, não pode fazer quaisquer suposições sobre a qualidade ou a fiabilidade da ligação. Se ocorrer uma interrupção na rede, a próxima chamada que o cliente fizer ao servidor poderá falhar.
A natureza orientada para as ligações destas tecnologias também torna difícil construir as infraestruturas com equilíbrio de carga necessárias para alcançar uma elevada escalabilidade. Assim que a ligação entre o cliente e o servidor é interrompida, não é possível simplesmente encaminhar o pedido seguinte para outro servidor.
Os programadores têm tentado superar estas limitações recorrendo a um modelo denominado sem nacionalidade programação, mas o seu sucesso tem sido limitado, uma vez que as tecnologias são bastante pesadas e tornam dispendioso restabelecer uma ligação com um objeto remoto.
Uma vez que o processamento do cartão de crédito de um cliente é realizado por um servidor remoto na Internet, o DCOM não é a solução ideal para facilitar a comunicação entre o cliente de comércio eletrónico e o servidor de processamento de cartões de crédito. Tal como numa solução ERP, é frequente que um componente de terceiros seja instalado no centro de dados do cliente (neste caso, pelo fornecedor da solução de processamento de cartões de crédito). Este componente funciona basicamente como um proxy que facilita a comunicação entre o software de comércio eletrónico e o banco do comerciante através de um protocolo proprietário.
Consegue ver aqui um padrão? Devido às limitações das tecnologias existentes no que diz respeito à facilitação da comunicação entre sistemas informáticos, os fornecedores de software têm recorrido frequentemente à criação da sua própria 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ões de crédito foram, em vez disso, dedicados à criação de protocolos de rede proprietários.
Num esforço para melhor dar resposta a esses cenários da Internet, a Microsoft adotou inicialmente a estratégia de ampliar as suas tecnologias existentes, incluindo os COM Internet Services (CIS), que permitem estabelecer uma ligação DCOM entre o cliente e o componente remoto através da porta 80. Por várias razões, os CIS não foram amplamente aceites.
Ficou claro que era necessária uma nova abordagem. Por isso, a Microsoft decidiu abordar o problema de baixo para cima. Vejamos alguns dos requisitos que a solução tinha de cumprir para ser bem-sucedida.
- Interoperabilidade O serviço remoto deve poder ser utilizado por clientes noutras plataformas.
- Facilidade de utilização na Internet A solução deverá funcionar bem para dar apoio aos clientes que acedem ao serviço remoto a partir da Internet.
- Interfaces fortemente tipadas Não deve haver qualquer ambiguidade quanto ao tipo de dados enviados para e recebidos de um serviço remoto. Além disso, os tipos de dados definidos pelo serviço remoto devem corresponder razoavelmente bem aos tipos de dados definidos pela maioria das linguagens de programação procedimentais.
- Capacidade de tirar partido das normas da Internet existentes A implementação do serviço remoto deve aproveitar, tanto quanto possível, as normas da Internet existentes e evitar reinventar soluções para problemas que já foram resolvidos. Uma solução baseada em normas da Internet amplamente adotadas pode tirar partido dos conjuntos de ferramentas e produtos existentes criados para essa tecnologia.
- Suporte para qualquer língua A solução não deve estar fortemente acoplada a uma linguagem de programação específica. O Java RMI, por exemplo, está fortemente ligado à linguagem Java. Seria difícil invocar funcionalidades num objeto Java remoto a partir do Visual Basic ou do Perl. Um cliente deve poder implementar um novo serviço Web ou utilizar um serviço Web existente, independentemente da linguagem de programação em que o cliente foi escrito.
- Suporte para qualquer infraestrutura de componentes distribuídos A solução não deve estar fortemente ligada a uma infraestrutura de componentes específica. Na verdade, não se deve exigir que se adquira, instale ou mantenha uma infraestrutura de objetos distribuídos apenas para criar um novo serviço remoto ou utilizar um serviço já existente. Os protocolos subjacentes devem facilitar um nível básico de comunicação entre infraestruturas de objetos distribuídos já existentes, tais como o DCOM e o CORBA.
Tendo em conta o título deste livro, não é de admirar que a solução criada pela Microsoft seja conhecida como Serviços Web. Um serviço Web disponibiliza uma interface para invocar uma atividade específica em nome do cliente. Um cliente pode aceder ao serviço Web através da utilização de normas da Internet.
Elementos básicos dos serviços Web
O gráfico seguinte mostra os elementos fundamentais necessários para facilitar a comunicação remota entre duas aplicações.
Vamos analisar a finalidade de cada um destes elementos constitutivos. Uma vez que muitos leitores estão familiarizados com o DCOM, irei também referir o equivalente em DCOM de cada elemento constitutivo.
- Descoberta A aplicação cliente que necessita de aceder às funcionalidades disponibilizadas por um serviço Web precisa de uma forma de determinar a localização do serviço remoto. Isto é conseguido através de um processo geralmente designado por descoberta. A deteção pode ser facilitada através de um diretório centralizado, bem como por métodos mais pontuais. No DCOM, o Gestor de Controlo de Serviços (SCM) fornece serviços de deteção.
- Descrição Assim que o ponto final de um determinado serviço Web for identificado, o cliente necessita de informação suficiente para interagir adequadamente com o mesmo. A descrição de um serviço Web inclui metadados estruturados sobre a interface, destinados a serem utilizados por uma aplicação cliente, bem como documentação escrita sobre o serviço Web, incluindo exemplos de utilização. Um componente DCOM expõe metadados estruturados sobre as suas interfaces através de uma biblioteca de tipos (typelib). Os metadados contidos na typelib de um componente são armazenados num formato binário proprietário e são acedidos através de uma interface de programação de aplicações (API) proprietária.
- Formato da mensagem Para trocarem dados, um cliente e um servidor têm de chegar a acordo quanto a uma forma comum de codificar e formatar as mensagens. Uma forma padronizada de codificação de dados garante que os dados codificados pelo cliente sejam interpretados corretamente pelo servidor. No DCOM, as mensagens enviadas entre um cliente e um servidor são formatadas de acordo com o protocolo DCOM Object RPC (ORPC).
Sem uma forma padronizada de formatar as mensagens, é praticamente impossível desenvolver um conjunto de ferramentas que isole o programador dos protocolos subjacentes. A criação de uma camada de abstração entre o programador e os protocolos subjacentes permite que este se concentre mais no problema empresarial em questão e menos na infraestrutura necessária para implementar a solução.
- Codificação Os dados transmitidos entre o cliente e o servidor têm de ser codificados no corpo da mensagem. O DCOM utiliza um esquema de codificação binária para serializar os dados contidos nos parâmetros trocados entre o cliente e o servidor.
- Transportes Depois de a mensagem ter sido formatada e os dados terem sido serializados no corpo da mensagem, esta deve ser transferida entre o cliente e o servidor através de algum protocolo de transporte. O DCOM suporta vários protocolos proprietários associados a diversos protocolos de rede, tais como TCP, SPX, NetBEUI e NetBIOS sobre IPX.
Decisões relativas à conceção de serviços web
Vamos analisar algumas das decisões de conceção subjacentes a estes elementos fundamentais dos serviços Web.
Escolha dos protocolos de transporte
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 é possível que o cliente comunique com o servidor através da Internet. Por conseguinte, o protocolo de transporte deve ser igualmente adequado tanto para ambientes de LAN como para a Internet.
Como referi anteriormente, tecnologias como o DCOM, o CORBA e o Java RMI não são adequadas para suportar a comunicação entre o cliente e o servidor através da Internet. Protocolos como o Protocolo de Transferência de Hipertexto (HTTP) e o Protocolo Simples de Transferência de Correio (SMTP) são protocolos de Internet comprovados. O HTTP define um padrão de mensagens de pedido/resposta para enviar um pedido e obter uma resposta associada. O SMTP define um protocolo de mensagens roteável para comunicação assíncrona. Vamos analisar por que razão o HTTP e o SMTP são adequados para a Internet.
As aplicações Web baseadas em HTTP são, por natureza, sem estado. Não dependem de uma ligação contínua entre o cliente e o servidor. Isto torna o HTTP um protocolo ideal para configurações de alta disponibilidade, como as firewalls. Se o servidor que tratou do pedido original do cliente ficar indisponível, os pedidos subsequentes podem ser automaticamente encaminhados para outro servidor sem que o cliente se aperceba ou se preocupe com isso.
Quase todas as empresas dispõem de uma infraestrutura que suporta o SMTP. O SMTP é particularmente adequado para a comunicação assíncrona. Se o serviço for interrompido, a infraestrutura de e-mail gere automaticamente novas tentativas. Ao contrário do que acontece com o HTTP, é possível enviar mensagens SMTP para um servidor de correio local, que tentará entregar a mensagem em seu nome.
A outra vantagem significativa tanto do HTTP como do SMTP é a sua generalização. Os colaboradores passaram a depender tanto do e-mail como dos seus navegadores da Web, e os administradores de rede sentem-se bastante à vontade a dar suporte a estes serviços. Tecnologias como a tradução de endereços de rede (NAT) e os servidores proxy permitem aceder à Internet através 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ão então encaminhadas para o seu destino final através da Internet.
No caso do software de processamento de cartões de crédito, é necessária 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ão de mensagens de pedido/resposta, é adequado para esta tarefa.
A maioria dos pacotes de software ERP não tem capacidade para processar grandes volumes de encomendas que possam vir a ser geradas pela aplicação de comércio eletrónico. Além disso, não é imprescindível 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.
Se o sistema ERP suportar transações distribuídas, outra opção é recorrer ao Microsoft Message Queue Server (MSMQ). Desde que a aplicação de comércio eletrónico e o sistema ERP se encontrem na mesma LAN, a conectividade através de protocolos que não sejam da Internet representa um problema menor. A vantagem do MSMQ em relação ao SMTP é que as mensagens podem ser colocadas e removidas da fila no âmbito de uma transação. Se uma tentativa de processar uma mensagem retirada da fila falhar, a mensagem será automaticamente colocada de volta na fila quando a transação for abortada.
Escolher um esquema de codificação
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.
Uma vez que o objetivo era tirar partido dos protocolos baseados na Internet, a Linguagem de Marcação Extensível (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ão da indústria.
Os esquemas de codificação binária, como os utilizados pelo DCOM, CORBA e Java RMI, têm de resolver problemas de compatibilidade entre diferentes plataformas de hardware. Por exemplo, diferentes plataformas de hardware têm diferentes representações binárias internas dos números multibyte. As plataformas Intel ordenam os bytes de um número multibyte utilizando a convenção «little endian»; muitos processadores RISC ordenam os bytes de um número multibyte utilizando a convenção «big endian».
O XML evita problemas de codificação binária, uma vez que utiliza um esquema de codificação baseado em texto que recorre a conjuntos de caracteres padrão. Além disso, alguns protocolos de transporte, como o SMTP, só podem conter mensagens baseadas em texto.
Os métodos binários de codificação, como os utilizados pelo DCOM e pelo CORBA, são pesados e exigem uma infraestrutura de suporte para isolar o programador dos pormenores. O XML é muito mais leve e fácil de manusear, uma vez que pode ser criado e utilizado recorrendo a técnicas padrão de análise de texto.
Além disso, existe uma variedade de analisadores XML disponíveis para simplificar ainda mais a criação e a utilização de documentos XML em praticamente todas as plataformas modernas. O XML é leve e conta com um excelente suporte de ferramentas, pelo que a codificação em XML permite um alcance incrível, uma vez que praticamente qualquer cliente, em qualquer plataforma, pode comunicar com o seu serviço Web.
Escolher uma convenção de formatação
É frequentemente necessário incluir metadados adicionais no corpo da mensagem. Por exemplo, poderá querer incluir informações sobre o tipo de serviços que um serviço Web precisa de fornecer para satisfazer o seu pedido, tais como a participação numa transação ou informações de encaminhamento. O XML não disponibiliza qualquer mecanismo para diferenciar o corpo da mensagem dos dados que lhe estão associados.
Os protocolos de transporte, como o HTTP, proporcionam um mecanismo extensível para os dados de cabeçalho, mas alguns dados associados à mensagem podem não ser específicos do protocolo de transporte. Por exemplo, o cliente pode enviar uma mensagem que precise de ser encaminhada para vários destinos, potencialmente através de diferentes protocolos de transporte. Se as informações de encaminhamento fossem colocadas num cabeçalho HTTP, teriam de ser convertidas antes de serem enviadas para o próximo intermediário através de outro protocolo de transporte, como o SMTP. Uma vez que as informações de encaminhamento são específicas da mensagem e não do protocolo de transporte, devem fazer parte da mensagem.
O Protocolo Simples de Acesso a Objetos (SOAP) proporciona uma forma independente do protocolo para associar informações de cabeçalho ao corpo da mensagem. Todas as mensagens SOAP têm de definir um envelope. O envelope tem um corpo que contém a carga útil da mensagem e um cabeçalho que pode conter metadados associados à mensagem.
O SOAP não impõe restrições quanto à forma como o corpo da mensagem pode ser formatado. Isto constitui uma potencial preocupação, pois, sem uma forma consistente de codificar os dados, é difícil desenvolver um conjunto de ferramentas que permita abstrair-se dos protocolos subjacentes. Poderá ter de dedicar bastante tempo a familiarizar-se com a interface do serviço Web, em vez de resolver o problema empresarial em questão.
O que era necessário era uma forma padronizada de formatar uma mensagem de chamada de procedimento remoto (RPC) e de codificar a sua lista de parâmetros. É exatamente isso que a Secção 7 da especificação SOAP prevê. Descreve uma convenção de nomenclatura e um estilo de codificação padronizados para mensagens orientadas a procedimentos.
Uma vez que o SOAP fornece um formato padrão para a serialização de dados numa mensagem XML, plataformas como o ASP.NET e o Remoting podem ocultar esses detalhes para si.
Escolha de mecanismos de descrição
O SOAP fornece uma forma padronizada de formatar as mensagens trocadas entre o serviço Web e o cliente. No entanto, o cliente necessita de informação 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údo de uma mensagem.
O XML Schema fornece um conjunto básico de tipos de dados integrados que podem ser utilizados para descrever o conteúdo de uma mensagem. Também é possível criar os seus próprios tipos de dados. Por exemplo, o banco comercial pode criar um tipo de dados complexo para descrever o conteúdo e a estrutura do corpo de uma mensagem utilizada para enviar um pedido de pagamento com cartão de crédito.
Um esquema contém um conjunto de definições de tipos de dados e de elementos. Um serviço Web utiliza o esquema não só para indicar o tipo de dados que se espera que constem numa mensagem, mas também para validar as mensagens recebidas e enviadas.
No entanto, um esquema por si só não fornece informação suficiente para descrever eficazmente um serviço Web. O esquema não descreve os padrões de mensagens entre o cliente e o servidor. Por exemplo, um cliente precisa de saber se deve esperar uma resposta quando uma encomenda é enviada para o sistema ERP. Um cliente também precisa de saber através de que protocolo de transporte o serviço Web espera receber pedidos. Por fim, o cliente precisa de saber o endereço através do qual o serviço Web pode ser acedido.
Esta informação é fornecida por um documento na Linguagem de Descrição de Serviços Web (WSDL). O WSDL é um documento XML que descreve na íntegra um determinado serviço 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.
Tal como acontece com qualquer componente utilizado na criação de software, um serviço Web também deve ser acompanhado de documentação escrita destinada aos programadores que desenvolvem aplicações com base nesse serviço. A documentação deve descrever o que o serviço Web faz, as interfaces que expõe e alguns exemplos de como utilizá-lo. Uma boa documentação é especialmente importante se o serviço Web for disponibilizado a clientes através da Internet.
Escolha dos mecanismos de descoberta
Depois de desenvolver e documentar um serviço Web, como é que os potenciais clientes podem localizá-lo? Se o serviço 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ância. Mas quando os potenciais clientes estão na Internet, promover o seu serviço Web de forma eficaz é uma história completamente diferente.
O que é necessário é uma forma comum de divulgar serviços Web. O Universal Description, Discovery, and Integration (UDDI) fornece exatamente esse mecanismo. O UDDI é um serviço de diretório centralizado, padrão da indústria, que pode ser utilizado para divulgar e localizar serviços Web. O UDDI permite aos utilizadores pesquisar serviços Web utilizando uma série de critérios de pesquisa, incluindo o nome da empresa, a categoria e o tipo de serviço Web.
Os serviços Web também podem ser anunciados através do DISCO, um formato de documento XML proprietário definido pela Microsoft que permite aos sítios Web anunciar os serviços que disponibilizam. O DISCO define um protocolo simples para facilitar a localização de recursos através de hiperligações. O principal utilizador do DISCO é o Microsoft Visual Studio.NET. Um programador pode selecionar um servidor Web específico e navegar pelos vários serviços Web disponibilizados por esse servidor.
O que falta nos serviços Web?
Talvez tenha reparado que alguns elementos-chave presentes numa infraestrutura de componentes distribuídos não são definidos pelos serviços Web. Duas das omissões mais evidentes são uma API bem definida para a criação e utilização de serviços Web e um conjunto de serviços de componentes, tais como o suporte a transações distribuídas. Vamos analisar cada uma destas lacunas.
- API específica para serviços web A maioria das infraestruturas de componentes distribuídos define uma API para realizar tarefas como a inicialização do ambiente de execução, a criação de uma instância de um componente e a reflexão dos metadados utilizados para descrever o componente. Como a maioria das linguagens de programação de alto nível oferece algum grau de interoperabilidade com o C, a API é normalmente exposta como um conjunto simples de assinaturas de métodos em C. A RMI vai ao ponto de acoplar fortemente a sua API a uma única linguagem de alto nível, o Java.
Num esforço para garantir que os serviços Web sejam independentes da linguagem de programação, a Microsoft deixou a cargo de cada fornecedor de software a decisão de vincular o suporte aos serviços Web a uma plataforma específica. Abordarei duas implementações de serviços Web para a plataforma .NET, o ASP.NET e o Remoting, mais adiante neste livro.
- Serviços de componentes A plataforma de serviços Web não disponibiliza muitos dos serviços normalmente encontrados em infraestruturas de componentes distribuídos, tais como a gestão do ciclo de vida de objetos remotos, o pooling de objetos e o suporte a transações distribuídas. A implementação destes serviços fica a cargo da infraestrutura de componentes distribuídos.
Alguns serviços, como o suporte a transações distribuídas, podem ser introduzidos posteriormente, à medida que a tecnologia amadurece. Outros, como o pool de objetos e, possivelmente, a gestão do ciclo de vida dos objetos, podem ser considerados um pormenor de implementação da plataforma. Por exemplo, o Remoting define extensões para fornecer suporte à gestão do ciclo de vida dos objetos, e o Microsoft Component Services fornece suporte ao pool de objetos.
Resumo
A programação baseada em componentes revelou-se uma mais-valia para a produtividade dos programadores, mas alguns serviços não podem ser encapsulados por um componente que resida no centro de dados do cliente. Tecnologias antigas, como DCOM, CORBA e Java RMI, não são adequadas para permitir que os clientes acedam a serviços através da Internet, pelo que a Microsoft considerou necessário começar do zero e criar uma forma, que se tornasse um padrão da indústria, de aceder a serviços remotos.
Serviços Web é um termo genérico que descreve um conjunto de protocolos e serviços padronizados pela indústria, utilizados para facilitar um nível básico de interoperabilidade entre aplicações. O apoio da indústria aos serviços Web tem sido sem precedentes. Nunca antes tantas empresas líderes no setor tecnológico se tinham mobilizado para apoiar uma norma que facilitasse a interoperabilidade entre aplicações, independentemente da plataforma em que estas são executadas.
Um dos fatores que contribuem para o sucesso dos serviços Web é o facto de estes se basearem em normas da Internet já existentes, como o XML e o HTTP. Consequentemente, qualquer sistema capaz de analisar texto e comunicar através de um protocolo de transporte padrão da Internet pode comunicar com um serviço Web. As empresas também podem tirar partido do investimento que já realizaram nestas tecnologias.