Entrevista


JBoss, XTS e Byteman: Entrevista com o desenvolver da Red Hat Andrew Dinn

Esta entrevista foi visualizada 26112 vezes.

Publicado em 04/05/2011 às 14:55

Versão para impressão Enviar por email



Andrew DinnPor favor, dê-nos uma visão geral do projeto Transations Web Services. E qual é a sua importância para a Red Hat?


Andrew Dinn » O XTS é uma ferramenta de transação para a criação de aplicativos Web Services de confiança e distribuídos. Ele fornece um conjunto de bibliotecas e serviços utilizados por desenvolvedores de Transactional Web Services e clientes de Web Services.
Estes permitem que um cliente envie solicitações de vários Web Services  independentes e, em seguida, decida confirmar ou reverter as alterações feitas pela serviços de web, ao mesmo tempo em que depende do XTS para garantir as propriedades ACID transacionais padrão.
O XTS é um importante complemento para o JBoss Web Services, pois permite que os programadores desenvolvam aplicativos confiáveis, que enviam solicitações para vários serviços de web distribuídos. As garantias transacionais são essenciais se você quiser acelerar a utilização de um único serviço de web empregando, por exemplo, um banco de dados local para vários serviços acessados através da internet ou, ainda, através de uma intranet da empresa.
Muitas pessoas desaprovam Web Services em favor de soluções baseadas em REST, mas, não importa o quanto a comunidade REST evita esta questão, a necessidade de suporte para transações ainda existe.  Se você precisa comprar um livro de um livreiro e transferir dinheiro entre contas bancárias para pagar o livro, então, a menos que sua livraria também seja dona de um banco, você precisa fazer alterações de forma consistente em dois lugares diferentes. Sem garantias transacionais, em algum momento alguém receberá um livro sem pagar ou pagará por um best-seller que não chega.
Por isso, nós vemos o suporte para transações de serviços de web como um próximo passo natural para aplicativos de web. De fato, assim como XTS, nós também implementamos um serviço de transação protótipo para uso com serviços RESTful, ele próprio baseado em um modelo REST. Independentemente da forma como a indústria evoluirá, nós achamos que haverá a necessidade de gerenciamento de transações para serviços baseados na web.


Como você descreve a plataforma JBoss desde que a Red Hat a adquiriu? Ela mudou ou evoluiu muito?


AD » Bem, eu estou no JBoss desde 2007 somente, depois da aquisição da Red Hat, mas acho que a Red Hat mudou JBoss. Nosso processo de desenvolvimento tornou-se certamente muito mais sistemático e também em escala muito maior.  No entanto, por mais que o processo tenha sido intensificado, é difícil ligar as mudanças no produto com a aquisição da Red Hat. Alguns dos trabalhos, por exemplo, a reescrita do núcleo AS entre as versões 4 e 5, foram iniciados antes do JBoss ser comprado. Além disso, muitas das mudanças foram feitas para implementar melhorias incluídas na especificação do Java EE como o EJB3. Nenhuma delas  aconteceu por causa de algo específico em relação à propriedade da Red Hat.
Quanto à funcionalidade do JBoss AS, o novo microcontentor no AS 5 proporcionou uma série de oportunidades de personalização do AS. Mais valioso que isso, foi que para nós, por exemplo, facilitar a implementação do suporte OSGi, provavelmente foi apenas de interesse de uma minoria de nossos clientes. O AS 6 certamente simplificou o AS 5 e melhorou significativamente o desempenho. O AS 7 deve facilitar a instalação e o gerenciamento, especialmente em instalações agrupadas. Então, no geral acho que houve uma evolução estável no JBoss AS.
É claro que todos esses recursos entrarão gradualmente na Plataforma SOA, juntamente com upgrades para a projetos específicos  de  SOA, como ESB, Drools JBPM. Foi realizada uma quantidade incrível de trabalho nessas ferramentas. Estou muito impressionado com quanto a  equipe de Mark Proctor acrescentou ao Drools nos últimos anos. Mas nada disso parece ter qualquer relação direta com o fato de que a Red Hat comprou o JBoss.


