Plataformas para SOAr 2
<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>
Continuando o papo de SOA, minha
primeira manifestação aqui no blog sobre o assunto
foi uma discussão filosófica que se resume da
seguinte
forma:
Daí, descrevi minha percepção sobre a
visão
moderna do assunto, que definiria SOA, em primeiro lugar, como um
ESTILO de arquitetura que busca primordialmente maior LUCRATIVIDADE
para o negócio do cliente através da
preocupação constante com o ROI, fazendo o
REAPROVEITAMENTO máximo dos ATIVOS existentes de forma
ÁGIL, não necessariamente visando a rapidez, mas
a
EFETIVIDADE dos resultados.
Então, na prática ocorre o seguinte:
Empresas privadas e órgãos públicos
possuem hoje
um grande parque de legados de software que se constituem em ativos
imateriais nos quais muito investimento já foi realizado e
cujo
redesenvolvimento poderia não ser a estratégia
mais
inteligente em termos de ROI.
Em se tratando de um conjunto estático e estável
de
sistemas legados, o reaproveitamento
de
seus
serviços em novas soluções
é facilmente
resolvido com algum esforço pontual de desenvolvimento para
externalização de funcionalidades
através de
alguma interface compreensível por todos os interessados.
Contudo, considerando que, neste conjunto, novos elementos podem surgir dinamicamente, decorrentes de parcerias entre Órgãos, disponibilização pública de sistemas na Internet ou aquisição de produtos tecnologicamente heterogêneos, a implementação manual de cada necessidade de integração pode não ser a decisão mais efetiva, e daí surge a questão: como garantir o mínimo de dinâmica na integração de legados para potencializar meus lucros?
Simplificadamente, eu vejo duas formas básicas de
integração de serviços.
 |
 |
Ou a integração se dá ponto-a-ponto,
ou numa
topologia de estrela.
A integração ponto-a-ponto interliga dois
serviços
de forma direta, através de tecnologias bastante conhecidas
pela
comunidade desenvolvedora. Neste modelo, cada serviço
acopla-se
diretamente a outro, sem possibilidade de muita dinâmica na
colaboração.
 |
 |
Já na integração estrela, os serviços não interagem entre si de forma direta, mas de forma desacoplada, através de algum elemento intermediário que intercepta todas as mensagens e as reencaminha a seus destinatários. Este man-in-the-middle já recebeu vários nomes ao longo da história, mas chega atualmente sendo chamado de Barramento Corporativo de Serviços (ou Barramento de Serviços Corporativos, sei lá) ou, da sigla em inglês, ESB.
Há uma baita discussão sobre ESB. Há
os que o
defende como produtos e os que garantem se tratar não mais
que
um modelo arquitetural. Independente do mérito, é
ao seu
redor que orbitam todas as grandes plataformas SOA de mercado.
Em síntese, num ESB, vários serviços
se conectam ao barramento e, quando da necessidade de
comunicação de um serviço S1 qualquer
com outro S5, por exemplo, ocorrem os seguintes passos:
- S1 produz a mensagem a ser enviada a S5
- S1 posta a mensagem no barramento (por enquanto, não se preocupe em como isso é feito)
- O barramento (ESB) transmite a mensagem ao serviço de destino S5
- S5 lê e processa a mensagem recebida
 |
 |
No mundo JBoss, esta estrutura é implementada no projeto JBoss ESB.
Entretanto, na vida real, nem sempre os cenários
são
tão simples quanto o exemplo apresentado. Por exemplo, nem
sempre o formato de mensagem produzida pelo serviço S1
é compatível com o formato de mensagem
compreendida pelo serviço S5, o que gera a necessidade de
conversão da mensagem durante sua passagem pelo barramento.
|
 |
Outro complicador da vida real é que nem sempre o destino da
mensagem é previamente conhecido por seu emissor, ficando
esta decisão por conta do próprio barramento.
 |
 |
 |
 |
