What is a web service?
A web service is a generic term for an interoperable machine-to-machine software function that is hosted at a network addressable location.
A web service has an interface, which hides the implementation details so that it can be used independently of the hardware or software platform on which it is implemented, and independently of the programming language in which it is written. This independence encourages web service based applications to be loosely coupled, component-oriented, cross-technology implementations. Web services can be used alone or with other web services to carry out a complex aggregation or a business transaction.
A SOAP web service has an interface that is described in a machine-processable format that is called the Web Service Definition Language (WSDL) document. A SOAP web service is described by using a standard, formal XML notion that provides all of the details necessary to interact with the service, including message formats, transport protocols, and location. Tools can be used to process the WSDL, and produce client programs capable of communicating with the service by using the XML-based SOAP protocol. SOAP can be a verbose communication protocol, but it has the advantage of extensibility; more specifications exist to support Enterprise qualities of service such as distributed two-phase-commit support and sophisticated security options.
Use JSON when you want to connect to CICS from mobile devices. Use SOAP when you want server to server communication.
Differences between SOAP and JSON web services in CICS
- The content of a SOAP message is XML data, whereas a JSON message contains JSON data. JSON and XML are different encoding mechanisms for describing structured data.
- JSON tends to be a more efficient encoding mechanism, so a typical JSON message is smaller than the equivalent XML message.
- SOAP provides a mechanism to add Headers to a message, and a family of specifications for qualities of service (such as security configuration, and distributed transactions). JSON does not provide this mechanism. It instead relies on the services of the underlying HTTP network protocol. This reliance results in fewer options for securing and configuring a workload. The JSON architecture is often described as lightweight compared to SOAP.
- SOAP web services are described by using WSDL documents. JSON web services are structured less formally; they tend to be loosely coupled and prefer informal documentation often including examples.
- SOAP has a larger ecosystem of related tools that can help with application development.
- SOAP web services have an explicit error format that involves using SOAP Fault messages. There is no equivalent for JSON.
- SOAP web services support use of both HTTP and WebSphere® MQ based messaging, JSON requires HTTP.
- JSON web services support both a RESTful and a Request-Response driven interface, SOAP supports the Request-Response interface only.
- SOAP web services support the INVOKE API command in CICS; using this API command requester (or client) mode applications can call remote SOAP web services. JSON does not support the INVOKE command, but JSON client applications can be hosted in CICS through use of the basic WEB API.
Despite these differences, there are also many similarities between JSON and SOAP. Both protocols are cross-vendor open technologies, and both share infrastructure in CICS, the same CICS supplied tools, and much of the same configuration. It is possible to provide both SOAP and JSON interfaces to an existing application program hosted in CICS.