gSOAP on OpenVMS
The gSOAP Toolkit for SOAP Web Services and XML-Based Applications
gSOAP was introduced by Robert A. van Engelen and Kyle Gallivan, The gSOAP Toolkit for Web Services and Peer-To-Peer Computing Networks, in the proceedings of the 2nd IEEE International Symposium on Cluster Computing and the Grid (CCGrid2002), pages 128-135, May 21-24, 2002, Berlin, Germany.
The official source of authority is the official gSOAP Web Site. The following is an excerpt from that Web site:
A cross-platform open source C and C++ software development toolkit. Generates C/C++ RPC code, XML data bindings, and efficient schema-specific parsers for SOAP Web services and other applications that benefit from an XML interface.
The gSOAP toolkit offers a comprehensive and transparent XML data binding solution for C and C++ through autocoding techniques. Autocoding saves developers substantial time to implement SOAP/XML Web services in C/C++. In addition, the use of XML data bindings significantly simplifies the use of XML in applications by automatically mapping XML to C/C++ data types. Application developers no longer need to adjust the application logic to specific libraries and XML-centric data representations such as DOM.
The gSOAP toolkit implements the XML data binding through the use of compiler technologies. These technologies map XML schemas to C/C++ definitions and vice versa. There are two main advantages to this approach. Firstly, strong typing is effectively leveraged to ensure data content validation of SOAP messages and XML documents. Secondly, compiler-based schema-specific parsing is more efficient than most other XML parsing techniques.
The gSOAP toolkit also generates WSDL and XML schemas (XSD) for existing C/C++ data types and application functions, thereby supporting and simplifying the conversion of legacy code into Web services. Code portability has been achieved for many platforms, including embedded systems and real-time software.
"A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards."
Unlike HP Web Service Integration Toolkit (WSIT), gSOAP can be used to both expose (serve) and call (invoke) Web Services. The fact that the gSOAP implementation is all native code (C/C++) means that it is easy to integrate with existing applications, regardless of the language they are written in. Some brief examples:
- an Australian customer is calling an Internet-based Web Service from an existing COBOL application
- another customer in Australia is invoking a Web Service from an existing application and is using SSL for additional security
- we assisted an US customer in creating a Web Services interface to their existing FORTRAN application, including a content-based router which routes services based on their XML content
a customer in EMEA is calling a gSOAP-based Web Service running on OpenVMS from a Java-based PDA client to perform telephone number lookups
The brief examples above illustrate how it is possible to call a Web Service from a program running on OpenVMS -client of a Web Service-, or to call a program running on OpenVMS from a Web Service -serve a Web Service. The fact that the the protocol (SOAP) and the Web Service Description Language (WSDL) both adhere to standards make it extremely easy to invoke routines running on almost any platform using any language. Add to this the fact that the data is transported using XML and you have a perfect mechanism for invoking remote procedures and exchanging data with them in a completely transparent, standards-conform, manner.
- Start with a WSDL (top down)
- Typically used when wanting to call an existing Web service
- Use wsdl2h to convert WSDL to C/C++ header file
- Use soapcpp2 to generate stubs and skeletons
- Develop client application
- Link client application with generated code and gSOAP runtime
- Start without a WSDL (bottom up)
- Approach will typically be used to expose existing code/functionality as Web services
- Create a C/C++ header file containing the necessary datat type and service (function prototype) definitions
- Use soapcpp2 to generate stubs and skeletons
- Link generated code and gSOAP runtime with existing or new application code
The following two diagrams and text are intended for the ACMS user. We shall try and provide a little more information for the non-ACMS user in the near future.
In addition, we have developed a Web Services interface for ACMS applications. The interface utility we provide (FIDDLE) automatically generates the code required by the gSOAP runtime interfaces from the STDL code provided by ACMS ACMSADU utility.
Using the ACMS/gSOAP interface it was possible to develop a fully functional 100%-generated Web Service, which communicated with their main ACMS application, which has some 90 tasks, in one day. The rest of the 5-day proof of concept was spent doing performance and stress testing, all of which went very well, the performance matching that of their current system.
The ACMS with gSOAP solution optionally uses the Apache Web Server with the Apache mod_gsoap module, which proves to be very efficient.
Another customer in the US is adopting a similar solution around their ACMS environment, thus enabling ACMS to play a full, transparent, role in their SOA with ESB environment.
How to request a kit is to be found at http://gSOAPonOpenVMS.blogspot.com/, the gSOAP on OpenVMS blog. It is also here that announcements and other information is published.