Por favor, conte-nos um pouco mais sobre como o Byteman funciona, e como ele pode ser útil para desenvolvedores.


AD » Byteman é uma ferramenta que faz com que o rastreamento e testes de aplicativos Java sejam mais simples, flexíveis e ad hoc. O principal problema que ele aborda é bem geral: como você entende o que o seu código está fazendo ou fará quando surgirem circunstâncias inesperadas. Por inesperado, não quero dizer somente coisas como as que acontecem quando ele está sob carga e mudanças de cronogramas. Refiro-me também a situações em que uma combinação de circunstâncias surge que você não sabia que poderia acontecer.
As abordagens convencionais para testar e rastrear exigem a escrita de muitos códigos que, na sua maior parte, não implementam a funcionalidade realmente necessária para o produto final realizar seu trabalho.  O rastreamento de depuração e rastreamento de produto são normalmente inseridos em toda a base de código. As rotinas de monitoramento são adicionadas para permitir que os programas de teste ou os aplicativos de monitoramento ao vivo validem o funcionamento do programa. Teste de scaffold ou código falso são criados para permitir que partes dos aplicativos sejam exercidas em isolamento. Além de acrescentar um grande acúmulo de código, todo este software extra geralmente dá muito trabalho para ser criado, é inflexível frente a novas exigências e relativamente pesado. Por pesado eu quero dizer que quando ele estiver habilitado, durante o teste ou na implantação, quase sempre ele altera significativamente a pegada e o cronograma do aplicativo.
Em muitos casos tudo que é realmente necessário para testar um aspecto particular do código é a capacidade de fazer modificações muito pequenas e locais no aplicativo em um ou dois pontos-chave e, em seguida, rastrear algumas ações específicas desenvolvidas pelo programa para ver como ele lida com o cenário de teste. Da mesma forma, o diagnóstico de problemas em um aplicativo implementado pode ser alcançado simplesmente rastreando algumas ações específicas. O Byteman permite modificar automaticamente o código do aplicativo durante um teste ou em implantações exatamente desta forma. Ao invés de inserir lotes de código no aplicativo, você pode inserir apenas o código que você precisa quando você precisar dele.
Na verdade, o Byteman não apenas possibilita, mas também facilita. Você pode escrever um script simples apresentando pequenos fragmentos de código Java e definir com precisão locais de destino onde o código Java deve ser injetado, em seu aplicativo, código da biblioteca ou, ainda, no próprio tempo de execução do Java. O código pode ser injetado durante a inicialização do JVM. De forma alternativa, ele pode ser instalado em um programa em execução, como por exemplo, um JBoss Application Server (AS). O código injetado é dinamicamente verificado para tipo e ligado a métodos objetivados que são recompilados onde necessário. Isso significa que ele pode acessar todos os objetos ou métodos que estão no escopo do ponto de injeção e computar praticamente qualquer informação e realizar quaisquer efeitos secundários que desejar. Você também pode remover o código injetado, restaurando seu aplicativo para o funcionamento normal.


Como a Red Hat vê o papel de suas ferramentas Java, como OpenJDK, em sua estratégia?


AD » Temos uma equipe de desenvolvedores muito experientes, que contribuem com o OpenJDK, desde quando ele foi o primeiro código aberto da Sun. No entanto, mesmo quando se leva em conta a escala de uma implementação total de Java EE, um sistema operacional ou a tecnologia de virtualização relacionada com o JVM, não temos proporcionalmente tantas pessoas trabalhando no OpenJDK como temos trabalhando no Java middleware, ou RHEL ou suporte de nuvem. Assim, a Red Hat está definitivamente interessada em aumentar sua contribuição com esta camada de stack de software e garantir que um JVM aberto de alta qualidade continue disponível para nossos clientes.


A Red Hat é conhecida por sua relação com a comunidade de desenvolvedores, em projetos como o Fedora. Vocês também trabalham muito com a comunidade? Como você pode descrever esta experiência?


