[SOLVED] SOAP access to the Zimbra server

[sahuguet]

Hi,

the greatest value I see in Zimbra is that it offers a programmatic access to the functionalities, using open standards.
Looking at the source code (zimbra\ZimbraServer\docs), I see a lot of information about the SOAP messages.

Is there a detailed example (e.g. in Java) a SOAP client for Zimbra?
Is there a WSDL?
If not, what SOAPAction should be used?
How is authentication handled? With HTTP headers, using Basic authentication.

regards,

Arnaud

[KevinH]

There is a simple Java client in the ZimbraServer code.

ZimbraServer/src/java/com/zimbra/cs/client/soap/Tester.java

This class has some sample calls using the client. We would like to have some better docs eventually but this is a start. Also we don't have WSDL, but would be gald to see the community help create them out of our soap*.txt docs.

[sam]

A good way to get familiar with the soap api's is to see the soap interaction between the Ajax client and the Zimbra server.

See this post for more info on how to view the requests/responses between the Ajax client and Zimbra server

[liyingchang]

While I fully understand Zimbra does not provide WSDL for its SOAP interface, I am wondering why that is the case, doesn't WSDL give you (therefore fellow developers) an even more standard way to communicate ? to this I mean apache, for example, project would compile the WSDL and provide the skeletons and stubs automatically. Wouldn't it give you guys better time to market instead of developing your own serializer/deserializer ? just out of curiosity.

[KevinH]

Maintaining WSDL is too much over head for our SOAP API. We could use the schema to repersent each of our SOAP commands but this would not allow the developer to work much faster as the relationship between each is the what makes this work. If you take a look at our SOAP code you'll see it's *very* light (hence pretty quick). Roland talked about our SOAP in a blog entry.

http://oompahzing.blogspot.com/2005/...-why-soap.html

[jgao]

There're quite a few perl scripts in ZimbraServer/src/perl/soap for manipulating messgaes/appointments.

Could you provide more perl examples for soapadmin such as adding/deleting/updating account?

Thanks.

[marcmac]

Check the docs in ZimbraServer/docs in the code base. That, and the scripts, should get you started.

[tim brennan]

Take a look at ZimbraServer/docs/soapadmin.txt, you'll see:

<CreateAccountRequest>
  <name>...</name>
  <password>...</password>*
  <a n="attr-name>...</a>+
</CreateAccountRequest>

<CreateAccountResponse>
  <account name="{name}" id="{id}">
    <a n="...">...</a>+
  </account>  
</CreateAccountResponse>

Notes:
  accounts without passwords can't be logged into
  name must include domain (uid@name), and domain specified in name must exist
  default value for zimbraAccountStatus is "active"  

Access: domain admin sufficient

From that point it should be relatively easy to modify one of the existing perl scripts -- I'd suggest starting with getacct.pl since it is already an admin command (the admin namespace is different and the login params are slightly different than non-admin)

[Coilcore]

I think the decision to use a standardized remoting mechanism like SOAP makes a lot of sense. But after looking through the Zimbra implementation, it seems that somehow a lot of reasons to use SOAP got lost in the final implementation.

1. The fact that there is no WSDL is quite simply a disaster, this means that most stub generators in most languages will fail, leaving a developer to either use an existing implementation already made by Zimbra (e.g. Java, Perl, or Javascript) or to write their own from scratch. It should be a very high priority at Zimbra to put out WSDL. Saying "We figured we'd let the community do this" is a cop-out and has the added disadvantage that if its not maintained at Zimbra then changes could get missed. More importantly the WSDL makes more sense than a text file describing the soap interface. Zimbra itself doesn't have to use this WSDL, if in hubris, they choose not to.

2. After looking at Zimbras SOAP implementation within the server package a number of things occur to me :
a. In all honesty, the server code is obviously functional but quite messy, there are very tight couplings everywhere and essentially no documentation within the code. Because of the tight couplings it would be a very cumbersome process of weaseling out just the code needed for a SOAP client, in order to actually use the existing SOAP client you need to take the whole Server package as a .jar - Servlets, Mail stuff, all of Apache Lucene, and so on.
b. The choice to avoid using a standard SOAP implementation like Apache AXIS or other alternatives is somewhat confusing as well. Using one of these instead of making a home-brew version seems like it would give outside developers an easier means to get their SOAP clients working since their is no WSDL. I saw someone at Zimbra saying their implementation is lighter. I can say that with enough familiarity with Apache AXIS its not very complicated to make a lightweight implementation (obviously its even less complicated to make a not-so-light version, which is what most people do), and I certainly haven't gone an made a homebrewed SOAP implementation and benchmarked it against an Apache AXIS implementation with proper Serializer/Deserializers, so I don't know how light it really is.

In any case, if Zimbra simply provided WSDL there could be a lot more development without trying to dig through the Zimbra code.

[KevinH]

Coilcore, thanks for your comments. WSDL for our SOAP api would be nothing more than a schema since all the interactions and dependencies of the commands can't be expressed in WSDL. While I can understand how you feel WSDL is mandatory it doesn't seem to be holding back either our internal development or that of our partners/users/customers based on the integrations I've seen. That said if the community thinks this is important enough then they will create a WSDL for our SOAP. Just like the folks who thought we needed a JSON adaptor for Ruby on Rails. So if someone feels the need to do this we are always here to help and will take the contribution seriously. If it's useful enough may even include it in future Zimbra releases.

Did you look at the com.zimbra.cs.client.* pkgs? This is a basic Java client that we use internally in a QA and performance test framework.