Serviços em SOA

Quando falamos de SOA é inevitável falar de Serviços. Eles são a base
de SOA e na indústria de software existe grande confusão e discórdia
sobre esse assunto. Vou falar qual é a minha perspectiva
sobre o assunto, vou comentar o que eu considero um serviço e o que eu
não considero um serviço.

Também vou falar sobre os tipos de
serviços e como podemos implementar cada um deles, neste ponto existe
bastante confusão e, o pior, existe uma forte junção disto ferramental e
soluções prioritárias, comentarei isso mais para frente.

O que é um Serviço?

Tentando Desenvolver um Serviço?

Essa
é um pergunta simples mas nem sempre você vai ouvir uma resposta
simples. Existe muita discórdia sobre o que é ou o que não é um
Serviço. Para mim, um serviço é:

• alguma funcionalidade de negócio que foi implementada e pode ser acessada por vários sistemas.

Segundo
as minhas crenças, um serviço não precisa ser necessariamente
reaproveitável, pois você pode ter várias funcionalidades de negócio
que só servem a um sistema, quanto mais reaproveitável melhor, nisso
que SOA esta fundada, no reaproveitamento, porém não é um regra.

Outra
questão relativa a serviços é quanto ao acesso. No meu ponto de vista
o serviço tem que ser acessível por outro sistema, não interessa se
isso será feito por um webservice, EJB, RMI, Sockets, HTTP ou até mesmo
por um arquivo texto. Porque a partir do que o serviço expõe vamos ter
um contrato, esse contrato pode ser estabelecido até por um método
Java, o importante é que isso possa ser acessível por outros sistemas. Se você não consegue reutilizar o que escreveu, não tem serviços.

Novamente
quero deixar bem claro o fato de que isso varia de acordo com o caso. Em SOA você terá sistemas comuns que podem não ter serviço e isso não é
necessariamente errado. Você tem que lidar com componentes e rotinas de
nível mais baixo, um serviço é um abstração de alto nível e nem sempre
é um para um.

Serviços um para um?

Imagine
que você vai desenvolver os serviços de um sistema em Java. Não pense
que necessariamente uma classe Java vai ser um serviço. Em alguns casos
isso pode ser verdade, mas na maioria não será, porque em SOA é quase
impossível lidarmos com a homogeneidade – os sistemas são heterogêneos,
porque envolvem diversas linguagens, fornecedores, plataformas, sos,
etc.

Esse assunto acaba levando a outro assunto: os tipos
de serviços. Existem alguns tipos de serviços, nesse ponto vou falar da
relação disso com BPEL. Podemos classificar os serviços de acordo com a
sua empresa e os seus sistemas, mas, falando de um modo geral, podemos
falar de 3 tipos de serviços, são eles:

• Serviços Básicos
• Serviços Compostos
• Serviços de Processos

Serviços compostos – usam outros serviços para atender/conseguir fazer o seu propósito, é comum ter um mix destes dois tipos de serviços.

Serviços de Processos –
aqui o bicho pega. Na verdade, serviços de processos podem ser
implementados em Java ou em qualquer linguagem de programação. Mas
existe uma vertente em SOA que insiste que isso deve ser feito com
BPEL. Você pode fazer isso, desde que saiba o custo e o que vai
acontecer se você utilizar BPEL, quando você pode ter gastado
muito esforço e recursos em BPEL para um ganho muito pequeno e pior
ainda pode ter sérios problemas de performance.

Serviços de
processos podem usar serviços básicos e serviços compostos. Normalmente
os serviços de processo estão em nível mais alto do que os outros dois
tipos e, bem como disse, podem ou não ser implementados com BPEL.

E os Componentes?

Existe
outra vertente forte que é a favor do SCA e outros são contra, alguns
confundem JBI com SCA, mas uma coisa não tem nada a ver com a outra. SCA
é um modelo de componentes que serve para definir a relação de serviços
e componentes e para muitos isso fere a definição de SOA.

