Passamos umas três semanas offline em razão de um problema esquisito que deu no Typo, nosso engine de blog. Mas, como devem ter percebido, desde a última semana, estamos de volta!

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?

1. S1 produz a mensagem a ser enviada a S5
2. S1 posta a mensagem no barramento (por enquanto, não se preocupe em como isso é feito)
3. O barramento (ESB) transmite a mensagem ao serviço de destino S5
4. S5 lê e processa a mensagem recebida

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.

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.

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.

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.

Ainda dentro da cultura declaratista do mundo JEE, a idéia é que o fluxo de processamento de uma mensagem por vários serviços seja definido de forma (novamente) declarativa e executado por alguma entidade independente, chamada de ‘Engine de Processos’, que instanciam processos previamente (e declarativamente) definidos e administram sua execução, controlando a passagem de um estado do fluxo para outro, disparando gatilhos configurados (para envio de emails, por exemplo) e até gerando estatísticas de execução para a tomada de decisões estratégicas (#clichê).

Existem várias soluções no mercado com este propósito. Destaco aqui o JBoss jBPM.

Em conjunto, JBoss ESB, JBoss Rules e JBoss jBPM constituem o que a RedHat comercialmente chama de JBoss SOA Platform. Lembrem-se de que o modelo de negócio da RedHat é baseado na venda de subscrição para suas várias plataformas.

Várias “plataformas SOA” estão sendo comercializadas por aí. Os três conceitos apresentados servem de base para compreensão da maioria das soluções disponíveis. Nem de longe eu tentei neste post explicar tecnicamente cada elemento da plataforma SOA da RedHat/JBoss. Este texto foi apenas uma continuação de outro.  Mais pra frente eu pretendo escrever especificamente sobre cada um dos 3 projetos mencionados (ESB, Rules e BPM). Mais coisa pro meu blog debit :-/

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

Pretendo continuar com o assunto de tuning mas, antes disso, preciso falar um pouco do mega-hype-não-tão-hype-assim SOA, em razão de uma sequência de workshops que temos feito internamente na SEA.

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.

Várias tecnologias de invocação remota de serviços falharam ao longo dos últimos anos e a principal razão foram as tentativas frustradas de imposição de novos padrões e protocolos, que sofriam de grandes dificuldade de trânsito na Rede. Agora, WebServices não têm como falhar, pois não estamos impondo nada novo. Com base em padrões totalmente estabelecidos (HTTP e XML), reinventamos a invocação remota de serviços. Vamos fazer o que sempre se quis com tecnologia já aceitas no cyberespaço.

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”.

No último post sobre JBoss, destaquei o profissional de mercado comumente conhecido por “Administrador JBoss” e as atividades que ele executa. Por conveniência, copio aqui o trecho em questão.

Destaque especial ao termo performance tuning, que sofre de grande estardalhaço no mercado, e que será o foco do meu discurso hoje.

Normalmente, os passos seguidos por um cliente em processo de aquisição de serviços JBoss são, primeiramente, a instalação e configuração básica do servidor, seguida da monitoração das instâncias com o JON e a realização de ajustes finos (tuning), com base nas métricas coletadas, para melhor utilização dos recursos disponíveis.

Tunar pra quê?

Tunar o quê?

ToC

ToC aqui não é Transtorno Obcessivo e Compulsivo, mas Theory of Constraints, ou Teoria das Restrições, um princípio de negócios que diz que “toda organização tem - em um dado momento no tempo - pelo menos uma restrição que limita a performance do sistema (a organização em questão) em relação a seus objetivos.” (Wikipedia).

Na definição dada, troque “organização” por “JBoss” e teremos a Teoria das Restriçõe aplicada ao servidor de aplicações JEE open source da Red Hat. Melhor ainda, troque “organização” por “infra-estrutura”:

Diving rescue

Num processo de tuning, mesmo antes de se saber ao certo o ponto exato do tuning, é preciso estabelecer alguma estratégia de varredura, que deve ser seguida à risca para que todos os potenciais pontos de gargalo sejam avaliados. A não obediência do padrão pré-estabelecido de pesquisa abre lacunas colaboradoras ao fracasso de todo esforço empreendido.

ROI

Está na moda, em com razão, IMHO, falar de retorno de investimento. Em tempos de crise global e de margens tão apertadas, qualquer puto gasto deve se provar útil o quão antes possível (não deve ter sido à toa que a Mitsubishi decidiu não mais participar do Paris Dakar, mesmo após 7 títulos consecutivos).

Assim, aplicar recursos em uma consultoria de tuning só se justifica sobre uma nobre razão (e.g. evitar que o sistema Y caia em seu lançamento), como discutido nas seções anteriores. E, mesmo sob a existência explícita desta justificativa, dentro do processo de tuning em si, é essencial a busca incessante do menor esforço que gerará o maior benefício (Pareto).
 
Em primeira instância, deve-se avaliar a curva de custo/benefício da contratação. Por exemplo, se o problema relatado pelo cliente é “o servidor cai por OutOfMemoryError sempre que o sistema atinge 400 usuários simultâneos”, pode sair mais barata a aquisição de mais pentes de memória do que a execução de um processo de tuning para investigação de memory leaks na aplicação ou o reajsute de parâmetros de inicialização do servidor.

Num segundo momento, já imerso no ciclo de tuning, o responsável pela atividade deve sempre buscar o ponto de ajuste que trará mais resultado visível ao olhos do cliente (é a estória da martela certeira).

Pode ser então que uma mega-complexa-configuração no app server resolva determinado problema mas, uma alternativa no nível de SO, muito mais simples de ser executada, e que também atenderá a demanda, é bem mais preferível.

Mas às vezes, o cliente diz assim “Não se preocupe com o resto da infra. Tuna ao máximo o JBoss e depois a gente vê o resto.”. Isso é uma punhalada. Há a possibilidade de se gastar meses em investigação e ajustes malucos no servidor que poderiam ser facilmente resolvidos com um refactoring da aplicação ou um micro-tuning no banco, por exemplo. É como te pedirem pra manter o chão de uma sala enxuto com uma flanela sem te deixarem fechar a torneira da pia que está transbordando de água. Pra evitar que isso ocorra, be nice.

E, por fim, sob a luz da Teoria das Restrições, a busca por gargalos (restrições) é um processo infinito (pois eles sempre existirão) e, decidir o ponto exato de parada está totalmente relacionado com o retorno do investimento aplicado até então (o custo de eliminar o próximo grande gargalo é menor que benefício obtido por sua eliminação?).

Being nice

Nenhum administrador de infra-estrutura sente-se confortável com pitacos de instrusos em seu ambiente. Então, é natural que a chegada de uma consultoria externa responsável por “resolver a parada” seja, a princípio, mal recebida, por várias razões. Se você, consultor externo, foi contratado para resolução do problema, provavelmente é porque a equipe interna não o resolveu por si só. Daí, qualquer sucesso da sua parte será a ratificação da incompetência do time local. Se você, consultor externo, concluir que ajustes no nível de rede, SO, banco ou aplicação é menos oneroso que ajustes no servidor de aplicações, você não apenas estará registrando em pedra o fracasso do pessoal da casa na resolução do problema, como também estará indiretamente questionando sua incompetência na execução de seus trabalhos de rotina, como a configuração do SO. E assim segue.

Veja então que, no papel de consultoria externa tida como a salvação da pátria, qualquer passo em falso pode desencadear conflitos capazes de inviabilizar todo o trabalho.

Não se esqueça que quem detém os acessos a todos os elementos da infra-estrutura são os membros do time local do cliente. Indispor-se de alguma forma com essa galera é fechar várias portas fundamentais para implementação de sua estratégia de investigação.

A única dica a se dar neste ponto é: seja legal. Acho que não existam técnicas formais para se ter sucesso nessas ocasiões. Tem muito a ver com soft skills desenvolvidos pelo próprio profissional ao longo de sua história e com seu bom senso. Parece óbvio, mas é hiper comum vermos profissionais nesta posição de consultoria externa apresentarem-se com extrema arrogância é pré-potência. Geralmente, são os malditos famosos homens de preto. É claro que um cara desses será mal recebido e todas as barreiras possíveis e imagináveis ao sucesso de seu trabalho serão criadas pelo pessoal da infra local. A filosofia ágil ataca um pouco este problema quando defende a integração mais próxima possível com o cliente. De fato, é seu dever apresentar-se à equipe do cliente como parceiro, e não concorrente. Se o seu problema não for o problema dele e o problema dele não for o seu, do fundo do coração, lascou. Se não for do fundo do coração, será caracterizada a falsidade. Aí é problema seu. Eu avisei que tinha que ser de coração.

A multicasionalidade

Pelo CENIPA, órgão da FAB responsável pela investigação e prevenção de acidentes aéreos, nenhuma aeronave cai por uma razão única. Em seu entendimento, todo acidente ou incidente aéreo só é materializado pelo alinhamento de alguma sequência de fatores. Por exemplo, um cochilo do piloto durante o processo de aproximação da aterrissagem, por si só, não é causa justificável para um desastre aéreo e tampouco o é a falha de um dos motores do equipamento. Agora, se o piloto dorme, o co-piloto vai ao banheiro,  o motor pára e essa combinação nunca antes fora prevista pela Força Aérea, então fatalmente veremos merda.

Em uma missão de tuning, o mesmo raciocínio da aviação é válido. O problema de latência da aplicação relatado pelo cliente não necessariamente é de responsabilidade única da aplicação, ou do servidor, ou da rede, mas é responsabilidade conjunta de todos eles. Ora, tudo bem que a aplicação consuma grandes quantidades de memória, desde que o servidor tenha memória superestimada. Tudo bem que o tamanho das sessões de usuários sejam da ordem de gigabytes, desde que a rede que interconecte os nodos do cluster seja de terabits. Tudo bem que qualquer elemento da infra apresente problemas, desde que haja outro que os compense. Cada elemento deficitário contribui para o problema final observado pelo usuário, mas não necessariamente carrega a culpa exclusiva. O que não pode ocorrer é a combinação desses fatores deficientes, como uma aplicação gulosa de memória rodando sobre um servidor com recursos escassos numa rede com banda limitada. Aí não há santo que dê jeito.

Assim, sempre sob a luz do ROI, é essencial conhecer quais fatores cujo alinhamento contribuem para o problema em questão, para que só então se tome a decisão certa sobre o próximo passo do tuning, de preferência, a que apresentar o melhor custo/benefício. Esse papo de ROI é tão importante que, às vezes, comprar mais memória ou substituir o barramento de rede pode ser mais barato que a execução do tuning. Novamente, é a análise do custo/benefício com Pareto.

Escopo

Na era industrial da computação, chamada por nós da SEA como a velha escola do pensamento de TI, ou a TI 1.0, havia o lema de que cada profissional possuía uma e apenas uma especialidade (vide tradicionais processos em cascata). Neste raciocínio, então, você como profissional JBoss seria responsável apenas por ajustes no app server, alienando-se dos demais elementos compositores de sua infra-estrutura (rede, SO, app…). Tecnicamente, pode até ser interessante para você, profissional auto-definido por consultor-intergalático com cabeça old-school. Afinal, é menos coisa para se preocupar. Mas, negocialmente falando, é a maior irresponsabilidade que se pode fazer. Ora, quem efetivamente está preocupado com o sucesso de um negócio está, naturalmente, interessado a se envolver em todas as suas instâncias.

Equipes 1.0 concorrem entre si. Equipes 2.0 colaboram entre si. No mundo 1.0, todos querem tirar os seus da reta. Por isso há tantos documentos, tantas assinaturas e tantas evidências geradas. Tudo para que eu possa comprovar que, em caso de merda, a culpa não foi minha. O principal sintoma desse modelo são os profissionais que lavam suas mãos ao afirmarem não ser deles o problema. Já no mundo 2.0, em contraponto, não existe problema seu ou meu. Os problemas são sempre nossos. Por isso, todos se responsabilizam por igual para o bom andamento do negócio. Por mais que eu, como DBA, possa ter certeza quase absoluta de que o principal gargalo não esteja no banco, eu visto as sandálias da humildade, desço do pedestal dos deuses e vou a campo me sujar com o restante do time, ajundando o máximo que puder, da forma que puder.

Assim, num processo de tuning, não existe o cara do banco, o cara do JBoss e o desenvolvedor da aplicação, mas sim a equipe responsável por resolver o problema em pauta, seja ele qual for. Neste modelo, ao invés de ficar cada um no seu quadrado, todos circulam além das fronteiras de sua especialidade, abraçando a mesma causa e colaborando um com ou outro para o sucesso global da iniciativa.

Tem a ver com a famosa estória da galinha e do porco contada pela literatura do Scrum. No modelo 1.0, você é responsável pela sua especialidade e apenas se envolve com as outras, sem exercer por elas qualquer relação de responsabilidade. Já no 2.0, você se compromete com todo o escopo de atividades do tuning, independente do seu papel principal. Queremos compormetimento, e não apenas envolvimento.

Em caso de haver qualquer limite no escopo de atuação da equipe de tuning, que seja então uma limitação política ou corporativa, mas não limitações por ego ou orgulho gerados pela especialização profissional.

Tuning não se compra, se faz

Não existe receita de bolo para tuning. Se existisse, todo servidor JBoss já viria tunado de fábrica.

Já disse que numa missão de tuning deve-se buscar sempre os pontos de ajustes com maior ROI e que todos os responsáveis pela infra-estrutura em produção devem estar igualmente comprometidos com o trabalho. Entretanto, há de se fazer ordem neste processo. Apesar do comprometimento de representantes de todas as camadas da infra, é necessário entrar em acordo sobre a estratégia de evolução do processo.

No próximo post vou falar do ciclo de instrumentalização, execução, monitoramento e ajustes que se repete dentro da estratégia pré-estabelecida. Em especial, vou tratar das ferramentas utilizadas neste ciclo para diagnóstico de gargalos e prognóstico de soluções.


Keep in touch, Keep walkin’, Drop a comment.

[]s

Rolou na SEA dia desses uma discussão sobre o encarreiramento JBoss. Como parceiros RedHat, estamos sempre executando serviços de consultoria em produtos JBoss. Mas, afinal, que tipo de atividades um suposto “Consultor JBoss” exerce e a qual nível de capacitação deve ser submetido? A missão deste post é tentar responder essas questões.

Depois de um exercício não muito intenso de reflexão, concluí que existem 5 tipos de profissionais JBoss no mercado. Dar nomes a esses 5 tipos seria totalmente 1.0 (Arquiteto JBoss, Adminsitrador JBoss, Desenvolvedor JBoss, Desenvolvedor de Portal, Arquiteto SOA - bah!). Por isso, prefiro referenciar-lhes como A, B, C, D e E, sem qualquer relação hierárquica entre as letras.

Pra início de conversa, é preciso entender a organização comercial que a Red Hat faz de seus produtos. Após a aquisição da JBoss, a RedHat incorporou em seu catálogo de produtos uma série de projetos open source e, para melhor apresentá-los a seus clientes, agregou-os em 4 grupos, ou plataformas, como dizem.

• JBoss Enterprise Application Platform
• JBoss Enterprise Portal Platform
• MetaMatrix Enterprise Data Services Platform
• JBoss Enterprise SOA Platform

Basicamente, há um tipo de profissional JBoss especialista em cada uma dessas plataformas. Não vou relacioná-los pra não caracterizar um discurso institucional. Liguem os pontos vocês mesmos.

Profissional JBoss A

O primeiro tipo de profissional talvez seja o mais raro do mercado. É o pré-vendas JBoss. Naturalmente, apenas parceiros Red Hat ou a própria Red Hat possuem profissional com tamanha especialização. Devem chamá-lo de ”Arquiteto JBoss”. É a pessoa que conhece bem todas as JBoss Enterprise XXX Platforms e é capaz de combiná-las para a formatação de soluções “corporativas” para seus clientes. Enfim, é o cara que sabe falar bem e que quer que você adquira o maior número possível de subscrições. #prontofalei  Por muitas vezes, sou um desses.

Então, quer trabalhar na RedHat/JBoss? Domine cada uma das plataformas acima e entre em contato com o Edgar. Se tiver feito seu dever de casa, há grandes chances de você entrar lá. Afinal, estão sempre em busca de bons profissionais.

Profissional JBoss B

• JEE
• Servlet, JSP, EJB, JDBC, JPA, JCA, JNDI…
• Infra
• Conceitos de rede (TCP/IP) e administração geral de Unix. (Windows? Só se você quiser ou precisar muito.)
• JBoss AS
• Instalação, deploy, arquitetura (microkernel, microcontainer, mbeans, bundles), segurança (configuração de portas, autenticação, autorização e encriptação de serviços), classloading, clustering, customização (slimming) e tuning.

Profissional JBoss C

Entendo pelo Profissional JBoss C como sendo o profissional especialista (old-school) em desenvolvimento com tecnologias JBoss. A velha guarda deve chamá-lo de ”Desenvolvedor JBoss”.

Trata-se nada mais que um desenvolvedor Java Enterprise Edition ordinário, com algumas preferências pela stack JBoss (Hibernate, JBoss Seam, Richfaces, JBoss Cache, JBoss AOP etc).

Profissional JBoss D

O quarto tipo de profissional, nesta minha taxonomia, é o profissional especialista na plataforma de portais da RedHat (JBoss Enterprise Portal Platform). O pivô deste profissional não é o servidor de aplicações em si, mas a ferramenta de portal que nele é disponibilizada, o JBoss Portal.

Este perfil instala, configura e customiza portais de internet ou intranet. Destaque especial para a customização, que envolve relativo talento para a criação de novos temas e o desenvolvimento de novas funcionalidades através de portlets. Um bom conhecimento de CSS e da JSR-168 é fundamental.

Profissional JBoss E

Este último profissional é o que o mercado anda chamando por aí de ”Arquiteto SOA”. No mundo JBoss, é o técnico especialista na JBoss Enterprise SOA Platform.  Este perfil está sintonizado não apenas no hype-não-tão-hype-assim SOA como também nos produtos que todos os grandes fabricantes têm lançado para fins de integração e governança de serviços.

Vou dedicar muito em breve um post exlucisvo à plataforma SOA JBoss mas, enquanto isso, apenas entenda que um Profissional JBoss E deve conhecer a fundo, além de toda a plataforma JEE, também o JBoss ESB, JBoss jBPM e o JBoss Rules que são, respectivamente, um barramento para integração de serviços, um framework para composição e execução de processos e um engine declarativa de regras. Termos estranhos à primeira vista, mas que serão esclarecidos muito em breve. Assinem logo o RSS.

(O JBoss ESB não tem logo. Clique para ampliar.)

Por fim

Ainda existem duas últimas especialidades no mundo JBoss em fase de consolidação, relativas a dois produtos recentemente (não tão recente assim) adquiridos pela Red Hat: MetaMatrix e Mobicents.

O primeiro é uma ferramenta para federação de dados. Quer dizer, se o seu ambiente de produção utiliza N fontes de dados distintas (MySQL, PostgreSQL, Oracle, M$SQL…), com o Metamatrix é possível fazer com que as aplicações tratem tudo como uma coisa só, sem se preocupar com detalhes específicos de cada base, como URLs, drivers, etc.

Já o Mobicents é um servidor JSLEE e SIP. Aliás, um dos únicos open sources do mercado, se não me engano. Saiba mais no java.net.


Eu diria que ainda é um pouco prematuro investir exclusivamente no MetaMatrix ou no Mobicents. Não é este o filão da Red Hat ainda. Se me perguntarem sobre uma ordem mercadológica de preparação para o mercado, eu diria:

1. Aprenda bem JEE, seus prós e, principalmente, seus contras. 
2. Conheça o JBoss e hackeie-o ao máximo. Estude sua arquitetura, componentes internos, principais serviços e customizações. 
3. Entre no mundo SOA. Estude não só a Plataforma SOA JBoss, mas também seus concorrentes.

Deixe um comentário em caso de dúvidas ou curiosidades.

[]s

 Reaceso o mercado de servidores de aplicação pela RedHat, foi hora de dar um colorido extra à administração de ambientes JBoss. Utilizando-se de uma base de software já criada para monitoração e controle de sistemas (hyperic), a RedHat criou o JBoss Operations Network, vulgo JON (não John), que rapidamente se tornou na menina dos olhos para potenciais assinantes de subscrição JBoss.

O JON é uma ferramenta de administração, monitoração e controle de servidores JBoss.

Figura 1 - JON

Mitos

Existem alguns mitos em torno do JON que precisam ser desfeitos antes que se desenvolvam.

1. O JON é proprietário?

NÃO! Já foi, mas não é mais. Hoje o JON é apenas a versão "enterprise" de um projeto open source chamado Jopr, que é construído sobre outro projeto open source chamado RHQ. Ou seja, assim como o RHEL está para o Fedora e o JBoss EAP está para o JBoss.ORG, o JON está para o Jopr. Este é o modelo da RedHat.

Figura 1 - RHQ Project Homepage

Figura 2 - RHQ Project

Figura 3 - Jopr (apesar da logo ser do RHQ, a tela é do Jopr).

A propósito, vale a pena dar uma lida nesta entrevista com Chris Morgan, um dos líderes do projeto Jopr.

2. O JON resolve todos os meus problemas de monitoração?

NÃO! Não é responsabilidade do JON a monitoração e controle de ativos de rede, máquinas, sistemas operacionais, bancos de dados etc. Ele até realiza parte deste trabalho, mas não é o seu foco. Seu foco é no servidor de aplicação JBoss (que roda sobre um SO, que roda sobre um hardware, que roda sobre uma rede….) e em seus sub-elementos. Para o acompanhamento de outros níveis, acima ou abaixo do app server, existem outras ferramentas (livres) que, se devidamente utilizadas junto ao JON, formam uma suite imbatível para administração pró-ativa de toda infra. Outro dia eu falo dessas outras ferramentas (os quadrinhos cinzas da figura 4 abaixo).

Figura 4 - Monitoração, cada um no seu quadrado

Basicamente, o JON possui 3 focos distintos:

(a) monitoração e controle
(b) distribuição de software
(c) disponibilização do conhecimento

De longe, o primeiro item, (a), é o que está mais maduro na ferramenta. Por ele, é possível realizar a coleta de métricas dos recursos inventariados pela ferramenta, analisá-las visualmente, configurar alertas com base nas mais diversas condições e estabelecer políticas preventivas de administração.

Figura 5 - JON, Monitoração

Figura 6 - JON, Controle

Os demais itens (b) e (c), apesar de atrasados quanto ao primeiro, já tiveram seu desenvolvimento inicalizado e demonstram-se em grandes promessas para um futuro próximo. Por distribuição de software, entende-se a capacidade do administrador do JON controlar e comandar, remotamente, a distribuição de novas releases e patches das ferramentas homologadas para as demais áreas de sua instituição. Já o item (c), disponibilização de conhecimento, tem o propósito de agregar num ponto único todas as informações relevantes para usuários de ferramentas específicas da JBoss. Pelo discurso oficial, não faz sentido que um profissional que paga por um contrato de subscrição de JBoss tenha que garimpar na Rede a solução para seus problemas. Todos os problemas conhecidos deve ser catalogados e suas respectivas soluções devem estar disponíveis através da ferramenta.

Figura 7 - JON, Distribuição de Software

3. O JON faz monitoramento em tempo real?

NÃO! Não é do propósito do JON a monitoração em tempo real dos servidores. Sua proposta principal é de viabilizar a consolidação de uma base histórica de dados a partir da qual pode-se extrair informações úteis para a tomada de decisões pró-ativas para adequação do ambiente a tendências de acesso. Para monitoramento em real time, é melhor buscar uma ferramenta de profiling, como o JBoss Profiler que, by the way, foi concebida e é hoje mantida por brasileiros.

Figura 8 - JBoss Profiler

Esta imagem é do JBoss Profiler 1.0. A versão 2.0 já tem o beta disponível e o Edgar está trabalhando na transformação do Profiler num plugin do JON.

Figura 9 - Plugin do JBoss Profiler para o JON

 Conceitos

O principal conceito do JON (e seus familiares Jopr e RHQ) é recurso. Por recurso, entende-se plataformas, servidores e serviços. Plataformas são máquinas fisicas ou virtuais (e.g. Windows, Linux…). Servidores são coisas que rodam dentro das plataformas (e.g. JBoss App Server, Tomcat, Apache, Postgres, IIS…). Serviços são coisas que rodam geralmente dentro de servidores (ou também dentro de plataformas) (e.g. Stateless Session Bean, Datasource, Connection, Web Application, Virtual Host…). Cada servidor possui um conjunto de serviços próprios. Nos exemplos dados, Stateless Session Beans é um serviço do servidor JBoss App Server, mas Virtual Host já é um serviço do servidor Apache HTTP Server.

Por este mesmo raciocínio, cada tipo de recurso possui métricas e controles próprios. Assim, as métricas disponíveis para uma plataforma Linux, por exemplo, não são as métricas disponíveis para uma plataforma Windows ou um servidor JBoss. Veja os exemplos abaixo:

Métricas de uma Plataforma Linux

• Free Memory
• Used Memory
• Total Memory
• Free Swap Space
• Used Swap Space
• Total Swap Space
• Idle
• System Load
• User Load
• Wait Load
• … 

Métricas de um Servidor JBoss

• Active Thread Count
• Active Thread Group Count
• JVM Free Memory
• JVM Max Memory
• JVM Total Memory
• Transactions Active
• Transactions Committed
• Transactions Committed per Minute
• …
•  

Métricas de um Serviço Datasource

• Total Connections
• Available Connections
• Active Connections
• Connections Created
• Connections Created per Minute
• Connections Destroyed
• Connections Destroyed per Minute

Arquitetura

O JON segue uma arquitetura Servidor/Agentes (como o Nagios). Normalmente, instala-se 1 JON Server e N JON Agents. Para cada plataforma a ser monitorada, um JON Agent deve ser instalado. O agente do JON é o responsável por realizar a descoberta dos servidores e serviços da plataforma onde está instalado, coletar localmente suas informações e enviá-las periodicamente ao servidor do JON para serem consolidadas e apresentadas visualmente. É também responsabilidade do agente receber instruções enviadas pelo servidor e processá-las localmente, como, por exemplo, a reinicialização de um JBoss.

Cada agente, por sua vez, é composto por um conjunto de plugins. Cada plugin define um escopo de funcionalidades do agente. Então, no fundo, no fundo, o conjunto de métricas coletadas pelo agente e o conjunto de operações que podem ser comandadas remotamente em qualquer recurso dependem essencialmente do conjunto de plugins disponíveis dentro do agente.

Na prática, o que distingue o RHQ do Jopr é basicamente o conjunto de plugins embutidos em seus agentes. A grosso modo, o RHQ não possui os plugins de JBoss, Hibernate e Tomcat que o Jopr tem. Isso quer dizer que no Jopr é possível monitorar JBoss, Hibernate e Tomcat e no RHQ, não. Simples assim.

Mas, o melhor de tudo, é que a partir do momento em que o JON passou a compartilhar o codebase do projeto RHQ, na versão JON 2.0, a arquitetura de plugins dos agentes foi aberta. Com isso, tornou-se possível a nós, desenvolvedores ordinários, criar plugins para o JON. Isso quer dizer que, desde então, é possível monitorar qualquer software pelo JON, desde que um respectivo plugin seja desenvolvido.

Por isso que, recentemente, uma penca de plugins apareceram na net. Dentre eles, plugin pro Oracle, Hudson, Continuum, Jira, MySQL etc. Isso só enriquece o JON/JOPR/RHQ e todos nós só temos a ganhar.

BAM

A última moda do JON, entretanto, é seu uso como instrumento de Business Activity Monitoring.

Utilizando-se de sua infra-estrutura de criação, distribuição e gerenciamento de plugins, tem-se extendido o JON para monitoração e controle de aplicações corporativas. Neste sentido, define-se a coleta e computação de métricas com significado de negócio e beneficia-se de toda estrutura do JON para análise dessas informações e definição de alertas quando da extrapolação superior ou inferior de baselines pré-definidos. Por exemplo, num sistema do Ministério da Educação, pode-se criar um plugin para o sistema do ENEM que aponte o número de inscrições por minuto, ou a taxa de variação das vendas de uma empresa privada ou ainda o ainda a carga horária média de trabalho de minha equipe de consultoria. Aqui, a imaginação é o limite.

Legal, né?

Futuro

 Muito tem sido investido na plataforma RHQ/Jopr/JON. Aparentemente, a RedHat tem pretensões de fazê-la pivô de administração de seus projetos.

Se você é administrador JBoss, faça o teste. Se você é desenvolvedor Java, aproveite a oportunidade para a construção de coisas interessantes. Se quiser uma ajuda, utilize o gerador de plugins do Heiko que, durante a construção deste post, foi lançado e atualizado.

Se não for tirar férias em Janeiro, aproveite e assista o Webinar sobre Jopr que será realizado no dia 13.

[]s e boas festas!



 

Está na hora de desovar uma série de posts sobre JBoss que há muito orbitam em minhas idéias. Vou começar por um discurso que eu repito em várias ocasiões e que acho que está na hora de ficar registrado para a prosperidade.

Todo mundo já deve ter ouvido falar dos altos e baixos da tecnologia Java. No lançamento da plataforma J2EE (+/- 2000), houve o boom. Passados uns anos, fracassos em massa em projetos críticos e a crise dos EJBs. Rod Johnson então põe ainda mais lenha na fogueira com o lançamendo de seu livro J2EE Development Without EJB. Por algum tempo a tecnologia ficou em cheque no mercado (boom do Spring), até que a comunidade resolveu reoxigená-la (JPA, EJB3…). De lá pra cá, a plataforma sofreu grandes ajustes e retoma, gradativamente, sua moral sem, entretanto, o mesmo glamour e frisson de outrora, tendo que brigar agora com concorrentes emersos de sua depressão (Ruby, Python, PHP…).

No lado dos fabricantes de servidores de aplicação J2EE, a mesma história se refletiu. O início do século representou a corrida atrás do ouro e dezenas de empresas entraram na briga dos servidores J2EE. Na metade da primeira década, fracassos de projetos, frustrações tecnológicas e a seleção natural das espécies. Vários produtos de mercado desapareceram. Na sequência, houve a reoxigenação da tecnologia e a establização dos mercados. Quem tinha que adotar J2EE como plataforma de desenvolvimento, adotou. Quem tinha que definir seus servidores de aplicação, definiu. Daí, observa-se a segmentação do mercado entre 4 principais players (Brasília/DF): IBM com Websphere, BEA com Weblogic, Oracle com OAS e Sun com SunONE.

Nesta época, o mundo já conhecia o servidor de aplicações J2EE livre JBoss que, apesar de amplamente respeitado pela comunidade tinha, na esfera pública federal de Brasília, adoção limitada a ambientes de teste ou desenvolvimento. Entretanto, em 2006, após a aquisição do JBoss pela RedHat, e seu consequente estabelecimento operacional em terras brasilis, em Abril de 2007, as bases estabelecidas do mercado brasiliense de servidores de aplicações começaram a ruim.

Curioso ou não, a partir do momento em que alguém se apresentou na Esplanada como representante oficial (e legal) do servidor cuja pressão pela adoção era gerada a partir dos níveis mais baixos da produção e não por articulações político-comerciais de alto escalão, observou-se no cenário brasiliense um processo de migração em massa de órgãos já estabelecidos em produtos proprietários para a solução livre agora da RedHat.

Com um modelo de negócio baseado em venda de contratos de subscrição, em pouco mais de um ano o  servidor de aplicações livre JBoss tem se tornado em Brasília uma das principais plataformas Java de produção, já com vários casos de sucesso divulgados na blogosfera. Neste modelo, muito recorrente no mundo do software livre, o cliente possui todo conforto e autonomia para a tomada de decisões, além de se permitir errar sem grandes prejuízos. Com o recurso necessário para custeio de uma licença proprietária sustenta-se anos de um contrato de subscrição com direito a suporte, acesso imediato aos últimos bug fixes, patches, notícias relevantes e fórum direto com os core developers da tecnologia. E, além do esperado suporte ao servidor de aplicações, todos os projetos desenvolvidos sob a marca JBoss são passíveis de suporte corporativo da RedHat.

Assim como seu sistema operacional, a RedHat manteve todo o código livre e o desenvolvimento do servidor de aplicações sob a dinâmica da comunidade open source. E, assim como o RHEL está para o Fedora, assim está o JBoss.EAP para o JBoss.ORG.

A vinda da RedHat/JBoss para o Brasil reaqueceu um mercado que há muito hibernava. Em sua curta história sob as asas da RedHat, o produto tem adquirido forma de gente grande, com adornos que não deixam a desejar a nenhuma das soluções-proprietárias-intergaláticas-com-promessas-mil. Evoluções recentes, entretanto, o posicionam além do crescimento tradicional de mercado. Discutiremo-las em outra ocasião. A quem estiver neste mercado corporativo, sugiro ficarem antenados.

[]s

Olá pessoal,

Vou aproveitar a entresafra bloguística do pessoal pra deixar uma notinha.

No começo de outubro, publiquei no Blog da Visão Ágil um artigo sobre uma consultoria de Agile que demos no INEP para desenvolvimento do Encceja.

Foi uma experiência muito interessante pra gente, além de considerar um marco muito importante para as metodologias ágeis no Brasil, pois se trata de um projeto de nível nacional e no governo! (Além de outras coisas, como ter utilizado um servidor de aplicação feito em Software Livre).

Espanta um monte de crenças e preconceitos a respeito de Agile.

Leia o artigo na íntegra aqui.

Ah, e pra quem ainda não leu sobre nossa Saga na Aeronáutica,apresentada no Falando em Agile, o Case Sigadaer descrito em maiores detalhes aqui.

Grande abraço, [                  ]

Willi