A estrutura de uma Arquitetura Orientada a Serviços

Para tornar o entendimento de SOA mais didático, invarialmente, apresentamos uma estrutura como a da figura abaixo. Diversas variantes são também possíveis mas os níveis de detalhes são bem próximos. A figura é aplicada para a indústria de Telecomunicações.

Uma sucinta descrição das camadas:

1. Camada de Recurso e Dados (legado): é a coleção atual dos sistemas, aplicações, bases de dados, etc de uma empresa.
2. Camada de Serviço: conjunto de serviços de negócio. Note que os exemplos foram "Detecção de Fraude", "Aprovisionamento", etc. Não há menção a "transações CICS" ou "importação de arquivos XML", por exemplo.
3. Camada de Processo: implementa os processos de negócio através da invocação dos serviços da camada de serviço. Tipicamente implementada por projeto de BPM.
4. Camada de Apresentação e Acesso: permite que usuários finais façam uso tantos dos processos como dos serviços de negócio.

Pode parecer óbvio mas para um projeto SOA, a camada mais importante da figura é a de Serviços. Não somente pelo nome "Serviços" mas por um simples motivo: é esta camada, e só ela, que é o resultante do projeto SOA.

Diria que esta camada possui pelo menos dois aspectos de alta complexidade:

a) A definição dos serviços desta camada.

b) O "gap" tecnológico (funcional e não funcional) entre ela e a Camada de Recurso e Dados.

Este "post" trata sobre o primeiro aspecto.

Se fizermos um "zoom" na Camada de Serviços poderemos encontrar algo mais ou menos assim:

A figura acima foi adaptada do livro "Applied SOA: Service-Oriented Architecture and Design Strategies" (pág. 58) de Michael Rosen e outros.

Todos os serviços da figura estão contidos logicamente na Camada de Serviço em uma estrutura hierárquica. Há serviços de baixo nível de abstração ("Serviços de Integração") e de alto nível de abstração ("Serviços de Negócio"). Nota-se então que um Serviço de Negócio faz uso do legado existente através de uma invocação indireta.

A concepção desta hierarquia de serviços deve ser o "projeto SOA" de uma determinada companhia. Várias questões devem ser consideradas: Quais são os serviços? Como eles se relacionam? Qual o impacto ocasionado em um serviço quando da definição de um novo serviço? Suas funcionalidades e qualidades sistêmicas (escalabilidade, segurança, disponibilidade) serão suficientes para atender as demandas dos seus consumidores? Quais pessoas devem ser envolvidas para a especificação de um serviço?

Tipicamente os chamados "Serviços de Integração" têm nível de abstração baixo em relação aos requerimentos de negócio e necessitam de uma especificação técnica mais apurada em relação às tecnologias existentes e as que serão empregadas. Por este motivo, é improvável que precisemos envolver analistas de negócio neste ponto. Todavia, estes analistas possuem não somente conhecimento mas senso de demanda e criticidade a respeito dos "Serviços de Negócio".

Enfim, o tratamento de questões como essa é que qualificam um projeto como SOA. Mais uma vez as escolhas tecnológicas para a sua implementação são um problema posterior.

SOA não pode ser um fim em si mesmo

A concepção de coisas como SOA não tem objetivo diferente daquele de qualquer outra tecnologia: atender alguma necessidade corporativa. Seja ela reduzir custos através do reaproveitamente de funcionalidades já existentes em aplicações legadas, implementação de federações de empresas para ofertas de novos produtos e serviços, etc, etc, etc. A construção de uma arquitetura de servíços, em tese, auxilia, e muito, a materialização das respostas a destas demandas.

A questão principal é que um projeto SOA deve ter um propósito. E não pode ser tecnológico. SOA deve ser construído para atingir algum objetivo de negócio de uma companhia.

SOA é uma arquitetura de serviços de negócios. Um serviço de negócio é aquele com a maior afinidade possível com os requerimentos de uma empresa. Este é o nível de abstração que um projeto de Arquitetura Orientada a Serviços deve atingir. Caso contrário poderíamos chamar tal projeto de integração de sistemas ou de qualquer outro nome. Menos de SOA.

E um projeto para a elaboração e construção de SOA deverá não somente entender o quão complexo são os temas pertinentes ao negócio da companhia como deverá também desenhar e modelar os seus serviços. Identificá-los. Especificá-los. Definir o seu relacionamento.
Este projeto, então, deveria contar com a participação de profissionais que entendem as necessidades do negócio da companhia e, mais importante ainda, percebem e requerem novas qualidades e funcionalidades. Daí outra observação: é bastante difícil a definição e implementação de uma Arquitetura de Serviços sem a presença de profissionais que entendem os temas não somente da indústria à qual a empresa trabalha como as especializações necessárias à empresa em questão. Em outras palavras: para implementar SOA na sua plenitude é necessário que façam parte do projeto analistas de negócio que não somente entendem requerimentos de indústria como os seus detalhes dentro da companhia. O serviço de "Convergent Billing" não é somente específico à indústria de telecomunicações mas também difere entre as empresas deste mercado.

A máxima "SOA promove o alinhamento entre TI e áreas de negócio" tem sido repetida exaustivamente nos últimos anos. Acredito que o correto seja sutilmente diferente mas que produz objetivos bem distintos: "O alinhamento entre TI e áreas de negócio é que promoverá SOA".
 Igualmente importante é a noção que SOA não é a resposta ideal para todos os problemas. A propósito, atualmente, muito se fala sobre "soluções" de tecnologia para negócio. É necessário que notemos que a palavra "solução" carrega, intrinsecamente, um problema a ser resolvido. Para apresentar uma "solução", seja ela qual for, é necessário que saibamos, antes de tudo, qual o problema que se apresenta.
