|System z on Facebook
IBM Announces Mobile Solution for Accessing IMS Assets Using REST and JSON
Amy Bennett 060000GQRQ email@example.com | | 1,331 Visits
By Teodoro (Ted) Cipresso
IBM Software Group, Information Management - IMS Connectivity Developer
Have you heard? IMS is releasing an integrated platform for seamless modeling, publishing, and management of mobile and cloud services that access trusted IMS assets! Learn about this exciting new offering by visiting http://www-01.ibm.com/software/data/ims/mobile.html.
IMS Mobile is a comprehensive tool and runtime solution that enables you to model, publish, manage, test, and discover RESTful Web services that access IMS transactions. These services can be discovered by consumers in a public or private cloud and may be invoked by mobile applications or other REST-enabled clients. The IMS mobile server runtime is based upon IBM WebSphere® Liberty z/OS Connect. z/OS Connect is a fast, secure, scalable, and reliable connector that can reach any z/OS asset, including IMS, and provides RESTful APIs for discovering, managing, and invoking services. IMS Mobile enhances z/OS Connect with the IMS Mobile Feature—offering an integrated REST endpoint for accessing IMS transactions using JSON as the data-interchange format. JSON is a light-weight object serialization format that maps easily to data structures and is preferred for mobile applications (see personal perspective). IMS Mobile can supplement existing mobile solutions including those that incorporate IBM Worklight®, or IBM WebSphere DataPower®, or both. IMS Explorer for Development (E4D) provides live modeling, publishing, management, and unit test of RESTful services that reside on an IMS Mobile server.
Using IMS Explorer for Development (E4D), developers define four types of IMS-related resources that comprise a service: IMS Transactions, IMS Connection Profiles, IMS Interaction Property Profiles, and IMS Transaction Services. These resources are stored seamlessly on the IMS Mobile Server by E4D.
Firstly, an IMS Transaction is created using the Transaction Message editor where imported COBOL and PL/I copybooks are used to define the layout of the transaction’s input and output messages. Since COBOL and PL/I data structure field names may not be suitable for consumption by mobile and cloud applications, the Transaction Message editor supports substituting new names for data structure fields.
Secondly, an IMS Connection Profile and IMS Interaction Properties Profile resource are created to define connectivity and interaction properties for IMS (the wizards are not shown here). Lastly, an IMS Transaction Service is created using a wizard where the IMS Transaction, IMS Connection Profile, IMS Interaction Properties Profile are selected to be used by the new service.
The final step of the IMS Transaction Service wizard allows the service developer to include/exclude data structure fields from the service’s input and output interface as well as specify default values. After clicking Finish on the IMS Transaction Service wizard, the service is published and ready to be unit tested.
Unit testing an IMS Mobile service using E4D is easy and does not require knowledge of JSON. Simply select the service you want to test and create a test case. To run the test case, select it, bring up the context menu and choose Run As->IMS Transaction. In the started dialog, a table representing the request message appears at the top and a table representing the response message appears at the bottom. Enter the field values you would like to send to the service and press the play button. A request JSON message containing the field values will be sent to the IMS mobile server to invoke the service. The response JSON from the service is parsed and the response is populated.
Personal Perspective on SOAP over HTTP, REST, XML, and JSON
Over the last decade (give or take), enterprises have successfully adopted traditional Web services (e.g., SOAP over HTTP) to open up and integrate disparate systems as well as create new lines of business. These new lines of business often required componentizing applications by enabling them as Web services and using these components to compose and offer innovative products using both business-to-business (B2B) and business-to-consumer (B2C) interactions. While no one can deny that innovations such as online banking, commodities trading, loans, insurance (and more) have changed these industries in ways that benefit the consumer, something happened that often does with successful technologies—we try to use them for everything.
SOAP Web services are described using Web Services Definition Language (WSDL) wherein one or more services and the operations they support are defined. The input and output messages for each operation are described using XML Schema (XSD). Both CRUD and analytic operations are typically offered. For example, one operation may create a new client in the system, while another may score a client’s risk for life insurance, and yet another will give a client a decision on that new rewards card they’re applying for. While all of this seems reasonable, the reality is that large and complex WSDLs were created to describe the B2B and B2C interactions involved in offering these services. To prevent a proliferation of different WSDLs for similar interactions, industry-standard WSDLs (e.g., ACORD AWSP) were created to prevent a new wave of integration work between systems in the future. These industry-standard WSDLs are quite comprehensive and have contributed in part to SOAP Web services being described as “high ceremony”.
When mobile and cloud applications were first being developed, SOAP services were used but SOAP eventually lost favor to “low-ceremony” services that use the REST architectural style. The creator of the REST architectural style observed that the HTTP protocol was not being utilized to its full potential. For example, HTTP already supports CRUD operations (POST, GET, PUT, DELETE) so a meta-protocol like SOAP can be seen as redundant. REST is resource-oriented and what constitutes a resource is very flexible and open to interpretation. Resources can be concrete, such as a file on a server, or they can be conceptual, such as a store of customer data. Typically one is allowed to filter or define “views” of resources. For example, one could retrieve invoices for a specific customer by specifying GET http://www.example.org/customers/invoices?cust_id=1234. The format of the data returned by the server when using REST is determined by the HTTP Accept header sent by the client. For example, if the client states it can accept either XML or JSON as the wire format, the server can decide which one to use for the response given the nature of the data. This “negotiation” of wire formats is very powerful and is often used behind the scenes in machine-to-machine (M2M) communication, a key element in the Internet-of-Things (IoT).
Teodoro (Ted) Cipresso is a developer on IMS Enterprise Suite, specifically IMS Explorer for Development. Ted has worked for almost 14 years designing, coding, testing, supporting, and promoting Eclipse-based enterprise modernization (EM) code generation tools in Java for Windows and Linux and related runtime components that together allow high-volume Batch, CICS® and IMS transactions to process XML/JSON and provide or consume SOAP or RESTful Web services.