Java Exchange Connector and EWSJ

Just saw this on  The Exchange Web Services for Java (EWSJ - what happened to the 4?).  It's a Java class library that uses the Apache AXIS web services stack to connect connects to Microsoft Exchange Server 2007, via the published and supported Exchange Web Services interfaces.   

What you can do with this is connect to Exchange 2007 from any Java app.  A good example is when building an HR or group scheduling app, in Java.  (While I love .NET, not everyone has seen the light! and some poor developers are relegated to using Java even for new applications.)   In the scenario where you write in Java and the enterprise messaging standard is Exchange, the EWSJ library may come in handy.

There's a beta of the Exchange Web Services for Java out now; it looks like the company updates the beta fairly regularly. They mention a free academic license, so I guess they will be licensing EWSJ for a fee for other purposes.

The company also has something called the JEC, which I guess is the Java Exchange Connector.  I don't understand the difference between EWSJ and JEC.  Based on reading, I'm guessing they do the same thing - provide access for Java apps into the Exchange store - but  I think the JEC is based on the older WebDAV interface into Exchange, and EWSJ uses the web services interfaces.  Just a guess... I don't know.  Maybe someone can enlighten me. Confirmed: JEC uses WebDav and EWSJ uses EWS.

This EWSJ works with the Web services interfaces supported by Exchange 2007.  By the way, those are the same web services interfaces I use from a Windows Forms app running in .NET, and the same interfaces I use from a Windows Mobile app running on my smartphone.

It brings up an interesting question - why pay for EWSJ - or any third-party library that wraps web services interfaces - when the webservices interfaces are public and free-of-charge?  I mean, if you have the WSDL and XML Schema, and you have access to good Web services tooling (Apache AXIS for Java, WCF in .NET), then you could just build (generate) the client-side proxies and classes and  get connected, right?  But, there's an opportunity to add in value to the interface - like caching of content, caching of credentials, simplifying the interface, integrating with other frameworks, and so on.  The approach I took with my .NET work was to use the tools and published interfaces. But I can see value in depending on a third party library that adds some additional capability. I don't know much about EWSJ, so I don't know what's been added, but I see the opportunity for the company to deliver something interesting there.

By the way, I have also previously demonstrated the use of WebDAV interfaces to get to Exchange Server from Java, prior to version 2007, as the JEC does it.  You can get from a JSP to Exchange 2003 for example, using WebDAV.  The way I did it was, like the JEC approach, to depend on the Apache libraries. In my case, just as with the JEC, I used the now-retired Jakarta Slide library and the httpclient from the commons package. I can publish this source code if you like. (But if you are running Exchange 2003, you really should upgrade. E2007 is much much better, and the web services interface is just one aspect.)

I was surprised to see that Jakarta Slide has been retired! Apparently it didn't attract enough developers. But it looks like there is a new WebDAV implementation in the Apache Jackrabbit project.  I guess this is a challenge facing all open-source projects. With so much attention focused on AJAX and pretty web interfaces, internetworking protocols like WebDAV take a back seat.  Good to see WebDAV is not totally dead at Apache.

EWSJ looks like one more interesting interop opportunity.