Muito comum no mundo JEE, os caminhos programático e declarativo para a utilização de serviços de infra-estrutura são já antigos conhecidos da comunidade desenvolvedora. Segurança, controle transacional e persistência talvez sejam os grandes expoentes dessa estratégia. O grande discurso fomenta a edição de arquivos XML em preferência à manipulação direta de código fonte Java. Pelos entusiastas, a configuração declarativa (XML) de serviços é favorável a sua manipulação programática (Java) a partir do momento em que (a) a edição de arquivos XML não exige a recompilação e reteste do código e (b) a sintaxe XML é mais simples (!!!!) que a sintaxe de qualquer linguagem de programação.  Obviamente, é um assunto extremamente polêmico, que teve seu auge e mérito no início da plataforma J2EE, mas que tem sofrido duras críticas nos últimos anos pela suposta burocracia agregada pelo excesso de arquivos XML de configuração. Tamanho é o frenessi em torno do debate que hoje já despontam tecnologias com discurso explicitamente opositor à tradicional proposta declarativa J2EE: ”convention over configuration”.  Depois eu discuto sobre os prós e contras desta abordagem. Não será nosso foco agora. Façamos vista grossa por enquanto.

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.

Neste ponto, a tendência é de caos e de total perda de controle do ambiente, sugerindo a rápida saturação do sistema.

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.

Que fique claro desde já que todo este texto não reflete a opinião institucional da SEA, mas apenas o meu desabafo, exclusivo e particular. Não sou especialista no assunto e tampouco entusiasta. Acompanho de longe a dinâmica do jogo e, dia-a-dia, consolido minha perspectiva.

SOA 1.0

Embebido de trememendo ceticismo, não sou a melhor pessoa a discorrer sobre a adoção de SOA no mercado brasiliense mas, coom dizem por aí, se não tem tu, vai tu mermo. Sendo claro, nunca acreditei integralmente nesse hype. Sempre achei de se tratar não mais que estratégia comercial para movimentação da indústria de TI. Entretanto, de uns tempos pra cá, talvez em meio a um novo cenário 2.0 que se desenha, algumas mudanças têm ocorrido e, ainda que timidamente, começado a me agradar.

Minha primera razão para tamanha indiferença é que, em primeiríssimo lugar, porque todo esse papo começou com a febre dos WebServices, lá no início deste século e, desde então, tem sofrido de constantes ajustes para manutenção da máquina econômica. Lembro de ter escrito artigos sobre o assunto nas JavaMagazine #1 e #3, em 2002. Naquela época, o discurso era mais ou menos o seguinte.

No fundo, o que todos querem é que um serviço computacional numa máquina X seja capaz de se comunicar com outro serviço numa máquina Y. É o discurso básico da computação distribuída. E, combinado com outro discurso básico, da Engenharia de Software, que prega a busca divina pelo baixo acomplamento e a alta coesão, desenvolveu-se outro discurso básico,  dos modelos orientados a componentes que, pra piorar a história, cultivaram uma abstração utópica, mas super vendável de que, num futuro não muito distante, a construção de software seria como a montagem de um escultura Lego, apenas através do encaixe de peças.

Ah, e mais! Diziam também que teríamos lojas especializadas em componentes das quais poderíamos adquirir componentes de negócio prontos para serem utilizados, out-of-the-box, em nossas aplicações.  Aí, pra dar ainda mais charme ao discurso, apareciam os fabricantes de ferramentas dizendo tudo isso seria integrado numa IDE que possibilitaria drag and drop desses componentes e que qualquer pessoa não técnica seria capaz de criar suas próprias aplicações. Isso, claro, sem mencionar o propósito lunático de disponibilização de um reponsitório intergalático de componentes, que poderiam ser localizados como que numa lista telefônica e dinamicamente incorporados em sua solução. Fui eu que sonhei com isso ou mais alguém foi seduzido pelo canto da sereia? Esse papo furado existiu no CORBA, repetiu-se nos EJBs e foi reciclado com os WebServices. Provavelmente há alguém, neste momento, preparando alguma roupagem inédita.

