Bruno Pereira

This morning I took the Sun Certified Enterprise Architect Part I Exam. I wasn’t very excited studying for this exam, but the exam itself was just fine.

What I liked the most about the test was that many questions presented different problems and requirements, and asked me to give the most suitable solution. Besides that, most of the design patterns questions were contextual. Based on a given problem, I had to decide which patterns could help in the design of a good solution for the problem. I liked the fact that these questions made me THINK much more than REMEMBER stuff. There were a few questions focused on specific pattern details, but fortunately they were only a small portion of the exam.

There are many EJB/JPA questions in the exam, but if you’re familiar with the technologies, you should have no problem with them. The questions were not tricky. If you know the main aspects of these technologies, you’ll be just fine.

There were several Web Services questions, actually more than I expected. I liked this, because such knowledge is very important for any enterprise architect, and I’m particularly interested in the subject. I have a reasonable experience with web services, and I thought the questions were not very demanding.

The exam objective that I thought was my weakest was security. I didn’t know much about the JVM Security prior to this exam, and now I’m still no expert, but I did learn a few things.

Overall, I thought this was a nice exam and definitely it was more pleasant than I expected. I had 120 minutes to do the exam, but it took me around 80 minutes to finish it. The SCJP and SCWCD exams were more tiresome than this one. When I finished the exam, I wasn’t sure if I had passed, but the same thing happened to me in the SCJP and SCWCD exams, and I did ok.

There are 64 questions in the exam, and the minimum score to pass is 57% (37 questions). I answered 49 questions correctly, which translated into a 76% score.

Now I must checkout the Part 2 Assignment, and design an application during a 1 year span. I definitely won’t touch anything this year, because I must chill out. I hope Part 2 gives me more pleasure than Part 1, and hopefully I’ll learn a few more things.

If anyone’s planning to take this exam and want to talk about it, feel free to contact me, and I’ll try to help.

Yesterday the JSR-311 (Java API for RESTFul Web Services - JAX-RS) was finally approved!

I’m using Jersey (the JSR’s reference implementation) for more than 6 months and I was anxious to have the specification approved.

In my team we’re currently using Jersey 0.7 in production, and were waiting for the JSR to be approved to analyse the final version of its implementations. Now we’ll wait for both Jersey and JBoss RESTEasy to release their final versions and we’ll analyse both to see which one we’ll use in our RESTFul services.

If anyone wants to give me good reasons to use either one of the implementations, now it’s the perfect time! I’m hearing…

Well, as I said recently, we want to use a registry to keep URIs of our services and also some configurations that are currently in properties files.

After looking better at WSO2 Registry, I figured out how to do what I need with the product. I had a very short time to evaluate properly WSO2 Registry and Mule Galaxy before my last post, but after another evaluation of them, I concluded I can use them in this case.

Last week I developed a Java client to consume my publications from WSO2 Registry. It wasn’t much fun to develop, because I had to make it compatible with JDK 1.4. This prevented me from using their client API, which runs only on JDK 1.5 and above.

Since I had to use JDK 1.4, I used XStream for my Java <-> XML mappings. Not being able to use the Registry’s Java client, I also had to consume data from their AtomPub API. I used Apache Abdera 0.3 for this task, which was their last version supporting JDK 1.4 (through retroweaver).

So far so good. Last week I had a prototype client consuming stuff from the Registry, so I moved on to some other tasks. Well, today I started integrating the Registry in my application. That meant moving from Tomcat 6 to JBoss 4.0.5. And that’s when I got in trouble.

Unfortunately I hadn’t seen this page before. It turns out that the only application server they have tested enough is Tomcat. And not any Tomcat, only Tomcat 6. Since their distribution format is a .war file, I never would think they support only Tomcat. In their download page it says: “This distribution includes the Webapp module with relevant JAR files and other resources to be deployed in the servlet container, providing a Web UI and an APP interface.”

