Bruno Pereira

Today my team started a new Sprint, with several very interesting technical stories. We are progressively migrating an architecture that uses EJB 2.1 for client-server communication and also for transaction control. Our new architecture uses RESTFul services (currently with Jersey 0.7) for communication and Spring + Ibatis underneath.

One of the main issues with the old architecture is the tight coupling between the server and the clients. The way it was designed, our server platform is limited by the oldest client’s platform.  To have more flexibility and loose coupling between server and clients, we decided to have an XML contract in the communication.

In this Sprint we must finish the implementation of a Java client to be distributed to the client applications. We have some optimization and refactoring tasks for this Sprint, and one of them includes a RESTFul registry. We don’t want the clients to have our URIs configured via properties files. This approach limits our flexibility to manage URIs, so a different approach is desirable.

Our client will access a repository to ASK FOR the URI corresponding to a given service AND version. That means: the client willing to access the login service will ask the repository for the URI of this service, in the client’s version. The client could ask for /repository/login/v2.0 and then receive back the URI http://login.globo.com/login/v2.0.

We could have several different versions of the same services, each of them with different contracts. Introducing the repository as an extra layer of indirection, we also have the flexibility to take down several server machines for a while and even update URIs if desired (although that’s unlikely).

I checked Mule Galaxy and WSO2 Registry, but unfortunately they don’t give me what I need. They’re both open source registries, but they index SOAP services and some other things, but not RESTFul URIs. They offer a REST API to interact with their registries (unlike UDDI, which uses SOAP), but don’t index RESTFul URIs at this moment.

After this analysis of both, i decided to implement my own RESTFul registry. It shouldn’t be too sofisticated for this first release, but since it’s a frequent need in my team, I’m probably going to take some off-time to develop a nice registry that might be useful for a wider range of applications. My goal with this post is to gather some requirements for this registry and also its client. Features that would be useful for other people too.

The initial set of requirements that I wanna deliver in this Sprint is:

• Must have a RESTFul API to search for services
• Should be possible to browse published services with a web browser (even IE, if you call it a browser)
• Ajax clients should be able to access the registry easily
• Java client must run on JDK 1.4 and above
• Java client should require as few libraries as possible
• Registry should access the database through a JDBC datasource
• Offer an authenticated user interface to publish the services (probably with Java EE authentication)

An extra list of desirable features (not for this Sprint) is:

• Import service URIs from WADL document
• Allow database access without a JDBC datasource
• Show history of modifications in the registry
• Registry should be distributed as .war
• Offer other ways of authentication

Well, that’s the first ideas that come to my mind. My intention is to implement a nice registry and offer it for everyone to use it. If you think of some other features that would be nice in the registry, please let me know. The idea of this post is to be an asynchronous brainstorm, so please help!

Algum tempo atrás o Fabiano me perguntou qual implementação de persistência em Java eu julgava a melhor opção. Na época conversamos um pouco sobre isso e eu estava para escrever sobre o assunto faz tempo.

Essa semana falei novamente sobre o assunto numa thread do CEJUG e então vou finalmente expôr algumas opiniões por aqui.

Provavelmente a implementação de persistência que está mais “na moda” atualmente é a Java Persistence Architecture (JPA) ou frameworks independentes com a mesma proposta, como o Hibernate e o Toplink. Realmente a proposta desta tecnologia é excelente. Quem programa usando orientação a objetos de verdade sempre prefere manipular classes de domínio ricas, e não gosta muito de lidar com as diferenças de paradigma que existem entre este modelo e o modelo relacional de bancos de dados.

A JPA aparentemente é bem fácil de usar, colocando anotações para mapear as classes e atributos em tabelas e colunas do banco de dados e colocando algumas anotações para declarar os relacionamentos entre as entidades. O problema que eu vejo é que as anotações de JPA são um tanto confusas. Em algumas situações você vê uma quantidade razoável de opções, e não fica tão óbvia a forma que você tem que usar as anotações.

Além disso, o esforço de analisar o comportamento da JPA é muitas vezes considerável. Você não escreve as queries, mas precisa acompanhar muito bem as queries que estão sendo geradas, se está sendo feito JOIN ou múltiplas queries, etc. Esse tipo de coisa a JPA abstrai da gente, mas muitas vezes os comportamentos não são triviais, e o esforço de monitorar isso não é desprezível. Uma anotação mal colocada pode te trazer problemas graves de performance e alguns dias de análise para otimização.

