Patterns for JSON in CICS
There are a number of approaches and patterns for using JavaScript Object Notation (JSON) in CICS, with the capabilities of the Customer Information Control System (CICS) Transaction Server (CICS TS) Feature Pack for Mobile Extensions. These approaches are described in this chapter, and the advantages of each pattern are explained, giving examples of when they could be applied. This chapter covers the following topics:
4.1 CICS as a JSON web service provider
When CICS acts as a provider of a JSON web service, it receives incoming requests and calls CICS programs to process them. There are two main approaches to developing a JSON web service in CICS, depending on whether you start with an existing application or with a JSON message. In either case, you can use the CICS JSON assistant (batch utilities called DFHJS2LS and DFHLS2JS) to generate the necessary artifacts.
When you start with an existing JSON message, you can use either a Request-Response or Representational State Transfer (REST)-conforming (RESTful) pattern. However, if you want to reuse an existing application with the RESTful pattern, you must write a wrapper program. Figure 4-1 contrasts the two approaches, and they are explained in more detail in the following sections.
Figure 4-1 The two approaches for developing JSON web services
4.1.1 Starting with an existing application (bottom-up)
The bottom-up approach is used when you have an existing CICS application that you want to make available as a JSON web service. No changes are required to the application, and CICS handles the conversion between JSON and application data. The application does not need to have any knowledge that it is being started as a JSON web service.
This approach normally involves a relatively small implementation cost when compared to other approaches, and can also be low-risk, because the application remains unchanged. Chapter 9, “Language structure to JSON schema scenario” on page 93 describes a scenario that applies the bottom-up approach.
The interface to the application is described using high-level language structures, and the CICS JSON assistant generates JSON schemas describing the request-and-response messages. Then, a client application (which might be a mobile application) can be written using these schemas as a basis.
CICS transforms the incoming request to an application, and calls the application using either a channel and container or communication area (COMMAREA) interface. This action implies that the application is appropriately structured to separate business logic from presentation logic.
The described approach results in a web service interface that is closely coupled to the underlying application. All of the fields in the language structure will be present in the JSON messages (unless changes are made to the language structures specifically for service enablement), although they might not be required for all operations supported by the application.
These superfluous fields might result in larger-than-necessary payloads, and data formats that are not convenient for the client to provide. The bottom-up approach inherently creates a request-response style, activity-based interaction rather than a RESTful one.
4.1.2 Starting with an existing JSON interface (top-down)
The top-down approach is used when you have an existing JSON web service interface that you want to implement in CICS. You might be developing a new application, or you might have an existing application you want to adapt to a new interface. The interface might have been mandated by a partner company, an industry standard, or an existing client application.
This approach will always involve some development effort, and will require some part of the application to be aware of the JSON web service interface to a degree. Chapter 10, “JSON schema to language structure scenarios” on page 105 describes a scenario that applies the top-down approach.
The interface to the service is described using JSON schemas. As JSON web services are often documented in a less formal way, you might have to create a JSON schema. Then use the CICS JSON assistant to generate language structures.
If you are writing a new application, you can develop it based on these language structures. If you want to reuse an existing application, you can write a wrapper program based on the language structures (which program adapts data into a format acceptable to the existing application). At run time, CICS converts between JSON and application data described by the generated language structures.
CICS implements two patterns for JSON web services developed using this approach. You can choose to adopt either the Request-Response or RESTful patterns for your web service, depending on the interface to which you need to conform, or your business requirements.
Request-Response
The Request-Response pattern enables a remote procedure call-style interaction to be implemented, similar to that of SOAP web services. Services are activity-oriented, and typically provide one or more well-defined functions. The function to be performed, and its parameters, are normally identified as part of the payload.
Some application state might be maintained by the service. Every web service invocation involves a request message and a response message, and these might differ. Only the Hypertext Transfer Protocol (HTTP) POST method is supported by CICS when using the Request-Response pattern.
This pattern might be the closest match to the style of interface supported by a traditional CICS application, and therefore might require less development effort. It works well for applications where the emphasis is on the functions performed, rather than the resources they operate on. This pattern also works well for applications where the request and response messages differ.
For example, the Request-Response pattern might be a good fit for a banking application. In this case, the emphasis is on the actions being performed, such as deposits and withdrawals. It wouldn’t make sense to treat a withdrawal as a resource that is created and updated. Instead, the application would consist of services such as getAccountBalance and transferFunds, and the parameters (such as account numbers and amounts) would be carried in the request body.
RESTful
The RESTful pattern provided by CICS implements a pure form of the REST architectural style (described in 2.1, “REST” on page 12). A RESTful JSON web service operates on a single application-specific resource, which is normally identified by the Uniform Resource Identifier (URI). A single message format describes this resource, and is used for either the HTTP request or response, depending on the function. The function performed on the resource is determined by the HTTP method.
A RESTful web service provider program (which might be a wrapper program) must perform the following tasks:
•Identify the resource from the URI.
A RESTful web service request relates to a specific resource that is normally identified by the URI. Typically, a URIMAP with a wildcard will be used so that CICS calls the web service for any instance of a given resource. The application must extract the resource identifier from the URI. CICS provides several containers with fragments of the URI to help with the identification.
•Check the HTTP method to determine what function to perform.
CICS puts the HTTP method in a container, which the application must read and perform the corresponding function. The function is application-dependent, and might involve linking to other business logic. A service does not need to support each method, and you can specify which methods your service accepts when using the JSON assistants. CICS validates that the method in the request is supported by the service before calling the program.
•Return an appropriate response.
If the method requires a response, the application can return data that CICS will transform to JSON. Otherwise, the application can set the HTTP status to indicate success or error. You can also choose to send a custom HTTP response body directly.
For more information about these tasks, see “Creating a RESTful web service provider application” in the CICS TS Feature Pack for Mobile Extensions Information Center. For CICS TS 5.1, see the following website:
Figure 4-2 on page 25 shows how a wrapper program can be used to perform these tasks, making existing business logic available as a RESTful JSON web service.
Figure 4-2 Using a wrapper program to make an existing application available as a RESTful JSON web service
Adopting the RESTful pattern requires at least some degree of application development to extract the relevant information from the request and convert it to a form usable by the business logic. For an application to be truly RESTful, it should be designed using the pattern from the ground up.
However, some benefits could be gained from adopting a RESTful pattern for the interface, even if the application itself does not fully implement REST. RESTful web services are most suited to applications where the focus is on the resources, and the functions are a good match with the set of HTTP methods.
For example, the RESTful pattern would be a good fit for an application that provides an online recipe book. It might have resources representing recipes, ingredients, and cooking techniques.
You would implement a JSON web service in CICS for each of these resources. Information about these resources might be retrieved individually (a recipe for sponge cake) or as collections (all of the ingredients for rice pudding). New recipes can be added, existing ones modified, and redundant ones deleted. However, the emphasis is on the resources and not the operations.
4.2 CICS as a client for JSON web services
In addition to making applications available as JSON web services, CICS can operate as a client of other JSON web services. This capability can be used to integrate the functionality provided by other JSON web services into the business logic of a CICS application.
4.2.1 Integrating other JSON web services into your CICS application
When designing a CICS application, you might want to use functionality provided by another JSON web service. This service could be hosted in CICS, or could be hosted on another platform.
For example, when processing a credit card application, you might want to obtain a credit score from a partner company. The partner company might make this functionality available as a JSON web service. The CICS TS Feature Pack for Mobile Extensions V1.0 provides the capability to convert between application data and JSON when starting such a service. This enables you to incorporate the credit scoring function into the business logic of your application.
Another possible scenario involves a CICS application acting as an aggregator of information from multiple services. For example, an insurance broker might implement an application in CICS to find the most competitive quote for a customer. The application would aggregate quotes from many insurance providers and compare them. Some insurance providers might also make their quoting applications available as JSON web services.
4.2.2 How CICS supports acting as a client for JSON web services
Writing a CICS application that acts as a client of JSON web service involves using a linkable interface to transform between application data, JSON, and the CICS WEB API commands to communicate with the service. If you are already familiar with how CICS supports acting as a client for SOAP web services, you should be aware that this approach is somewhat different.
When writing a client for a JSON web service, both the INVOKE SERVICE API command and the pipeline are not used. The approach used for transforming between JSON and application data, in this case, is somewhat similar to the TRANSFORM application programming interface (API) used for Extensible Markup Language (XML).
Developing an application that acts as a client of a JSON web service begins by defining the interface to the service. In most cases, the interface will already exist, defined by the party providing the service. CICS requires a JSON schema describing the interface to the service, so if one does not already exist you will need to create it.
Alternatively, if the service does not yet exist, you can start with a language structure to define the interface to the application. After you have obtained either a JSON schema or a language structure, run the CICS JSON assistants. This creates either a language structure or a JSON schema, and a CICS bundle that contains the mapping that will be used at run time to transform between application data and JSON.
You can then write a CICS application that uses the CICS WEB API commands to connect to the JSON web service. Depending on the interface to the service, you might need to send a JSON request, or the request might be encoded in the URI of the service. If you need to send JSON, you can use the linkable interface to transform your application data to JSON. Then, read the response from the remote service and, if necessary, use the linkable interface to transform the response to application data.
The linkable interface used to transform between application data and JSON consists of a transformer program provided by CICS and a designed set of containers that must be populated by your application. You use an EXEC CICS LINK PROGRAM command to call the transformer, and data is returned in containers.
For an example of how to write a client for a JSON web service, see Chapter 11, “Developing a simple JSON web service client application” on page 127.
4.3 Handling JSON in other CICS applications
Using JSON in CICS applications is not limited to web services. The linkable interface for transforming between JSON and application data can process JSON from any source, and for any purpose. This opens a wide range of possible uses of JSON in your CICS applications, whether you are reusing existing assets or creating new ones. The following list notes some examples of other uses for JSON:
•Sending and receiving JSON over transport protocols other than HTTP, such as WebSphere MQ or raw sockets.
•Interacting with a JSON data store.
•Interoperating with applications written in server-side Javascript, where JSON is the data interchange format of choice.
•Implementing complex web service interactions that cannot be implemented using CICS JSON web service support. These might include services that support several message types, or where you want to mix RESTful and Request-Response patterns.
For more information about using the linkable interface to transform JSON, see 11.1.3, “The linkable interface for transforming JSON” on page 129 and the “Transforming application data and JSON using the linkable interface” topic in the CICS TS Feature Pack for Mobile Extensions Information Center. For CICS TS 5.1, see the following website:
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset