SOA e o legado

Em um "post" anterior eu comentei que a Camada de Serviços, não somente pelo seu nome, era a mais importante e essencial para um projeto SOA. Isso se deve a dois principais fatores:
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.
Enquanto a definição dos serviços necessita da participação intensa de analistas de negócio, a análise de "gap" normalmente é conduzida pelos arquitetos de tecnologia. Alguma coisa como: em um primeiro momento, os analistas de negócio são os principais responsáveis pelo recolhimento dos requerimentos de um serviços. Posteriormente, tais requerimentos são conduzidos pela equipe de tecnologia para a respectiva implementação. Neste ponto, uma das questões mais críticas é o "gap analysis" entre "o que se quer" (serviços) e "o que se tem" (legado).
A análise de "gap" deve ser considerado como ponto crucial na específicação e consequente implementação de um serviço. Infelizmente, é bastante comum verificar que tal análise não recebe a atenção e recursos necessários por parte da equipe de tecnologia que faz parte de um projeto SOA. Simplificações do assunto levam invarialmente a problemas críticos que necessariamente deverão ser corrigidos no futuro.
Poderiamos relatar algumas questões e problemas que nascem a partir de uma análise não completa do "gap":

• É comum ouvirmos que SOA adota muito mais a postura de "wrap and reuse" do que "rip and replace". Isto é, SOA deve tomar vantagens de capacidades já existentes da camada de sistemas legado em vez de reescreve-las. Contudo, é preciso não confundir um serviço como uma "webficação" de um legado. O fato de inserirmos uma "casca" Web Services em uma transação CICS, por exemplo, pode ser necessária mas absolutamente não será suficiente. Nunca é demais lembrar que um servíço deve ser responsável, além de questões funcionais, por requerimentos não funcionais. Diria que atender os requerimentos funcionais é muito mais simples que do implementar os não funcionais.
• A "webficação" tipicamente cria uma relação 1:1 com um aspecto funcional de um legado. O exemplo acima serve para isso. Tal relação é muito improvável: é bastante razoável imaginar que serviços dependerão de mais do que um legado para cumprir o seu papel funcional. A relação então seria 1:N. A definição de escopo funcional para cada legado não possui uma resposta simples. Eventualmente, encontramos duplicidade funcional dentre os sistemas do legado.
• Como se não fosse suficiente, dentre os requerimentos de um serviços encontraríamos por exemplo, disponibilidade 24x7, escalabilidade, etc. Igualmente fácil de imaginar que há sistemas do legado que não estão em condição de atender esses requerimentos. É insuficiente termos uma camada de ESBs suprindo tais demandas se um legado não acompanhá-la. A solução não é trivial: deveriamos evoluir o legado ou reescreve-lo? Qual o custo de cada decisão? Não há uma resposta única para todas essas perguntas.
• Em uma relação 1:N entre um serviço e os sistemas legado, é possível que tenhamos uma aplicação que atendam os requerimentos não funcionais e outras que não. Mais uma vez a resposta não é direta.

Por outro lado, processos de "webficação" de legado com relacionamento 1:1, podem ser (e normalmente são), o primeiro passo da implementação da camada de serviços em uma aproximação "bottom-up". Em outras palavras, a "webficação" de um aspecto funcional de um legado, acarreta na implementação do nível mais baixo de abstração da Camada de Serviços. Outros serviços (Integração, Negócio, etc) certamente, tirarão proveito da "webficação".
Outra questões importantes:

• Um projeto SOA deve implementar níveis de abstrações novos sobre a camada do legado. Apesar de tentar enfatizar o "wrap and reuse", é a melhor ocasião para descartar sistemas obsoletos que, historicamente, não atendem os requerimentos de seus usuários finais.
• Contudo, um projeto SOA não pode ter como principal responsabilidade a "modernização" do legado. Melhor seria se a modernização fosse considerada um "projeto derivado" ou um "subprojeto" dentro de um espectro maior. Em outras palavras, um projeto SOA não deve ser encarado primordialmente como a correção de problemas crônicos de aplicações já existentes.

Como conclusão direta: um processo formal para conduzir o ciclo de vida de um serviço se faz necessário.

SOA e SOI

No "post" anterior eu comentei sobre a hierarquia de serviços envolvendo Serviços de Negócio e Serviços de Integração. Nesta estrutura, que é a essência de SOA, há outras categorias de serviços como Serviços Externos e Serviços Utilitários. Contudo, mais uma vez para a implementação de SOA na sua plenitude, é importante que o projeto atinja o nível de abstração dos Serviços de Negócio.

