Eserin Muhtevâsı

Um padrão fornece uma solução comprovada para um problema comum documentado individualmente num formato consistente, geralmente como parte de um conjunto maior. A solução fornecida por um determinado padrão pode não representar necessariamente a única solução adequada para o problema. Na verdade, pode haver padrões que fornecem soluções alternativas para o mesmo problema. Tendo em vista que cada solução terá suas próprias exigências e consequências, cabe ao profissional escolher a solução. O padrão é parte fundamental da vida cotidiana, soluções comprovadas já são utilizadas para solucionar problemas comuns. Porém, quando os padrões são relacionados especificamente a sistemas automatizados, estes são denominados Padrões de Projeto (ERL, 2009a).

Segundo Erl (2009a), os padrões de projeto são úteis devido às seguintes razões: representam soluções testadas para problemas de projeto comuns; organizam a inteligência do projeto em um formato normalizado e que pode facilmente ser referenciado; são geralmente repetíveis pela maioria dos profissionais de TIC envolvidos com projeto; podem ser usados para garantir a consistência na forma como os sistemas são projetados e construídos, podem se tornar a base para normas de projeto; são usualmente flexíveis e opcionais; podem ser utilizados como apoio para o ensino por meio da documentação dos aspectos específicos de projeto de sistema; e podem ser apoiados por meio da aplicação de outros padrões de projeto que fazem parte da mesma coleção.

Embora os padrões de projeto forneçam soluções de projetos que já foram previamente validadas, sua simples utilização não garante que os problemas de projeto sejam sempre resolvidos. Conforme Erl (2009a), muitos fatores pesam para o êxito do uso de padrões de projeto, incluindo restrições impostas pelo ambiente de implementação, a competência dos profissionais, divergências nos requisitos de negócios e assim por diante. Todos eles representam aspectos que influenciam o grau em que padrões podem ser aplicados com sucesso.

Dentre estes, são destacados alguns importantes para o estudo apresentado neste trabalho: padrão composto representa um padrão de alta granularidade, composto por um conjunto de padrões com granularidade baixa; e catálogo de padrões de

projeto uma coleção documentada de padrões de projeto relacionados.

A orientação a serviços tem suas origens em projetos de plataformas de computação distribuída. Muitos padrões de projeto SOA têm suas origens e são influenciados pelos conceitos e abordagens de projeto e pelos padrões de projeto já estabelecidos. Conforme ilustrado na Figura 10, os padrões de projeto de SOA são influenciados pelos padrões de projeto das áreas: orientação a objeto, Enterprise Application Integration (EAI), arquitetura de aplicação empresarial e arquitetura de software. Esses padrões de certa forma são influenciados pela linguagem de padrões original criada por Alexander et al. (1977).

Figura 10:As influências primárias de padrões de projeto SOA

Fonte: Adaptado de Erl (2009a)

Os padrões discutidos por Alexander et al. (1977) são oriundos da construção civil, com o objetivo de registrar soluções comuns observadas em diferentes projetos arquitetônicos. Os padrões relacionados à arquitetura e áreas afins foram organizados em uma série pré-definida chamada "sequência", e o resultado foi uma linguagem arquitetônica de padrões que inspirou a comunidade de TIC a criar seus próprios padrões para o projeto de sistemas automatizados. Alexander defende também a importância da clareza da documentação dos catálogos de padrões.

Os padrões de projeto orientados a objetos contribuíram para consolidar a orientação a objetos. Os padrões de projeto estabelecidos na orientação a objetos são a base de alguns dos padrões no catálogo de padrões de projeto SOA.

Os padrões de arquitetura de software definem seus subsistemas, especificando suas responsabilidades, regras e orientações para a organização dos

relacionamentos entre os subsistemas (BUSCHMANN et al., 1996). Um exemplo de padrão arquitetural é o Model-View-Controller.

Após a computação distribuída ter se tornado uma plataforma estabelecida para o projeto de soluções, foi concebido um conjunto de padrões arquiteturais corporativos, muitos dos quais foram construídos sobre os conceitos e padrões orientados a objetos. Pelo fato da orientação a serviços ser um paradigma de projeto para computação distribuída, ela tem como base os padrões e conceitos fundamentais relacionados à arquitetura de aplicação corporativa em geral. Fowler (2006) publicou um catálogo de padrões para arquiteturas de aplicações corporativas, no qual apresenta padrões para decompor aplicações corporativas em camadas. São apresentados padrões relacionados à lógica de domínio, fontes de dados, apresentação Web, entre outros.

Catálogos de padrões trataram o uso de mensagens para cumprir os requisitos de integração originados durante a era EAI. Portanto, a orientação à mensagem da EAI é outra forte influência observada na orientação a serviços. Entre os padrões de projeto SOA propostos por Erl (2009a), existem padrões de interação de serviços com base na utilização de mensagens, para, principalmente, apoiar cenários de composição de serviços.

A coleção de padrões de projeto SOA, proposta por Erl (2009a), representa soluções para problemas encontrados na definição, implementação e catalogação de serviços. Esses padrões são agrupados nas seguintes categorias:

• Padrões de projeto de inventário de serviços, • Padrões de projeto de serviços e

• Padrões de projeto de composição de serviços.

Os padrões de projeto de inventário de serviços são relacionados ao escopo, estrutura e padronização de inventário. São 24 padrões de projeto de inventários de serviços, dentre estes, os padrões mais relacionados a esta pesquisa são: Normalização de Serviços, Centralização de Lógica e Camadas de Serviços. O padrão Normalização de Serviços estabelece que serviços diferentes não devem ter sobreposição de limites funcionais, ou seja, não devem conter lógicas semelhantes. O padrão Camadas de Serviços estabelece a necessidade de definição de camadas de serviços no inventário de serviços. Para classificar os serviços em camadas, Erl (2009a) propõe os tipos de serviços Tarefa, Entidade e Utilitário, conforme descrito na Seção 2.2.1.

de serviços. São 31 padrões de serviços, dentre estes os mais relacionados ao tema desta pesquisa são: Decomposição Funcional e Encapsulamento de Serviço. O padrão Decomposição Funcional estabelece que um grande problema de negócio deve ser decomposto em problemas menores para que estes possam ser resolvidos por um serviço específico.

Os padrões de projeto de composição de serviços fornecem os meios para montar e compor a lógica de serviço que foi decomposta, particionada, e simplificada por meio da aplicação de padrões estabelecidos na categoria padrões de projeto de serviços. São apresentados 23 padrões de composição de serviços, sendo que os mais relacionados ao tema desta pesquisa são os padrões: Composição da Capacidade e Recomposição da Capacidade. O padrão Composição da Capacidade estabelece que quando um serviço necessita acesso à lógica fora do seu contexto, esta lógica, deve ser consumida na forma de composição. O padrão Recomposição da Capacidade estabelece que uma capacidade deve ser projetada para ser reutilizada em composições de serviços e assim, aumentar o potencial de reutilização da lógica.

Embora os padrões e os princípios de projeto forneçam orientação de projeto visando alcançar os objetivos estratégicos de SOA, a relação entre os princípios de projeto SOA (descritos na Seção 2.2.2) e os padrões de projeto SOA (descritos nesta seção) pode ser sintetizada da seguinte forma: enquanto os princípios são diretrizes altamente recomendáveis para dar forma à lógica da solução orientada a serviços e podem ser aplicados coletivamente, os padrões de projeto fornecem solução para problemas comuns encontrados durante a aplicação de princípios de projeto orientado a serviços. Os padrões de projeto podem ser vistos como fornecedores de suporte para a realização dos princípios de projeto e seus objetivos associados.