Well, I’m probably just dumb. They didn’t say “a servlet container“. They said “the servlet container“. This certainly means “the servlet container we support, which is Tomcat 6″. But this is not written there, so dumb people like me will be subject to mistakes.

“Heck, this is open source, I’m gonna make it work on JBoss!”. This was my first thought. And then I started setting up the Registry in JBoss, right after lunch today.

The first thing I noticed is that the Registry packs a newer version (1.2.13) of log4j than the one present in JBoss (1.2.8). This shouldn’t be a problem, but anyone who has experienced some of the JBoss Classloader Hell knows that it’s not a wise decision to bring a newer version of log4j inside your application if you’re going to run on JBoss. This is not a Registry fault, so I gladly fixed the problem by removing the log4j they had packed inside the .war file.

After fixing this, I was gettings errors trying to open the Registry’s index page on JBoss. I quickly found out that their jsps had scriptlets using JDK 1.5 code, and JBoss was not able to compile the jsps. This was easy to fix by uncommenting a init-param in the web.xml in the Tomcat module inside JBoss. However, the amount of scriplets inside their pages was the first symptom that something didn’t smell right.

After fixing the jsp problem, I configured the Registry to connect to MySql through a JBoss datasource. I then could open their index page and even use some features. However, when I started checking the server logs I was shocked. A huge amount of errors in jdbc operations. I had no clue of what was going wrong, because the UI was apparently working normally and the database was being manipulated.

Well, since it’s an open source product, I promptly checked out their code and started looking for problems. Most errors occured in simple jdbc operations like the creation of a prepared statement. The application logs were not very helpful, and I couldn’t figure out where the problem was.

However, something scared me a lot. Between the zillions of jdbc errors, I saw JBoss screaming for help, saying that the PreparedStatements were left open. I went to look at their jdbc code, and it definitely needs care. There were a LOT of jdbc operations inside try/catch blocks, where they treated SQLExceptions. I didn’t see the finally blocks closing the PreparedStatements and the ResultSets. This explains JBoss’s complaints about the PreparedStatements.

After several hours trying to use WSO2 Registry inside JBoss and looking at their code, I must say I am VERY discouraged to put anything in production right now using the product.

I just downloaded Mule Galaxy and now I’m gonna try to integrate it in my application. A very good sign is that they say I can use it with ANY servlet container, including Tomcat and Jetty. I think it’ll be a successful effort, but it’s hard to say anything after my problems with WSO2 Registry today.

But knowing Dan Diephouse’s work for several years, I’m pretty confident in this new attempt. I’ll post the results later this week.

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!

Bom, certamente o que eu estou falando não é nenhuma novidade, e nem fui eu que descobri isso ou falei isso pela primeira vez. Entretanto, devido à quantidade de vezes que eu já vi a utilização de atributos de classes para representar chaves estrangeiras (Foreign Keys - FKs), quis comentar isso por aqui para dar meus palpites.

Chaves estrangeiras são componentes importantes de um bom modelo de banco de dados. Elas são muito úteis no controle da integridade referencial e também são usadas com freqüência para indexar tabelas. Porém, não devemos nos esquecer que elas fazem parte do modelo relacional de dados, e não existem em um modelo orientado a objetos.

Esse assunto me veio à cabeça essa semana, quando eu estava analisando algumas coisas na JPetStore, a aplicação de exemplo do Ibatis, e que possui algumas das famigeradas chaves estrangeiras no modelo de domínio. Bom, se até projetos da Apache fazem isso, não me surpreende a quantidade de aplicações que já vi com uma porção de atributos long qualquerClasseReferenciadaId.

Pois bem, eu me lembrava de ter visto essa aplicação Pet Store em mais algum lugar além do Ibatis. Após uma breve pesquisa, encontrei de novo a aplicação da lojinha de bichinhos feita em Java, no catálogo de Blue Prints Java EE 5.

