Tuesday, September 15, 2009

Comparing Metro and CXF

Over the past couple of weeks, I have been doing some research on Metro and CXF to find out some performance nos and see if there's a clear advantage in using one over the other for JAX-WS compliant service. In short, Metro definately was faster than CXF (untuned or out of the box). Here's a chart I put together showing the numbers - I ran the same call in a loop, making 100 serial calls.


(All timings are in seconds)

The data was collected on a Toshiba Dual Core 2.1 Gz, 2GB RAM Tablet running Windows XP with the services hosted in Weblogic 10.3. The service itself did not do much in terms of functionality but to populate some in-memory data into the service response. So these times would not necessarily match true functional service times.

I also took a look at development simplicity as the other key measure in determining the viability of the 2 libraries in the enterprise. I took the WSDL first approach in the development of these services, and found that CXF was a little easier to work with than Metro. Code generation and configuration were the 2 key factors here and both had some quirks here (with namespaces especially). CXF, out of the box integrates well with Spring. Metro doesn't though there is some hook that has been developed for it (though the initial version had a memory leak) - I did not try Spring integration with Metro.

In terms of functionality and supporting the WS-* standards, Metro definately has it all, while CXF is catching up. To me the key WS standards are WS-Security/WS-Policy, WS-Reliability & WS-Transaction. While Metro supports them all being a reference implementation for the spec, CXF supports some parts of WS-Security/WS-Policy while it does not support WS-Transaction at this point.

Overall, I still prefer CXF over Metro, though it seems like Metro looks a winner in all key categories I considered. At the end of the day, the differences are marginal and really depend upon what your needs are from a project perspective. What I mean here is that if you are looking at other things - eg. an ESB maybe (though management hates that word now, so be careful on that one...:)), for your project, then CXF fits in very well since it is a part of the Apache FUSE project. For Metro, Sun's(or Oracle) libraries are under a binary license (BCL), so that may be an issue to you if you are looking to change code (sometimes to fix a problem), but other than that, both libraries are solid and will probably both have equal adoptance across the enterprise space. While it may be a no brainer that if you were using XFire before, you should move to CXF now, performance wise, don't expect any difference (in-fact XFire was actually marginally faster over CXF). One thing I do need to play with here is the tuning recommendations on marshalling/unmarshalling of Xml in CXF that the project site talks about when using JAXB. I will post that information later since currently the documentation on it is really lacking (besides this - SXC).

Hope this post helps you make a choice - if its not helped, then its probably because both libraries are equally good - though I will say that Apache Axis definately has fallen behind.

Sunday, September 13, 2009

Sync your Outlook Calender on an iPod Touch with Exchange even with the iPhone 3.1 update


Thought I would blog about this since many people are feeling the pinch from the latest iPhone 3.1 OS update that happened last Friday. While my solution may not be perfect, it works and helps you continue to sync your iPod touch or old iPhone 3G with your enterprise Exchange server that requires your device to encrypt your data. As you may be aware, the 3.1 OS update fixed a loophole Apple had introduced, for maybe the first time, in its product line. Old devices were allowed to sync with Exchange 2007 servers even if the servers required the hardware to require encryption of the data. In general when iPod Touch/iPhone communicated with Exchange, they wrongly stated to the Exchange server that they supported encryption. That is what allowed these devices to work with Exchange even though your enterprise policy required that such mobile devices store their data in an encrypted format. Apple has recently fixed this - meaning all these old devices, except the iPhone 3GS, won't lie about their encryption offering anymore. As a result of this, if your Exchange server requires encryption, your device will probably not sync with Exchange. So what do you do - and the option to get a 3GS makes no sense to you - well, then you workaround it of-course, because there was another feature added into the iPhone 3.0 OS upgrade that allows you to sync with Google Calender (using CalDAV) - and I believe you can sync with Yahoo Calendar too. Once again indirection solves the issue. You download Google Calendar Sync. This allows all your appointments in Outlook to be synced with Google calendar. Then setup your ipod touch or iphone to sync with Google Calendar. Here are the steps for that -
This is how I configured CalDAV for Google Calendar on my iPod Touch:

Go to Settings > Mail, Contacts, Calendars
Tap "Add Account...", then "Other"
Under Calendars, "Add CalDAV Account"
Enter account information:
Server: www.google.com
User Name: [your username]
Password: [your password]
Description: [e.g. Personal]
Tap "Next"


Hopefully, this option will help you out. Since CalDAV can be setup to use SSL, the appointment information can be securely pulled down. However, your enterprise still may not want your calendar information replicated to an outside site (in this case Google) for whatever reason. So be sure to confirm that this is considered a viable fallback option in your enterprise before you go ahead with it.

While this helps with appointments/meetings which it really what I find useful on the iPod Touch, the iPhone users may be making use of the Mail sync function as well - and there really isn't a solution for that besides upgrading to 3GS. That's why I recommend this solution more for the iPod Touch users than the iPhone users.