AD » Mesmo os mais experientes desenvolvedores do JBoss têm de estar disponíveis para lidar com questões complexas com o cliente que não podem ser tratadas pela nossa equipe de suporte. Isso é bom para nós, desenvolvedores, bem como para nossos clientes, porque nos mantêm em contato com as necessidades de nossos clientes. Há também a expectativa de que ofereçamos auxílio e orientação ocasional aos usuários da comunidade, através de fóruns de usuários e discutamos nossos planos para os projetos nos fóruns de desenvolvedores. Desta forma os usuários da comunidade sabem o que estamos fazendo e podem comentar sobre os nossos planos ou escolher os recursos que eles gostariam.
Mas os fóruns são uma via de mão dupla. Com o projeto Byteman, eu inventivo os usuários a reportar problemas ou erros, mas também tento muito fazer com que eles informem êxitos e expliquem porque e para que estão usando o Byteman. Alguns dos atributos interessantes e inovadores  do Byteman surgiram de ideias que começaram com um fórum de discussão. Discussões no fórum XTS realmente ajudaram a esclarecer ideias e assegurar que os recursos que foram adicionados funcionem da forma que o usuário precisa e não da forma que acho mais fácil de implementar.
Pessoalmente, eu acho que é uma coisa fantástica saber que as pessoas que estão usando o software são capazes de falar diretamente com  você e permitir que você ganhe com suas experiências e compreenda suas preocupações. É mais uma das grandes coisas sobre o código aberto.


Você é formado em a matemática e filosofia. Como você se tornou um engenheiro de software?


AD » Eu deixei a faculdade querendo continuar como um filósofo, mas consternado com a falta de perspectivas de trabalho nesse campo. Então, por acaso, me candidatei a um emprego em uma empresa de software, já que parecia ser interessante. Eu nunca tinha sequer olhado para um computador ou linguagem de programação até então, apesar de que três anos de lógica na Universidade significaram que eu sabia mais sobre a teoria da computabilidade, cálculo lambda, lógica e semântica de modelo teórico do que até mesmo o cientista da computação mais radical gostaria de admitir. Acho que foi a melhor escolha que eu poderia ter feito.


Quantas pessoas você gerencia em sua equipe? Que competências você acha que são importantes para um engenheiro trabalhar na Red Hat?


AD » A equipe de desenvolvimento das transações do JBoss tem apenas quatro pessoas em tempo integral. Além disso, tem também alguns contribuidores, que também trabalham em outras coisas (incluindo o diretor técnico e de pesquisa do JBoss, Mark Little). Todos nós somos programadores muito experientes, por isso nós mesmos nos gerenciamos. Para o Byteman, eu sou o principal desenvolvedor, mas até agora quatro pessoas contribuíram com o projeto.
A gestão do processo de desenvolvimento no JBoss é muito liberal, pois a maioria dos nossos funcionários é altamente experiente e capaz de planejar e executar seu próprio trabalho. Nós definimos metas de longo prazo e de curto prazo, prazos para lançamentos e nos certificamo de que esses lançamentos atendem às necessidades de outras equipes de projeto. No entanto, a responsabilidade é transferida para o indivíduo ou equipes envolvidas, na medida do possível, e contamos com a boa comunicação dos desenvolvedores e na cooperação quando necessário.
Assim, além da óbvia necessidade de conhecimentos técnicos específicos para um determinado projeto, como saber quantos servidores de transação são construídos ou como implementar o EJBs, essas são realmente as habilidades mais importantes que esperamos que um desenvolvedor tenha.


Como você vê o crescente uso de linguagem .net? Em sua opinião, ela é um desafio para o Java?


