SOA - Service Oriented Architecture

Fonte RMA Comunicação 13/03/2013 às 17h

Por Fernando Lunelli, gerente de Tecnologia da Teclógica*

Como reorganizar e compartilhar funcionalidades comuns entre as várias soluções específicas de cada área do negócio.

Projetos de software costumam contar com uma equipe com diferentes papéis, que vai desde gerente comercial à gestor de Medição e Análise. É fato que qualquer um destes papéis, mesmo não tendo responsabilidade direta sobre o assunto, já teve algum contato com o conceito de SOA - Service Oriented Architecture. Esta arquitetura tem sido aprovada, vislumbrada e referenciada sempre que uma solução é projetada, seja ela nova ou esteja em evolução.

A proposta de solucionar de forma madura e estável problemas como integração, reusabilidade, desacoplamento e escalabilidade, é muito atraente tanto do ponto de vista técnico quanto funcional. Porém, exige um estudo aprofundado sobre o ambiente em que a mesma será implementada, uma vez que, ao final, deve-se entregar uma composição de serviços que nada mais serão do que funcionalidades já existentes, porém reorganizadas de maneira a respeitar os padrões da arquitetura (SOA), compartilhando funcionalidades comuns entre as várias soluções específicas de cada área do negócio.

Durante a implementação desta arquitetura, que é orientada a serviços, deve-se justamente despender um tempo considerável na identificação destes serviços, a fim de alcançar o benefício efetivo proposto por SOA.

Dentre as várias técnicas e teorias de identificação de serviços, gostaria de expor um pequeno conjunto de boas práticas, ou ainda considerações a se fazer durante a execução desta atividade. Estas sugestões foram compiladas a partir dos trabalhos realizados em diferentes clientes e necessidades variadas.

Princípio da Simplicidade:

Da mesma forma que em definições de soluções quaisquer, sempre que algo torna-se complexo, a probabilidade de estarmos seguindo um caminho incorreto é alta. Na identificação de serviços em SOA esta filosofia também é válida, ou seja, não existem regras de identificação infalíveis ou ainda que atendam a todos os casos. Logo, é muito interessante partir de uma visão simplificada, e trabalhar com o fato de que as regras de identificação serão modificadas conforme a evolução e amadurecimento dos trabalhos.

Manter em mente o negócio e não os sistemas:

Identificação de serviços depende diretamente da análise da representação do negócio em forma de sistema. Sendo assim, é muito mais importante ter bons conhecimentos sobre o modelo de dados de cada solução envolvida na integração do que conhecimentos de implementação técnica da solução em questão. Por este motivo, esta etapa deve ser realizada sempre em conjunto com alguém que detenha o conhecimento dos requisitos funcionais e do modelo de dados da solução, uma vez que é neste contexto que estarão as informações mais úteis para definir quantos, quais, onde estão ou onde ficarão os serviços identificados. Torna-se então um tanto quanto óbvio, mas não pode-se deixar de comentar que uma modelagem de negócio (BPM) aplica-se perfeitamente como material de referência para a identificação de serviços.

Imitar os conceitos de DDD (Domain Driven Design):

Aproveitando o gancho de associação entre negócio, pessoas e responsabilidades sobre as informações, sugiro fortemente o reaproveitamento dos conceitos definidos pelos projetos orientados a domínio. Estes conceitos definem que um sistema deve ser construído definindo o domínio das informações que são de sua responsabilidade, e isolando completamente o acesso a estas informações. Desta forma, todo e qualquer acesso a este dado só pode ser feito pelo sistema definido e nenhuma informação é obtida, alterada ou excluída sem que seja através de funções disponíveis no sistema que domina o conhecimento de como manter tal informação. A principal característica de projetos que seguem estes conceitos é que, mesmo módulos dentro de um mesmo sistema devem implementar esta divisão de responsabilidade por domínio de informação.

Atribuição de Responsabilidades:

Na minha visão, a tarefa mais importante no processo de identificação de serviços é a atribuição de responsabilidades para cada um dos sistemas envolvidos. Isto é devido ao fato de que, a partir do momento em que identifica-se que um sistema é responsável por determinada informação, torna-se clara a necessidade de serviços que devem ser oferecidos para outros sistemas que façam uso desta informação. Ainda dentro da etapa de atribuição de responsabilidades, pode-se fazer a separação entre informações que são utilizadas somente para complemento do modelo interno do sistema e informações que devem ser compartilhadas entre os demais modelos pertencentes a outros domínios.

Concluindo, serviços podem ser identificados de maneira simplificada, uma vez que as informações necessárias para sua identificação já existem e devem apenas ser analisadas. Indiferente da estratégia adotada, este trabalho deve ser levado a sério pois ele é responsável por fazer o uso correto da estrutura de integração via serviços, ou seja, não faz nenhum sentido ter um barramento de serviços ótimo em termos técnicos, porém utilizado de maneira incorreta, com serviços mal definidos ou mal utilizados.

A identificação de serviços sempre deve ser feita por uma equipe e não por uma pessoa específica, uma vez que exige conhecimentos variados (técnicos, analíticos e de negócio). Os serviços identificados sofrem evolução contínua, conforme o amadurecimento das soluções que compõe os mesmos, e o crescimento do negócio que eles representam. Mesmo baseando-se em uma lista de passos, é necessário o estudo de cada situação a fim de descobrir necessidades específicas que venham a exigir uma estratégia diferenciada.

É importante lembrar ainda que esta é apenas uma sugestão para iniciar os trabalhos de identificação de serviços e implementação de uma arquitetura orientada a serviços. Se entrarmos em detalhes, descobriremos que existem normas para segregação de serviços.

Inicie com um projeto que ofereça menos risco, realize todo estudo da unidade de negócio e a implemente. Ao final, tire as lições aprendidas e aumente a complexidade na implementação do conceito.

*Fernando Lunelli, graduado em Ciências da Computação. Trabalha na área de TI desde 1996, onde teve oportunidade de atuar em praticamente todas as áreas envolvidas, iniciando com suporte técnico, evoluindo para a área de infraestrutura, administração de sistemas operacionais e banco de dados, onde participou de vários projetos em empresas multinacionais. Em 2007 seu foco de trabalho passou para a área de desenvolvimento de software, onde atuou como Arquiteto de Software em diferentes plataformas tecnológicas e clientes de vários ramos de atuação. De 2010 até agora, atua como gerente de tecnologia na Teclógica, gerenciando a área de Arquitetura de Software, Gerência de Configuração e Soluções Internas.

 

Sobre a Teclógica

Fundada há 18 anos, a Teclógica é uma empresa de gestão dos processos de TI e negócios comsoluções tecnológicas sob medida que garantem a operação e o crescimento sustentável de seus clientes. Seus principais serviços são Consultoria, Desenvolvimento de Sistemas e Gerenciamento de Aplicações, com certificações CMMi em cada uma destas áreas. A empresa também conta com uma área de produtos, cujos destaques são a Mobuss, uma plataforma projetada para facilitar a criação de aplicativos móveis, e o Mobuss Construção Civil. Localizada em Blumenau, no Estado de Santa Catarina, um dos dez maiores pólos de tecnologia do Brasil, a empresa conta com 200 funcionários e tem como missão entregar uma relação única de valor, garantida por um modelo de entrega diferenciado, por meio de conhecimento e aplicação das melhores práticas que permitem, aos seus clientes, a continuidade do negócio. www.teclogica.com.br

RMA Comunicação
Fonte RMA Comunicação 13/03/2013 ás 17h

Compartilhe

SOA - Service Oriented Architecture