Bruno Pereira

Acabei de saber do anúncio da compra da Sun pela Oracle, e posso dizer que fiquei muito surpreso. A Oracle é uma empresa que vive desde o começo de venda de licenças, e todo seu histórico de aquisições foi nessa linha, comprando empresas como a Peoplesoft, Siebel e BEA.

O que me intriga é que a Oracle não é tradicionalmente uma empresa de serviços. Ela costuma desenvolver e vender produtos, e a prestação de serviços é feita através de parceiros, como a Concrete por exemplo. Não consegui ter ainda a visão de como essa aquisição vai se encaixar dentro da estratégia da Oracle.

Não sei bem também como será a relação da Oracle com Open Source. A Sun não vinha tendo resultados financeiros muito bons, mas mantinha muitos projetos open source importantes, como o Glassfish, Solaris, MySql, stack SOA e vários projetos Java em geral. Além disso, desempenha um papel muito importante no desenvolvimento de linguagens dinâmicas para a JVM, além do desenvolvimento da própria JVM.

Se em termos de software tenho várias dúvidas, em relação às ofertas de hardware da Sun eu já consigo ter algumas idéias. Um dos principais concorrentes da Oracle é a IBM, que tem um braço bem forte de hardware. Não é raro a IBM ganhar concorrências com a Oracle “dando” o hardware, e vendendo o software. A Oracle não tinha condições de oferecer uma proposta equivalente, mas agora isso será possível.

Além disso, a Sun anunciou recentemente sua oferta de Cloud Computing, que pode ser um mercado que a Oracle quer entrar. Como ela já possui muitas aplicações críticas para empresas, ela pode querer oferecer estas aplicações como serviços, em uma estrutura de Cloud. Posso estar totalmente fora do alvo, mas não duvido que isto seja um objetivo da Oracle para diversificar seu modelo comercial.

Assim como em outras aquisições, muita coisa ainda não está clara, mas já temos vários aspectos para prestar atenção.

Pessoal, a Concrete fechou mais projetos, e estamos com várias vagas, para todos os níveis de experiência. Os principais projetos que temos feito envolvem desenvolvimento de portais colaborativos de internet/intranet, integração de aplicações e soluções móveis.

No momento atual, temos de 8 a 10 vagas, todas para início imediato e horizonte de longo prazo. Queremos profissionais que tenham paixão por software e auto-motivados, buscando evolução contínua. Profissionais deste perfil encontrarão um ambiente ótimo para seu crescimento dentro da Concrete. A descrição técnica dos perfis pode ser vista a seguir.

Os níveis de experiência são variados, então entre em contato se você se julgar dentro do perfil de profissional que buscamos. Quem quiser mais informações, não deixe de entrar em contato.

Desenvolvedor Java (preferencialmente com experiência em Web e/ou Mobile)

Java SE 5 e/ou 6. Java EE 1.4 e/ou 5.

JPA e/ou Hibernate são bastante desejáveis. Importante conhecer banco de dados relacionais e mapeamento objeto-relacional.

Experiência de uso com alguns dos seguintes application servers: BEA Weblogic 9 ou 10, Jboss AS, Jetty, Apache Tomcat  e Geronimo.

Struts, Spring MVC ou outro framework para web em Java. Boa experiência com Grails, Ruby on Rails ou Django também são válidos, e podem nos interessar mesmo se você não conhecer um framework web Java.

Inglês para leitura e estudo de material técnico.

Desejável

Graduação em Ciência da Computação, Engenharia da Computacão ou Informática

Conhecimento e interesse em outras linguagens de programação é bastante apreciado: Python, Scala, Ruby, Rhino, Javascript, Perl, OCAML, Common Lisp.

Bons conhecimentos de client-side (HTML, CSS, Javascript) são muito positivos.

Conhecimento de plataforma Linux é desejável, mas não obrigatório.

Conhecimento em shellscripting para Unix/ Linux é muito bem-vindo.

Os interessados devem enviar um e-mail com currículo para marcia.cataldi@concretesolutions.com.br com cópia para bruno.pereira@concretesolutions.com.br

Hoje o Sacha Labourey (CTO da JBoss) publicou um post interessante sobre as dificuldades que a Sun vem encontrando, em especial com seu modelo de negócios open source. Como eu já pensei um bocado sobre isso e conversei com algumas pessoas, vou deixar aqui algumas opiniões.

