• Nenhum resultado encontrado

CAPÍTULO 2 REVISÃO BIBLIOGRÁFICA

2.2 SERVIÇOS WEB

2.2.7 Metodologias de desenvolvimento de serviços Web

Quando se fala em interoperabilidade entre diferentes serviços Web, não se pode desconsiderar a metodologia de desenvolvimento desses serviços. Portanto, ao se escolher a metodologia de desenvolvimento mais adequada para um determinado cenário, é preciso também levar em conta questões e formas de garantir uma maior interoperabilidade entre os serviços Web. Essa seção apresenta detalhes das metodologias de desenvolvimento de serviços Web existentes, e considerações sobre a interoperabilidade de cada uma delas.

Ciclo de vida de serviços Web

O ciclo de vida de um serviço Web consiste de diferentes fases. Essas fases podem ser definidas como (BRITTENHAM, 2001):

• Construção: Essa fase do ciclo de vida inclui o planejamento, desenvolvimento e teste da implementação do serviço e a definição da interface do serviço. A implementação de um serviço Web pode ser feita através da criação de um novo serviço Web, da transformação de uma aplicação existente em um serviço Web, e da composição de serviços Web existentes em um novo serviço. As metodologias de desenvolvimento de serviços Web são descritas na subseção seguinte.

• Disponibilização: Essa fase inclui a publicação do serviço e de sua interface em um registro de serviços – UDDI, por exemplo – e inclusão dos executáveis do serviço em uma plataforma de execução de serviços Web.

• Execução: Durante essa fase, o serviço Web já está disponível e operacional. Os consumidores do serviço podem então localizar a sua interface e invocar todas as operações disponibilizadas pelo serviço Web.

• Gerenciamento: Essa fase inclui o gerenciamento e administração do serviço Web, que inclui segurança, desempenho, disponibilidade, etc.

Modelagem de serviços Web

Existem quatro métodos que um provedor de serviços pode utilizar para desenvolver um serviço Web, que são apresentados na Tabela 1. A escolha da utilização do método resulta da existência ou não de uma aplicação ou interface que irá se tornar um serviço Web.

Nova interface de serviço Interface de serviço existente

Novo serviço Web green-field top-down

Aplicação existente bottom-up meet-in-the-midle

Tabela 1: Métodos para desenvolvimento de serviços Web (BRITTENHAM, 2001) Green-Field

Nesse método, primeiramente a aplicação é criada, depois exposta como um serviço Web, e então uma nova definição de interface é gerada a partir desse novo serviço.

Após isso, o serviço é então disponibilizado em um servidor de aplicações, e a interface publicada em um registro.

Top-Down

Nesse método, o serviço Web é criado a partir de uma interface de serviço antes da criação da lógica da aplicação. Essa interface pode ser também um padrão da indústria, onde diversos provedores de serviço podem implementá-la (TAO et al., 2006). O provedor do serviço primeiramente cria ou localiza a descrição da interface do serviço, em seguida implementa as operações dessa interface, para então disponibilizar o seu serviço em um servidor de aplicação e publicá-lo em um registro.

Bottom-Up

Ao contrário do top-down, esse método é usado para criar uma nova interface de serviços a partir de uma aplicação ou função de negócio já existente, que pode ter sido desenvolvida em diferentes linguagens de programação em sistemas legados da organização (PEREPLETCHIKOV et al., 2005). Esse método se assemelha ao do green- field, porém já existe uma aplicação previamente desenvolvida e funcional, que será exposta como um serviço Web através da criação e publicação da sua interface. Esse método permite que o desenvolvedor reutilize componentes já existentes.

Meet In The Middle

Esse método é uma combinação dos métodos top-down e bottom-up, que consiste na utilização de uma interface e de uma aplicação já existente, de forma que o desenvolvedor implemente um suporte adicional entre estes, através da utilização de um adaptador ou um invólucro15 (TAO et al., 2006). Nesse método, uma funcionalidade de processos negócios de alta granularidade16 é utilizada, e adaptada, de forma que se forneça um serviço com uma granularidade mais baixa (PEREPLETCHIKOV et al., 2005).

15

Invólucro também é referenciado na literatura como wrapper

16

A granularidade de um serviço pode ser baixa (fine-grained) ou alta (coarse-grained), e se refere ao escopo ou funcionalidade que um serviço expõe (LEYMANN, 2003). Um serviço de granularidade baixa provê uma função de negócios mais simples (como acesso a dados, por exemplo) e que oculta seus detalhes de implementação, enquanto que um serviço de granularidade alta normalmente provê funções de negócios mais complexas, expondo as funcionalidades e os detalhes de implementação.

Considerações sobre a metodologia de desenvolvimento e interoperabilidade

De acordo com LEHMANN (2005), a escolha do método para desenvolvimento de serviços Web pode ter influência direta em sua interoperabilidade.

Foram apresentados na seção anterior quatro métodos para o desenvolvimento de serviços Web, porém os métodos top-down e bottom-up17 são os mais comumente utilizados para desenvolvimento de serviços Web (LEHMANN, 2005, PEREPLETCHIKOV et al., 2005), e por isso foram escolhidos para uma análise mais detalhada a respeito da interoperabilidade.

Conforme visto, no método top-down existe uma análise prévia dos processos de negócio e a identificação das atividades desse processo, para então definir as operações que podem ser expostas na especificação do serviço. No método bottom-up, é feita uma análise das aplicações já existentes em um sistema legado, identificando aqueles que podem ser expostos como serviços (PEREPLETCHIKOV et al., 2005).

O método de top-down torna os serviços mais interoperáveis em comparação aos serviços gerados pelo método de bottom-up (LEHMANN, 2005, PEREPLETCHIKOV et al., 2005). Essa maior interoperabilidade é devida ao fato de que no método top-down o desenvolvimento é iniciado a partir da definição da interface e mensagens do serviço, evitando assim tipos de dados específicos de uma linguagem de programação em particular. Por exemplo, um problema de interoperabilidade pode ocorrer quando um cliente .NET invoca um serviço Java que utiliza algum tipo de Collections (Vectors, HashMap, etc), que é específico da linguagem Java (SWITHINBANK et al., 2005).