O mesmo vale para SOA: há situações onde simplesmente SOA não é a melhor solução, ou ainda pior, uma solução ruim. Jason Bloomberg, analista do ZapThink um dos autores junto com Ronald Schmelzer do livro "Service Orient or Be Doomed!: How Service Orientation Will Change Your Business",  escreveu em 2004 um artigo chamado "When Not to Use an SOA" sobre este tema. Recomendo não somente a leitura do artigo mas também o registro no "site".

Impressões iniciais sobre Arquitetura Orientada a Serviços

Acredito que SOA tenha sido um dos termos de uso mais abrangente em termos de tecnologia empregada a negócios nos últimos anos. Há atualmente uma diversidade de interpretações que, usualmente, levam a confusões. Para tentar esclarecer o tema, poderia dividir alguns comentários em dois grupos:

• O que não é SOA
• O que é SOA.

O Que Não É SOA:

• SOA não é software, ESB (Enterprise Service Bus), Web Services, Middleware, etc. De fato, questões tecnológicas como essas são importantes, mas não essenciais quando falamos de um projeto SOA. O uso de Web Services, por exemplo, é meramente uma escolha tecnológica para a implementação de um projeto SOA.
• SOA não é Integração de Sistemas. Projetos de integração de sistemas pretendem resolver problemas de baixo nível de abstração e relacionados a questões tecnológicas. Por exemplo: exposição de transações CICS em mainframe para outros ambientes, importação/exportação de dados em sistemas ERP, etc. Tipicamente, projetos SOA, para sua melhor implementação, fazem uso da infraestrutura de integração oferecida. Em outras palavras, projetos SOA presumem que a infraestrutura de integração já exista e esteja operando. Caso não exista, um projeto SOA pode (e deve) levar ao início de um novo projeto (ou subprojeto) de integração de sistemas.

O Que É SOA:

• SOA (como a sigla indica) é uma arquitetura. Simples assim. Nem mais, nem menos. Entretanto não é uma arquitetura de hardware, software, tampouco de rede. É uma arquitetura de Serviços de Negócio. Para definirmos um Serviço de Negócio é importante considerarmos o contexto onde ele está inserido. No mercado financeiro, alguns exemplos de Serviços de Negócio são: Cálculo de Juros, Análise de Risco, Transferência de Valores, etc. Já na indústria de Telecomunicações temos "Fulfillment", Aprovisionamento, etc.

Um projeto SOA, então, deve ser responsável por diversos aspectos como, por exemplo:

• Identificação de Serviços de Negócio. Os exemplos citados acima são simples e óbvios. Certamente há uma quantidade considerável de outros Serviços de Negócio que existem nas companhias e que necessitam ser identificados.
• Relacionamento entre Serviços de Negócio. Este aspecto deve especificar como os Serviços de Negócio interagem entre si, quais os domínios de Serviços de Negócio existentes, etc.
• Uso da infraestrutura tecnológica existente. Aqui sim haverá uma análise de "gap" entre os requerimentos dos Serviços de Negócio e o conjunto tecnológico existente na companhia (leia-se legado). Este "gap" não é uma tarefa simples pois deve considerar não somente os requerimentos funcionais dos Serviços de Negócio mas também os não-funcionais ou níveis de serviços como escalabilidade, disponibilidade, segurança, etc. Deste modo, por exemplo, pode-se imaginar que seja requerido que um Serviço de Negócio tenha característica de disponibilidade 24x7 e que, entretanto, os sistemas legado, usados por este Serviço não tenham sido construídos para atender esse requerimento.

Como conclusão, é importante que projetos de SOA não sejam considerados um fim, mas um meio. O fim deve ser, necessariamente, a melhoria do negócio da companhia através de maior agilidade, redução de custos, eventuais novas linhas de receita, etc

Sobre este blog

"Living is easy with eyes closed, misunderstanding all you see." - John Lennon


SOA é uma daquelas coisas que encontramos onde o entendimento é simples mas a construção é complexa. Assim como ter filhos. Por razões diversas, durante anos, ocorreram (e ainda ocorrem) várias tentativas para a simplificação do tema. Acredito que a mais danosa tenha sido reduzir a discussão ao processo de aquisição de produtos. Alguma coisa como "dê-me um ESB e eu moverei o mundo". A vida parece mais fácil quando adotamos modelos reducionistas.

Entretanto, da mesma forma que a cura do câncer não pode ser reduzida à mera aquisição de aparelhos de radioterapia, a definição e o desenvolvimento de uma Arquitetura de Serviços não podem ser encarados como um resultado da compra de um software.

É sobre isso que este blog procura discutir: Arquiteturas Orientadas a Serviços pós-modismos e pós-"hype".

Claudio Acquaviva
Formado em Ciencia da Computação pela Unicamp em 1985, atua como Arquiteto de Software da Oracle desde 2010, fazendo parte da equipe de Arquitetura Corporativa da empresa. Sua atuação concentra-se em dois grandes temas: SOA e IAM ("Identity and Access Management"). Com mais de 20 anos de experiencia, trabalhou em empresas como Informix, Siebel, BroadVision e Sun Microsystems.