Este objetivo só poderá ser atingida através de um esforço corporativo que envolve, inexoravelmente, unidades de negócio. Desnecessário dizer que tal movimento não é simples tampouco barato. É muito comum projetos SOA serem conduzidos pelos departamentos de tecnologias das empresas onde não há visibilidade ampla e profunda dos requerimentos de negócio, processos, etc das unidades e linhas de negócio da empresa.

Por conta disso, projetos SOA usualmente transformam-se em projetos SOI ou "Service Oriented Integration". Apesar de semelhantes as siglas não têm muito em comum: enquanto SOA é uma arquitetura de serviços de negócio, SOI é sobre integração de sistemas. Este termo é normalmente usado para denotar projetos de integração de sistemas que usam os mesmos protocolos usados na implementação de SOA (por exemplo, Web Services e Enterprise Service Bus (ESB)). SOI cumpre um papel similar à infraestrutura EAI ("Enterprise Application Integration") que projetos no passado lançavam mão. A diferença é o uso de tecnologias mais "modernas".

Dentro da hierarquia de serviços, teríamos uma linha sutil que distinguiria os serviços de alto nível de abstração (pertencentes ao projeto SOA) dos serviços de baixo nível (de responsabilidade do projeto SOI). Abaixo uma figura ilustrativa:

Várias fontes descrevem SOI em detalhes. Dentre elas destaco o livro "Service-Oriented Architecture - A Field Guide to Integrating XML and Web Services", primeiro de uma coleção importante de Thomas Erl e outros. Apesar de, durante a leitura, termos a impressão que SOA é implementável somente com a pilha de tecnologias Web Services, há referências que ressalvam que WS-* não são a única opção para isso.

O emprego das mesmas tecnologias para a implementação de ambos os projetos leva a mais uma confusão ou engano: projetos SOI são chamados de SOA. Entretanto, por outro lado, um projeto SOI pode ser considerado como um "entry point" para o projeto SOA que compreenderá outras diversas dimensões e requerimentos. Há várias vantagens para isso:

• Um projeto SOI é tipicamente conduzido pela equipe de TI da companhia posto que o envolvimento de analistas de negócio é muito improvável. As questões a serem resolvidas normalmente têm considerações puramente técnicas.
• O projeto SOI pode ser um "laboratório" importante para especialização sobre as tecnologias WS-*, ESB, etc. Afinal, em tese, essas mesmas tecnologias seriam usadas na implementação dos Serviços de Negócio.
• Liberdade de escolha de produtos: a infraestrutura usada para a implementação de Serviços de Integracão não é necessariamente a mesma usada para os Serviços de Negócio.
• A implementação dos Serviços de Integração pode ocorrer distintamente à dos Serviços de Negócio, diminuindo os riscos.
• As infraestruturas separadas permitem que o processo de evolução dos serviços seja altamente escalável.

Uma visão da infraestrutura de software poderia ser alguma coisa como:

Uma das principais diferenças entre os famosos ESBs e EAI é aquilo que David Chappell, Vice Presidente da Oracle para SOA, definiu no seu já classico "Enterprise Service Bus" de 2004, como "Distributed Integration" ou Integração Distribuída. O grande benefício dos ESBs é a capacidade de distribuir os seus requerimentos de integração. Instâncias isoladas de ESB são responsáveis por uma coleção específica de processos de integração. A figura acima mostra isso: o ESB de nível mais baixo de abstração é responsável por questões totalmente particulares de integração e distintas ao ESB de mais algo nível. Em termos de implantação os ESB podem ser (e normalmente são) de fornecedores diferentes e rodam em ambientes operacionais (Sistemas Operacionais, Hardware, etc) também específicos. Claro que, de acordo com a demanda, novas instâncias de ESB podem ser adicionadas em cada uma dessas camadas para novamente dividirmos responsabilidades de integração.

Como conclusão, a implementação de toda e qualquer demanda de integração em um único ESB, geralmente, não é um bom negócio. Em um ambiente crítico haverá um diversidade muito grande de classes de softwares e, para cada um deles, uma coleção de instâncias de ESBs. Uma aproximação como essa é antes de mais nada escalável e consequentemente apresenta menos riscos em todos os sentidos: desenvolvimento, gerenciamento, manutenção, produção, homologação, etc.

SOA e Web Services não são sinônimos

Um dos maiores enganos em torno de SOA é o seu tratamento como sinônimo para as tecnologias e padrões Web Services (leia-se SOAP, WSDL, UDDI, WS-*, etc).

