[Kolab-devel] Kolab Webservice initiative

Hendrik Helwich 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.
>   https://evolvis.org/projects/kolab-ws/
> 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 [1] which was developed by Tarent [2] 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:
>   Goals:
>   * 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 [1]. 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 [3] 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,

[1] http://evolvis.org/projects/syncphony/
[2] http://www.tarent.de/

> Best Regards,
> Bernhard

More information about the devel mailing list