HostBridge Technology

A HostBridge White Paper

Content > White Papers


Choosing Formal or Informal Web Services for CICS Integration

In 2007, Gartner predicted that Web oriented architectures defined by REST and XML over HTTP would replace 90% of Web SOAP-only implementations by 2012.1 You can see the move away from SOAP to RESTful architectures in Google APIs,, and within large organizations like Wal-Mart. SOAP and REST will continue to play roles, but what will those roles be and when should you choose one over the other?


When HostBridge Technology launched itself into the CICS integration scene in 2001, our mantra was simple: “XML for CICS.” We made CICS transactions available as XML for use in application access and integration. It was, to us, an obvious marriage between the Web and the mainframe made possible by advances in CICS Transaction Server. The next obvious step was to make CICS resources available as Web services. Continuing with the theme that made us popular, our Web services were plain old XML (POX2) over HTTP.

The years passed and people began to talk about Simple Object Access Protocol (SOAP). The dirty secret about SOAP is that it is anything but simple. There is a formal structure that promised to make it possible for any business to deploy, but differences between how application servers handled the requests, differences between how .NET and Java environments handled the documents, and lack of knowledge about best practices for its use made SOAP a huge headache. But, because it was the buzzword in every press and analyst conversation about integration, people began asking for it.

Eventually, we added SOAP support to HostBridge prior to the availability of native SOAP support within CICS TS. Soon a trend began to emerge: relatively few customers were using SOAP – not even those who said they would like to see it added.

Like HostBridge, CICS Transaction Server has evolved with customer needs. IBM provided access to CICS via HTML, then XML, then SOAP, and now Representational State Transfer (REST). We will talk about these technologies in this white paper, but the net of it is that REST is a return to the basic architectural assumptions we made in HostBridge 1.0 – XML over HTTP is flexible and easy to use, so why make it harder than you need to?

Let’s take a look at the differences between formal Web services (SOAP) and informal Web services (RESTful), as well as when to use each one to best effect.

Formal and Informal Web Services

There are a number of ways to implement program-to-program interactions and still consider them Web services. For example, a Web service can be implemented as a “Web API that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services.” Alternatively, the Web service can be implemented according to a more formal approach: “clients and servers that communicate using XML messages that follow the SOAP standard.” This distinction is very important. However, we need some words to describe the difference. In this white paper we use the words “formal” and “informal” to denote two basic approaches to implementation of Web services, where the definitions for these approaches are:

What is SOAP?

SOAP, or Simple Object Access Protocol, is a transport-, platform-, and language-agnostic designed as an alternative to interoperability technologies like CORBA and DCOM. A crowd of standards govern the use of SOAP, so much so that Gartner has begun calling Web services based on SOAP “WS-*” . The proliferation of standards makes SOAP increasingly complex to understand and use. Minus the standards, a basic SOAP message looks like the following:

Figure 1

Figure 1. Basic SOAP Message Format

The SOAP message is an XML document, but the format is different. The basic XML document is “wrapped” in a pair of elements: and . According to the SOAP specification, SOAP messages wrap their contents in an envelope and use the body to identify the beginning and ending of the payload. The addition of the “hb:” prefix to the standard XML elements illustrates the use of namespaces. Namespaces provide a tool for developers to use to identify which elements are HostBridge input elements.

SOAP Model

Below is the basic model for accessing CICS applications as Web services through HostBridge.

Figure 2

Figure 1. HostBridge and SOAP Web Services Model

The diagram shows three Web services: a Provider (HostBridge) that provides the Web service, a Requester that uses a Web service, and a Broker that finds Providers for Requesters. The following steps are required to find and use a Web service. (Subsequent requests do not require steps 1-3.)

  1. HostBridge uploads a WSDL specification to publish its Web service with a Broker

  2. The Requester queries the Broker for a Web service by name or category

  3. The Broker selects a Provider and returns the Provider information to the Requester

  4. The Requester uses the information from the Broker to format and send a SOAP message to the HostBridge

  5. HostBridge returns an XML document to the Requester with the CICS data enclosed.

SOAP Example

In this example, HTTP will be the transport protocol. The SOAP request-response sequence represents a call to CICS to call a Web service that retrieves a stock quote.

Figure 3

Figure 3. SOAP Request for Stock Quote

Figure 4

Figure 4. SOAP Response with Stock Quote

Notice that both the client and server must understand and adhere to the SOAP messaging format.

What is REST?

RESTful Web services are a lightweight alternative to the heavy, SOAP-based standards. In RESTful Web services, the emphasis is on simple point-to-point communication over HTTP using XML. The origin of the term "REST" comes from the thesis from Roy Fielding describing the concept of Representational State Transfer. REST is an architectural style in which distributed systems are built on a shared model and have agreement between nouns (resource names as URIs), verbs (HTTP methods used), and content types (usually XML or JSON). The REST model for the relationship is depicted as a triangle shown below.