SOA trata de arquitetura e desenho de serviços de negócio. Web Services são tipicamente a primeira escolha tecnólogica para a implementação de tais serviços. Além deles, há uma infinidade de opções como CORBA, RMI, DCOM, DCE, sockets, REST, etc. Algumas não são mais usadas mas o ponto é que a escolha tecnológica para a implementação de SOA não é uma das responsabilidades em si de um projeto como esse.

Várias analogias existem: Modelos Entidade-Relacionamento - MER de Peter Chen (ou "Entity-Relationship Models" - ERM em Inglês) para representação lógica de dados e informações não definem qual a tecnologia de banco de dados será aplicada para a implementação. Usualmente, Gerenciadores de Bancos de Dados Relacionais são empregados por permitirem a implementação mais direta da lógica definida nos modelos. Entretanto quaisquer outras tecnologias poderiam ser usadas como Hierárquica, Rede, arquivos, XML, etc, etc.

O mesmo acontece com a especificação de programas. Um algoritmo não pressupõe o uso de nenhuma linguagem para a sua implantação. Seja ela Java, C#, Pascal, Cobol, etc.

Então, em resumo: SOA pode ser implementado sem Web Services. Web Services podem ser usados em projetos que não sejam de SOA.

Outro ponto a considerar é o seguinte: o uso de Java, C++ ou qualquer outra linguagem de programação não resulta em programas "orientados a objetos". É preciso que tenhamos bons desenhos de programas orientados a objetos. Mais uma vez a analogia procede: o simples uso de Web Services não implica necessariamente em Arquitetura Orientadas a Serviços. Muitas arquiteturas serão construídas com Web Services e não serão "orientadas a serviços" pelo mero fato de terem sido mal desenhadas.

O uso (e consequente confusão) de Web Services para a construção de "serviços" talvez tenha como base a maior facilidade, flexibilidade, etc proporcinadas por esta tecnologia em relação a outras. Afinal o "S" de SOAP quer dizer "simple"... Todavia os atributos de "simples" e "fáceis" para os Web Services têm sido questionados. Richard Monson-Haefel, em 22 de Abril de 2006, postou em seu "blog" o já classico "Dave Podnar’s 5 Stages of Dealing with Web Services". Reproduzo os cinco estágios no original em Inglês:

1. Denial - It’s Simple Object Access Protocol, right?
2. Over Involvement - OK, I’ll read the SOAP, WSDL, WS-I BP, JAX-RPC, SAAJ, JAX-P,… specs. next, I’ll check the Wiki and finally follow an example showing service and client sides.
3. Anger - I can’t believe those #$%&*@s made it so difficult!
4. Guilt - Everyone is using Web Services, it must be me, I must be missing something.
5. Acceptance - It is what it is, Web Services aren’t simple or easy.

Tecnologias como REST prometem "simplificar" de verdade o desenvolvimento. Isso fica prá outro "post"...
Outra típica confusão instaurada está relacionada ao Modelo de Implementação de Serviços baseado em "find-bind-execute". Abaixo temos uma figura ilustrativa.

Funciona mais ou menos assim:

1. Provedores registram seus serviços em um repositório público.
2. Consumidores procuram no repositório serviços que satisfaçam seus requerimentos.
3. Os repositórios fornecem aos consumidores o “contrato” para o uso do serviço.
4. Consumidores usam o “contrato” para interagir com o provedor.

O engano acontece imaginando que este modelo seja particular aos Web Services. Na realidade, é o contrário: os Web Services são mais uma tecnologia que também segue este paradigma. CORBA, por exemplo, baseia-se neste mesmo princípio. Em última análise, o conceito de "contrato" sendo exposto a consumidores permeia quase todas as tecnologias existentes. Um arquivo ".h" na linguagem C é um contrato sobre as funções expostas por uma biblioteca. A "novidade" em Web Services talvez seja a publicação dos contratos em servidores específicos.

Enfim, enfatizando, SOA não é sobre tecnologia. É uma arquitetura. Anne Thomas Manes, diretora de pesquisa do Burton Group escreveu em 2007 um "post" em seu "blog" chamado "When Technology Matters in SOA" que resume muito bem a questão.

SOA, acoplamento e coesão

Um das principais qualidades de um serviço de negócio deve ser o baixo acoplamento em relação a outros serviços. Este é um das mais importante características de SOA e que deve ser buscada na especificação e desenvolvimento dos serviços de negócio.

