Patent Issued for Web Service Gateway (USPTO 10,244,067)

2019 APR 04 (NewsRx) -- By a News Reporter-Staff News Editor at Insurance Daily News -- According to news reporting originating from Alexandria, Virginia, by NewsRx journalists, a patent by the inventors Kemp, Bradley David (Bloomington, IL); Turilli, Larry Gregory (Bloomington, IL); Boll, Tracey Ann (Bloomington, IL); Ayers, Matthew Stephen (Peoria, IL), filed on March 28, 2018, was published online on April 8, 2019.

The assignee for this patent, patent number 10,244,067, is State Farm Mutual Automobile Insurance Company (Bloomington, Illinois, United States).

Reporters obtained the following quote from the background information supplied by the inventors: “Many computing environments, especially those found in corporate or governmental organizations, include host applications running on mainframe systems, for example, IBM’s z/OS operating system. These organizations often rely on mainframe host applications to run critical applications and bulk data processing, and often maintain teams of host application developers who specialize in writing programs for these platforms. Common mainframe host applications can be run in either batch or online mode, and are written in languages such as COBOL, PL/I, C/C++, Assembler, Java, CLIST, REXX, or others such as DB/2 stored procedures.

“Increasingly, computing environments of all types seek to utilize resources or services made available according to the service-oriented architecture (SOA) model. The SOA model is a software design and software architecture design pattern based upon discrete pieces of software providing application functionality as services to other applications. These services are sometimes provided over a network, thus facilitating the cooperation of computers and applications with network access. According to the web service SOA model, every computer in the network can run an arbitrary number of web services, and each web service may be built in a way that ensures that the service can exchange information with any other service in the network. If an SOA model is implemented over standard internet protocols, it is often termed a web service. Web service providers and clients communicate according to open protocols, sometimes termed service standards or web service specifications, which allow them to be used independently of platforms and programming languages, and without human intervention. Examples of common protocols include Representational State Transfer (REST), Simple Object Access Protocol (SOAP), JavaScript Object Notation Web-Service Protocol (JSON-WSP), Extensible Markup Language (XML) and others. The web services are defined by a Web Services Description Language (WSDL), an XML-based interface description language that is used for describing the functionality offered by a web service. The WSDL describes services as collections of network endpoints or ports. The WSDL specifications provide an XML format for documents for this purpose (called a WSDL file) wherein the abstract definitions of ports and messages are separated from their concrete use or instance. To be a web service client, an application must be capable of performing certain tasks required by the nature of internet communications and the web service protocols, including, for example, native sockets programming, string manipulation, and XML parsing.

“Increasingly, existing host programs seek access to information that is best accessed via, or possibly only accessible via, SOA services. Adapting existing host programs to use SOA services presents several difficulties. The host programs are often maintained by developers or teams of developers with traditional host developer skillsets. These host developers are likely to encounter a variety of difficulties in adapting host programs to use SOA services because of a mismatch between the common types of problems and architecture between the two environments. Unlike in host systems, SOA services no longer entail one discrete program natively or dynamically ‘calling’ another program. Instead, the target service in an SOA service is always on another computer. There is always a network and a network communication involved in SOA web services. There are likely to be multiple environments in SOA services such as a production environment and multiple test environments. SOA services may exist on multiple execution domains, or the same target service may even exist multiple times in the same execution domain. Host developers are likely to encounter difficulties in view of the foregoing challenges when trying to route SOA requests to the correct instance of a target service. To do so successfully would require these developers to have a substantial knowledge of the network naming conventions, to keep up with changes to target services in multiple test environments, and to imbed infrastructure logic in their host applications, which may be undesirable generally because it introduces a lack of portability into the applications and diminishes their robustness.

“Adapting host programs to use SOA services also implicates a variety of security issues. When invoking SOA services, it is preferable not to pass user credentials, but rather to secure target services using ProcessID credentials. Requester credentials may be authenticated by a Resource Access Control Facility (RACF), and target service ProcessID credentials may be authenticated according to the Lightweight Directory Access Protocol (LDAP) using Basic Authorization Credentials (BAC) in the HTTP request header. Further tangling the security is that different instances of the same target service are likely to have separate credentials, and those credentials may change over time. These security and authorization safeguards introduce an additional level of complexity to the host application that is often difficult to manage in an organized, disciplined, and efficient fashion.

“Even under optimistic assumptions of developer skill and dedication to the task, training these programmers to develop the necessary skills is expensive and time-consuming. To do so would likely require a large degree of trial-and-error development as the host application teams experiment with the SOA web services and interfaces to achieve an acceptable level of service. This approach may involve an unacceptably high risk of complete failures in the event the developers are unable to master the requisite skills and successfully incorporate the SOA services into the host application. If there are multiple host development teams, as is common in large enterprise or corporate environments, then it is likely that these teams would incur a large degree of duplication of effort, and ultimately arrive at multiple one-off solutions unique to each team and incompatible with one another.

