Page 1 of 2 12 LastLast
Results 1 to 10 of 30

Thread: [SOLVED] SOAP access to the Zimbra server

Hybrid View

  1. #1
    Join Date
    Sep 2005
    Posts
    10
    Rep Power
    10

    Default [SOLVED] SOAP access to the Zimbra server

    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

  2. #2
    Join Date
    Aug 2005
    Location
    San Mateo, CA
    Posts
    4,789
    Rep Power
    19

    Default

    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.

  3. #3
    Join Date
    Aug 2005
    Posts
    821
    Rep Power
    11

    Default Soap access to the Zimbra Server

    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

  4. #4
    Join Date
    Nov 2005
    Posts
    24
    Rep Power
    9

    Default why not WSDL ?

    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.

  5. #5
    Join Date
    Aug 2005
    Location
    San Mateo, CA
    Posts
    4,789
    Rep Power
    19

    Default

    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
    Looking for new beta users -> Co-Founder of Acompli. Previously worked at Zimbra (and Yahoo! & VMware) since 2005.

  6. #6
    Join Date
    Dec 2005
    Posts
    74
    Rep Power
    9

    Default Perl examples for soapadmin api

    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.

  7. #7
    Join Date
    Nov 2005
    Posts
    55
    Rep Power
    10

    Default Soap rational, verses implementation

    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.
    Last edited by Coilcore; 01-17-2006 at 02:24 PM.

  8. #8
    Join Date
    Aug 2005
    Location
    San Mateo, CA
    Posts
    4,789
    Rep Power
    19

    Default

    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.
    Looking for new beta users -> Co-Founder of Acompli. Previously worked at Zimbra (and Yahoo! & VMware) since 2005.

  9. #9
    Join Date
    Nov 2005
    Posts
    55
    Rep Power
    10

    Default com.zimbra.cs.client.*

    Kevin, thanks for the quick reply. I did look at com.zimbra.cs.client.* which was what the second part of my rant was about.

  10. #10
    Join Date
    Aug 2005
    Posts
    228
    Rep Power
    10

    Default

    We agree that WSDL would be nice, it is just a matter of resources, given that we are working on fixing bugs and adding features and trying to get a major release out.

    Also, a WSDL only gives you syntax, so it is only a part of the picture. We need to work on more detailed docs that include semantics (sessions, authTokens, etc), which is also a large chunk of work. It will eventually get done, either by us or the community.

Similar Threads

  1. Replies: 26
    Last Post: 04-19-2011, 10:24 AM
  2. Replies: 9
    Last Post: 03-01-2008, 08:21 PM
  3. Removing hostname from hosts file fixed prob.
    By lemur in forum Installation
    Replies: 10
    Last Post: 06-13-2007, 07:29 PM
  4. zmtlsctl give LDAP error
    By sourcehound in forum Administrators
    Replies: 5
    Last Post: 03-11-2007, 04:48 PM
  5. Unable to start tomcat
    By chanck in forum Administrators
    Replies: 11
    Last Post: 06-11-2006, 01:58 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •