Connecting mobile devices to CICS Transaction Server
This chapter is about general considerations when using mobile devices to interact with IBM CICS TS applications. The two chapters that follow covers specific CICS TS technologies for connecting mobile devices when using IBM CICS Transaction Server for z/OS Value Unit Edition.
This chapter includes the following topics:
5.1 Mobile devices and IBM CICS Transaction Server for z/OS Value Unit Edition
For many years, CICS TS has been capable of hosting programs that can be called from outside CICS TS. Technologies such as the CICS TS Transaction Gateway, CICS TS Web Support, and CICS TS web services have enabled integration of CICS TS assets in a heterogeneous computing environment. The clients of these services could be dumb terminals, web browsers, peer servers, or even mobile devices.
Exposing existing CICS TS assets to new types of clients can be an example of a new workload, particularly if the client is a mobile device, or other system of engagement. There are many technologies that can be used to connect a mobile device to CICS TS, some of which involve hosting transformation services in CICS TS. The transformation service qualifies as a candidate for approval to be hosted in IBM CICS Transaction Server for z/OS Value Unit Edition if it meets these conditions:
•Enables a new type of client (that is, a new workload) to call a program in CICS TS
•Is hosted in a JVM server in CICS TS
•Links to a target application program that is hosted in a regular CICS TS region
These are examples of transformation services that enable connectivity:
•Transforming data in JSON format to and from CICS TS application data format
•Transforming data in XML format to and from CICS TS application data format
Figure 5-1 illustrates a mobile device being used to access CICS TS. A transformation service is hosted in the Value Unit Edition and provides access to applications from another CICS TS region.
Figure 5-1 Hosting a transformation service that links to an existing CICS TS program
Two major connectivity options exist that can satisfy the criteria:
•Hosting transformation services in an IBM WebSphere Application Server Liberty profile environment in CICS TS. This can involve using standard Java data manipulation technologies, such as JAX-RS and JAX-WS. The WebSphere Application Server Liberty profile is hosted within a JVM server in CICS TS. Therefore, it is candidate for approval to be deployed to the Value Unit Edition.
•Hosting CICS TS integrated transformation services in a JVM server. This involves hosting a WSBind file in a Java-based pipeline in CICS TS. Because the pipeline meets this hosting criterion, it a candidate for approval to be deployed to the Value United Edition.
These two techniques are described further in the two chapters that follow:
The remainder of this chapter reviews issues that are common to both scenarios.
|
Note: Other techniques exist to connect a mobile device to CICS TS, but the associated workload is less likely to be approved to be hosted in IBM CICS Transaction Server for z/OS Value Unit Edition. The techniques presented in this book are candidates for approval for use with the Value Unit Edition.
If you’re interested in alternative connectivity, you could consider using any of these options:
•IBM WebSphere Liberty z/OS Connect
•CICS Web Support and the 3270 Web Bridge
•CICS native web services implementation
•CICS Transaction Gateway
•Connectivity through IBM MQ
•Any other mechanism that can send work to CICS
Mobile devices, and the intermediate servers that they communicate with, are general purpose computing devices. With sufficient effort, they can be made to communicate by using any protocol that is supported by CICS.
|
5.2 Use of mobile devices with CICS TS
The revolution in mobile computing is a significant opportunity for CICS TS based organizations. By extending existing enterprise applications to a mobile platform, a business can capitalize on its existing investment without the need to develop an entirely new solution to support mobile services. In addition, a line of business can provide service to users who increasingly expect to be able to interact with an organization byusing their mobile phones.
As a platform, these are the primary benefits offered by CICS TS with mobile devices:
•Provides reuse of existing enterprise services
Existing assets and investments can be reused as part of a mobile application. Any existing investment in web services can be leveraged for mobile clients.
•Provides simplified access to enterprise data
CICS TS supports access to data by using two popular data serialization formats: XML (Extensible Markup Language) and JSON (JavaScript Object Notation). JSON is a particularly popular data format for use from mobile devices.
•CICS TS already operates at the heart of the enterprise
Hosting mobile applications within CICS TS brings them closer to the enterprise data that they are accessing. This minimizes application path lengths and improves response time.
•Adopts a RESTful architectural style for service delivery
A RESTful architectural style is one where the target resource and the operation to be performed against it are defined by a combination of a well-structured Uniform Resource Identifier (URI) and one of the four Hypertext Transfer Protocol (HTTP) methods (GET, POST, PUT, and DELETE). This architectural approach is favored among developers of applications for mobile devices.
•Provides capacity to manage mobile workloads
Customers around the world use CICS TS TS to host hundreds of millions, and in some cases billions, of transactions per day. CICS TS workload management provides a robust and scalable platform that is suitable for supporting the heaviest of mobile workloads.
5.3 Accessing services by using XML and JSON
There are two common standards-based technologies for cross-platform data serialization: Extensible Markup Language (XML) and JavaScript Object Notation (JSON). CICS TS supports them both. It is likely that workload initiated from a mobile device will use one of these formats.
The two formats share much in common. They both provide a way to describe structured data in an interoperable text-based form. But their differences make them more or less suitable for particular use scenarios. Either format can be used to serialize data when contacting CICS TS from a mobile device, either directly or indirectly, via an intermediate gateway, mediation service, or server.
5.3.1 Extensible Markup Language (XML)
XML is readily recognizable by the presence of angle brackets in the serialized data. XML tags wrap each atomic data unit. The size of these tags can be a significant proportion of the total size of the serialized data, which is the main cause of XML’s reputation as a verbose (therefore inefficient) data format. In Example 5-1 on page 51, 160 characters of markup data are used, compared to 85 characters of application data.
XML-based web services have been supported in CICS TS Transaction Server since
version 3. They involve a Web Service Description Language (WSDL) document that describes the data format for a service in an interoperable form. Client programs can be written or generated to call the XML-based web service by using the information from the WSDL document.
version 3. They involve a Web Service Description Language (WSDL) document that describes the data format for a service in an interoperable form. Client programs can be written or generated to call the XML-based web service by using the information from the WSDL document.
The XML representation of the data is encapsulated in a SOAP message. SOAP is the messaging protocol. A SOAP message can optionally contain an extensible list of headers in addition to the XML application data. A family of related specifications has evolved for SOAP and WSDL to allow for sophisticated data exchange models, including such qualities of service as transactionality, identity propagation, and dynamically reconfigurable addressing.
SOAP implements its own error format, the SOAPFault. Applications pass error information to each other by using SOAPFault messages.
XML-based web services are widely adopted in many industries and in many programming environments. They remain a favorite technology for interoperability scenarios.
Example 5-1 XML data example with 160 characters of markup, 85 characters of application data
<contact xmlns="http://example.org/contacts">
<name>International Business Machines Corp.</name>
<address>
<street>1 New Orchard Road</street>
<city>Armonk</city>
<state>NY</state>
<code>10504-1722</code>
</address>
<phone>800-426-4968</phone>
</contact>
5.3.2 JavaScript Object Notation (JSON)
JSON is a relatively young technology compared to XML. It offers an alternative method for serializing data, characterized by the presence of curly braces in the data. It generally serializes data to a shorter form than the equivalent XML, which has led to its reputation as an efficient data format. In 5.3.3, “Key differences between XML and JSON” on page 52, 81characters are used for markup of the same application data that required 160 characters for XML markup in Example 5-1.
Example 5-2 Example JSON data, 81 characters of markup, 85 characters of application data
{
"name": "International Business Machines Corp.",
"address": {
"street": "1 New Orchard Road",
"city": "Armonk",
"state": "NY",
"code": "10504-1722"
}
"phone": "800-426-4968"
}
JSON is particularly associated with the JavaScript programming language, which is popular as a language for mobile devices. It is often the data format of preference among developers of mobile applications. CICS TS has supported JSON-based web services since version 4 release 2, through use of the CICS TS Feature Pack for Mobile Extensions.
JSON does not have an equivalent to the WSDL document used in XML, so it can be difficult to document the characteristics of a JSON interface in a formal fashion. A JSON schema language exists for defining the syntax of JSON data, but it is not widely implemented throughout the industry.
JSON does not have the wealth of supporting specifications that are available for XML web services. This can limit its usefulness for some tasks but makes it more efficient for others.
JSON enables (but does not require) a Representational State Transfer (RESTful) interface to data. Typical CICS TS programs implement a remote procedure call that accepts input, performs an action, and returns output. This pattern is referred to as request-response.
A RESTful interface is quite different. It is data-driven, where each data fragment is referenced through its own URI, and the only actions that can be performed on the data are Create, Read, Update, and Delete. These actions map to the underlying HTTP methods of POST, GET, PUT, and DELETE. This concept is rather exotic under CICS TS, but it is widely used among JSON service providers. The association between JSON and RESTful services is sufficiently strong that the terms are sometimes used interchangeably.
5.3.3 Key differences between XML and JSON
The following list explains the key differences between the two formats, as implemented in CICS TS:
•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.
•JSON is easy to integrate in JavaScript applications, but XML is not. This difference makes JSON a preferred data format for many mobile application developers.
•SOAP provides a mechanism to add headers to a message and a family of specifications for qualities of service. For example, WS-Security defines sophisticated rules for securing SOAP messages, and WS-AtomicTransactions defines a distributed two-phase commit protocol. JSON does not have this mechanism. Instead, it relies on the services of the underlying HTTP network protocol. This reliance results in fewer options for securing and configuring a workload.
•SOAP web services are described by using WSDL documents. JSON web services are structured less formally. They tend to be loosely coupled and rely on informal documentation, often including examples of serialized data.
•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 SOAPFault messages. There is no equivalent for JSON.
•SOAP web services support use of both HTTP and IBM MQ based messaging, whereas JSON requires HTTP.
•JSON web services support both RESTful and request-response driven interfaces, but SOAP supports only the request-response interface.
•The comparative performance characteristics of the two technologies are difficult to predict. The smaller payload of a JSON message does not necessarily result in a less costly or more efficient web service. The business cost is further complicated by the deployment technologies, which involves the use of IBM CICS Transaction Server for z/OS Value Unit Edition, IBM Mobile Workload Pricing for z/OS, and IBM System z Application Assist Processors.
Business requirements are likely to dictate which data serialization protocol is used in a project. In general, SOAP tends to be more suitable for server-to-server communication (for quality of service), and JSON is more suitable for mobile device-to-server communication (for ease of client-side development). In some deployment scenarios, JSON is be used between the mobile device and an intermediate server, and SOAP is used for further server-to-server communication.
5.4 CICS TS web service development strategies
Enabling a CICS TS program to be called from a mobile device often involves exposing it as a remotely callable web service.
There are two main service enablement techniques used to do this. The first is called bottom-up, and it involves exposing an existing asset to new callers. The second is called top-down, which involves implementing a new service that conforms to the requirements of an external specification. A third, hybrid scenario also exists, called meet-in-the-middle.
In each case, a transformation service is used to convert the application data to and from the format used for data interchange. The data interchange format can be either JSON or XML. The application data is structured in the format used by the application (for example, as described by a COBOL copybook).
5.4.1 Bottom-up service enablement
In this scenario, a web service (based on either JSON or XML) is generated from an existing program. The programmatic interface to the existing program (such as a COBOL copybook) is processed by using tools, and transformational metadata or programs are produced. The specifics of how this works and the artifacts produced vary by scenario. But the general concept is common to both: You have an existing asset that needs exposing as a web service, and the tools make this possible without changing the existing application.
In practice, this is not always achievable. There can be characteristics of an existing application that make it unsuitable for use as a web service. For example, it might have a 3270 interface, rely on the existence of a CICS TS terminal, or use shared memory for cross-program communication. A program’s interface might rely on data types that are not supported by the tools, such as pointers, or redefined data structures.
In most cases, an existing program can be exposed as a web service, either without changes or with minimal additional effort.
5.4.2 Top-down service enablement
In this scenario, a web service (either JSON- or XML-based) is generated from a specification document, typically either a WSDL document or a JSON-Schema. Tools are used to generate new application data structures from that specification. A new application is then written that uses the generated data structures and interacts with the existing programs.
This generally results in a better web service than in a bottom-up approach. The interface is defined according to the requirements of the service, not the existing implementation. Services can be designed to support version control and to evolve with minimal disruption for existing callers.
An important variation of a top-down scenario involves creation of a requester or client program in CICS TS. This program can invoke a remote web service that is hosted outside of CICS TS. Requester mode scenarios can also be considered as part of a new workload if the transformation capability is hosted in a JVM server. One method that can be used is to have a CICS program link to a stub program that is hosted in IBM CICS Transaction Server for z/OS Value Unit Edition, and the stub can invoke the remote web service. The stub must either be hosted in a JVM server or drive a transformation service that is hosted in a JVM server to be a candidate for approval for the Value Unit Edition.
5.4.3 Meet-in-the-middle service enablement
This is a hybrid scenario that can combine the best features of both bottom-up and top-down service enablement. It involves mapping an existing program to a defined interface.
A typical meet-in-the-middle scenario involves generating a web service interface to an existing application by using bottom-up enablement techniques. This is followed by a manual modification of the generated service description documents. The modifications might include renaming fields so that they will make sense to an external developer, removing unnecessary content, adding additional validation rules, adding versioning information, and so on.
After a perfected interface is established, the existing program must be integrated with the new interface. This might involve the use of tools to map between the two formats or the generation of new application structures by using top-down techniques. The application might need to be changed to implement the new interface. Subsequent maintenance of the web service is performed top-down from the service description document.
This technique tends to involve significantly more effort than a pure bottom-up enablement strategy, so it is not popular for that reason. But it results in a better quality of web services.
5.5 IBM MobileFirst Platform Foundation and CICS TS
The recommended strategies for integrating mobile devices into a secure and high-performance CICS TS environment are described in the IBM Redbooks publication titled Implementing IBM CICS JSON Web Services for Mobile Applications, SG24-8161:
A key consideration includes the use of IBM MobileFirst Platform Foundation (formerly known as IBM Worklight®), which provides a comprehensive platform on which to build, test, run, and manage mobile web applications. It can help reduce both application development and maintenance costs, improve time to market, and enhance mobile application governance and security.
Figure 5-2 on page 55 illustrates a MobileFirst server being used to mediate between the mobile devices and CICS TS.
Figure 5-2 IBM MobileFirst server as an intermediate node between mobile devices and CICS TS
The MobileFirst server acts as an aggregation point, allowing many devices to share a single connection to CICS TS. It also provides device abstraction services for the application developer, helps ensure the physical security of the devices, and can provide protocol conversion services for CICS TS.
The mobile devices can communicate with the MobileFirst server by using JSON format data, and the MobileFirst server can communicate with CICS TS by using whatever mechanism is most convenient, including both JSON- and SOAP-based web services.
The MobileFirst capabilities for mobile application security are explained in the IBM Redbooks publication titled Securing Your Mobile Business with IBM Worklight, SG24-8179:
5.6 IBM DataPower and CICS TS
An IBM WebSphere DataPower® appliance is often deployed alongside CICS TS to secure web services workloads.
DataPower can secure mobile traffic before it arrives at CICS TS and validate the JSON and XML data at high speeds, acting as a form of firewall. It can also be used in combination with IBM MobileFirst to provide authentication services for mobile devices.
The combination of DataPower and MobileFirst to secure mobile workloads is described in detail the IBM Redbooks publication titled Securing Your Mobile Business with IBM Worklight, SG24-8179, cited previously.
Figure 5-3 illustrates DataPower being used to authenticate users and secure communication between mobile devices and the MobileFirst server.
Figure 5-3 IBM DataPower appliances authenticate user sand protect communication to the MobileFirst server
The DataPower capabilities for integrating and securing web services for CICS TS are explained in the IBM Redbooks publication titled Set Up Security and Integration with the DataPower XI50z for zEnterprise, SG24-7988:
5.7 Configuration for high availability
Configuring a CICS infrastructure for high availability involves two primary techniques:
•Using TCP/IP load balancing to distribute work across several routing regions
•Using a distributed program link to route work to a suitable application-owning region
|
Note: Additional techniques may be available for deployment scenarios that involve the use of WebSphere Application Server Liberty profile.
|
Figure 5-4 illustrates a workload being balanced across a series of CICS routing regions, each of which hosts a transformation service for new workload and routes the work to a group of application-owning regions (AORs) in another LPAR.
Figure 5-4 Workload balancing across multiple regions
These techniques are suitable for use in both of the implementation scenarios described in Chapter 6, “Mobile devices and CICS Liberty JVM server” on page 59 and in Chapter 7, “Mobile devices and CICS TS Java” on page 67.
The IBM Redbooks publication titled CICS Web Services Workload Management and Availability, SG24-7144, explores the CICS architectures for supporting high availability of web services:
The two chapters that follow investigate two different technologies that are suitable for hosting Java-based transformation services:
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.