Apesar de parecerem novos, na realidade, os conceitos de acoplamento ("coupling") e coesão ("cohesion") aplicados na Ciência da Computação são bastante antigos. Os primeiros a formalizarem tais conceitos foram Edward Yourdon e Larry Constantine em seu clássico e seminal livro "Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design" de 1977.

No glossário de termos do livro Yourdon e Constantine conceituam coesão ("cohesion") como: "The degree of functional relatedness of processing elements within a single module", ou o grau de conexão funcional de elementos de processamento no interior de um módulo. Já acoplamento ("coupling") é definido como segue: "a measure of the strength of interconnection between one module and another" ou uma medida da força de interconexão entre um módulo e outro.

As noções de acoplamento e coesão estão intimamente relacionadas. Um módulo com alto grau de coesão possui um baixo grau de acoplamento e vice-versa. Um dos indicativos de bom desenho de um programa é a alta coesão de suas rotinas e o baixo acoplamento entre as rotinas. Programas com estas características tendem a ter um menor custo para manutenção, evolução, etc. Nos capítulos 6 e 7, Constantine e Yourdon descrevem métricas para a classificação dos graus de acoplamento e coesão.

Estes conceitos são aplicáveis universalmente em quaisquer ambientes computacionais. Uma classe de um programa orientado a objetos é justamente um pedaço de código com alto nível de coesão e baixo nível de acoplamento em relação a outras classes.

Em SOA, a diferença está, mais uma vez, no nível de abstração onde tais conceitos são usados. Enquanto o contexto de discussão de Yourdon e Constantine são subrotinas e módulos de um programa, SOA emprega estas mesmas noções entre sistemas. É claro que, se baixo acoplamento e alta coesão são objetivos a serem perseguidos em programas, em SOA esta importância aumenta sobremaneira em relação aos Serviços de Negócio. Basta lembrar que em SOA o ponto de discussão não é mais em relação a subrotinas, módulos, componentes ou classes mas sim entre sistemas corporativos de uma companhia. Alguns Serviços de Negócio se apoiarão no sistema ERP, outros terão como base aplicações em "mainframe", etc.

Como conclusão, não é exagero dizer que a implementação de Arquitetura de Serviços consiste no conjunto de todas as melhores práticas e conceitos para o desenvolvimento de aplicações acumulados nos últimos 40 anos. Coesão e acoplamento são somente alguns destes conceitos.

Afinal, o que é um Serviço?

Acredito que a extrema diversidade dos conceitos sobre SOA advém, dentre várias razões, de termos muito genéricos que as palavras que formam a sigla contém.
Arquitetura Orientada a Serviços. As palavras "Arquitetura" e "Serviço" são muito genéricas. Podem ser usadas para denotar uma infinidade de coisas.
Eu explorei a semântica de "Arquitetura" em SOA anteriormente. Mas o que são os "Servíços" de SOA?
Acho que uma boa definição é: "Um serviço responde por requisições através de interfaces bem definidas, padronizadas e publicadas." Uma outra: "É um componente auto-contido que implementa funcionalidades de negócio com um conjunto extenso de aspectos não funcionais".
Um diagrama exibe melhor a questão:

Como comentado anteriormente, a especificação lógica (ou requerimento) funcional de um serviço de negócio deve ser conduzida por analistas de negócios. São eles que conhecem mais profunda e amplamente as necessidades da empresa e são deles que partem as demandas por novos serviços.
Por outro lado, mesmo tendo a sua complexidade, a funcionalidade de um serviço não é nada comparada com os requerimentos não funcionais do mesmo. Alguns deles:

• Performance: garantir o número de mensagens processadas em um período de tempo
• Tempo de vida
• Bilhetagem sobre o uso
• Monitoração: Métricas, Relatórios, etc.
  
• Segurança: autenticação e autorização
• Tempo de recuperação em caso de falha
• “Compliance” e regulamentações

Não é difícil encontrar situações onde estes aspectos não funcionais são inseridos em termos contratuais para a comercialização de serviços de negócio. Portanto, a observação destas questões não deve ser vista como um "luxo" mas sim como requerimentos reais do negócio.
A coleção destas especificações funcionais e não funcionais é chamada de metadados dos serviços. Um "contrato" onde são definidos como o serviço deveria funcionar e como o serviço deveria se comportar.
Um parêntese para a tecnologia hoje disponível para os "contratos": o padrão WSDL ("Web Services Description Language") é comumente invocado. Entretanto é insuficiente para declararmos todos os aspectos do contrato. Normalmente há o uso em conjunto do WSDL com XML Schema para definição de formato de mensagens e WS-Policy para definição de capacidades do serviços.

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.