Você
pode usar SCA, mas a portabilidade também não é garantida. Na prática
tudo o que você faria com SCA pode fazer com Spring, muito mais fácil e
simples. Mas você tem que ter componentes e ter rotinas reaproveitáveis
– os famosos úteis. Os serviços podem utilizar esses componentes, mas
cuidado para não chamar isso de serviço.

Lembrando que o serviço
tem que ser visível ao negócio, você tem que tomar cuidado para não
confundir um componente com um serviço. De um modo geral, pense em
negócio quando falamos de serviços e pense em infra e arquitetura
quando falamos de componentes.

Chamar componentes de infra de
serviços pode gerar muita confusão com o pessoal do negócio e complicar
a sua adoção de SOA, então procure diferenciar o que é infraestrutura
do que é negócio.

Separando Infra do Negócio

Ainda
pensando que vamos implementar os serviços em Java, como poderíamos
fazer essa separação? A resposta é simples: interfaces. Você deve usar
interfaces em Java como contratos, que por sinal podem ser usadas em
Webservices. Mas o mais importante e o que eu nunca vi ninguém no
mercado fazer: Design de jars.

Você tem que modelar os módulos
da sua aplicação em componentes, separando os módulos por
responsabilidades. O apache maven 2 ajuda muito nisso, mas tudo pode ser
feito com diagramas da UML. O problema é que ninguém faz esse tipo de
design. E logo as coisas começam a ficar acopladas, misturadas,
bagunçadas e aí serviços acabam por se misturar por código de
arquitetura e infra, e a bagunça está feita.

Onde ficam os Serviços?

Essa
é uma questão hilariante, muitos gerentes falam de SOA hoje em dia,
porém poucos falam onde os serviços vão ficar, acho que o pessoal
pensa que os serviços vão ficar no limbo e que essa questão não importa
tanto. A questão aqui é simples.

Serviços não ficam no limbo,
eles vão estar dentro de uma aplicação, dentro de um container JEE,
dentro de um contexto do Spring publicado em uma aplicação JSE, etc.
Isso é importante porque você tem que saber que serviços têm que
se preocupar com transação e principalmente com segurança.

Essa
questão é deixada de lado porque existem muitos arquitetos que, ao
falar de SOA, apenas WS surge na cabeça deles como forma de implementação. Esse é um
erro comum e que vai dar dor de cabeça quando percebe-se que nem
tudo pode ser feito com Webservices porque não compensa, ou porque não
se paga o custo, ou porque o sistema é muito velho e não tem esse
recurso.

E a transação…

Sou
obrigado a falar de transação com Serviços, vamos por partes. Transação
local no mesmo sistema pode ser utilizada sem problemas, porque a
principio não será um gargalo mas, como disse antes, depende muito do
sistema.

Agora o problema é que ainda vejo arquitetos falando de
transação distribuída com SOA e isso é um grande problema. O Comitê de
duas fases é um inimigo da performance, sistemas distribuídos têm
problemas para escalar com transações distribuídas, e tem mais: nem
sempre você pode ter isso, porque nem todos os recursos são
transacionados, o pessoal se esquece disso 🙂

Transação distribuída em ambientes heterogêneos envolvendo várias linguagens e plataformas, hahahahahaha que piada. 🙂

Em
SOA, a abordagem padrão para isso é a Compensação. Eu já utilizei essa
abordagem com BPEL sem problemas, então basicamente pode-se fazer dois
tipos de compensação.

No primeiro tipo, o sistema chamador tem
que dar um jeito de corrigir os dados inconsistentes no outro sistema. Isso pode ser feito pela invocação de rotinas, componentes genéricos
que apagam dados no sistema com inconsistências.

No segundo tipo,
o usuário corrige essas inconsistências. Teve um sistema que fiz onde
de um lado existia um sistema Java com Spring e Hibernate, que falava
através de uma fila JMS, e do outro lado um sistema clipper que falava
através de arquivos texto. Com BPEL foi gerado uma Human Task para
apresentar os problemas ao usuário para ele corrigir.

Por
default, não sou contra a transação distribuída, mas o cenário para sua
utilização tem que ser olhado com muita cautela. Os serviços podem
utilizar transação local, como falei antes pode ser usando até um
TransactionManager do Spring.

Abraços e até a próxima.