Na minha opinião, a Sun fez e vem fazendo um excepcional trabalho mantendo a plataforma Java como um todo. O problema todo está no contexto que girou em torno disso.

Em um determinado momento a Sun lutava bastante contra a Microsoft e suas soluções Windows/.NET, e de fato parecia que as empresas seriam adversárias. O que ocorre é que a Sun gastou tantas energias combatendo a Microsoft que não dedicou o esforço necessário para conquistar espaço dentro do próprio mercado Java.

O Glassfish V2 foi o primeiro bom servidor de aplicações da Sun, mas ele chegou bem tarde. Muito antes a BEA e a IBM já tinham um vasto portfólio de produtos Java Enterprise, e servidores de aplicação bem melhores do que o antigo Sun Application Server. Com isso, mesmo com o enorme sucesso da plataforma Java, a Sun não estava muito bem posicionada no mercado de software.

Creio que em decorrência deste primeiro problema (a falta de um bom app server), veio o problema que eu acho o mais grave. Na minha opinião o que fez mais falta à Sun é um bom modelo de serviços em torno da plataforma que ela desenvolveu tão bem. A Sun tem muitos grandes engenheiros, mas não conseguiu traduzir isso em muito lucro com Java. Penso que um modelo de serviços semelhante ao da IBM teria sido adequado à Sun, mas para isso eles precisariam de um portfólio de produtos melhor.

O grande (e bem-sucedido) esforço no desenvolvimento da plataforma Java consumiu energias que poderiam ter sido aplicadas na construção de uma linha de produtos mais rica, e com isso o sucesso do Java acabou drenando muito da saúde da Sun.

Mais recentemente a Sun tentou mudar a sua estratégia, e passou a abraçar ainda mais o modelo open-source. Embora isso tenha sido muito bem recebido pela comunidade de desenvolvedores, não podemos dizer que essa mudança tenha trazido mais sucesso para a empresa.

Eu tenho a clara impressão de que a Sun abraçou este modelo sem ter muita noção do que a esperava, mas talvez a sensação fosse de que não havia uma outra alternativa óbvia. A verdade é que a Sun está há anos lutando, mas sem encontrar a estratégia correta. O modelo de negócios em torno de open source foi mais uma tentativa da empresa, mas não estou vendo muitas perspectivas da Sun conseguir deste modelo as receitas necessárias para cobrir seus custos.

Eu fico triste por essas dificuldades da Sun, pois eles fizeram um excelente trabalho desenvolvendo a plataforma Java, mas isso custou a própria saúde da empresa.

E o que poderá vir em conseqüência? Difícil dizer, mas me parece inevitável que a Sun seja comprada por um player de maior porte, como a HP ou a SAP.

Como a Oracle agora é um concorrente direto da SAP em várias linhas, e a SAP começou a investir em Java, talvez faça sentido que a gigante alemã compre a Sun.

Quanto à HP, seria um movimento muito mais coerente do que a compra da EDS, que ocorreu esse ano. Comprando a Sun, a HP teria a stack completa, com hardware HP, sistema operacional e middleware da Sun, e serviços provenientes da EDS. Isto a deixaria em situação semelhante à da IBM, e acho que faria sentido nesse contexto atual.

Não sei qual será o futuro da Sun, mas sinceramente torço muito para que seja próspero, pois seu legado de contribuições ao cenário mundial de software é valioso demais para que a empresa tenha um final agonizante.

Com a minha mudança de alocação da Globo.com para a Globosat, continuo trabalhando bastante com integração de aplicações, mas agora com um ferramental e paradigmas diferentes.

Na Globo.com eu trabalhei muito com open source, e estava acostumado a montar as aplicações a partir de componentes “crus”, em vez de usar ferramentas sofisticadas. Open source faz parte da cultura da empresa, e tínhamos uma boa liberdade de escolha de tecnologias e arquiteturas.

Como falei algumas vezes no passado, nós migramos boa parte da arquitetura legada com EJBs para serviços REST usando por baixo o Jersey, Spring e Ibatis. A produtividade no desenvolvimento de serviços REST me agrada muito, e mesmo alguém que não conheça muito de serviços REST consegue desenvolver um serviço sem tanto esforço.