Aproveitando a nova onda, vieram todos os grandes fabricantes de TI, com produto$,  soluçõe$ e prome$$a$, geralmente recheadas de termos, tecnologias e complexidades acessíveis apenas aos moradores do Olimpo. Não bastasse o oportunismo, aproveitaram o hype do momento e aplicaram-no num limite tendendo ao infinito, institucionalizando o maior de todos os Elefantes Brancos computacionais, IMHO, o termo SOA (Service Oriented Architecture). Não é à toa que muita gente, até hoje, defende a tecnologia de WebServices como o pilar fundamental das Arquiteturas Orientadas a Serviços.

SOA =

lim aplicarWebService(w)  w → ∞

Mas vários gestores deixaram-se seduzir e abraçaram a causa em seus projetos. E, como em todo lugar e com toda tecnologia, alguns avançaram e outros (maioria) fracassaram, assim como na genesis dos EJBs. No geral, vejo os primeiros projetos de SOA tendo sido desenvolvidos no melhor estilo Torre de Babel…

… ou seria um castelo de cartas?

Aparentemente, quanto mais projetos se fazia, mais projetos falhavam e o coeficiente de sucesso da tecnologia não escalava, o que colocava em cheque todo o investimento até então realizado pelos grandes vendors.

Mas aí o leitor pode estar se perguntando: e hoje? continua assim? aceitar SOA em minha corporação continua sendo um presente de grego?

Bem, não sei dizer ao certo. Por isso, passo a questão aos universitários (John Cupri), e é a partir daí que eu acho que começa a revolução do pensamento em torno do tema.

Guerrilha SOA

Antes de tratar desta frente cheguevariana do SOA, vamos resumir alguns pontos:


Um artigo muito esclarecedor de Setembro de 2008 diz, com suas próprias palavras, claro, que SOA é a arte se transformar artefatos digitais intangíveis em ativos de valor contábil, o que faz muito sentido. Ora, é normal que todo grande órgão público inventarie todo o seu patrimônio. Mas, ecnonomicamente falando, o investimento de muitos órgão públicos em patrimônio material (os que são inventariados) é irrisório frente aos investimentos realizados em software que, pela natureza intangível, costumam não ser inventariados e não constar em seus balanços como ativos contábeis.


Deste raciocínio, deriva-se a idéia do reaproveitamento máximo dos ativos existentes, ou melhor, da busca do maior retorno possível do investimento outrora realizado. Um sofá (ativo tangível) só é trocado após não ser mais possível sua reforma (ao menos é assim na minha terra de gente humilde). Então, por que também não utilizar o mesmo raciocínio com software? Se software é, em alguns casos, o maior ativo do órgão, por que descartá-lo com tanta facilidade e frequência apenas pelo capricho da moda tecnológica? Por que não usá-lo e abusá-lo até a última gota?


Jim Webber, consultor da ThoughtWorks, mesma empresa de Martin Fowler (que dispensa apresentações), defende uma perspectiva bastante new-school sobre a adoção de SOA, batizada por ele de ”Guerrilha SOA”.


Em resumo, Webber diz que a adoção de SOA deve ser um processo primeiramente filosófico, incremental, baseado em prioridades (ROI) e em muito muito muito feedback a cada passo dado. Reparem a semelhança de seu discurso com o discurso da maioria dos pensamentos new-school, como o próprio pensamento ágil.


E, para ratificar mais ainda esta tendência 2.0, Steve Jones defende em seu livro ”Enterprise SOA Adoption Strategies” que as grandes mudanças num processo de  adoção de SOA não são técnicas, mas na forma de se pensar software.

SOA 2.0

Então, nesta visão contemporânea, SOA é, em primeiríssimo lugar, um ESTILO de se fazer software com o intuito de incremento de LUCROS pelo foco constante no ROI. Para isso, o REAPROVEITAMENTO dos ATIVOS existentes deve ser sempre realizado o quão antes possível, com AGILIDADE, não necessariamente visando a rapidez, mas a EFETIVIDADE dos resultados.

Assim sendo, importa-se do mundo ágil todas práticas e valores lá defendidos. Indivíduos e interação entre eles mais que processos e ferramentas; Baby-steps; Feedback; Refactoring pela simplicidade; etc

Particularmente, em muito me cativou esta proposta. Principalmente, depois que ouvi um cara da RedHat/JBoss (eu só convivo com esses caras) dizendo pra um cliente do Governo Federal que SOA não dizia respeito à ferramenta, mas a cultura de trabalho, e que ele não precisaria adquirir nenhum produto, mas apenas instrospectar os valores descritos na cruzada “Guerrilha SOA” de Jim Webber.

