Exemples d’extraction de ressources traductionnelles

Segundo Erl (2005), o paradigma de orientação a serviços pode ser descrito a partir de uma série de princípios, que devem ser seguidos na construção de uma arquitetura: reuso, contrato padronizado, baixo acoplamento, abstração, facilidade de composição, autonomia, independência de estado, localização e interoperabilidade.

2.3.1 Reuso

A orientação a serviços visa tornar cada serviço reusável, mesmo que não haja requisitos específicos para um dado serviço no momento em que ele é desenvolvido. (ERL, 2005).

Serviços reusáveis são aqueles que podem possuir valor em diversos contextos de processos de negócio e interações intra e inter-organizacionais e, por isso, devem suportar diversos padrões de consumo. Devido a essa natureza, novos clientes podem reusar um serviço de uma maneira que não foi prevista em seu projeto original. Nestes casos, deve haver uma infra-estrutura de gerenciamento e governança de serviços que garanta o desempenho e devido funcionamento de tal serviço (MARKS; BELL, 2006).

Os serviços devem ser projetados considerando-se as várias formas de reuso, como transações entre aplicações, composição de serviços e processos de negócio e uso como serviços utilitários. A reusabilidade de um serviço é relacionada à sua

granularidade, sendo que quanto mais alta a granularidade de um serviço, menores são as possibilidades de ele ser usado em mais de um processo de negócio.

2.3.2 Contrato padronizado

Um serviço deve possuir um contrato bem definido que descreve para o mundo externo a funcionalidade por ele exposta e ao mesmo tempo encapsula os detalhes específicos de sua implementação (MARKS; BELL, 2006). O contrato, ou a interface do serviço, disponibiliza as seguintes informações para os consumidores: a localização do serviço, as operações executadas, as mensagens de entrada e saída utilizadas pelo serviço e regras para sua utilização (ERL, 2005). Podem conter também detalhes semânticos das operações do serviço.

O contrato representa um acordo firmado entre o Provedor do serviço e seus Consumidores, criando uma relação de dependência. Por isso, deve haver uma atenção especial na manutenção e versionamento destes documentos.

Contratos de serviço devem ser representados em uma linguagem ou notação bem definida, seguindo padrões abertos que garantam a interoperabilidade do serviço. No contexto de Web Services, contratos de serviço são definidos por documentos em Web Services Description Language (WSDL) (CHISTENSEN et al., 2006), esquemas na linguagem XML Schema Definition (XSD) (FALLSIDE, 2004) e políticas. Em um documento WSDL, são especificados os tipos de dados envolvidos, as mensagens e as operações do serviço. Já os esquemas XSD são a especificação dos tipos de dados e das mensagens XML que serão utilizadas.

2.3.3 Baixo acoplamento

Uma característica importante de serviços em uma arquitetura orientada a serviços é a de que eles devem possuir baixo acoplamento entre si, ou devem ser fracamente acoplados. No entanto, na literatura, o termo baixo acoplamento pode possuir vários significados práticos.

Um serviço fracamente acoplado pode significar um serviço cuja implementação pode ser substituída, modificada ou evoluída ao longo do tempo sem causar impactos nos Consumidores do serviço (MARKS; BELL, 2006). Neste caso, está-se referindo ao acoplamento entre a implementação do serviço e seus Consumidores. Nesta mesma linha, baixo acoplamento pode ser indicado pela transparência de localização. Um serviço pode ser consumido independentemente de onde seu Provedor está fisicamente localizado, criando um desacoplamento entre Consumidor e Provedor (PAPAZOGLOU, 2003).

De maneira geral, o baixo acoplamento é uma condição em que um serviço está ciente da existência de outros serviços mas ainda é independente deles (ERL, 2005).

2.3.4 Abstração

Um princípio importante na orientação a serviços é a abstração ou encapsulamento da lógica interna de um serviço por meio de sua interface. Ao separar interface de implementação, o serviço age como uma caixa preta e expõe aos seus Consumidores somente informações sobre as operações disponíveis.