Agora vou trabalhar mais com serviços SOAP, mas usando ferramentas muito produtivas, como o Aqualogic ESB e o Workshop, entre outros. Essas ferramentas facilitam muito o trabalho oferecendo Abstrações Opacas. Como ainda estou muito ligado ao trabalho com Open Source, eu venho tentando no meu tempo vago encontrar ferramentas open source com a mesma proposta.

Neste momento estou tentando encontrar a maneira mais produtiva de se trabalhar com web services SOAP usando open source. No passado eu desenvolvi serviços com o XFire, com o Axis 2 e com o JAX-WS, mas achei interessante reavaliar as opções existentes atualmente.

Nos últimos dias eu fiz testes com o Axis 2, com o Apache CXF e com o JAX-WS.

Eu não gosto muito do Axis 2. Você até consegue desenvolver serviços rapidamente com ele, mas ele gera um código tão sujo que é muito triste colocar qualquer coisa em produção com ele, sabendo que você vai ter que manter depois aquele código. Além disso, para utilizá-lo você precisa levar nada menos que 51 jars para sua aplicação, o que transforma qualquer aplicação em um mastodonte. Um outro problema dessa lista massiva de dependências é que a chance de uma aplicação pré-existente ter conflitos de dependências com o Axis é grande.

Na prática, eu só utilizaria o Axis 2 (e mesmo assim com má vontade) para desenvolver serviços se fosse numa estrutura como o WSO2 Web Services Application Server, que é um servidor de aplicações “dedicado” a serviços Axis.

O Apache CXF oferece um “front-end” com JAX-WS (que é o mais recomendado) e um “front-end” alternativo, que usa o Aegis Databinding. Por enquanto olhei apenas o front-end com JAX-WS, mas não vi nenhuma vantagem em utilizar o CXF em vez da implementação de referência presente no Glassfish. Se pintar disposição eu darei uma olhada no front-end com Aegis Databinding, mas por enquanto não tenho grandes expectativas em relação a ele não.

Para finalizar, fiz muitos experimentos com a implementação de referência do JAX-WS, embutido no Glassfish V2. A forma de trabalho que achei mais produtiva nestes meus testes foi desenvolvendo com JAX-WS no Netbeans (utilizei a versão 6.5).

Tentei desenvolver a partir de classes Java, e a partir do WSDL, e esta última me trouxe melhores resultados.A melhor forma que achei foi começar desenhando os schemas XML com o editor do Netbeans:

Criei um Complex Type para cada classe de domínio, e 1 Complex Type para o Request de cada operação e 1 Complex Type para o Response de cada operação. Tendo feito isso, criei depois 1 Element para o Request de cada operação e 1 Element para o Response de cada operação. Com o schema XML criado dessa forma, criei em seguida o WSDL, com o editor do Netbeans também:

Na criação do WSDL, coloquei nas mensagens de Request/Response das operações os Elementos declarados no schema XML anterior. É importante prestar atenção nisso. Usando Elementos nas mensagens, você está criando serviços no modelo Document/Literal. Se você colocar nas mensagens um Complex Type diretamente, em vez de colocar um Elemento, você estará criando um serviço no modelo RPC/Literal. Eu particularmente prefiro Document/Literal, e o código gerado pelo JAX-WS neste modelo me agrada mais.

A implementação do serviço com JAX-WS ficou parecida com isso aqui:

package org.brunopereira.cadastro;
import javax.jws.WebService;
import org.brunopereira.schema.cadastroclientes.CadastroClienteRequestType;
import org.brunopereira.schema.cadastroclientes.CadastroClienteResponseType;
import org.brunopereira.schema.cadastroclientes.Cliente;
import org.brunopereira.wsdl.cadastrocliente.CadastroClientePortType;
 
@WebService(serviceName = "CadastroClienteService", portName = "CadastroClientePort",
endpointInterface = "org.brunopereira.wsdl.cadastrocliente.CadastroClientePortType",
targetNamespace = "http://brunopereira.org/wsdl/CadastroCliente",
wsdlLocation = "WEB-INF/wsdl/CadastroCliente/CadastroCliente.wsdl")
public class CadastroCliente implements CadastroClientePortType {
public CadastroClienteResponseType cadastrarCliente(CadastroClienteRequestType request) {
System.out.println("Cadastro de cliente foi invocado!! Será feito o roteamento para o serviço adequado!!");
Cliente cliente = request.getCliente();
CadastroClienteResponseType response = new CadastroClienteResponseType();
response.setCliente(cliente);
return response;
}
}