Em síntese, implantar SOA, em primeira instância, está relacionado ao incremento do ROI. Então, um simples ato de integração de sistemas (independente do mecanismo utilizado - CSV, TXT, FTP, SGBD, SMTP, WebServices, REST etc) para o reaproveitamento de serviços em prol da economia de recursos já é, por si só, uma ação rumo às Arquiteturas Orientadas a Serviços. Pra isso, não é preciso homens de preto e nem gigantescas soluções proprietárias. Então, nesta nova perspectiva, uma simples troca de arquivo entre aplicações é um passo dentro do mundo SOA.

Aliás, importante destacar que SOA não é um processo cujo sucesso da implantação é  mensurado em termos de indicadores objetivos. Ao menos na minha cabeça, não existe a definição de “você é SOA” e “você não é SOA”. Assim como Agile, SOA não é o destino, mas o caminho. Não se chega à SOA. Anda-se sobre os trilhos de SOA. Então, quando lhe disserem que para se tornar um órgão SOA é preciso fazer A, B e C e comprar X, Y e Z, duvide. Eu entendo SOA como um conjunto de práticas e princípios que te guiam rumo aos valores (ROI….) já aqui definidos. Podem até haver níveis de maturidade distintos de adoção de SOA, mas dizer que eu sou SOA e você não, IMHO, é papo de vendedor mal-intencionado.

Acho que o artigo Six stages to SOA evolution in the enterprise, apesar de não ser explícito quanto aos valores do seu discurso SOA, nos dá uma noção clara do raciocínio geral de um processo de adoção dessas práticas, apesar de uma leve tendência comercial que deve observada de forma crítica durante a leitura.

   1. First, business process owners demand improved processes.
   2. The organization then must look at how the IT assets support the execution of those business processes.
   3. Once done, IT must be scrutinized for bottlenecks and other issues, like determining which services should be used.
   4. The organization identifies where and how SOA services can best be deployed.
   5. When multiple services have been deployed, the organization must manage this using an enterprise service bus, thereby reaping agility.
   6. Look at composing processes, composite applications and automating business processes.

SOA is Dead

No início deste ano, Anne Thomas profetizou o óbito de SOA em virtude da crise econômica mundial. Por suas próprias palavras, ”SOA was supposed to reduce costs and increase agility (…) SOA has failed to deliver its promised benefits (…) SOA fatigue has turned into SOA disillusionment (…) ‘SOA’ has become a bad word. It must be removed from our vocabulary.”. Entretanto, ela complementa dizendo que ”Although the word ‘SOA’ is dead, the requirement for service-oriented architecture is stronger than ever.”

Percebam a antipatia pelo termo SOA, e não necessariamente às idéias relacionadas. Isso é algo muito comum entre os céticos no assunto. Todo carnaval comercial em torno de qualquer tecnologia desperda sentimentos de crítica extrema. Logo, o mal visto não são as Arquiteturas Orientadas a Serviço, mas a forma com que os grandes players tentaram empurrá-las mercado a dentro.

Mais a frente, Anne continua com um grito de esperança: ”Successful SOA (i.e., application re-architecture) requires disruption to the status quo. (…) And it requires a massive shift in the way IT operates. The small select group of organizations that has seen spectacular gains from SOA did so by treating it as an agent of transformation. (…) SOA needs to be part of something bigger. If it isn’t, then you need to ask yourself why you’ve been doing it. (…) The latest shiny new technology will not make things better. (…) If you want spectacular gains, then you need to make a spectacular commitment to change.”

Ou seja, não é a adoção de uma tecnologia ou produto que fará a diferença positiva ao seu negócio, mas sim a disposição a assumir mudanças, principalmente, culturais. E, se o discurso de SOA não estiver debaixo de uma iniciativa mais ampla de transformação corporativa, não espere muito sucesso.

E vivam as mudanças (pra melhor)!

Slides

Seguem os slides usados no workshop. Este post reflete apenas sua primeira parte. Acho que nesta semana ainda escrevo a segunda, falando agora de ferramentas que compõe as chamadas “plataformas SOA”.