Eu gosto bastante da idéia de frameworks de mapeamento objeto-relacional. Quem trabalha verdadeiramente com orientação a objetos sempre quer ter a comodidade de usar este paradigma na aplicação toda. Entretanto, essas opções que temos em Java são complexas e muitas vezes não trazem ganhos de produtividade comparando com alternativas como o Ibatis por exemplo.

A parte mais chata da persistência em Java é escrever o código JDBC de gravação de objetos no BD e recuperação dos mesmos. Aqueles tratamentos altamente repetitivos e trabalhosos de conversão de colunas do BD de diferentes tipos para seus atributos das classes. Eu odeio escrever esse tipo de código, e o Ibatis ajuda demais nesse sentido, sem introduzir complexidade.

Uma coisa positiva que eu vejo no Ibatis é que ele é bem simples de usar e muito óbvio e previsível. Você manipula as coisas com o paradigma relacional, que embora tenha seus defeitos é amplamente conhecido de todo mundo e fácil de manipular. Usamos a DSL que é provavelmente a mais bem-sucedida até hoje (SQL).

A implementação de mapeamento objeto-relacional do Django (framework Python) por exemplo é excepcional, extremamente inteligente e produtiva. Muito dificilmente trocaria ela pelo Ibatis (assumindo que trocar fosse uma opção). Mas já há algum tempo eu estou desiludido com a JPA e vejo o Ibatis como uma opção com melhor custo-benefício.

Em situações em que o time todo domina plenamente JPA e já têm uma boa experiência com a mesma, é possível que o time ganhe um pouco de produtividade ao usá-la. Entretanto, em muitas situações o custo-benefício pode ser pior do que usar o Ibatis.

Já presenciei alguns casos em que a adoção de JPA em diferentes equipes prejudicou mais do que ajudou.  Os principais motivos para isso foram:

• Falta de experiência geral do time com a tecnologia
• Modelos legados de BD que não permitem um mapeamento de classes tão interessante
• Grande esforço de tunning

Eu e outros profissionais que eu respeito muito já passamos por esse tipo de situação, em que acabou prevalecendo o pragmatismo e a visão do que é valor para o negócio.

Eu li uma entrevista com o Carlos Ghosn (o brasileiro presidente da Renault e Nissan) na qual ele falou que a Nissan passou a ter bons resultados quando os engenheiros pararam de colocar ítens que eles achavam “bonitos” nos projetos, mas que os usuários nem percebiam. O argumento era mais ou menos esse: o usuário quer que o carro funcione bem, não importa para ele se o revestimento do motor vai ser de adamantium e resistente a criptonita

Decisões técnicas devem ser tomadas com foco no valor de negócio, em vez de focar na tecnologia que ficará mais bonita no currículo. Não esqueçam do exemplo do Carlos Ghosn

Como falei anteriormente, estou usando o SQL Server 2000 para um projetinho freela. Para me conectar ao SQL Server, baixei o driver jdbc jtds, pois li que ele funciona melhor que o driver jdbc fornecido pela Microsoft. Isto não me surpreende muito, pois a Microsoft não deve ter muito interesse em alavancar o uso de Java com o SQL Server, preferindo sempre empurrar o uso de .NET.Pois bem, eu estava tendo problemas para me conectar ao SQL Server via jdbc. Inicialmente o problema parecia ser da forma de autenticação, pois o servidor foi instalado com as opções default e as configurações padrão especificavam autenticação pelo Windows somente, sem autenticação pelo SQL Server. Eu encontrei na internet várias referências dizendo que os drivers jdbc para o SQL Server 2000 não suportam autenticação pelo Windows, então habilitei também a autenticação pelo banco de dados.

Após habilitar a autenticação pelo banco de dados, eu continuava sem conseguir conectar. Os problemas eram sempre os mesmos, e a mensagem de erro era essa aqui: “An error occurred while establishing the connection: Type: java.sql.SQLException Error Code: 0 SQL State: 08S01
Message: Network error IOException: Connection refused: connect”. Procurando por esse erro, encontrei algumas referências sugerindo conferir se o servidor estava configurado para permitir acesso por TCP/IP, e no meu caso estava sim.

Como eu não estava conseguindo conectar de forma alguma usando TCP/IP, tentei conectar através de named pipes, e funcionou. Minha URL de conexão com o uso de named pipes ficou da seguinte forma: jdbc:jtds:sqlserver://127.0.0.1:1433;DatabaseName=sistema_cms;namedPipe=true

