About Jabon
Jabon (SOAP in Spanish) is an attempt to build a Simple Object Access Protocol (SOAP) toolkit in C++, for C++.
SOAP is a recommendation of the W3C consortium (something similar to a estandar, check W3C Soap recommendation), that defines several things as the estructure of the messages to be exchanged between nodes. These messages must have an Envelope that contains a compulsory Body and an optional Header field.
The main core ideas of SOAP (as using XML) are quite obvious, but as you get into the details of Web Services (WS) you can get extremely confused (at least I am). There are several toolkits as gSOAP that encapsulates all the SOAP functionality and automatically generates C++ code that is linked into the developer application to provide WS functionalities. The only drawback of the gSOAP approach is the lack of a library that supports all the SOAP and WSDL functionality in order to make it available at runtime without statically generating source code. On the other hand, WsdlPull is a client tool that makes possible to invoke web services which interface (WSDL definition) is only known at runtime.
Both tool have the great advantage of being very lightwaigth and autonomous, not having any dependecies to other packages. Apache Axis is a complete SOAP framework, available both for Java and C++, but from our point of view, it is a little complicated.
Jabon was born in the spirit of being a lightweight C++ source code generator (as gSOAP) to provide basic server and client SOAP functionality, but providing a runtime library in which such source code is based. Such runtime library could also serve to provide SOAP functionality at runtime (as WsdlPull). Jabon is also centered in the architecture, trying to provide a good Object Oriented (OO) Software Engineered solution.
While developing Jabon, we soon realized that the word "Simple" from SOAP is not real. There are separate W3C recommendations for SOAP, the Web Service Definition Language (WSDL), the data type (XML Schema). The specfications are too complex. They are sacrificing simplicity for power. In fact, the recommendations are so complex and confusing at some points that the Web Services Interoperatibility (WS-I) has defined some rules and restriction to which implementors of SOAP has to adhere if they want interoperability with other implementors.
Our little experience with Jabon let us to think that it is required:
- A single especification for web services, that includes both the SOAP and the WSDL recommendations. Maybe a new single NameSpace (lets call it Standar Web Services SWS) for that specification.
- An extremely simple especification, so it is not ambiguous, confusing or require interpretation. It is better to sacrifice power and gain standarization. Make sure that everybody that follows the specifications will be able to interact with each other.
- Simpler documentation.