O código do cliente foi gerado bem facilmente a partir do WSDL também, e ficou bem limpo. O que achei bem fraco foi a parte de teste dos serviços tanto no Netbeans como no Eclipse. No Eclipse você só consegue usar os plugins de teste se você tiver desenvolvido os serviços dentro do Eclipse, o que inviabilizou o meu uso. E o Netbeans tem um suporte que só serve pra HelloWorld, pra aqueles serviços de Calculadora, que você passa uns parâmetros primitivos e recebe um resultado simples. A interface do testador do meu serviço ficou dessa forma:

Dá pra ver que não serve para nada além de um HelloWorld basicão.

Bom, de uma maneira geral, o suporte a Web Services no Netbeans é muito melhor do que no Eclipse, que pra piorar só suporta a criação de serviços com o Axis. Até agora a maneira mais produtiva que encontrei de trabalhar com serviços SOAP foi essa que descrevi. Nos próximos dias olharei o que tem de interessante no projeto Metro e no JBoss ESB. Se encontrar coisas interessantes falarei mais por aqui. Ah, e se alguém tiver dicas para melhorar esta forma de trabalho que descrevi, por favor me avisem, pois estou avaliando muita coisa e não dá tempo de dedicar tanto tempo a cada opção dessas.

No mundo de software nós freqüentemente encontramos ferramentas, frameworks e outros ítens que nos abstraem alguns conceitos, e nos dão uma maneira de trabalhar “mais alto nível”.

Nessas situações, é comum ouvirmos que essa abstração é “transparente para o desenvolvedor”, “transparente para o usuário”, ou “transparente alguma coisa”. Essa terminologia abstrai (usar esse termo aqui foi irresistível ) dois tipos de abstração bem diferentes, então vou falar um pouco sobre os dois tipos de abstração encontrados em software, com algumas opiniões sobre ambos.

O que eu chamo de Abstrações Transparentes são as que te oferecem uma forma de trabalho num nível mais alto, mas te permitem ver (é transparente afinal de contas) o que está por baixo dos panos sem tanto esforço. Um exemplo disso eu diria que é o que acontece no Struts e no Spring MVC.

Frameworks web deste estilo tentam te dar um desenvolvimento mais produtivo, sem que você tenha que se preocupar com tudo que está envolvido no processamento de requisições e respostas HTTP. Entretanto, o fluxo de processamento da requisição e resposta é bem intuitivo do ponto de vista do que está acontecendo na interação do usuário com o servidor. E se você quiser manipular a requisição e a resposta, você conseguirá facilmente, sem “burlar” a proposta do framework.

O que eu chamo de Abstrações Opacas são as que também te oferecem uma forma de trabalho num nível mais alto, mas te escondem bem mais o que está acontecendo por baixo dos panos. O objetivo é de fato que você não precise saber dos detalhes, e não queira se meter com eles. Um exemplo disso é o que acontece no JSF e no Wicket, e também no Aqualogic Service Bus.

O JSF e o Wicket oferecem um paradigma de desenvolvimento web diferente do tradicional modelo “Request/Response”. Eles têm um modelo componentizado, no qual a requisição e a resposta HTTP ficam bem encapsulados, e as suas interações com o usuário devem ser totalmente focadas nos componentes. A idéia é que você realmente não veja o que está rolando por baixo dos panos, e não se envolva mesmo com os detalhes.

Eu pensei um pouco sobre isso hoje mais cedo, mexendo com o Aqualogic Service Bus. Troquei umas idéias sobre o que ele faz quando ocorre mais de uma chamada a mais de um web service dentro da mesma transação, e na hora eu pensei: “Ainda bem que essa abstração é opaca!” :)  A ferramenta é sensacional e cuida de muitos detalhes cabeludos do trabalho com WS-* sem que você precise fazer na mão.

Sobre os dois tipos de abstração, a decisão de qual é mais adequado varia muito com a situação e com gostos pessoais. Em relação a frameworks web, eu tenho me dado muito melhor com Abstrações Transparentes, pois eu quero ver os detalhes e quero ter controle sobre eles.

Em situações em que não queremos controlar os detalhes do que está sendo feito, as Abstrações Opacas são muito boas, pois nos poupam esforços. É interessante saber em cada situação qual tipo de abstração você quer, porque a sua escolha de tecnologias e ferramentas será traçada com isso em mente.

