We have stared development of Bedework web services interface to Microsoft Exchange using Exchange Web Services (EWS). The road to Microsoft integration has been a long one. When we first announced the Bedework project late in 2005, one of the goals for Bedework was interoperability with Microsoft Outlook. We did not have the time or the skills necessary to do this work ourselves. We were confident that the marketplace, open source and/or commercial, would provide us with the solution we sought.

stalksurveyorSecurity

Nov 3, 2013 (3 years and 9 months ago)

228 views

We have stared development of Bedework web services interface to Microsoft Exchange using Exchange
Web Services

(EWS)
. The road to Microsoft integration has been a long one.


When we first announced the Bedework project late in 2005, one of the goals for
Bedework was
interoperability with Microsoft Outlook. We did not have the time or the skills necessary to do this work
ourselves. We were confident that the marketplace, open source and/or commercial, would provide us
with the solution we sought.


In Augus
t 2007, we announced we were providing financial and technical support to the Open
Connector project, which was producing a CalDAV plug
-
in for Outlook. Ultimately, Open Connector
never achieved the reliability or the complete functionality necessary for pr
oduction software.


In September 2008, we became aware of the ZideOne CalDAV plug
-
in for Outlook under development in
Germany. After we met the ZideOne developers at a CalConnect event in the Czech Republic, we began
working with them more directly. The Zi
deOne plug
-
in was more stable and feature rich than the Open
Connector, and looked very promising. Shortly prior to their first production release in January 2010, the
ZideOne web site shutdown
,

and the connector was no longer available.


So, roughly four
years after launching Bedework, the marketplace had not yet delivered the Outlook
integration we had sought.


Just this summer we ran across ical4Ol, an outboard CalDAV synchronization client for Outlook. ical4ol is
relatively inexpensive, and works reaso
nably well, but it a little challenging to configure. ical4Ol is a
useful utility, but perhaps not the ultimate solution we were looking for.


Recently we learned of the "Microsoft Exchange data provider for Thunderbird Lightning", an open
source
Lightning

plug
-
in which provided interoperability between Mozilla
Lightning

calendars and
Microsoft Exchange calendars via
Exchange Web S
ervices

(EWS)
.


Although we did not actually look at the Lightning plug
-
in, we were inspired to revisit our initial
objectives.
Given that we had been searching for a
CalDAV

plug
-
in for Outlook, why were we now
developing a web services interface for Exchange? What had changed?


There have been a number of inquiries lately about Bedework interoperability with Exchange, and, like I
said, we were inspired by the Lightning plug
-
in mentioned previously. If others were having success
using EWS, perhaps it was time to try it ourselves.


We had targeted Outlook
,

and not Exchange, because Exchange was available to only enterprise users,
but

Outlook was used outside the enterprise as well as within. Exchange 2010 has greatly improved
OWA
-

Outlook web access, with equally good support for all popular browsers,

not just Microsoft’s
Internet E
xplorer. It was clear that many Exchange 2010 users
would no longer necessarily be Outlook
users.


We had become familiar with web services while developing a Web Services API for calendaring
specification within OASIS, the Organization for the Advancement of Structured Information Standards.
This work init
ially focused on a RESTful API. Developing a EWS interface for Bedework provided an
opportunity to become familiar with SOAP, which would be next in the development of
the OASIS

specification.

And, w
e had a pre
-
production Exchange 2010 environment we could

use for testing.



In brief, the EWS
/Bedework
Synch”
project

consists of a

JB
oss package

(largely independent of
Bedework)
,
built using standard JAXB tools,

and
includes a service
,

and a web server.




It communicates with the remote calendar system
via a simple proprietary web service which is
currently being developed. The intent is to allow the option of 1
-
way synchronization, or 2
-
way
synchronization, optionally with a nominated master.

We are testing against Exchange 2010, but we
anticipate that

the service will be compatible with Exchange 2007



We
expect
that

a milestone

release of this not
-
yet
-
completed work will be included in the Bedework 3.7
release.




What is needed to have a working synchronization service:

1. Initial population of
either or both end(s) (partially done)

2. Fetching of the changed event from exchange

3. Pushing changed events to exchange.


A subscription is for one calendar collection. Can be one way (either way) or both ways. Both ways one
end is the master to resolv
e simultaneous changes on one entity.


What was learned:

EWS is almost standard SOAP. The aim was to do this the right way
-

that is use the java web services
framework. Mostly successful but, EWS non
-
standard enough to cause some difficulties.



Where ar
e we going?

The awkward issue with Exchange is likely to be the mapping of their calendar data to a different model
-

e.g. iCalendar. Once that has been solved and with the understanding gained from creating this service,
other types of service may be rela
tively easy to create. iSchedule should be easy in comparison.


Some longer term possibilities:

CalDAV gateway?

Fake EWS out of Bedework so that Outlook thinks it's Exchange


Using the Java web
services

framework makes that second option less of a stretch
. All the needed
schemas are defined.