Desde seus momentos embrionários, quando se confundia  com outros modelos proeminentes, a Arquitetura Orientada a Serviços – Service Oriented Architecture (SOA) tem se transformado para consolidar-se  como  uma  alternativa  arquitetônica  concreta, capaz de endereçar muitos  aspectos pendentes  de  evolução  nos modelos computacionais. A  essência  de  SOA se direciona  para  o suporte ao negócio e ao ser vista somente como recurso de integração, perde o fundamental de
sua contribuição.
 
O aspecto evolutivo de SOA é uma característica importante que deve ser evidenciada, pois muitos escritos de hoje ainda se baseiam em suas formulações iniciais, distantes daquilo que se consolida atualmente. A interpretação imprecisa desse grande cenário pode levar a um modelo de implementação insuficiente para explorar todo o potencial que SOA pode propiciar. Ocorrendo isto, o  resultado final acrescentará pouco àquilo que a organização já dispõe nomomento, gerando possível descrédito em sua adoção.
 
Em seu formato atual omodelo consolida algumas qualidades herdadas de modelos anteriores, especialmente os objetos distribuídos e componentes, como: distribuição, reutilização, contratos, aspecto modular, baixo acoplamento, capacidade de integração, etc. Sevista unicamente através destes aspectos – já  presente nos modelos anteriores - SOA acrescentará muito pouco, culminando com inevitável frustração. Se visto sob a perspectiva de negócio – aspecto que a consolida neste momento – SOA agregará valor sobre importantes questões que permaneciam em aberto nos modelos anteriores, tornando-a uma possibilidade de inovação concreta e representativa.

A  implementação  de  SOA  baseada  em  padrões,  incorporará  muitos  paradigmas  relevantes, notadamente aqueles em torno de Web Services. No flanco do apoio aos negócios, os padrões de
Business Process Management, apoiados por BPMN (Business Process Management Notation)  e
WS-BPEL  (Web Services – Business Process Execution Language), progressivamente dão maior
distinção para esse modelo em relação aos anteriores, com visível efeito de inovação direcionado
para as novas formas de negócio da organização.
 
Muitos movimentos de mercado podem confundir coisas antigas com as novidades dos modelos orientados a serviço. Um aspecto importante a ser notado é o de que as inovações em infraestrutura promovidas por SOA não são suficientes para suprir os quesitos de um modelo computacional completo. Por outro lado, não podemos confundi-las com os modelos anteriores, sob pena de atribuir-se a algo convencional um perfil de orientação para serviço que ele não tem.

Isto tem sido recorrente no jogo de mercado: Confundir SOA com modelos de baseados em mensagem  (Message  Oriented  Middleware) tem sido âncora para muitas proposições ditas orientadas a serviços. Essas propostas tendem a atribuir semântica nova para coisas que já existiam, distorcendo os fatos e frustrando expectativas.
 
Não  podemos também confundir modelos de integração com modelos orientados a  serviços. As implementação atuais dos ESB (Enterprise Service Bus) disponíveis no mercado, por exemplo, apóiam-se em modelos baseados em mensagem, já disponíveis há muitas décadas atrás. Outro aspecto importante a ser considerado  na adoção dos ESBs é o fato de que não são modelos padronizados. Introduzir um elemento proprietário no centro do modelo computacional, poderá tornar a empresa refém de algo difícil de remover.

Adotar SOA apenas como recurso de integração não acrescenta o resultado representativo que este modelo  pode nos dar, pois o essencial  foi deixado para trás. O empresário que adota um modelo  orientado a  serviço tem que exigir mais, explorando o fundamental de SOA: a efetiva inovação no tratamento dos negócios com TI.

As estratégias em modular, visando desacoplar e reutilizar, não podem desprezar os modelos de componentes, pois não será possível alcançar estes objetivos com tecnologias exclusivas de SOA. Se olharmos um pouco para  trás, vamos perceber que através de CORBA ou EJB encontramos
respostas  efetivas e maduras para modular a implementação da lógica de negócio em sua total dimensão, coisa impossível de se alcançar exclusivamente com Web Services.
 
Com o advento de SOA, acompanhado da maturidade de middlewares  como o JEE e .NET, o desenvolvimento baseado em componentes visando o aspecto modular e a reutilização têm sido revitalizados. Componentes não dependem de SOA, inversamente, porém, modelar a provisão de
serviços sem componentes pode ser um movimento circular que deixará a  empresa no mesmo lugar neste aspecto, sem melhorar as condições para efetivar a reutilização.
 
Os rumos de SOA dentro das organizações tem flutuado em função dos aspectos que moldam seu formato neste instante, desde os conceituais até os logísticos. A decisão sobre os caminhos que cada organização irá seguir demanda o domínio destas questões e carecem de cuidados especiais, suficientes para desviar-se das armadilhas de mercado e resguardar os interesses almejados. A melhor âncora para equilibrar este  jogo está na opção incondicional pelo uso de padrões de mercado bem estabelecidos e na ênfase à efetiva aproximação com os direcionadores
de negócio. Ao apoiar-se nos padrões, os princípios se fortalecem e a distinção entre o antigo e o novo fica mais evidente.  
 
O serviço é o elemento central deste novo cenário e sua semântica deve ser preservada, não se confundindo com as interpretações que tentam perpetuar modelos do passado. O modelo arquitetônico orientado a serviço deve representar flexibilização e inovação nas formas de negócio, influindo no front de atuação da empresa e dando efetivo suporte à competição na dinâmica dos mercados atuais. Isto é o fundamental que um modelo SOA deve nos dar.
 
* José Carlos Lazzeri é profissional da área de TI e autor do livro Arquitetura Orientada a Serviços – Fundamentos e Estratégias.