De acordo com uma pesquisa lançada pela ISOC (Internet Society), a migração para o protocolo de rede IPv6 está sem diversos tipos de incentivos.
Atualmente utilizamos o protocolo de rede IPv4, que utiliza endereços com até 32 bits de informação e permite à rede possuir em torno de 4,3 bilhões de equipamentos diferentes identificados através do número IP. Para ampliar esta limitação o IPv6 foi desenvolvido, ele trabalha com endereços com até 128 bits de informação, e permite aumentar brutalmente a quantidade de dispositivos identificados na rede, caso queira fazer as contas é só fazer 2 na 128° potência.
As faltas de incentivos, dizem as empresas, são principalmente a falta de conhecimento técnico sobre tecnologia, seguido de suporte ainda não excelente das ferramentas e sistemas administrativos, infra-estrutura de segurança e suporte de fornecedores.
Especialistas prevêem que até 2012 os números IP no protocolo IPv4 irão acabar, e neste momento toda infra-estrutura de rede do planeta precisa estar preparada para migrar do protocolo que já não irá mais atender as necessidades, tanto de expansão da rede quanto de recursos do protocolo.
Isso não assusta se formos pensar na velocidade da evolução tecnológica, em três anos muita coisa pode ser feita. E uma das informações geradas pela pesquisa pode provar isto, a maioria das organizações entrevistadas indicaram que estão implementando ou implementaram o protocolo em algum nível.
Confirma maiores detalhes, leia a pesquisa clicando aqui.
Porque é uma saída interessante integrar sistemas WEB heterogêneos via Webservices, se existem tantas outras formas de integração e compartilhamento como o RSS, XML-RPC, ou até uma chamada direta no maior estilo “mão grande com PHP” file_get_contents($url)?
Webservices nos proporcionam recursos mais flexíveis e completos para abstrair uma determinada interface de comunicação, como por exemplo, para transportarmos os dados do ERP de uma empresa para a base de dados de produtos do seu Website, ou ainda, os valiosos dados de cadastros efetuados nos inúmeros canais de interação do site, até as listagens de leads dos CRMs.
No momento em que imaginarmos um contexto onde o fornecedor do ERP é diferente do CRM e também da solução WEB, precisaremos “azeitar” a comunicação entre os sistemas destes pobres desenvolvedores.
Utilizando esta tecnologia em sistemas de menor escala, me chamou atenção a facilidade com que podemos saber o que vai e vem das operações de um Webservice, sem precisar mandar um e-mail para o “pessoal do ERP”. Recurso muito importante quando trabalhamos em diferentes equipes e frentes de atuação.
Todos sistemas precisam interagir, mas quando um não consegue alguma coisa do outro começa a operação: E-mail pra cá, telefone pra lá, “o dado que tu me fornece não é compatível com meu banco”, “vou ter que fazer um workaround e a culpa é deles”, etc. No momento em que temos uma documentação detalhada sobre como é a interface de cada sistema, estas discussões se tornam menos frequentes.
Estamos falando no tal WSDL (Web Service Description Language) ou UÍSDOL na linguagem tech-balaquês.
De acordo com a W3C, WSDL é um formato XML para descrever Web Services como um conjunto de canais de comunicação operando sob mensagens contendo qualquer tipo de informação estruturada. As operações e mensagens são descritas de uma maneira abstrata, e depois vinculadas a um protocolo de rede e formato para assim definirem o funcionamento de um canal de comunicação.
Em outras palavras o WSDL é um protocolo que define as entradas, saídas e funcionalidades de um Web Service, através dele saberemos como acessar os métodos ou procedimentos do sistema que está disponibilizando o serviço, assim como que tipo de dados receberemos do mesmo.
Então, temos condições de ler:
- Quais são as operações.
“SincronizarProdutos”, “SincronizarCadastrosSite”
- O que precisamos enviar para recebermos uma resposta.
“ProdutoID”, “Usuário” e “Senha”, “ArrayCadastros”
- E o tipo de dado de resposta
“ArrayProdutos”, “boolean”
Claro, este documento pode nos fornecer uma infinidade de outras informações dependendo da complexidade que precisarmos para a integração, por exemplo, podemos criar tipos de dados específicos, semelhante a atributos de uma classe na OO. Quando sincronizamos um produto, especificamos dentro do WSDL o ComplexType “Produto” com todos seus atributos, e na hora de efetuar a transferência de dados, um XML no formato SOAP é serializado na estrutura de “Produto”, que podem posteriormente ser encapsuladas diretamente como um objeto, dependendo da ferramenta que fará a leitura da resposta da Operação. Que legal!
Seguirei em outros posts com mais detalhamento a respeito de WSDL em Webservices.
Caso tenha mais interesse:
Ferramenta para validação de WSDLs: Altova XML Spy
Bibliografia onde WSDL é detalhado: Web Services Essentials
No dia de hoje (na verdade ontem) a comunidade twitteriana pode observar o lançamento do “beta-livro” (assim definido por seus criadores) chamado “Para entender internet“. Uma bela atitude tomada em conjunto por “ativistas, acadêmicos e profissionais que estão ajudando a inventar/moldar a cultura da Web no Brasil.”
Não só o livro mas um espaço dentro do Blogger foi aberto para assuntos relacionados a este projeto.
Assim que conseguir digerir a informação poderei comentar algo mais interessante, aproveitem!!