“Even if host developer teams are able to incorporate SOA web client functionality into their applications, the APIs commonly available to host applications to enable SOA client access have several drawbacks, if they are even available at all, and are thus ill-suited for this purpose. Batch jobs and DB2 stored procedures, two common environments in which host applications execute, have no high level APIs suitable for SOA client communications. Other host application environments such as CICS or IMS have the WEBSERVICE interface and the ICAL interface using IMS Connect and IMS Soap Gateway, respectively, but use of these APIs is limited to the corresponding execution environment The only common API across all execution environments is native sockets programming, which is complicated, and requires networking protocols that are difficult to learn, and string manipulation and XML programming in host applications. This is not a common skill among host programmers.

“All of these issues are problematic when encountered by traditional host developers. Moreover, even if an organization does successfully implement SOA client code in its host programs, it will experience low code reusability, slow development, and error-prone host applications that must be addressed by programmers familiar with that particular host application. Overall, this approach presents a development environment that is far from ideal for the incorporation of SOA web services into host applications.”

In addition to obtaining background information on this patent, NewsRx editors also obtained the inventors’ summary information for this patent: “The web service gateway disclosed herein is an enterprise infrastructure component that provides a single web service API to host applications for accessing any web service.

“Aspects of the web service gateway may include: that it has a single API available across all host execution environments, it does not require significant new training of existing host application developers, it uses simple, low-cost additions to existing infrastructure for each target SOA web service, and it handles target service addresses and security credentials outside the application source by managing the addresses and credentials as configuration data in the enterprise infrastructure rather than within the host application source. The web service gateway supports multiple execution domains and multiple test environments.

“In one embodiment, the web service gateway utilizes a transaction server to assist with transaction processing, such as the Customer Information Control System (CICS) or IMS (Information Management System), both produced by IBM Corp. The transaction server executes a gateway program that permits the host applications to submit request data by dynamically or natively calling a gateway interface program in the same way a host application would traditionally call another program. The transaction processor moves any request received from a host application to the appropriate transaction server gateway system where there is an existing web service API. The transaction server handles any errors that can occur on a web service request, and returns only the results to the calling host application. The transaction processor need only implement one requester web service that invokes a proxy web service running on an SOA appliance, such as, for example, the IBM WebSphere DataPower SOA appliance. In this configuration, all host application requests flow through the same transaction server web service, request and response data flows as a single variable length character string, and all host systems have the same configuration settings for client participation in any SOA web service.

“For each target web service supported by the SOA appliance, the web service gateway registers a unique URL that delivers the transaction server’s web service request to the SOA appliance proxy web service. The host application submits data requests and receives response data in the form of copybooks or record formats populated with typed variables and/or pointers to other copybooks or record formats. These copybooks are mapped into the necessary web service protocol formats, for example SOAP, for submission to the web server via the proxy web service, and are translated back to copybook format for delivery to the calling host applications. The request copybooks contain all information necessary to complete the SOA web service requests, including the web service server, endpoint, and any necessary parameters. The response copybooks contain the response from the SOA web service as well as additional metadata supplied by the web service gateway. The web service gateway returns any error messages or error codes received from the web service API to the invoking application regardless of where they occur. The web service gateway also returns its own set of error codes to the calling application.

“The present embodiments as disclosed herein may enable an organization with skilled host application programmers to leverage a simple pattern for invoking SOA web services consistently throughout all host applications using a familiar API. The present embodiments may allow for flexibility by handling differences across execution domains outside the source code, thereby freeing the developers from a requirement of network topology knowledge. The present embodiments may also provide for secure communications, and need only a small incremental addition of infrastructure hardware for most existing enterprise computing environments.

“In one aspect, a computer-implemented web service gateway system comprises a host application execution environment including one or more processors, a memory configured to store and execute one or more host applications, and a gateway interface configured to receive a gateway copybook input from one of the host applications. The gateway copybook includes at least (1) input data including a pointer identifying a memory location where a request structure copybook resides, and (2) output data including a pointer identifying a memory location where a response structure copybook resides. A gateway program is configured to receive the gateway copybook from the gateway interface via a network and to invoke a proxy web service with a request using the request structure copybook. The proxy web service is configured to map data from the request structure copybook to web protocol format data. The proxy web service is configured to invoke a target web service with the web protocol format data. The gateway program is further configured to return a response to the gateway interface. The response to the gateway interface is based upon a response that (1) the gateway program receives from the proxy web service, and (2) uses the response structure copybook.

“In another aspect, a computer-implemented method for managing host application web service client requests includes: (1) natively calling a gateway interface from a host application; (2) submitting target web service request data in a request structure copybook to a gateway interface via a pointer in a gateway copybook to the request structure copybook, wherein the gateway copybook includes at least: (a) input data including the pointer to the request structure copybook, the pointer to the request structure copybook identifying a memory location where the request structure copybook resides; and (b) output data including a pointer identifying a memory location where a response structure copybook resides; (3) transferring, via a network, the gateway copybook from the gateway interface to a gateway program executing on a transaction server; (4) mapping, via a proxy web service, the target web service data into web service protocol format; (5) submitting target web service request data according to the web service protocol format to a target web service to facilitate managing host application web service client requests; and (6) returning a response from the gateway program to the gateway interface, the response to the gateway interface being based upon a response that (a) the gateway program receives from the proxy web service, and (b) uses the response structure codebook.”