Ah, um detalhe importante. Ao tentar usar essa URL com localhost em vez de 127.0.0.1 , eu recebia um erro dizendo que o nome da máquina não era encontrado na rede. Colocando o hostname correto da máquina (no meu caso, blpsilva-vostro) funcionou sem problemas também. Possivelmente esta solução que utilizei não é a melhor possível para situações mais críticas. Entretanto, para o meu caso esta solução excede bastante o “good enough”, então fiquei com ela mesmo.

OBS: Esse template do Wordpress tem o péssimo hábito de eventualmente cortar algumas frases que não caibam na largura da área central . Para não prejudicar a leitura aqui, segue abaixo novamente o nome do último parâmetro da URL jdbc:

namedPipe=true

Com a crescente adoção do uso de Linux, algumas pessoas têm me perguntado qual software de acesso a banco de dados eu uso no Linux. Eu utilizo um software que já conheço desde os meus tempos de desenvolvimento para PDAs, quando o DbVisualizer era a única forma conhecida de se acessar as bases de dados dos dispositivos móveis.O software pode ser baixado a partir daqui, após preenchimento de um pequeno cadastro. Para que usa distribuições baseadas em pacotes rpm, a opção do download do rpm é mais conveniente, e a instalação pode ser feita com o comando rpm –install nome_arquivo_dbvis.rpm. Para Linux em geral, pode ser utilizado o instalador em formato .sh

Baixando o instalador .sh, basta copiar o arquivo para um diretório qualquer de sua preferência e executá-lo como ./dbvis_linux_6_0_2.sh para iniciar o processo de instalação.

Caso o instalador não se inicie normalmente, verifique se o arquivo .sh está com permissão de execução (caso não esteja, faça chmod a+x dbvis_linux_6_0_2.sh) e se você possui o Java no PATH do seu usuário. Para verificar se você possui o Java e a versão do mesmo, use o comando: java -version. O recomendado é ter uma versão de Java da Sun e que seja a partir do 1.5. Muitas distribuições Linux instalam uma versão do Java da GNU, mas não gosto e não recomendo esta versão. Coloque o diretório do Java da Sun no começo do PATH do usuário (se alguém não souber como, eu explico posteriormente).

O processo de instalação em si é bastante simples. Você precisa apenas aceitar os termos de uso do software e escolher o diretório de instalação. No resto, aceite as opções padrão apresentadas e Next -> Next -> Next O processo de instalação cria um atalho no Desktop.

Com a aplicação instalada, vou mostrar agora como configurar a aplicação para conseguir acessar o Oracle. O driver jdbc do Oracle não vem incluído na instalação do DbVisualizer. Para conectar ao Oracle é necessário carregar o driver. Para isto, entre na opção Tools -> Driver Manager, conforme abaixo:

Nesta tela que abrir, selecione no menu esquerdo a opção Oracle Thin e então na janela que se abrirá, você terá que selecionar o jar do driver jdbc do Oracle (ojdbc14.jar ou classes12.jar), conforme abaixo:

Se o jar foi corretamente carregado, a opção do Oracle Thin aparecerá verde. Tendo feito isso é hora de criar a conexão. Vá para a tela principal da aplicação, e no menu esquerdo, clique com o botão direito na opção Connections e então escolha Create Database Connection. Escolha por não usar o wizard, e você chegará na tela a seguir:

Preencha os campos da seguinte forma:

• Alias: nome que você quer dar à conexão
• Database Type: Oracle
• Driver (JDBC): Oracle Thin
• Database URL: url jdbc de acesso, conforme será explicado abaixo.
• Userid: usuário de banco
• Password: senha do usuário

A URL jdbc varia de um servidor para o outro. No caso do Oracle, o formato é conforme publicado neste outro post. Como referência para o Oracle, se você tiver acesso a um tnsnames que acesse o servidor que você precisa, no tnsnames o formato da declaração é: nome_alias = string_conexao

Para criar uma URL jdbc do Oracle a partir de uma conexão declarada no tnsnames, você deve fazer jdbc:oracle:thin:@string_conexao

Pronto, após preencher este formulário de configuração, você está pronto para conectar-se ao Oracle! Caso alguma coisa não tenha ficado clara, por favor me indiquem para eu explicar melhor