Figure 5
Figure 5. REST Relationship Model.

Verbs are operations applied to resources. The REST Web services model assumes universal verbs applied to all nouns based on methods in HTTP 1.1 which correspond to the CRUD (create, read, update, delete) database operations.

Nouns are URIs to resources. In our examples, a service to request a stock price for the company 'IBM', for example, would be handled using an HTTP GET to

REST Model

Below is the basic model for RESTful Web services.

Figure 6

Figure 6. HostBridge and the RESTful Web Services Model

The diagram shows two Web services: a Provider (HostBridge) that provides the Web service and a Requester that uses a Web service. In the RESTful model, the services are self-describing, so there is no need for WSDL and a UDDI server to act as a Broker. The following steps are required to find and use a Web service. (Subsequent requests do not require steps 1-3.)

  1. The Requester queries the Provider over HTTP using a URI. The request uses one of the HTTP methods to determine whether the request is intended to create, read, update, or delete data.

  2. HostBridge returns an XML document to the Requester with the CICS data enclosed.

As you can see, the simplified architecture and process not only makes RESTful Web services easier to use and deploy, but without all the middleware calls, the RESTful services are much more scalable.


The stock quote service above, rewritten as a RESTful Web service, might adopt the following request-response model.

Figure 7

Figure 7. REST Request for Stock Quote Using HTTP GET

Figure 8

Figure 8. REST Response with Stock Quote

The RESTful version is simpler and more concise than the RPC-style SOAP version. RESTful Web services are intentionally closer in design and style to the Web itself.

When to Use Formal and Informal Web Services

Before we make some recommendations on when to use SOAP and REST for CICS integration, keep in mind the following points for comparison.

When someone uses the phrase “Web services” or “Services Oriented Architecture” (SOA) they often assume the formal approach (use of SOAP, WSDL, etc.). But the practical reality is that a formal approach to Web services requires more human planning, as well as machine processing, on both sides of the connection. Thus, deploying a formal Web services approach may be more appropriate when:

Alternatively, deploying an informal Web services approach may be appropriate when:

The distinction between informal and formal Web services is important. With the release of CICS Transaction Server 4.1, support for Web services through REST is built into CICS alongside the existing SOAP pipeline. This means CICS integration teams are able to choose the right style of Web services for their needs, and an understanding of formal and informal services can help guide the decision-making process.

HostBridge, REST, and CICS Transaction Server

IBM added RESTful Web services to CICS TS with the release of SupportPac CA1S and includes this support as part of CICS Transaction Server 4.1. REST support comes with the addition of PHP running under the Java Virtual Machine. As IBM describes it: “Facilities provided by this SupportPac allow RESTful services to be created easily that exploit existing CICS COMMAREA applications. As well as existing application components, this SupportPac allows PHP scripts to access DB2 tables via PHP Data Objects (PDO) using the CICS Java Database Connectivity (JDBC) driver.” In the same way that the SOAP Pipeline provides access to CICS resources using formal Web services, PHP running under Java provides access to CICS resources using REST.

This creates yet another avenue to CICS. However, it still does nothing to make your 3270 BMS and non-BMS transactions available as Web services or XML.

You still need HostBridge to express application logic as business services, though now you have another way to call the services.

Since our product’s first release, HostBridge has always run within the CICS address space and under a CICS-managed TCB. Thus, this style of execution would be described as “under CICS.”


HostBridge customers have always been at the leading edge of implementing CICS-based Web services. While some use HostBridge as part of a formal Web services approach, the majority use HostBridge to implement informal Web services. Specifically, the most common methodology is using HTTP GET or POST requests, whereby the input parameters are specified using a URL query string or POST data, and the output data is an XML document (using a customer-specific or service-specific XML vocabulary). Why do customers do this? Because it is simple and efficient.

HostBridge makes CICS resources callable as RESTful Web services or SOAP objects. Regardless of the model you choose, HostBridge allows you to include CICS in your SOAs, mashups, or any other Web service implementations.


[1]“Applying WS-* Based Web Services and WOA Standards to Enterprise Application-to-Application Interoperability Challenges,” Gartner 2007.

[2]Yes, Plain Old XML, or POX, is a real industry term and a real acronym.

Copyright Notice

Copyright © 2011-2015 by HostBridge Technology. All rights reserved. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any computer language, in any form or by any means, electronic, mechanical, optical, chemical, manual, or otherwise, without prior written permission. You have limited permission to make hardcopy or other reproductions of any machine-readable documentation for your own use, provided that each such reproduction shall carry this copyright notice. No other rights under copyright are granted without prior written permission. The document is not intended for production and is furnished “as is” without warranty of any kind. All warranties on this document are hereby disclaimed including the warranties of merchantability and fitness for a particular purpose.

Revision date: 8/10/2012


HostBridge and the HostBridge logo are trademarked by HostBridge Technology. All other trademarks mentioned are property of their respective owners.