The claims supplied by the inventors are:

“The invention claimed is:

“1. A computer-implemented web service gateway system comprising: a host application execution environment including one or more processors, a memory configured to store and execute one or more host applications, and a gateway interface configured to receive a gateway copybook input from one of the host applications, the gateway copybook including at least: input data including a pointer identifying a memory location where a request structure copybook resides; and output data including a pointer identifying a memory location where a response structure copybook resides; wherein a gateway program is configured to receive the gateway copybook from the gateway interface via a network and to invoke a proxy web service with a request using the request structure copybook, the proxy web service being configured to map data from the request structure copybook to web protocol format data; wherein the proxy web service is configured to invoke a target web service with the web protocol format data; and wherein the gateway program is further configured to return a response to the gateway interface, the response to the gateway interface being based upon a response that (i) the gateway program receives from the proxy web service, and (ii) uses the response structure copybook.

“2. The system of claim 1, wherein the proxy web service is further configured to: map response data from the target web service into a data format of the response structure copybook.

“3. The system of claim 1, wherein the proxy web service is further configured to: transmit mapped response data to a transaction server.

“4. The system of claim 3, wherein the transaction server is configured to: store gateway copybook data in a container.

“5. The system of claim 3, wherein the transaction server is configured to: receive response data from the proxy web service.

“6. The system of claim 3, wherein the transaction server is configured to: update the response structure copybook with information received from the target web service.

“7. The system of claim 3, wherein the transaction server is configured to: update the gateway copybook with metadata relating to information received from the target web service.

“8. The system of claim 3, wherein the transaction server is configured to: transmit response data from the target web service to the gateway interface.

“9. The system of claim 3, wherein the gateway interface is further configured to: receive the gateway copybook containing the pointer identifying a memory location where a response structure copybook resides from the transaction server.

“10. The system of claim 3, wherein the host application execution environment is the transaction server.

“11. The system of claim 1, wherein the proxy web service is further configured to: retrieve service information from a configuration Extensible Markup Language file.

“12. The system of claim 1, wherein the gateway interface is further configured to: transmit response data from the target web service to the one of the host applications.

“13. The system of claim 1, wherein the gateway interface is further configured to: identify the host application execution system.

“14. The system of claim 13, wherein the gateway interface is further configured to: update the gateway copybook with transaction server connection information based upon an identification of the local network topology of the identified host application execution system.

“15. The system of claim 1, wherein the host application comprises: a message viewing area.

“16. A computer-implemented method for managing host application web service client requests, the method including: natively calling a gateway interface from a host application; submitting target web service request data in a request structure copybook to a gateway interface via a pointer in a gateway copybook to the request structure copybook, wherein the gateway copybook includes at least: input data including the pointer to the request structure copybook, the pointer to the request structure copybook identifying a memory location where the request structure copybook resides; and output data including a pointer identifying a memory location where a response structure copybook resides; transferring, via a network, the gateway copybook from the gateway interface to a gateway program executing on a transaction server; mapping, via a proxy web service, the target web service data into web service protocol format; submitting target web service request data according to the web service protocol format to a target web service to facilitate managing host application web service client requests; and returning a response from the gateway program to the gateway interface, the response to the gateway interface being based upon a response that (i) the gateway program receives from the proxy web service, and (ii) uses the response structure codebook.

“17. The computer-implemented method of claim 16, further comprising: receiving response data from the target web service, the response data being according to the web service protocol format; and mapping the response data from the target web service into response structure copybook format.

“18. The computer-implemented method of claim 17, further comprising: transmitting mapped response data to the transaction server; and updating the gateway copybook with information received from the target web service, wherein updating the gateway copybook with information received from the target web service includes updating the gateway copybook with metadata.

“19. The computer-implemented method of claim 18, further comprising: identifying a host application execution system; and updating the gateway copybook with transaction server connection information based upon an identification of a local network topology of the identified host application execution system.

“20. The computer-implemented method of claim 18, further comprising: identifying a host application execution system; and updating the gateway copybook with transaction server connection information based upon an identification of a local network topology of the identified host application execution system.”

For more information, see this patent: Kemp, Bradley David; Turilli, Larry Gregory; Boll, Tracey Ann; Ayers, Matthew Stephen. Web Service Gateway. U.S. Patent Number 10,244,067, filed March 28, 2018, and published online on April 8, 2019. Patent URL: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=10,244,067.PN.&OS=PN/10,244,067RS=PN/10,244,067

(Our reports deliver fact-based news of research and discoveries from around the world.)