Tuesday, January 31, 2006

RMI Nightmares - Non Interoperability

These days we tried to make Websphere and Jonas interoperate. Some EJBs are deployed in Jonas and we just try to call them from Websphere. The most natural way is to use RMI (with JRMP) for that. Jonas uses JDK1.4.2 (conforms to J2EE 1.4) and Websphere IBM JVM 1.3.1 (conforms to J2EE 1.3). Because of RMI serialization, an EJB from Jonas will not work on Websphere, because this EJB has references to J2EE 1.4 classes which are different from J2EE 1.3. The exact root cause is not exactly clear to me, it probably has to do with the Naming Factory and the EJB Stub, but we tried every possible thing here without success.
Update: JRMP worked between JBoss 3.X on JDK 1.4 and Websphere 5.X (IBM JDK 1.3) using JBoss NamingFactory. So RMI interoperation seems quite unpredictable. One thing is that you have to pay attention to the naming factory you use. If it is a special library like in JBoss case, make sure it is compatible with your JDK.

One solution is to use RMI-IIOP, as it does not rely on serialization. It almost works. In our case we use Websphere Portal that needs to have security enabled. You might ask what security has to do with all that. Well, enabling security on websphere means that CORBA exchange will also be secured (using CSIv2). Tuning Jonas to understand what websphere asks is something we did not manage to do (and we don't know if it is possible at all).
Update: We did manage to make it work by disabling Jonas CSIv2 support.

So there we are using Axis to do the communication!
Update: Axis is not needed anymore as RMI-IIOP works as advertised.

There is an interesting benchmark of Axis vs JRMP vs RMI-IIOP (pdf). Axis is more than 10x slower than pure JRMP. Application servers use of JRMP seems to matter a lot, JBoss looks bad.

RMI Nightmares - Non Interoperability

These days we tried to make Websphere and Jonas interoperate. Some EJBs are deployed in Jonas and we just try to call them from Websphere. The most natural way is to use RMI (with JRMP) for that. Jonas uses JDK1.4.2 (conforms to J2EE 1.4) and Websphere IBM JVM 1.3.1 (conforms to J2EE 1.3). Because of RMI serialization, an EJB from Jonas will not work on Websphere, because this EJB has references to J2EE 1.4 classes which are different from J2EE 1.3. The exact root cause is not exactly clear to me, it probably has to do with the Naming Factory and the EJB Stub, but we tried every possible thing here without success.
Update: JRMP worked between JBoss 3.X on JDK 1.4 and Websphere 5.X (IBM JDK 1.3) using JBoss NamingFactory. So RMI interoperation seems quite unpredictable. One thing is that you have to pay attention to the naming factory you use. If it is a special library like in JBoss case, make sure it is compatible with your JDK.

One solution is to use RMI-IIOP, as it does not rely on serialization. It almost works. In our case we use Websphere Portal that needs to have security enabled. You might ask what security has to do with all that. Well, enabling security on websphere means that CORBA exchange will also be secured (using CSIv2). Tuning Jonas to understand what websphere asks is something we did not manage to do (and we don't know if it is possible at all).
Update: We did manage to make it work by disabling Jonas CSIv2 support.

So there we are using Axis to do the communication!
Update: Axis is not needed anymore as RMI-IIOP works as advertised.

There is an interesting benchmark of Axis vs JRMP vs RMI-IIOP (pdf). Axis is more than 10x slower than pure JRMP. Application servers use of JRMP seems to matter a lot, JBoss looks bad.

Monday, January 16, 2006

What Is Clustering About – An answer to Spring is not designed for scalability

I wanted to reply to Diego Parilla post about scalability, but my reply ended up being too long not to post it over here. I don't know if I am the only one here but I don't fully understand his post and arguments.

Clustering the web server and clustering the model are just two parts of clustering, not exclusive.

In a LAMP application, clustering the model is traditionally done by clustering the DB (MySQL) which is a no brainer. Clustering the web server does not always implies sharing the "HTTP session". For example you can limit yourself to use cookies. For many web apps this works well.

For more stateful web apps, there are strategies to avoid clustering the session, you can make one client attack one server only for his whole session duration. Another strategy is to use DB where you would use a session. This is actually reported to work quite well. If my memory is right, this is how Friendster rewrote its app (used to be Java and session based, moved to PHP+DB).

EJBs are not about clustering the model more than Spring, they are about clustering the business logic. And I don't see how EJB3 is more scalable than Hibernate.

What Is Clustering About – An answer to Spring is not designed for scalability

I wanted to reply to Diego Parilla post about scalability, but my reply ended up being too long not to post it over here. I don't know if I am the only one here but I don't fully understand his post and arguments.

Clustering the web server and clustering the model are just two parts of clustering, not exclusive.

In a LAMP application, clustering the model is traditionally done by clustering the DB (MySQL) which is a no brainer. Clustering the web server does not always implies sharing the "HTTP session". For example you can limit yourself to use cookies. For many web apps this works well.

For more stateful web apps, there are strategies to avoid clustering the session, you can make one client attack one server only for his whole session duration. Another strategy is to use DB where you would use a session. This is actually reported to work quite well. If my memory is right, this is how Friendster rewrote its app (used to be Java and session based, moved to PHP+DB).

EJBs are not about clustering the model more than Spring, they are about clustering the business logic. And I don't see how EJB3 is more scalable than Hibernate.

Thursday, January 12, 2006

My Dream Job


In my dream job, I would have freedom to play with and build software based on new ideas I have.
In my dream job, I would work with creative people, luminaries.
In my dream job, I would have a good enough salary.
In my dream job, I would not have to worry about the company stability.
In my dream job, I would have freedom in my work schedule.

Get paid for doing what you really want (i.e. your ideas) is possible. But without worrying about the next 6 months, I have not seen that.

My Dream Job


In my dream job, I would have freedom to play with and build software based on new ideas I have.
In my dream job, I would work with creative people, luminaries.
In my dream job, I would have a good enough salary.
In my dream job, I would not have to worry about the company stability.
In my dream job, I would have freedom in my work schedule.

Get paid for doing what you really want (i.e. your ideas) is possible. But without worrying about the next 6 months, I have not seen that.

Wednesday, January 04, 2006

Ogg better than MPC and MP3 - AAC crap

The latest well done (e.g. blind) listening test comparing Ogg, MPC, MP3, AAC at about 180kbps shows that Ogg is superior to all other compressing formats. It's not that easy to find relevant tests. Many people claim to be able to notice huge differences between CD and MP3 and yet, but confronted to a blind listening test, they are very surprised how difficult it actually is. Hydrogenaudio has a good community of audiophiles.

Unfortunately Ogg is not supported officially in iTunes and not supported in the most popular hardware (iPod). It's been a while now Ogg is out, and even if it is a superior format, unless Apple embraces it, I don't see it succeeding. I wish Apple would make a tiny effort.

In Java it is possible to play ogg files using Jorbis but I did not find any useable Java player compared to Windows foobar2000 or Linux XMMS or Apple iTunes.


Ogg better than MPC and MP3 - AAC crap

The latest well done (e.g. blind) listening test comparing Ogg, MPC, MP3, AAC at about 180kbps shows that Ogg is superior to all other compressing formats. It's not that easy to find relevant tests. Many people claim to be able to notice huge differences between CD and MP3 and yet, but confronted to a blind listening test, they are very surprised how difficult it actually is. Hydrogenaudio has a good community of audiophiles.

Unfortunately Ogg is not supported officially in iTunes and not supported in the most popular hardware (iPod). It's been a while now Ogg is out, and even if it is a superior format, unless Apple embraces it, I don't see it succeeding. I wish Apple would make a tiny effort.

In Java it is possible to play ogg files using Jorbis but I did not find any useable Java player compared to Windows foobar2000 or Linux XMMS or Apple iTunes.