Objetivos do WSIF

O WSIF tem como objetivo estender a flexibilidade fornecida pelos serviços SOAP em um modelo geral para chamar serviços da Web, independentemente dos protocolos de ligação ou de acesso subjacentes.

As ligações SOAP para serviços da Web são parte da especificação Web Services Description Language (WSDL), portanto, quando a maioria dos desenvolvedores pensa em usar um serviço da Web, imediatamente pensam em montar uma mensagem SOAP e enviá-la na rede para o terminal em serviço, usando uma API de cliente SOAP. Por exemplo: utilizando Apache SOAP, o cliente cria e ocupa um objeto Call,0 o qual encapsula o nó de extremidade do serviço, a identificação da operação SOAP a ser chamada, os parâmetros a serem enviados, e assim por diante.

Os objetivos do WSIF (Web Services Invocation Framework) são, portanto:

Os Serviços da Web São Mais que Apenas Serviços SOAP

É possível implementar como um serviço da Web qualquer aplicativo que tenha uma descrição com base no WSDL de seus aspectos funcionais e protocolos de acesso. Se você estiver utilizando o ambiente Java™ Platform, Enterprise Edition (Java EE), o aplicativo estará disponível sobre vários transportes e protocolos.

Por exemplo, você pode tomar um procedimento armazenado no banco de dados, expô-lo como um bean de sessão sem estado e, em seguida, implementá-lo em um roteador SOAP como um serviço SOAP. Em cada estágio, o serviço fundamental é o mesmo. Tudo que é alterado é o mecanismo de acesso: de JDBC (Java DataBase Connectivity) para RMI-IIOP (Remote Method Invocation over Internet Inter-ORB Protocol) e depois para SOAP.

A especificação WSDL define uma ligação SOAP para serviços da Web, mas é possível incluir extensões de ligações para o WSDL para que, por exemplo, seja possível oferecer um enterprise bean como um serviço da Web que usa RMI-IIOP como o protocolo de acesso. É possível ainda tratar uma única classe Java como um serviço da Web, com chamadas de métodos Java em encadeamento como o protocolo de acesso. Com essa definição mais ampla de um serviço da Web, será necessário um mecanismo independente de ligação para chamada de serviço.

A Ligação do Código do Cliente a uma Implementação de Protocolo Específico é Restritiva

Se o código do cliente estiver firmemente ligado a uma biblioteca do cliente para uma determinada implementação de protocolo, ele pode ser de difícil manutenção.

Por exemplo, se você mudar de Apache SOAP para Java Message Service (JMS) ou enterprise bean, o processo poderá consumir muito tempo e esforço. Para evitar esses problemas, você necessita de um mecanismo independente da implementação do protocolo para a chamada de serviços.

A Incorporação de Novas Ligações ao Código do Cliente é Difícil

Se desejar que um aplicativo que usa um protocolo customizado funcione como um serviço da Web, é possível incluir elementos de extensibilidade no WSDL para definir as novas ligações. Mas alcançar este recurso é complexo.

Por exemplo, é necessário projetar as APIs de cliente para utilizar esse protocolo. Se seu aplicativo usa somente a interface abstrata do serviço da Web, será necessário escrever ferramentas para gerar os stubs que ativam uma camada de abstração. Essas tarefas podem exigir muito tempo e esforço. O que você precisa é de um mecanismo de chamada de serviço que permita atualizar ligações existentes e adicionar novas ligações.

Várias Ligações Podem Ser Utilizadas de Formas Flexíveis

Para tirar proveito de serviços da Web que oferecem diversas ligações, é necessário um mecanismo de chamada de serviço que possa alternar entre as ligações de serviços disponíveis no tempo de execução, sem a necessidade de gerar ou recompilar um stub.

Imagine que você tenha implementado com êxito um aplicativo que usa um serviço da Web que oferece diversas ligações. Por exemplo, imagine que você tenha uma ligação SOAP para o serviço e uma ligação Java local que permite tratar a implementação de serviço local (uma classe Java) como um serviço da Web.

A ligação Java local para o serviço só pode ser utilizada se o cliente for implementado no mesmo ambiente que o serviço. Nesse caso, é mais eficiente comunicar-se com o serviço fazendo chamadas Java diretas do que utilizando a ligação SOAP.

Se os clientes puderem mudar a ligação utilizada com base nas informações de tempo de execução, eles poderão escolher a ligação mais eficiente disponível para cada situação.

Um Ambiente de Serviços da Web Mais Livre Permite Intermediários

Os serviços da Web oferecem aos integradores de aplicativos um paradigma de acoplamento frouxo. Em ambientes desse tipo, os intermediários podem ser muito poderosos.

Intermediários são aplicativos que interceptam as mensagens que fluem entre um solicitante de serviço e um serviço da Web de destino e executam alguma tarefa intermediária (por exemplo, criação de log, alta disponibilidade ou transformação) antes de passar a mensagem. O WSIF (Web Services Invocation Framework) é projetado para tornar a construção de intermediários possível e simples. Utilizando WSIF, os intermediários podem adicionar valor à chamada do serviço sem necessitar de programação específica do transporte.


Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwsf_goals
Nome do arquivo: cwsf_goals.html