AD » Bem, eu nunca usei a .net, por isso eu não estou em posição de fazer comentários informados. Eu acho que ter um tempo de execução de linguagem comum é uma coisa muito poderosa e eu os parabenizo por embutir isto desde o início. O JVM agora suporta a uma variedade de linguagens, mas elas foram introduzidas à força, em vez de apenas implementadas. Por exemplo, o suporte para depuradores para identificar as linhas de código em outras linguagens foi implementado, mas de forma um pouco desajeitada em comparação com o Java.
Eu acho que o Java tem duas vantagens em relação à .net. A maior delas é que ele não é proprietário e, em particular, tem uma definição acordada e implementações em código aberto. O JCP e o conjunto vasto de JSRs que definem o Java são uma conquista notável e representam um consenso maciço por parte de um grupo de empresas altamente competitivas. O processo de adoção e execução do JSRs tem muitas falhas, mas o resultado final tem uma vantagem grande sobre uma oferta da Microsoft, que é de propriedade total da empresa e definido por ela.
A segunda vantagem é o intervalo de escalonamento dos JSRs e, por conseguinte, das muitas implementações de Java EE deles derivados. Para todas as funcionalidades que não são definidas por estas especificações, é impressionante o quanto é definido e padronizado e pode ser usado em implementações concorrentes. Nós nunca vimos um esforço de padronização desta escala ou com esta quantidade de sucesso antes e eu só espero que a indústria, os fornecedores de Java EE e desenvolvedores de Java EE reconheçam isso e a usem como base.


Você trabalha como engenheiro de software desde 1984. Em sua opinião, o que foi a maior inovação em linguagens de computador desde então?


AD » Eu tive sorte o suficiente para desenvolver software em uma das máquinas PARCs Xerox Lisp em 1985. Ela incorporou mais de uma década de trabalho pelos maiores cientistas da computação da América, todas as pessoas da Xerox podiam comprá-la com desconto de imposto. Isso incluiu evoluções históricas, como estações de trabalho e servidores, redes locais, intrarredes e internet, e-mail, processamento de documentos, múltiplos desktops, manipulação direta, interfaces, hipertexto, programação orientada para objetos, chamadas de procedimento remoto, arquiteturas cliente / servidor e, o mais incrível de tudo, um sistema operacional inteiro escrito em Lisp. A revolução que ela provocou acabou desaparecendo depois que a Xerox perdeu seu monopólio em fotocopiadoras. E todos os inventos foram restaurados pela Windows, Unix, Linux ou Mac OS, principalmente em uma versão muito mais limitada e reduzida.
Então, se você quer que eu rigorosamente fale de uma linguagem, eu teria que dizer Interlisp-D, a linguagem do tempo de execução da máquina Lisp (além de também LOOPS, a linguagem orientada a objetos que ela incorporou) porque ela possibilitou todas essas tecnologias em um sistema coerente e integrado.
Obviamente, Smalltalk-80 é também um forte concorrente e muitas das capacidades da máquina Lisp também estivam presentes no ambiente Smalltalk da Xerox. No cômputo geral acho que a capacidade de metaclasse no LOOPS, que mais tarde evoluiu para o CLOS, o Common Lisp Object System, é bem superior ao modelo metaclasse Smalltalk, assim o Interlisp-D vence.


Comentários

lançamento!

LM 119 | Backup e Restauração




Impressa esgotada
Comprar Digital  R$ 10,90 Digital

  1. Baixe o curso de shell script do Julio Cezar Neves

    Publicado em 07/04/2008 às 19:41 | 433275 leituras

  1. Soluti Certificação Digital em busca de especialista Linux

    Publicado em 19/04/2017 às 17:18 | 308029 leituras

  1. Seminário sobre gestão de privilégios do Linux dá direito a certificado CPE

    Publicado em 23/05/2017 às 10:35 | 223281 leituras

  1. Resultado do concurso "Por que eu mereço ganhar um netbook?"

    Publicado em 30/09/2009 às 3:00 | 184914 leituras

  1. Software público brasileiro na Linux Magazine Especial

    Publicado em 29/07/2011 às 15:07 | 163275 leituras

  1. Tux3 inicializado pela primeira vez como sistema de arquivos raiz

    Publicado em 25/02/2009 às 23:04 | 8608 leituras

  1. Pinguim gigante faz sucesso no fisl11

    Publicado em 23/07/2010 às 17:09 | 8737 leituras

  1. Google libera o Android – com código-fonte!

    Publicado em 22/10/2008 às 11:29 | 7340 leituras

  1. Intel e Wind River embarcando Linux em veículos

    Publicado em 21/05/2008 às 16:31 | 9664 leituras

  1. Desenvolvedores do Amarok lançam campanha para arrecadar fundos

    Publicado em 20/10/2010 às 16:44 | 8368 leituras

whitepapers

mais whitepapers