Development toolkit for Web Services and XML data bindings for C & C++Read More
The gSOAP toolkit is an extensive suite of portable C and C++ software to develop XML Web services with powerful type-safe XML data bindings. Easy-to-use code-generator tools allow you to directly integrate XML data in C and C++ (and C++11/C++14). Serializes native application data in XML. Includes WSDL/XSD schema binding and auto-coding tools, stub/skeleton compiler, Web server integration with Apache module and IIS extension, high-performance XML processing with schema validation, fast MIME/MTOM streaming, SOAP and REST (WCF compatible), WS-* protocols (WS-Security, WS-Policy, WS-ReliableMessaging, etc), XML-RPC and JSON. Licensed under GPLv2. Commercial licensing and technical support options are available: visit the project web site.
- Celebrating our 15th anniversary of gSOAP
- Web services development tools, interoperates with .NET WCF, J2EE, Apache Axis, etc.
- Fast, compact, and portable (runs on small & embedded devices)
- XML data binding tools for C and C++ (and C++11)
- XML schema to C/C++ type binding means XML and C/C++ data is always type safe
- XML serialization of C/C++ data (true serialization, including data graphs!)
- Qt type serialization in XML (Qt primitive types and containers)
- WSDL 1.1/2.0, XSD 1.0/1.1 SOAP 1.1/1.2 compliant
- WADL (REST XML apps) for C and C++
- WS-Security XML authentication, signatures, encryption (also in streaming mode)
- WS-Trust with SAML 1.0/2.0 tokens
- WS-Policy 1.2, 1.5 and WS-SecurityPolicy 1.2 compliant
- WS-Addressing 2003/03, 2004/03, 2005/03 compliant
- WS-ReliableMessaging 1.0 and 1.1 compliant
- WS-Discovery 1.0/1.1
- jsoncpp tool: generates C or C++ for JSON & JSONPath queries
- domcpp tool: generates C or C++ DOM code for XML & XPath queries
- testmsgr tool: test messenger for (randomized) testing of services and clients
- REST JSON and JSON RPC for C and C++
- JSON conversion to/from XML-RPC for C and C++
- REST HTTP(S) 1.0/1.1 operations (GET,PUT,POST etc) for XML, JSON, etc
- Flexible IO: send and receive XML over sockets, file FD, and C++ streams
- WS-I Basic Profile 1.0a, 1.1, and 1.2 compliant
- W3C schema patterns for data binding full test pattern coverage
- MIME and MTOM attachment support (also in streaming mode)
- UDDI v2 API
- NTLM authentication
- HTTP basic and digest authentication
- SSL/TLS with SSL session caching (OpenSSL, GNUTLS, SystemSSL)
- Proxy and proxy authentication support
- Compression (HTTP compression and zlib)
- IPv4 and IPv6, including direct TCP and UDP data transfer
- cURL plugin to integrate gSOAP with cURL
- RSS 0.91, 0.92, 2.0 XML support
- Apache 1.x and 2.0 modules
- IIS (ISAPI) and WinInet modules
- CGI and FastCGI support
- Stand-alone Web server included (multithreaded, SSL, compression)
- Integrated memory management with deallocation and leak detection
- Plug-ins for additional capabilities such as message logging and stats
- Internationalization/localization support (UTF8, UCS4, MB encodings, etc)
- WSDL/XSD conversion to C or C++ and vice versa
- Auto-test server code generation for (dummy) server testing
- Automatic XML document and message generation from WSDL and XSD
- C/C++ (cyclic) object graph auto-serialization (with id-ref)
- STL container auto-serialization and custom C++ container auto-serialization
- Handles large WSDL and XSD, such as ONVIF, AWS-S3, EWS, and more
- Over 40 example client and server applications included
- Licenses: GPLv2, gSOAP public license (for engine and plugins), commercial non-GPL license available upon request (software is 100% in-house developed, no third-party GPL contributions included)
KEEP ME UPDATEDGet project updates, sponsored content from our select
partners, and more.
Thanks developers for this beautiful ToolKit!!!
Very powerful toolset that can handle just about anything you throw at it. Has flags for many different options/features. And it was easy to extend -- I wrote a custom plugin (for session management using cookies) without much trouble. I also used gSOAP to connect to AWS S3. The documentation has everything you need in it (and more!), but to get started the only necessity is the examples. If you run into any trouble, Robert (the developer / maintainer) is quick to respond with advice or patches.
The user guide is in an unconventional format and I will take a hard look at it to modernize its content and layout. I'm happy to receive honest feedback to make gSOAP better. I do wonder though if the last two reviewers who gave 2-3 stars checked out the new web site's documentation, submitted a support request or otherwise contacted me directly? As far as records show, these folks have never asked questions using the available support channels. The new site www.genivia.com/dev.html has up-to-date documentation, tutorials, and examples. Also, a technical support ticket system is offered at www.genivia.com/contact.html for assistance. The Yahoo gSOAP mailing list is still maintained, but it is not active because most developers have moved on to use StackOverflow to get help with gSOAP or they contact Genivia directly. I do not know why the reviews missed the point that the software is not only for SOAP. In fact, REST with XML and JSON is working fine too. And gSOAP handles XML for HUGE web services. There are lots of resources available for gSOAP these days to get started and resolve issues (if any). Anyway, there is no need to give up that easily. Disclosure: this site has no review feedback system to address concerns, so I'm just adding my comment as a "review".
I would steer clear of the Community Version as support does not appear to exist. Some years ago - when the project was newer, ~some~ questions were answered . Now, the Yahoo group is silent with very little activity at all. It seems a message there may be logged once per month. I attempted to use the package to interface with Oracle database functionality written sometime ago. I; myself, had worked with Oracle for about 15 years. The functionalities would require a significant number of rows to be returned to the calling program. When using the package, there was a requirement for memory to be allocated (in the form of malloc) on the server side (in order to support the return of data to the client). Supposedly, memory would be de-allocated by the software but - in reality, this does not appear to be the case and; services that work on the first, second or third calls fail (intermittently) on subsequent calls. As of now, the preference in the market place is for the use of REST. The package was chosen initially because it allowed for the upload of images and mp3 files to a server. Again, the instructions to make such functionality take place were unclear and there were portions of the documentation - required to make things "work" that were missing.You were not made aware of this fact until you opened a message on the Yahoo site and received an answer - 2 weeks later. Even so, it was possible to get it working. Since one can use Google Drive, Amazon, et.al APis, other avenues can be explored and staying with gSOAP is no longer necessary. Perhaps the commercial version would be better; however, a phone call to the GSoap office today forwards one to an answering machine whereby the caller is encouraged to leave a message. I worked at NASA for a bit putting together code that tracked tile manufacturing (in support of shuttle missions) - so - I can say with some certainty that I am not the dullest pencil in the box. If you are using it for simple tasks, then I feel it would fit the bill. The "calc" samples worked really well. If you need to use it for a lot of data, then, based on ~my experience~ I would seek other options.
Good project, good product overall. Shitty documentation. I have to say, first, that I'm using GSoap on a C project, not a C++ one. So I can't talk about the C++ aspects. It's not very intuitive working with GSoap at first (at least when taking the WSDL files, without knowing how that works - I had to find the RIGHT wsdl to use, and the like). However, I ended up with nice sources and headers, generated from the WSDL, so that's nice. The "namespace binding" file could be named as a header, which would make it more obvious that it MUST be included, too. But, there again, it's not that hard to figure out. However, right now, I'm struggling to send custom Faults, using the built-in fault mechanism. The documentation is happy to tell you which functions to call to send DEFAULT faults ("sender" and "receiver" faults). However, I need to send faults described in the WSDL file, and NOWHERE IN THE DOC am I able to find the right information about how to do that. Which means that I'm now downloading the SOURCE CODE for the project, in the hope of being able to find how they do it for the "standard" faults, and replicate the procedure for the custom faults. ALL BECAUSE OF A LACK OF (GOOD) DOCUMENTATION. More generally, I find the documentation to be made more of a collection of examples on how to do something or something else, but without a "basic" documentation describing the underlying logic, for instance, or which function does what. It's basically an incomplete tutorial, and it is infuriating. So, maybe I've missed obvious things, maybe I'm a moron, but... when the only places where a mechanism is mentioned discuss problems unrelated to the one I'm having, I can't help but feel lost. To sum it up, this project would deserve 4 or 5 stars with a good documentation. But, in its current state, with the documentation found on the Genivia website (www.genivia.com/doc/soapdoc2.html), I won't give more than 3 stars. Hope this helps.