Claro que imediatamente baixei a aplicação e fui olhar as classes de domínio. Tamanha foi a minha surpresa ao constatar que também nesta implementação existem vários exemplos de atributos representando FKs. Na classe Product há um belo String categoryId. Na classe Item há um belo String productId. Achei curioso que nesta mesma classe Item há um atributo SellerContactInfo, que é uma outra classe de domínio, com atributos coerentes. Eles podiam ter colocado um atributo String contactInfoID, mas em vez disso colocaram a classe efetivamente. Ou seja, dentro de uma mesma classe há políticas diferentes de uso das FKs.

Me deixou um tanto desapontado ver isso num catálogo de Blue Prints (boas práticas). Provavelmente muita gente toma esses Blue Prints como referência de implementação, então isso me esclareceu um dos motivos pelos quais as FKs estão tão difundidas em modelos de domínio por aí.

Eu estou ainda com 2 vouchers da Sun que pretendo usar na certificação SCEA. Quando eu comprei esses vouchers eu achei que fosse usá-los na certificação de EJB 3 e na de Web Services, porém não estou animado para fazer nenhuma das 2, então me decidi pela prova de arquiteto.

Dentro do conteúdo da certificação de arquiteto está esse tipo de coisa dos Blue Prints, catálogos de padrões de projeto, entre outras coisas. Isso me lembrou mais uma vez que temos sempre que ler as coisas com olhar bastante crítico, para julgar de fato o que podemos aproveitar e o que temos que descartar.

It’s worth saying that these Blue Prints are looking more like Brown Prints, and some annoying smell is coming from them…

O Bill de hÓra publicou um post sobre um assunto que me interessa enormemente. Ele comentou sobre a dificuldade de se projetar boas APIs e protocolos.

Para quem não o conhece, o Bill de hÓra foi o co-editor da RFC do AtomPub, o protocolo de publicação do formato Atom. No post ele comentou sobre a dificuldade de elaborar um bom protocolo de comunicação (no caso o AtomPub). O trabalho demorou mais de 2 anos para ser concluído, e neste 2 anos não contam o tempo no qual o Joe Gregorio (o outro editor da RFC) já estava trabalhando no protocolo antes.

Uma observação que ele faz é que é difícil encontrar indivíduos capazes de projetar boas APIs, e bem mais difícil é encontrar indivíduos capazes de projetar bons protocolos de comunicação. Algumas pessoas dizem que essas habilidades (projetar APIs e projetar protocolos) são de certa forma opostas, o que implica que seria especialmente difícil encontrar pessoas com habilidade nas 2 coisas.

Ler esse post foi motivante e inspirador para mim.  Neste exato momento eu estou fazendo as duas coisas simultaneamente. Meu time é responsável pelo sistema de cadastro de usuários e autenticação da Globo.com, entre outras coisas. Esse sistema é provavelmente o que possui mais clientes internos na empresa. A implementação original utilizava EJBs para comunicação remota entre clientes e o servidor, e permitia apenas clientes Java.

Estamos progressivamente saindo dessa estrutura. Estamos implementando novas interfaces e clientes que usam serviços REST na comunicação, em vez dos EJBs. Isto está sendo feito de forma progressiva porque nenhum Product Owner daria alto valor de negócio para uma migração dessas, exceto em situações extremas (que não são nosso caso).

Pois bem, nesta migração eu estou atuando nas 2 frentes que o Bill de hÓra classificou como desafiadoras. Estamos modelando os serviços REST e o novo protocolo de comunicação. E estamos também implementando uma API Java para realizar as operações através deste novo protocolo.

Sem dúvida esta migração é desafiadora. De fato não é fácil elaborar um bom protocolo e uma boa API. Porém, isto também motiva demais. Quem acompanha o meu blog já sabe do meu apreço por serviços REST. Assim, este trabalho atual tem sido ótimo para conseguir explorar inúmeras situações envolvidas neste tipo de comunicação.