A granularidade de um serviço é diretamente relacionada com a quantidade de funcionalidade que é encapsulada pelas operações de um serviço (ERL, 2005).

2.3.5 Facilidade de composição

Serviços devem possuir facilidade de composição, isto é, devem ser projetados de forma que possam participar de composições com outros, formando serviços compostos, ou ser orquestrados no contexto de um processo de negócio. Para isso, devem ser desacoplados e suas operações devem ser as mais atômicas possíveis (MARKS; BELL, 2006) (ERL, 2005).

2.3.6 Autonomia

Autonomia exige que a lógica de processamento encapsulada por um serviço fique restrita dentro de uma certa fronteira estabelecida, o que evita a dependência com relação a outros serviços. Isto permite que um serviço tenha controle total sobre sua própria lógica e possa exercer um tipo de auto-governança.

A autonomia de um serviço pode-se dar em dois níveis diferentes (ERL, 2005): no nível do serviço e autonomia pura.

Na autonomia no nível do serviço, os limites entre os serviços são distintos, mas eles ainda podem compartilhar recursos encapsulados, como bases de dados e sistemas legados. Este cenário é comum no caso de diversos serviços desenvolvidos a partir de uma mesma aplicação já existente. Neste caso, os serviços compartilham a aplicação, mas fazem uso dela de maneira independente. Na autonomia pura, a lógica e os dados encapsulados estão sob completo controle do serviço, não sendo compartilhada com outros.

2.3.7 Independência de Estado

Um serviço deve evitar armazenar informações de estado e contexto ou minimizar o período de tempo que estas informações são mantidas (ERL, 2005). Isto quer dizer que a resposta do serviço para uma mensagem deve ser independente das mensagens anteriores processadas pelo serviço. Dependência de contexto ou de estado diminui o potencial de reuso do serviço. Além disso, enquanto o serviço retiver informações de estado de um Consumidor, ele se torna indisponível para atender chamadas de outros Consumidores.

Para tornar um serviço o mais independente possível de estado, as mensagens devem ser inteligentes, isto é, deve ser adicionado às mensagens o máximo de informação para que elas se tornem auto-suficientes e possam ser processadas sem a necessidade de dados de estado.

2.3.8 Localização

Os serviços devem ser localizáveis, o que significa que suas interfaces devem ser de alguma forma publicadas e tornadas visíveis para os potenciais Consumidores. Na arquitetura SOA básica, essas interfaces são publicadas em um Registro de Serviços, de onde elas podem ser buscadas pelos Consumidores (MARKS; BELL, 2006).

2.3.9 Interoperabilidade

Serviços devem ser interoperáveis, isto é, deve ser possível interagir com um serviço independentemente da tecnologia empregada em sua implementação. Quaisquer que sejam a linguagem de programação, a plataforma ou o sistema operacional utilizados na construção dos Provedores, Clientes e Registros de Serviços, as interações entre eles devem ser possíveis. Para isso, essas interações devem ser realizadas utilizando-se padrões e protocolos abertos compatíveis com qualquer tecnologia ou plataforma. Por isso, em uma arquitetura orientada a serviços, a provisão e o consumo de serviços ocorrem de maneira transparente às tecnologias e linguagens utilizadas em sua implementação, garantindo a interoperabilidade entre serviços.

Atualmente, os padrões relacionados à tecnologia Web Services (WSDL, SOAP, UDDI) permitem a descrição de interfaces, a troca de mensagens e a busca por serviços de maneira neutra às plataformas e linguagens utilizadas. Por basearem-se em padrões abertos como o XML e o protocolo HTTP, que são largamente aceitos e suportados, a tecnologia Web Services possibilita a obtenção desta interoperabilidade.

2.3.10 Granularidade de Serviço