Então na próxima ver que alguém disser que alguma coisa é “transparente”, veja logo se é Transparente ou Opaca

Ontem na minha apresentação de REST no RioJUG um rapaz (infelizmente não sei o nome dele) me perguntou se eu conheço algum curso ou treinamento sobre REST.

Não conheço nenhum curso disso e não sei se teremos algum em breve. Na verdade, como o Guilherme comentou, existem muito poucos cursos de web services, mesmo os WS-*, que já são bem antigos.

Resolvi escrever esse post para tentar colher opiniões do pessoal quanto a um curso nesse assunto. Vocês se interessariam por um curso de REST? Será que esse curso teria muitos interessados ou a maioria dos desenvolvedores iria preferir a maneira autodidata mesmo? Para os que assistiram a alguma das minhas apresentações de REST, vocês acham que uma expansão do conteúdo com maior detalhamento e exemplos práticos bem explicados daria um bom curso?

A Concrete já ministra alguns treinamentos em produtos da BEA, então certamente haveria espaço para novos cursos de conteúdos interessantes. Eu gosto de fazer apresentações, mas nunca preparei um curso. Estou tentando participar de mais eventos, e também já pensei em atuar um pouco com treinamento técnico, mas ainda não me decidi sobre isso.

Opiniões são bem-vindas

Hoje foi anunciado que a HP está comprando a EDS. O valor divulgado da compra é de US$ 13.9 bi.

Li algumas notícias dizendo que este movimento da HP tem como objetivo fortalecer a empresa para competir com a IBM. Entretanto, tenho sérias dúvidas se isso terá sucesso. A HP tem muita força na venda de equipamentos, e também presta serviços de manutenção de infra-estrutura. Já a EDS é uma gigante na prestação de serviços de software, tanto na área de manutenção de infra-estrutura como no outsourcing de aplicações, e consultoria de uma maneira geral. Como algumas áreas das empresas claramente se sobrepõem, imagino que muitos empregos serão cortados.

A HP passará a ter uma estrutura gigantesca, mas ainda ficará atrás da IBM em termos de faturamento. Além disso, embora fortaleça a empresa na disputa com a IBM, não fortalece tanto. A IBM tem uma área enorme de produtos de software que a HP continuará não tendo. Será muito difícil para a HP ganhar espaço contra a IBM sem um braço de software forte. Principalmente na área de middleware, onde a IBM está muito forte. E além da IBM, a HP teria que brigar também contra a Oracle neste nicho, depois que ela comprou a BEA.

É bom lembrarmos que a HP não tem lá um bom histórico em compras. A aquisição da Compaq foi bem traumática e não teve custo-beneficio muito bom para a HP. O mercado americano também não reagiu bem a essa compra da EDS. As ações de ambas as empresas caíram razoavelmente, mostrando que a maioria das pessoas do mercado não achou este negócio uma boa idéia para as empresas.

Na minha opinião, a HP após esta compra ainda é uma empresa incompleta para competir com a IBM, Oracle e Sun. Antes dessa compra a HP não era tida como concorrente direta dessas empresas, mas agora ela é. Penso que para a HP ter realmente relevância nessa disputa, ela precisará de um braço forte de middleware, e uma boa pilha de software em geral.

Com o histórico que a empresa tem, duvido que ela se transforme nisso por conta própria. Na minha visão o que faz sentido é a HP comprar mais alguma(s) empresa(s), para conseguir complementar suas ofertas de serviços. Considerando a consolidação atual do mercado, acho que faria sentido que a HP comprasse a Red Hat, levando o JBoss de lambuja. Além disso seria interessante que eles contassem com algum servidor de BD na pilha, já que os concorrentes possuem isso (DB2, Oracle e MySql). Uma ótima opção seria comprar a EnterpriseDB, que oferece uma versão comercial do Postgres, o excepcional BD open source.

De todas as grandes aquisições que rolaram recentemente, esta da HP é a que menos faz sentido, pelo menos atualmente. Dependendo das ações que eles tomarem em seguida, esta compra pode ser uma boa jogada ou um episódio lamentável como a compra da Compaq. Torço para que a HP aumente seus já fortes vínculos com Linux e Open Source e compre a Red Hat para se apresentar firmemente como competidora de peso. E claro, continuo torcendo pelo sucesso do meu estimado Postgres