[Kolab-devel] Kolab Webservice initiative
h.helwich at tarent.de
Tue Nov 8 11:04:37 CET 2011
Hi Bernhard, kolab devel,
Am Dienstag, 8. November 2011 09:26:36 schrieb Bernhard Reiter:
> Hi Hendrik,
> just noticed that you have started to publish more about
> a Kolab Webserver product that you are developing.
> That is very cool! Can you tell us more about this?
thank you for the interest :-)
The Kolab Webservice is an older project and was a part of the Syncphony
project  which was developed by Tarent  for a customer. It is used by
the Tarent company to synchronize mobile phones with the Kolab server.
We just decided to extract the existing webservice to a new project because it
can be used stand-alone.
> We also should put it in the wiki.kolab.org if you have not done so.
This would be nice. Please tell me if we should do any actions about that
> Aobut the goals you have stated:
> * Simpler Kolab client development
> Kolab clients can be developed in a more secure and easy way if they use
> the abstraction layer which is provided by the Kolab webservice. Kolab
> clients can use a well defined more high level interface and does not need
> to deal with Kolab XML parsing/writing and the IMAP protocol.
> * Data consistency
> With the Kolab Webservice the data consistency on the Kolab server can be
> enforced and it is not possible to store invalid Kolab data any more.
> Yes, up to a point any access layer would insolate against the lower
> layers. It would be cool to have more helper libraries that can make client
> development easier. Maybe having others in C, C++ or Python, too.
I forgot that point: The Kolab WS project is designed to be used as a client
library as well. This feature has never been used or tested but it could be
made possible without to much effort.
So you could use Kolab WS it in two ways to develop a Kolab client:
1) Compile the Webservice WSDL file to a Client Stub in your prefered
language. This should also create classes/structs like Contact, Event etc
that you need to use the webservice stub. This way is already used in
practice with the Syncphony Funambol connector . You can also create a
Kolab WS client in languages like C or C++ as long as a WSDL compiler is
available for that language. We have e.g. also developed a PHP client.
2) Create a Java Kolab client that uses the Kolab WS Jar file as a library so
that you do not need to run the Kolab Webservice. This feature has not been
> One cool other idea would be to use the same backend as the modern Kontact
> Clients on the server as well. I guess it is all a matter of the interface
> and design to keep that scaling.
Yes it would be great to locate much of the complexity/functionality which is
available in Kolab clients like Kontact on the server. This would make client
developement more easier and secure because the functionality can be reused.
This was also the idea behind the Kolab WS project.
The use of a Webservice has the benefit that the interface is usable
independent from OSs and programming languages and can also be used via HTTP.
As i can see on the Kolab Format mailing list, there is also a discussion
about designing an XML schema for the Kolab format. This is also needed to
create a webservice and such an XML Schema can be compiled to data
structures/classes which can automatically be (de)serialized to XML.
The Kolab WS project does also define an XML Schema  which is very near to
the Kolab Format and could be helpful.
> * No concurrency conflicts
> Conflicts if Kolab clients are accessing the Kolab server concurrently
> can be avoided with the Kolab Webservice.
> I wonder how you are aiming to solve this one. When establishing the Kolab
> concept it got clear that conflicts cannot be avoided from a conceptual
> point of view. You would have to either give up scaling or change the human
> nature. ;)
The conflicts which are addressed here are that the IMAP server does not
support transactions like a DBMS does. So if a layer like the Kolab WS is put
on top of the Kolab server, it can add this feature to server operations
which should be atomic but need more then one step. This can be used e.g. if
you want to update a contact, which are two operations on the IMAP server
(delete old mail, create new mail).
This feature can only be enabled for clients who use the extra layer. For
normal Kolab clients this would still be seen as multiple steps.
> Again thanks for publishing Free Software and growing the Kolab Community!
It's a pleasure ;-)
> Best Regards,
More information about the Kolab-devel