Transformação e roteamento
dinâmico de mensagem são apenas 2
exemplos de funcionalidades normalmente disponíveis nos
principais ESBs de mercado. Outros problemas comuns da
integração de serviços são
também resolvidos nesses produtos. E, sendo a tecnologia
Java uma das principais protagonistas deste mundo de
integração de serviços corporativos,
há sempre as alternativas programática
e declarativa
para uso dos serviços nativos dos middlewares
ESB.
Mais recentemente, elevando este discurso ‘declarativista’ ao limite, criaram a possibilidade de se implementar até as regras de negócio dos sistemas em XML, e é esta tecnologia que tem sido utilizada dentro das plataformas ESB para a configuração de regras de roteamento e transformação de mensagens, por exemplo.
Isso quer dizer o seguinte: ao se adotar um ESB para integração de serviços corporativos, usa-se algum mecanismos baseado em linguagem de alto nível (XML ou outra qualquer) para se descrever como deverá ser o tratamento das mensagens que circularem dentro do barramento. A este mecanismo, deu-se o nome de ‘Engine de Regras’.
Para efeitos didáticos, eu descrevo um Engine de Regras com o auxílio de 2 dos 3 poderes da República. Num extremo, está o Poder Legislativo, resposável pela criação, edição e publicação das lei que regirão todo o sistema. No outro extremo, o Judiciário, responsável por analisar e julgar fatos ocorridos na sociedade sob a luz da legislação vigente.
 |
 |
Assim, de alguma forma, configuramos declarativamente no ESB, por exemplo, as regras de roteamento de mensagem. Então, como o ESB possui internamente um Engine de Regras ativo, quando da chegada de uma mensagem no barramento (fato esperado pelo Engine), a mensagem é submetida às regras previamente definidas e, com base no processamento realizado pelo Engine de Regras, um ou outro encaminhamento será dado ao seu percurso.
Na comunidade JBoss, esta funcionalidade é provida pelo projeto Drools ou, comercialmente falando, JBoss Rules, que se integra ao JBoss ESB.
Mas, os problemas não páram por
aí.
A medida que a integração entre
serviços se torna prática estabelecida (e
amadurecida), é natural que as estruturas de relacionamento
entre sistemas fiquem cada vez mais complexas, envolvendo cada vez mais
serviços (e até pessoas), em cenários
cada vez mais heterogêneos. Uma mensagem que nos primeiros
projetos de ‘SOA’ era simplesmente produzida por um serviço
X e consumida por outro Y, com necessidades exporádicas de
conversão e/ou roteamento, é, em arquiteturas
mais avançadas e complexas, consumida e transformada por
vários atores, que a processam em fluxos
específicos e, por que não, dinâmicos.
Por isso, desde os primeiros passos da integração de sistemas, é importante a consolidação de processos que organizem os fluxos de trabalho e a execução de serviços compostos.
Nesta altura do campeonato, o importante de ser compreendido é o seguinte: “plataformas SOA”, em sua definição tradicional, tem muita a ver com a visão de SOA 1.0 descrita no post anterior. É preciso muita cautela ao examiná-las. Qualquer ímpeto, por menor que seja, de interepretação dessas plataformas como as balas de prata para a integração de serviços é um grande erro. Lembrem-se dos valores defendidos na visão de SOA 2.0. SOA não tem a ver com tecnologia, mas com a adoção de práticas. Logo, só se justifica a adoção de uma ou outra plataforma se os serviços por ela prestados corroborarem com os novos valores defendidos.
Ainda neste raciocínio, lembre-se de que você não precisa de um ESB, ou qualquer outro produto desses, pra começar a implantar SOA. Muito mais que uma mudança tecnológica, estamos falando de uma mudança comportamental. Então, se seu objetivo é reaproveitar um sistema qualquer para otimização do ROI de sua empresa, faça-o da forma mais efetiva. Dê o tiro certo. Se o tiro certo for através da adoção de uma plataforma SOA, ótimo. Senão ótimo também. Se, para o primeiro passo, apenas o Engine de Processos for necessário, ótimo. Se apenas o ESB for relevante, ótimo também. Não adeque sua necessidade à tecnologia. Adeque a tecnologia às suas necessidades. SEMPRE!
[]s