Para minha sorte, pude contar com alguns pontos facilitadores. Na elaboração do protocolo, o conhecimento do AtomPub ajuda muito. Eu já conheço bem esse protocolo e tinha desenvolvido serviços REST em alguns projetos, então essa parte da empreitada ficou muito facilitada.

Além disso, o conhecimento da API Java anterior do projeto traz várias idéias que podemos explorar. Algumas decisões na API anterior foram muito boas, e outras trouxeram alguns problemas. Eu não participei da implementação original do projeto (isso foi em 2004), mas após trabalhar no projeto por bastante tempo, consegui vivenciar bem os problemas dela. O principal era o alto acoplamento entre o servidor e os clientes, então isso é o principal ganho que pretendemos ter com essa nova implementação baseada em REST.

O outro ponto facilitador é estar no mesmo time que o Silvano, certamente um dos melhores caras que já conheci tecnicamente. Nós temos visões complementares sobre a arquitetura e a implementação. As idéias que colocamos na prática após as freqüentes discussões são muito superiores às que eu ou ele seríamos capazes de desenvolver individualmente. Com a liberdade de decisões técnicas que temos na Globo (principalmente após a adoção do Scrum), conseguimos evoluir nossas aplicações progressivamente, sempre avaliando pontos positivos e negativos das decisões anteriores.

Após ler esse post do Bill, tive uma dimensão melhor da grandeza do desafio que estamos tendo agora. Isto traz ainda mais motivação, e não abala a confiança. Tenho a mesma sensação que Isaac Newton teve ao dizer que “se ele pôde enxergar mais longe foi porque se apoiou nos ombros de gigantes”.

Quando estamos trabalhando freqüentemente com padrões e tecnologias abertas, temos sempre essa vantagem. Viver no mundo open source é se apoiar sempre nos ombros de gigantes, e então qualquer desafio fica muito mais suave e a nossa confiança aumenta. É por isso que eu amo o que faço

I’m currently using Google Data API at work. This API offers RESTful interfaces for several Google services, such as Calendar, Picasa, You Tube, Blogger, Google Documents, among others. There are also client libraries for Java, C# and Python, but these are actually tools to facilitate, rather than new interfaces. All client libraries access the RESTful interfaces, so by all acounts the API is RESTful.

What I’d like to comment is how easy it was for me the to get up to speed with the API. There are several pages explaining the API’s features, the URIs, their use of HTTP method, return types, etc. Their design is pretty much compliant to all REST best practices (although they do use some query string parameters ocasionally). Being very familiar with this kind of web services, most of what I did was looking and saying: “Ok , this is how i expected it to be”. And after less than one hour I was ready to begin using the API properly.

Worth noting is that there were no “Interface Document” to look at. Not anything similar to WSDL or any other IDL. What was there was just a simple and RESTful API that was pretty easy to use after you knew what the resources were and which operations they support. Several pages describing their protocol and the XML entities they use were enough for me to know how I was supposed to integrate with a reasonable amount of their services.

I don’t even want of to think of how would it be if they had WS-*. Just to read the WSDL documents would take me more time than to read all their RESTful documentation. There would be a lot of operations and messages described in their WSDLs, and it’d be a massive reading to get the grasp of the API.

Fortunately Google (the most powerful web company) is embracing a RESTful design and it should probably take many other companies with it. They’re also supporting the use of Atom and Atom Publishing Protocol, so many nice things should keep coming. Apache Abdera is already integrating Google Feed Server code, and hopefully we’ll be able to use Abdera for most of Google’s services.

Very very nice! By the way, I took a good look in the source code of Google Data API and it’s very well implemented. They have a very interesting approach to manipulate feeds and entries. It makes it very easy to model a lot of stuff using just feeds and entries. It was an inspiring code inspection and I’m thankful Google also embraces open source These guys are good!