Granularidade é um aspecto importante para se determinar o escopo de um serviço. Ao se identificar um serviço, deve-se determinar se ele possuirá baixa granularidade

(serviço técnico ou de baixo nível) ou alta granularidade (serviço de negócio ou de alto nível). A granularidade depende de quanta funcionalidade é encapsulada por um serviço, sendo que quanto mais funcionalidade, mais abrangente é o escopo do serviço e mais alta é sua granularidade. Serviços de granularidade mais alta são utilizados diretamente pelo negócio e podem ser formados pela composição de serviços de granularidade mais baixa.

Segundo a interpretação da empresa IBM (BIEBERSTEIN et al., 2005), os dois tipos de serviços são necessários. Uma arquitetura SOA deve conter serviços diretamente relacionados e com alto valor para o negócio e serviços técnicos que encapsulam lógica com alto potencial de reuso. Os serviços de granularidade mais alta terão menos consumidores, mas agregarão mais valor para o negócio. Eles terão também alta dependência em relação a serviços de granularidade baixa, que por sua vez, terão alto potencial de reuso e terão baixa dependência com outros serviços.

Já Marks e Bell afirmam que serviços devem possuir alta granularidade e representar funções, processos e transações de negócio, encapsulando demais componentes de baixa granularidade (MARKS; BELL, 2006). Segundo os autores, serviços de baixa granularidade, como componentes de software, teriam pouca utilidade direta para o negócio. Por isso, eles não compensariam o overhead de se transformar em um serviço e deveriam ser encapsulados por serviços maiores.

2.3.11 Camadas de Serviço

A orientação a serviços pode trazer uma abstração entre a lógica de negócio e a infra-estrutura de TI, gerando um desacoplamento entre os modelos de processos de negócios e a arquitetura de sistemas de informação. Em uma arquitetura orientada a serviços dando suporte tecnológico aos processos de negócio de uma empresa, a camada de serviços localiza-se exatamente entre a camada de processos e a infra-estrutura de aplicações de TI (ERL, 2005). A camada de serviços cria uma abstração entre os processos de negócio e as aplicações (BIEBERSTEIN et al., 2005), conforme mostra a Figura 2.6.

Figura 2.6: Camadas de uma arquitetura SOA (ERL, 2005)

Baseado no princípio de composição, é possível dividir a camada de serviços em mais três camadas de abstração que determinam o tipo e a granularidade dos serviços. Assim, temos: a camada de serviços de aplicação, a camada de serviços de negócio e a camada de orquestração de serviços. Na Figura 2.7, pode ser visualizada a hierarquia das camadas de serviços.

Figura 2.7: Camadas de serviços (ERL, 2005)

Os serviços de aplicação possuem menor granularidade e representam os serviços de infra-estrutura de uma arquitetura SOA, oferecendo funções específicas de tecnologia. O propósito dos serviços de aplicação é prover funções reusáveis e processar dados contidos em sistemas legados e novas aplicações desenvolvidas. Os serviços de negócio são os elementos fundamentais da arquitetura SOA, pois são aqueles que representam a lógica de negócio da organização. São formados pela composição de diversos serviços de aplicação para implementar a lógica de negócio. Podem representar tarefas de processo ou entidades de negócio.

Por fim, a camada de orquestração de serviços realiza a ligação entre os modelos de processos de negócio e os serviços da arquitetura SOA. O conceito de orquestração baseia-se na construção de processos de negócio a partir da composição de diversos serviços, por exemplo, utilizando uma linguagem de orquestração como o Web Services Business Process Execution Language (WS- BPEL) (OASIS WSBPEL TC, 2007). Trata-se de uma linguagem para se especificar o fluxo de trabalho e lógica de negócio envolvidos nas chamadas de Web Services. Nesta camada estão os serviços de processo, que possuem alta granularidade e representam processos de negócio completos, encapsulando a lógica e regras de negócio envolvidas.