BRPI0417511B1 - PROXY AGNOSTIC SUPPORT METHOD AND SYSTEM FOR WEB SERVICES INTERMEDIATE DOOR TYPE - Google Patents

Description

(54) Title: METHOD AND SYSTEM FOR SUPPORTING AGNOSTIC PROXY AS TO DOOR TYPE FOR WEB SERVICES INTERMEDIARIES (51) lnt.CI .: H04L 29/08 (30) Unionist Priority: 12/12/2003 US 10 / 734,773.12 / 12/2003 US 10 / 734,770 (73) Holder (s): INTERNATIONAL BUSINESS MACHINES CORPORATION (72) Inventor (s): GREGORY ALAN FLURRY; SIMON ANTONY JAMES HOLDSWORTH; JAMES MICHAEL SNELL (85) National Phase Start Date: 06/12/2006

1/63

METHOD AND SYSTEM. FOR AGNOSTIC PROXY SUPPORT AS TO

TYPE OF DOOR FOR WEB SERVICES INTERMEDIARIES.

Technical Field [0001] The field of the invention is data processing or, more particularly, methods, systems and products to support agnostic proxy as to the type of port for web service intermediaries.

Prior Art [0002] The term web services refers to a standardized way of integrating web-based applications. Web services typically provide business services upon request through data communication in standardized formats called bindings. A binding is a specification of a data encoding method and a data communication protocol. The most common binding in use for web services is the data encoding in XML, according to the SOAP protocol and data communications with HTTP.

[0003] Unlike traditional client / server models, such as an HTTP server that provides HTML documents in response to requests from browser clients, web services are not involved with display. Web services, instead, share business logic, data and processes through a programmatic interface over a network. Web service applications interface with each other and not with users. Since all data communications between web services are done according to standardized bindings, web services are not tied to any operating system or programming language. A Java client running on a Windows _TM platform can

Petition 870180049145, of 06/08/2018, p. 9/71

2/63 call web service operations written in Perl and that run inside Unix. A Windows application written in C ++ can call operations on a web service implemented as a Java servlet.

[0004] Today's web services are growing across many industries. As web services grow in importance, web service intermediaries are increasingly recognized as a means to provide many value-added services. A web services intermediary, generally referred to in this description as an intermediary, is a web service component that lies between a web service client and a web services provider. Intermediaries generally operate by intercepting a customer request, providing intermediary services and then forwarding the customer's request to a web service provider. Similarly, responses from web service providers are intercepted, operated, and then returned to the customer. Examples of commercially available products, with which web services intermediaries can be implemented, include IBM's Web Services Gateway ™ and IBM's Web Service Bus ™.

[0005] Services provided by intermediaries include authenticating request sources for target services, validating messages for content and forms, and recording messages for auditing purposes. Intermediaries can provide management reporting services, number of web service accesses, number and timing of services used by individual customers, and so on. Intermediaries can be

Petition 870180049145, of 06/08/2018, p. 10/71

3/63 used as caches in support of improved performance storing frequently changed but frequently requested data, such as new stories, for example. Intermediaries can be used to improve performance in the sense of load balancing, storing requests for services from some customers and forwarding them to a target service during off-peak service hours. Intermediaries can add services, such as, for example, an accounting intermediary that accepts requests for account postings that are then routed to separate target services into payable accounts, receivable accounts and general tax book services.

[0006] It is common in the state of the art to implement web service intermediaries so that they are firmly coupled to their target services. That is, a private broker provides intermediary services only for private web services. The need for this is clear when, for example, the intermediary provides message validation and must therefore have accurate knowledge of the appropriate message content and form. In this web services terminology, an operations group is referred to as a type of port. In this terminology, the restriction of the high coupling medium that commonly in the state of the art, an intermediate service and all target services served by the intermediate service would have the same type of port. There are situations, however, where it is useful for an intermediary service to work through port types, for example, a client identity authorization function designed to provide exactly the same

Petition 870180049145, of 06/08/2018, p. 11/71

4/63 authentication in messages directed to any target service, regardless of the type of port. The state of the art forces additional configuration complexity in such cases and there is an ongoing need for improvement of web service intermediaries.

Description of the Invention [0007] According to a first aspect, an agnostic proxy support method is provided as to the type of port for web service intermediaries, the method comprising: -receiving, at a web services intermediary, a request to perform a web service operation, where the request includes parameter information from which an endpoint for a target service that supports the operation can be identified; identify, depending on the parametric data, the endpoint for a target service that supports the operation, create a target service request to perform the operation of the target service; and issue the target service request to the target service.

[0008] In one embodiment, it is determined whether the request requires a synchronous response; and a response from the target service is expected if the request requires a synchronous response.

[0009] In typical embodiments, the determination whether the request requires a synchronous response is made by determining depending on parametric information whether the request requires a synchronous response. In typical embodiments, creating a target service request to perform the operation on the target service includes creating the target service request depending on a determination whether the

Petition 870180049145, of 06/08/2018, p. 12/71

5/63 request requires a synchronous response. For a request that does not require a synchronous response, some embodiments include receiving a confirmation of the target service request from the target service and returning the confirmation to a requester without waiting for a response message.

[0010] For a request that does not require a response, some embodiments implement waiting for a response from the target service for synchronous receipt at the intermediary of a response from the target service; creation in the intermediary, depending on the response from the service request, of a response from the intermediary; and return the response from the intermediary to a requester. In typical embodiments, the synchronous receipt at a broker of a response from the target service is done by invoking a block receiving function on a data communication connection between the broker and the target service.

[0011] In many embodiments, the target service request as created and issued to the target service takes unexamined and unmodified message contents from the request received at the web service intermediary. Exemplary embodiments typically also include the return path of response request processing: receiving a response from the target service at the intermediary; create in the intermediary depending on the response from the target service, a response from the intermediary; and return the response from the intermediary to the requesting customer.

Petition 870180049145, of 06/08/2018, p. 13/71

6/63 [0012] Typical embodiments of the present invention also include identifying for a requester an endpoint of the web services intermediary as an endpoint that supports the operation. In such embodiments, parametric information often includes a type of door for the operation. In addition, identifying an endpoint for a target service that supports an operation often also includes identifying, depending on parametric information, a multiplicity of target service endpoints that support the operation and selecting an endpoint from the multiplicity of endpoints according to the rules of selection. The identification of a multiplicity of endpoints of the target services that support an operation can be done by identifying from a record depending on a type of port, a multiplicity of target services for the type of port. Selecting an endpoint from the multiplicity of endpoints may include selecting an endpoint from the multiplicity of endpoints according to the selection rules for load balancing between target services.

[0013] The creation of a target service request to perform the operation on the target service can be performed by composing the request in a useful data structure in a neutral binding interface and called a neutral binding interface, passing the request as a call parameter. Issuing the target service request to the target service may include calling one or more member methods on a neutral binding interface.

[0014] In accordance with a second aspect, the invention provides a system for supporting agnostic proxy regarding

Petition 870180049145, of 06/08/2018, p. 14/71

7/63 to the type of port for web service intermediaries, the system comprising: means for receiving, at a web services intermediary, a request to perform a web services operation, where the request includes parameter information from which an endpoint for a target service that supports the operation can be identified; means to identify, depending on the parametric data, the endpoint for a target service that supports the operation; means for creating a target service request to perform the operation of the target service; and means for issuing the target service request to the target service.

[0015] In accordance with a third aspect, a computer program product is provided to support agnostic proxy as to the type of port for target service intermediaries, the computer program product comprising: a recording medium; medium, recorded on a recording medium, to receive, at a web services intermediary, a request to perform a web services operation, where the request includes parameter information from which an end to a target service that supports the operation can be identified; medium, recorded on a recording medium, to identify, depending on the parametric data, the endpoint for a target service that supports the operation; medium, recorded on a recording medium, to create a target service request to perform the operation of the target service; and a half, recorded on a recording medium, to send the target service request to the target service.

Petition 870180049145, of 06/08/2018, p. 15/71

8/63 [0016] The invention can be implemented in computational software.

Brief Description of the Drawings [0017] Preferred embodiments of the present invention will now be described by way of example only and with reference to the following drawings:

Figures IA and 1B show line drawings of exemplary architectures for web services, in which proxy support agnostic as to the type of port for web service intermediaries can be implemented in accordance with the embodiments of the present invention.

Figure 2A shows a line drawing of a block diagram of an exemplary intermediate according to embodiments of the present invention.

Figure 2B shows a line drawing of a block diagram of an intermediary (202) implementing a SOAP - http channel according to the embodiments of the present invention.

Figure 3 shows a flowchart illustrating, according to a first embodiment, an agnostic proxy support method as to the type of port for web service intermediaries.

Figure 4 presents a flowchart that illustrates, according to a second embodiment, an agnostic proxy support method as to the type of port for web service intermediaries.

Figure 5 shows a flowchart that illustrates, according to a second embodiment, a method of waiting (361) for a response from a target service when a request requires a synchronous response.

Petition 870180049145, of 06/08/2018, p. 16/71

9/63

Mode for the Invention [0018] The present invention is described by a wide extent in that specification in terms of methods for supporting agnostic proxy as to the type of port for web service intermediaries. Persons skilled in the art, however, will recognize that any computer system that includes programming means for operation in accordance with the disclosed methods will also fall within the scope of the present invention. Suitable programming means include any means for directing a computer system to perform the steps of the method of the invention, including, for example, systems comprised of processing units and arithmetic logic circuits coupled to the computer's memory, whose systems are capable of store in the computer's memory, where the computer's memory includes electronic circuits configured to store data and program instructions, programmed steps of the method of the invention for execution by a processing unit.

[0019] The invention can also be realized in a computer program product, such as a floppy disk or other recording medium for use with any suitable data processing system. Embodiments of a computer program product can be implemented by using any recording media for machine-readable information, including magnetic media, optical media, or other suitable media. Persons skilled in the art will immediately recognize that any computer having adequate programming means will be able to perform the steps of the method of the invention as embodied in a

Petition 870180049145, of 06/08/2018, p. 17/71

10/63 program product. Persons skilled in the art will immediately recognize that, although most of the exemplary embodiments described in this description are guided by software installed and running on the computer hardware, however, alternative embodiments implemented as firmware or as hardware are within the scope of the present invention.

Definitions [0020] A business register, as the term used in this description, is an Internet directory of web services containing business listings and web services offered by stores. Web service listings include supported operations, port types, endpoints, bindings, and so on. Some business registries are based on open standards, such as ebXML, and some are based on specifications conducted by industrial consortia, such as UDDI. Companies can register with a registrar. Companies can submit material to be shared through a registry and customers of the registry can search for material that others have submitted. Business records can be accessed and searched manually through browsers or programmatically through APIs that can be network services. Records are becoming an increasingly important component of network services because they allow companies to collaborate with each other, dynamically, in a loosely coupled manner.

[0021] HTTP stands for HyperText Transfer Protocol - Hypertext Transfer Protocol - the most common data communication protocol on the network. In this specification,

Petition 870180049145, of 06/08/2018, p. 18/71

11/63 the term network, however, is not limited to HTTP communications, but it can also include communications with other protocols that support similar modes of communication, such as HDTP, the Handheld Device Transfer Protocol - or WAP, the Wireless Access Protocol - Wireless Access Protocol and others, as will occur to those skilled in the art.

[0022] SOAP stands for Simple Object Access Protocol or Simple Object Access Protocol, a lightweight XML-based messaging protocol used to encode information in network service request and response messages, before sending them over a network . SOAP messages are independent of any operating system or protocol and can be transported using a variety of Internet protocols, including SMTP, MIME and http.

[0023] UDDI stands for Universal Description, Discovery and Integration - Description, Discovery and Universal Integration, a distributed directory based on the network, which allows companies to connect on the Internet and discover each other, similar to the yellow and white pages of the phone book traditional.

[0024] WSDL stands for Web Services Description Language - Language for Description of Network Services. WSDL is an XML formatted language, which was developed jointly - by Microsoft and IBM and is used to describe the network's service capabilities as collections of communication endpoints capable of exchanging messages. WSDL is an integral part of UDDI because UDDI uses USDL to describe the capabilities of network services.

Petition 870180049145, of 06/08/2018, p. 19/71

12/63 [0025] ebXML stands for electronic business Extensible Markup Language - Extensible Markup Language for electronic business, a modular set of specifications for standardizing network service descriptions in XML to facilitate electronic commerce. Like UDDI, the ebXML specification gives companies a standard method of e-commerce. Like UDDI, the ebXML specification gives companies a standard method for defining and registering network services.

[0026] This specification, in general, describes network service components with terminology similar to that of WSDL. Network services are described as collections of network endpoints, data communications endpoints, capable of exchanging messages. Endpoints are sometimes referred to as ports. In this general specification, however, the term endpoint is preferred to the port, to reduce the risk of confusion with the term port type. A port type is not a port type or an endpoint type. A port type is a collection of operations, that is, software actions or functions, supported by a service.

[0027] A particular communication protocol and a data format specification for a port type constitute a binding. An example of binding is SOAP / HTTP, with message data encoded according to SOAP and messages communicated between endpoints according to HTTP. Another example of a binding is GET / POST / HTTP, with message data encoded in GET or POST messages and data communications performed according to HTTP.

Petition 870180049145, of 06/08/2018, p. 20/71

13/63 [0028] Each type of port can have more than one binding. An endpoint is defined by the association of a network address with a binding and, as mentioned, a collection of endpoints defines a service. Data communication and requests for operations in network services are carried out through data structures called messages, which, in turn, are composed of parts. The terms request and response are generally indications of the direction of message flow. Request messages and response messages for a particular binding can have the same structure.

Agnostic Proxy Support as to the type of port for

Network Service Intermediaries.

[0029] With reference to the attached drawings, methods, systems and products are described to support agnostic proxy as to the type of port for network service intermediaries, starting with figures IA and 1B. Figure IA presents a line drawing of an exemplary architecture for network services in which proxy support agnostic as to the type of port for network service intermediaries can be implemented in accordance with the modalities of the present invention. In the architecture of figure IA, the intermediary (202) is capable of connecting data communication through a protocol to the requester (102) and target service (118). A service component of the network in the position of requester (102) sometimes referred to as a customer. Similarly, a component in the middle position (202), in particular when viewed from the point of view of a requester, and sometimes referred to as a server.

Petition 870180049145, of 06/08/2018, p. 21/71

14/63 [0030] The client / server distinction should be used carefully in the context of network services. In the architecture of figure IB, for example, the target service (118), in the process of preparing a response to a request from the requester (102) can, in turn, request services from the target service network (119) through the intermediary (203). In doing so, the target service (118) is acting as a customer. Whether a particular component is considered a client or a server at any particular time depends on the particular function being performed by the component at the moment. That is, a service component of the network can be a client at a time, and a server afterwards. To reduce the risk of confusion of terminology, therefore, network service components are usually described in this specification by using the terms requester, intermediary and target service instead of client or server.

[0031] In order for the intermediary (202) to provide intermediary services on behalf of the target service (118), the intermediary (202) must know an endpoint in the target service (118). As mentioned above, in the state of the art, a service, called a proxy, running at the intermediary (202), will support the same type of port as the target service (118) and will have in its configuration data an endpoint for the target service (118 ). In the architecture of figure 1, however, the proxy is 'port type agnostic', meaning that no configuration data available to the proxy describes an endpoint of the target service and that the requester (102) can submit requests for operations on types port completely unknown to the middleman.

Petition 870180049145, of 06/08/2018, p. 22/71

15/63 [0032] Figure 2A shows a line drawing of a block diagram of an exemplary intermediate (202) according to the embodiments of the present invention. Intermediate (202) comprises automated computing machines, a computer system, including at least one central processing unit, computer memory, a system bus, and so on. The blocks in the block diagram of figure 2A represent software application modules operable in an intermediary computer system (202). The arrows in figure 2A represent the data flow between software modules.

[0033] The intermediary (202) includes an input agent (208) capable of receiving a request (102) from a requestor (102), including parametric information (107), to perform a network service operation. Here is an example of this request for SOAP-HTTP binding:

POST / Channel / proxy? portType = A HTTP / 1.1

Host: www.myhtermediary.com

Content-Type: text / xml; charset = utf-8

Content-Length: nnnn

SOAPAction: Some-URI <SOAP-ENV: Envelope xmlns: SOAP-ENV = http://schemas.xmlscap.org/ scap / envelope /

SOAP-ENV: encodingStyle = http: //schemas.xmlsoap.org/ scap / encoding / ”>

<SOAP-ENV: Body>

<m: myOp xmlns: m = Some-URI>

</ m: myOp>

Petition 870180049145, of 06/08/2018, p. 23/71

16/63

C / SOAP-ENV: Body>

</ SOAP-ENV: Envelope>

[0034] This example POST message includes a SOAP envelope, requesting the ‘myOp’ operation from the broker. That is, the name of the operation to be performed on a target service (118) is identified internally within the soap message. The myOp operation, its port type and its endpoint are all known to the broker (202) before the request is received. In this example, the parametric information (107) from which an endpoint for a target service (118), which supports the operation, can be identified is presented in a name-value pair in the URI-coded query string on the first line of POST : portType = A.

[0035] In a second embodiment, the first line of the example request must be:

POST / Channel / proxy? PortType = A & synchRespReqd = True

HTTP / 1.1 [0036] In this Monday modality, the information parametric (107) includes a couple name-value synchRespReqd = True of which an agnostic proxy about the

type of door according to an embodiment of the present invention can determine whether the request requires a synchronous response.

[0037] In addition to receiving a request (102) from a requestor (106), including parametric information (107), for network services, the input agent (208) also has an ability to provide the request, including its parametric data , for the agnostic proxy regarding the type of port (212). Let us consider as an example of

Petition 870180049145, of 06/08/2018, p. 24/71

17/63 incoming agent, the example request presented above. That example request is introduced as SOAP-HTTP. For this request (106), therefore, the incoming agent can be a SOAP-enabled HTTP server that transfers an incoming request to a proxy (212) implemented as any kind of server-type application, including, for example, script Java Bean, Java servlet or CGI (Common Gateway Interface) written in Perl. Java servlets and CGI scripts are mentioned for explanation only, not for limitation. Within the scope of the present invention, any kind of server-side functionality as will occur for those skilled in the art can be used to implement agnostic proxy functions as to the type of port for network service intermediaries.

[0038] The agnostic proxy for the type of port (212) can have a hard code to operate exclusively as an agnostic proxy for the type of port or, alternatively, the agnostic proxy for the type of port (212) can operate modally in the dependency on configuration parameters (223). A configuration parameter can be provided to indicate whether the agnostic proxy for the type of port (212) should operate as a traditional intermediate service or in an agnostic mode for the type of port. This configuration parameter advantageously promotes efficient program coding, including, in particular, the reuse of code segments that could be used in both modes. Another configuration parameter, supporting efficient use of program code is a parameter identifying a binding or 'channel type' for a proxy. As explained in more detail

Petition 870180049145, of 06/08/2018, p. 25/71

18/63 below, the port type agnostic proxy can operate with any binding supported by network services, SOAP, MIME, GET / POST / HTTP, and so on. The port type agnostic proxy can be coded to operate with any type of binding or channel and then configured with a parameter recommending the proxy of its type of binding or channel for processing time operations. In addition, a configuration parameter can be provided to turn on or off intermediary services in the proxy, which will require the analysis of the contents of a request or response message. This parameter can advantageously be used to optimize performance because the analysis of the message contents in a tendency to reduce the performance of the intermediary. Many agnostic proxies as to the type of port as well as other intermediate services can operate simultaneously on the intermediate (202) and the names for each one can be assigned as configuration parameters. Message handlers and filters can be assigned to proxies in configuration parameters. This paragraph describes several configuration parameters for agnostic proxies as to the type of port by way of explanation, not limitation. The use of any configuration parameters as will occur for those skilled in the art is within the scope of the present invention.

[0039] Figure 2B shows a line drawing of a block diagram of an exemplary intermediate (202), implementing a SOAP-HTTP channel according to embodiments of the present invention. As mentioned, an input agent (208), capable of providing

Petition 870180049145, of 06/08/2018, p. 26/71

19/63 the request, including parametric data, to the agnostic proxy as to the type of port (212) for a request with a SOAP binding, can be implemented as an HTTP SOAP enabled server. This input agent can be configured with a number of references to SOAPHandler objects (210) for the proxy, where each SOAPHandler object (210) is configured to provide a data processing task in the request to the proxy. This input agent typically operates by encapsulating the input request along with its parametric information (107) in a SOAPContext object (209), passing a reference to the SOAPContext object, in turn, for each SOAPHandler (210) configured for the proxy and then passing the SOAPContext (209) in its entirety to the proxy (212). In a general sense, it is an agnostic proxy as to the type of port that identifies the endpoint, but a detailed implementation level may include proxy functionality in the handlers, as is the case for SOAP. That is, the input agent can establish a property in a SOAPContext (209) that can be established for an endpoint of a target service, a URL in the case of SOAP-HTTP. In this modality, one of the SOAPHandler objects (210) can be usefully programmed to extract the parametric information from the request and place it in name-value pairs in SOAPContext so that the proxy can use it to identify a endpoint for a target service (118), which supports a requested operation of network services.

[0040] Alternatively, an incoming request can be linked with GET / HTTP instead of SOAP. In this example, the proxy (212), in figure 2A, can be implemented as Java

Petition 870180049145, of 06/08/2018, p. 27/71

20/63 servlet, the input agent (208) can be implemented as a Java-enabled HTTP server, which encapsulates the request, including its parametric information (107), in an HTTPServletRequest object and provides the proxy with a reference to that HTTPServletRequest object. The proxy can then obtain parametric information by calling HTTPServletRequest.getQueryString (), which returns the query string from the request URL, that is, everything in the request URL after the tag in question. Having the entire query chain, this exemplary proxy is programmed to extract the parametric data from the query chain, that is, in this example, portType = A and use the information thus extracted to identify an endpoint for a target service (118) that it supports an operation of requested network services. One way in which the proxy can identify an endpoint for a target service that supports an operation of requested network services is to retrieve an endpoint description from a business record (211), such as a UDDI record or an ebXML record. Target services (118) typically make these descriptions, including, for example, descriptions expressed as WSDL documents, by registering (224) them in a business registry (211).

[0041] In network services based on SOAP, The own message SOAP contains the operation name and the parameters for the operation, they are not in the URL in endpoint. IS useful for the intermediary to receive information

parametric, such as the portType parameter. That parameter can be something as simple as the name of the portType. If that is the case, then some business logic, which performs

Petition 870180049145, of 06/08/2018, p. 28/71

21/63 on the server (in a handler, for example, or even in the proxy function itself) must choose the actual endpoint URL for the target service (118) based on the type of port or other parametric information. Parametric information can even include an actual endpoint URL. In that case, 'business logic' could finally send the request to that URL. Both the port type and the endpoint URL could be present in the parametric information and 'business logic' can then try to determine an endpoint URL and use one in the request as a standard, if nothing better is found. The invention, preferably, allows all three scenarios as well as any variants that can be controlled by 'business logic'. There can always be other parameters that help to control 'business logic'.

[0042] Although this specification tends to discuss exemplary bindings in terms of the SOAP-HTTP binding and sometimes in terms of the GET / POST / HTTP binding, the discussion of these exemplary bindings for convenience of explanation and not as a limitation. Exemplary alternative bindings useful according to the various embodiments of the invention include MIME / SMTP (Multipart Internet Mail Extensions via Small Message Transport protocol) and RML / IIOP (Java's Remote Method Invocation over the Common Object Request Broker Architecture's Internet Inter-ORB Protocol) . In fact, an arbitrary Java class can be treated as a Network service, with invocations of native Java as the access protocol and use in agnostic proxies of the port type of any other binding, as will occur for those skilled in the art, is inside

Petition 870180049145, of 06/08/2018, p. 29/71

22/63 scope of the present invention, according to preferred embodiments.

[0043] In the exemplary intermediary (202) of figure 2A, the proxy (212) is an agnostic proxy as to the type of port that is executed whatever the intermediary services for which it is designated, requester authentication, message validation , message logging, management reporting services and so on, identifies an endpoint of a target service (118) that supports a requested operation and then transmits the request to the target service (118) through a neutral binding interface (218). As explained in more detail below, the neutral binding interface (218) is an interface whose form of use does not depend on the request binding.

[0044] In the example intermediary (202) (202) of figure 2A, the neutral binding interface (218) operates a provider (22 0), which, in turn, calls an outbound agent (222) to forward the request (106) for a target service (118). It is possible that the interface (218) operates in a neutral binding mode because it is retrieved by the code in the provider (220), which is protocol specific. The provider (220) performs the exchange of real messages according to the specifics of a particular protocol, SOAP, HTTP and so on. The decoupling of the provider's neutral binding interface that performs the actual data communication supports dynamic registration of new providers, so that an intermediary can enhance their data communication capacity without the need to recompile or redeploy. A provider can be implemented as an object, often provided by a target service supported by protocols

Petition 870180049145, of 06/08/2018, p. 30/71

23/63 of the provider, with a reference to the provider dynamically installed on a neutral binding interface. The outbound agent (222) is the actual data communications agent for the protocol implemented by the provider (222). When the protocol is taken as SOAP-HTTP, for example, the outbound agent (222) is a SOAP / HTTP agent capable of sending and receiving SOAP-HTTP request and response messages to and from the target network services. When the protocol is HTTP, for example, the outbound agent is an HTTP data communication client module, similar to a web browser.

[0045] In order to provide its intermediary services, the intermediary is advantageously able to identify an endpoint for a request. A method for doing so is discussed with reference to figure 3. Figure 3 presents a flowchart, illustrating a method of agnostic proxy support as to the type of port for network service intermediaries that includes receiving (104) at an intermediary (202 ) network services of a request (106) to perform a network services operation, where the request includes parametric information (107) from which an endpoint for a target service, which supports the operation, can be identified.

[0046] Here, again, is an example of this request for SOAP-HTTP binding:

POST / Channel / proxy? PortType = A HTTP / 1.1

Host: www.myhtermediary.com

Content-Type: text / xml; charset = utf-8

Content-Length: nnnn

SOAPAction: Some-URI

Petition 870180049145, of 06/08/2018, p. 31/71

24/63 <SOAP-ENV: Envelope xmlns: SOAP-ENV = http://schemas.xmlsoap.org/soap/ envelope /

SOAP-ENV: encodingstyle = http: //schemas.xmlsoap. org / soap / encoding />

<SOAP-ENV: Body>

<m: myOp xmlns: m = Some-URI>

</ m: myOp>

<SOAP-ENV: Body>

</ SOAP-ENV: Envelope>

[0047] This example POST message includes a SOAP envelope, requesting the ‘myOp’ operation from the broker (202). The MyOp operation, its port type, its endpoint are all known to the intermediary before the request is received. In this example, the message is taken as the SOAP envelope and the parametric information (107) from which an endpoint for a target service, which supports the operation, can be identified is the HTTP parameter portType = A. In this example, as the name of the operation in the target service is already encoded in the SOAP envelope, the only parametric data to be added is the type of port A, a type of port that includes the operation in the target service.

[0048] The method of figure 3 also includes identifying (108), depending on the parametric data, the endpoint (110) of a target service that supports the operation. In this SOAP-HTTP example, identification (108) of the endpoint (110) of a target service (118) that supports the operation is accomplished by retrieving an endpoint description from a business record, such as a UDDI record or record of ebXML. In this example, the intermediary retrieves from a record

Petition 870180049145, of 06/08/2018, p. 32/71

25/63 of a port type A endpoint described as connected by

SOAP-HTTP at http://www.myTarget.com/SOAP- network address

HTTP / servlets /.

[0049] The illustrated method includes the creation (112) of a target service request (114) to perform the operation on the target service. In this example, the broker is programmed to create a target service request as in the HTTP POST message, using the endpoint in the target service (118). Parametric data for identifying an endpoint is canceled and the request is directed to a script for handling SOAP messages which will identify the operation name operation on the envelope

SOAP.

[0050] The resulting target service request is as follows:

POST / SOAP-HTTP / servlets / QuoteServiceservlet HTTP / 1.1

Host: www.myTarget.com

Content-Type: text / xml; charset = utf-8

Content-Length: nnnn

SOAPAction: Some-URI <S0AP-ENV: Envelope xmlns: SOAP-ENV = http://schemas.xmlsoap.org/soap/ envelope /

SOAP-ENV: encodingStyle = http://schemas.xmlsoap.org/ soap / encoding />

<SOAP-ENV: Body>

<m: my0p xmlns: m = Some-URI>

</ m: my0p>

C / SOAP-ENV: Body>

</ SOAP-ENV: Envelope>

Petition 870180049145, of 06/08/2018, p. 33/71

26/63 [0051] The method of figure 3 also includes the issue (116) of the target service request (114) to the target service (118). In this example, the target service request includes opening a TCP / IP connection to the target service endpoint (118) at http://www.myTarget.com/ and sending the HTTP POST message over the TCP connection / IP to the target service.

[0052] It is useful to note that in at least some embodiments of the present invention, in support methods of agnostic proxy regarding the type of port, such as one illustrated in figure 3, the target service request, as created and issued for the service target carries unexamined message contents of the request received at the network service intermediary. In the example just discussed above, the proxy service at the broker identified an endpoint of a target service from the parametric data portType = A and redirected the message to the endpoint thus identified, all without touching, opening, examining, analyzing or otherwise disturbing the message body, the SOAP envelope, which remained unexamined and unchanged throughout the distribution process from its requester to its target service. In the process, the proxy service provided one or more of the intermediary services, authentication, management reporting, load balancing, service aggregation, and so on.

[0053] As an additional explanation, an example request is presented for the GET / HTTP binding, directed to an endpoint at http: //www.myintermediary/channelApps/GET-

Petition 870180049145, of 06/08/2018, p. 34/71

27/63

HTTP / servlets / Proxy. The example entry request message takes this form:

GET / servlets / proxy? Message = messageContentString & operation = myOp & portType = A HTTP / 1.1 [0054] And in the URI space, the example request can be shown as:

http: // www. mylntermediary.com/servlets/ proxy? message = messageContentString & operation = myOp & portType =

A [0055] In this example, the message is taken as the URI-encoded query data message = messageContentString encoded as a name-value pair. the message content is a URI-encoded chain. In this example, the parametric information (107) from which an endpoint for a target service that supports the operation can be identified and all query data following the message content chain. In this example, the query data includes both type of port A and the name of a target service operation.

[0056] In this example, the identification (108) of the endpoint (110) of a target service that supports the operation is performed by retrieving an endpoint description from a business record, such as a UDDI record or an ebXML record. In this example, the intermediary (202) retrieves a port type A endpoint from a record described as connected by GET / HTTP at network address http://www.myTarget.com.

[0057] The method of figure 3 also includes the creation (112) of a target service request (114) to perform the operation on the target service. In this example, the middleman

Petition 870180049145, of 06/08/2018, p. 35/71

28/63 (202) is programmed to create a target service request as an HTTP GET message by concatenating the endpoint address to the target service request with the operation name and parts of the message. The resulting target service request, expressed in the URI space is:

http://www.myTarget.com/servlets/myOp?message=messageC ontentString [0058] The method in figure 3 also includes the issue (116) of the target service request (114) for the target service (118). In this example, issuing the target service request includes opening a TCP / IP connection to the target service endpoint at http://www.myTarget.com/ and sending the HTTP GET message:

GET / servlets / myOp? Message = messageContentString HTTP / 1.1 [0059] Readers of skill in the art are amazed at how the requester knows how to send a request to the intermediary for an operation on the target service. The answer is that the broker or a developer of the broker identifies for the requester an endpoint of the network services broker as an endpoint that supports the operation on the target service. An identification of an intermediary's endpoint as an endpoint that supports the operation on the target service can be implemented in a WSDL document, which is registered in a corporate directory for discovery by the requester. Alternatively, this identification can be downloaded from the intermediary to the requester or even simply sent by email to the requester or to the administrator of the requester for installation by a

Petition 870180049145, of 06/08/2018, p. 36/71

29/63 administrator in the configuration data of the requester's target services (102).

[0060] Consider an example in which a target service is described by the following WSDL pseudocode segment:

<definitions targetNanespace = ...>

<message name = GetQuoteInput> ... </message>

<message name = GetQuoteOutput> ... </message>

<portType name = StockquotePT> ... </portType>

Cbinding nane = SOAPBinding ...>

<operation name = getQuote> ... </operation> ...

</binding>

<Service name = StockquoteService>

<port nane = SOAPPort binding = tns: SOAPBinding>

<soap: address location = http: // myTargetService / soap / servlet / getQuote />

</port>

</service>

</definitions>

[0061] An intermediary for that target service can identify to a requester a network service intermediary endpoint as an endpoint that supports operation on the target service by replacing the location attribute of the address extension element in the description of the target service below. if:

<soap: address location = http://www.myintermediary.com/

Channel / SOAP / proxy? PortType = StockquotePT />

[0062] Thus, creating a WSDL document exemplified by the following segment:

<definitions targetNamespace = ...>

Petition 870180049145, of 06/08/2018, p. 37/71

30/63 <message name = GetQuoteInput> ... </message>

<message name = GetQuoteOutput> ... </message>

<portType nane = StockquotePT> ... </portType>

Cbinding name = SOAPBinding ...>

<operation name = getQuote> ... </operation> ...

<binding>

<Service name = portTypeAgnosticProxy>

<port name = intermediaryEndpoint binding = SOAPBinding>;

<soap: address location = http://www.myintermediary.com/Channel/SOAP/proxy?portType= StockquotePT />

</port>

</service>

</definitions>

which identifies an endpoint of a network service broker as an endpoint that supports the getQuote operation on the target service. The provision of WSDL of the species exemplified by this last segment to a requester, through a registration, a download, e-mail or by other means depending on those skilled in the art, identifies for the requester an endpoint of the target service intermediary as a endpoint, which supports operation on the target service.

[0063] In the method of figure 3, the identification (108), depending on the parametric information (107), the endpoint for a target service that supports the operation can often include the identification not exactly of an endpoint for a target service, but two or more target service endpoints that support the operation. Consider an example where

Petition 870180049145, of 06/08/2018, p. 38/71

31/63 a proxy agnostic as to the type of door according to a modality of the method of the present invention receives as a parametric information (107) a type of door for an operation, queries a business register with the type of door as a query parameter and thus identifies two or more target service endpoints that support the operation. This identification of two or more endpoints can be accomplished, for example, by querying a UDDI record with the port type and receiving in response two or more WSDL documents that describe target services for the port type.

[0064] When two or more endpoints are so identified, methods for supporting agnostic proxy as to the type of port for network service intermediaries according to the modalities of the present invention, typically include the selection of one of the endpoints according to selection rules. In a trivial case, a selection rule may be to select the first of the endpoints thus identified and neglect the others. Selection rules can be more complex, including, for example, selection rules for load balancing. Load balancing rules can be implemented using a data structure similar to that shown in Table 1.

Table 001

Table 1. Latency tracking

Tip Endpoint URI Time Time Latê Latent O in in ncia was going in send I received in Cumula ment Viag

Petition 870180049145, of 06/08/2018, p. 39/71

32/63

Per OK in (ms) tiva (ms) THE http://www.ibm.com/aTar getService 12:01: 01.1 12:01: 01.2 100 100 THE http://www.ibm.com/aTar getService 12:05: 02.3 12:05: 02.45 150 250 THE http://www.ibm.com/anot herTargetService 01:10: 01.5 01:10: 01.57 70 70 THE http://www.ibm.com/anot herTargetService 01:15: 02.5 01:15: 02.8 30 100 - - - - - - - - - - - -

[0065] Each row in Table 1 represents a measurement of latency for a round trip request - response in data communications from network services between an intermediary and a target service. Table 1 provides columns for the port type and the endpoint URI for each request and response cycle. The Send Time column records the time that a request message is sent from the broker to an endpoint on a target service for an operation of a type of port. The Receiving time column records the time that a corresponding reply message is received from the target service. Travel Latency and the difference between Receiving Time and Shipping Time. Cumulative Latency is a sum of Travel Latencies for each endpoint represented in the table. With a similar structure of Travel Latencies for each endpoint represented in the table. With a structure

Petition 870180049145, of 06/08/2018, p. 40/71

33/63 similar to Table 1, the selection rules for use when more than one endpoint for a request is identified can be implemented as the following example rules:

- as more and more requests for operations on the same type of port arrive at the intermediary, use one at a time each one of more than one of the identified endpoints;

- record latency data for each of these uses;

- for subsequent requests for operations of the same type of port, select the endpoint having the lowest cumulative Latency from the latency table, send the request to that endpoint and record the relevant Latency data, when the message is sent to the target service and when the corresponding response is received at the intermediary.

[0066] The sample data in Table 1 shows cumulative latency for requests recently sent to port type A for two endpoints, a first endpoint at URI http: /www.ibm.com/anotherTargetService. The first has a cumulative request latency of 250 milliseconds and the second has a cumulative request latency of 100 milliseconds. Using the exemplary selection rules presented above, a current request for an operation on port type A will be routed to the second endpoint, one at URI http: /www.ibm.com/anotherTargetService.

[0067] In the method of figure 3, the creation (112) of a target service request (114) to perform the operation on the target service can be performed by composing the request in a useful data structure in a neutral binding interface and calling the interface neutral binding,

Petition 870180049145, of 06/08/2018, p. 41/71

34/63 passing the request as a call parameter.

Similarly, issuing (116) the target service request (114) to the target service comprises calling one or more elements on a neutral binding interface.

[0068] A neutral binding interface is one in which the use of the interface does not depend on a message binding request. That is, the data structure and calling methods used to implement the interface and carry out data communications through it, do not depend on the type of data encoding used in a message, nor do they depend on the data communication protocol used for a message. Developers of agnostic proxies as to the type of port for intermediaries in accordance with the modalities of the present invention will often build their neutral binding interfaces. There is an open standard for a neutral binding interface, however, known as WSIF, Web Service Invocation Framework. WSIF is now supported as part of the Apache Software Foundation's Web Services Project.

[0069] The use of a neutral binding interface (218) provides advantages for the modalities of the present invention. SOAP-HTTP binding is so common in current technique that users and developers sometimes forget that there are other bindings. This results in the development of systems that are difficult, if not impossible, to use with other bindings or to adapt for use with other bindings. As network services develop, however, other bindings will become more useful and more common, the use of a neutral binding interface (218) for specifying modalities of the present invention, in addition to

Petition 870180049145, of 06/08/2018, p. 42/71

Furthermore, it also means that available bindings can be determined at processing time, thus providing a flexible, powerful and generally more useful network service intermediary.

[0070] One way to implement a neutral binding interface is to provide endpoint objects that are capable of invoking services on target services given a type of port and an endpoint. One way to provide these endpoint objects is by using an endpoint factory similar to the one illustrated in the following pseudocode segment:

// Endpoint Factory Class // Defines a parameterized factory method for creating endpoint objects //

Class EndpointFactory {

public static Endpoint createEndpointObject (portType, networkAddress) {

// establish reference for new endpoint object

Endpoint anEndpoint = null;

if (portType == A && networkAddress == www.abc.com) anEndpoint = new endpointl;

if (portType == B && networkAddress == www.def.com) anEndpoint = new Endpoint2;

if (portType == C && networkAddress == www.ghi.com) anEndpoint == new Endpoint3;

if (portType == LAST && networkAddress == www.lastSupported.com)

Petition 870180049145, of 06/08/2018, p. 43/71

36/63 anEndpoint == new Endpoint465; if anEndpoint == null) reportError (); else return anEndpoint;

} // end createEndpointObject ()} // end class EndpointFactory [0071] The classes of endpoints, Endpointl, Endpoint2, Endpoint3 and so on, are concrete classes that inherit an abstract endpoint class (or implement it as an interface) which provides element methods for creating message objects to contain message parts. This endpoint factor and other elements in this neutral binding interface can be used to perform the steps of creating (112) a target service request (114) and issuing (116) the target service request (114) to the target service , as illustrated in the following pseudocode segment:

// Get endpoint object from endpoint factory

Endpoint ep = endPointFactory.createEndPoint (portType, networkAddress);

// Prepare an input message

Message input = ep.createlnputMessage ();

// use message accessor function to insert contents of message socketsetPart (symbol, IBM);

// Prepare a placeholder for a response value

Message output = ep.createOutputMessage ();

// execute the operation ep.executeRequestResponseOperation (getQuote, input, output);

// return the result

Petition 870180049145, of 06/08/2018, p. 44/71

37/63 return output;

[0072] This example pseudocode segment, given a type of port and a network address for an endpoint, calls an endpoint factory to create an endpoint object. The segment then creates a target service request by loading parts of the message into the endpoint object and issues the target service request to the target service by calling the executeRequestResponseOperation () element method. The method of figure 3 includes receiving (120) a response (122) from the target service at the intermediary; creation (124) in the intermediary, depending on the response (122) of the target service, a response (126) from the intermediary; and returning (128) the response (126) from the intermediary to the request client. In this example pseudocode segment, the steps of receiving (120) a response (122) from the target service and creating (124) a response (126) from the intermediary are implemented by the call to executeRequestResponseOperation (), typically a blocking call, which awaits by a response from the target service and makes the response available via the Message reference for 'outgoing'.

[0073] The above pseudocode segments illustrate the use of a neutral binding interface with ports referred to as endpoints. The WSF interface syntax, however, uses the term port when referring to endpoints. By means of additional explanation regarding the use of neutral binding interfaces, therefore, another additional example pseudocode segment is present, adhering more closely to the WSF standard. In this example, port is used

Petition 870180049145, of 06/08/2018, p. 45/71

38/63 to mean endpoint and, for consistency of explanation, the factory name is changed to portFactory.

// get a port (an endpoint) from the factory

WSIFPort port = portFactory.getPort (portType, networkAddress);

// Prepare an input message

WSIFMessage input = port.createlnputMessage ();

// insert message contents socketsetPart (symbol, new WSIFJavaPart (String.class, symbol));

// Prepare a placeholder for a response value

WSIFMessage output = port.createOutputMessage ();

// execute the operation port.executeRequestResponseOperation (getQuote, input, output, null);

// extract and return the result return output;

[0074] Although this specification discusses exemplary methods of supporting agnostic proxies as to the type of port in network service intermediaries, mainly in terms of processing a request on its way from a requester to a target service, it is useful to note that intermediaries according to the modalities of the present invention are also typically able to process response messages, making their way back from a target service through the intermediary to the original requester. The method of figure 3, for example, includes receiving (120) at the intermediary a response (122) from the target service; creation (124) at the intermediary, depending on the response (122) of the service targeted by a response

Petition 870180049145, of 06/08/2018, p. 46/71

39/63 (126) of the intermediary; and {128} feedback from the intermediary (126) to the requesting customer.

[0075] Figure 4 presents a flowchart illustrating a proxy support method agnostic as to the type of port for network service intermediaries, which includes receiving (304) at a network service intermediary a request (106) for execution of a network service operation, in which the request includes parametric information (107) from which an endpoint for a target service that supports the operation can be identified.

[0076] Here, again, is an example of this request for SOAP-HTTP binding:

POST / Channel / proxy? PortType = A & synchRespReqd = True HTTP / 1.1

Host: www.myintermediary.com

Content-Type: text / xml; charset = utf-8

Content-Length: nnnn

SOAPAction: Some-URI <SOAP-ENV: Envelope xmlns: SOAPENV = http: //schemas.xmlsoap.org/soap/envelope/

SOAPENV: encodingStyle = http: //schemas.xmlsoap.org/soap/encoding />

<SOAP-ENV: Body>

<m: myOp xmlns: m = Some-URI>

</ m: myOp>

</ SOAP-ENV: Body>

</ SOAP-ENV: Envelope>

Petition 870180049145, of 06/08/2018, p. 47/71

40/63

This example POST message includes a 'myOp' operation from the [0077] middleman envelope,

SOAP requesting

The myOp operation, its port type and its endpoint are all unknown to the intermediary before the request is received. In this example, the message is taken as the SOAP envelope and the parametric information (107) from which an endpoint for a target service that supports the operation can be identified is the HTTP parameter portType = A. In this example, as the name of the operation in the target service is already encoded in the SOAP envelope, the only parametric data to be added is the type of port A, a type of port that includes the operation in the target service.

[0078] The method of figure 4 also includes identifier (308), depending on the parametric data, of the endpoint (110) of a target service that supports the operation. In this SOAP-HTTP example, the identification (308) of the endpoint (110) of a target service that supports the operation is accomplished by retrieving an endpoint description from a business record, such as a UDDI record or an ebXML record . In this example, the intermediary retrieves a port type A endpoint described as SOAPHTTP connected at the network address http://www.myTarget.com/SOAPHTTP/servlets/ from a record.

[0079] The method illustrated in figure 4 also includes determining (350) whether a request (106) requires a synchronous response. The determination (350) of whether the request (106) requires a synchronous response can be carried out by examining the query data in the first line of a request message received. In the example POST message shown above, the query data in the

Petition 870180049145, of 06/08/2018, p. 48/71

41/63 first line is all the data between the? and the HTTP version code, which is:

portType = A & synchRespReqd = True.

[0080] In this example, synchRespReqd = True is taken by the intermediary to mean that a synchronous response is required. Similarly, synchRespReqd = False can indicate that a synchronous response is not required. These are exemplary encodings only, of course, not limitations of the invention. Any means of encoding within the parametric information an indication of whether a synchronous and required response from an intermediary is well within the scope of the present invention according to preferred embodiments. In this example, the determination (350) of whether a request requires a synchronous response is made by making that determination depending on the parametric information (107), the parametric information being the name - value pair synchRespReqd = True.

[0081] The illustrated method includes creation (312) of a target service request (114) to perform the operation on the target service. In this example, the broker is programmed to create a target service request as an HTTP POST message, using the endpoint on the target service. More particularly, the following POST message represents an example of an input message or input data for a requested network service operation. Parametric data is canceled, parametric data for identifying an endpoint, as well as any parametric data for determining whether the synchronous response is required and the request is directed to a script, servlet or other functionality for handling SOAP messages

Petition 870180049145, of 06/08/2018, p. 49/71

42/63 that will identify the operation of the operation name in the SOAP envelope.

[0082] The resulting target service request is as follows:

POST / SOAP-HTTP / servlets / QuoteServiceServlet HTTP / 1.1 Host: www.myTarget.com

Content-Type: text / xml; charset = utf-8

Content-Length: nnnn

SOAPAction: Some-URI <S0AP-ENV: Envelope xmlns: SOAP-ENV = http: //schemas.xmlsoap.org/soap/ envelope /

SOAP-ENV: encodingStyle = http: //schemas.xmlsoap. org / soap / encoding />

<SOAP-ENV: Body>

<m: myOp xmlns: m = Some-URI>

</ m: myOp>

C / SOAP-ENV; Body>

</ SOAP-ENV: Envelope>

[0083] In the method of figure 4, the creation (312) of a target service request (114) to perform the operation on the target service can still include the creation (312) of the target service request (114), depending on a determination (152) of whether the request requires a synchronous response. Likewise, the intermediary can create an incoming message carrying input data for a requested operation of network services, so an intermediary can also create an outgoing message. This outgoing message is typically a location maintenance object for use in storing and communicating any message

Petition 870180049145, of 06/08/2018, p. 50/71

43/63 response from a target service. An exemplary method of creating a response message object for a request that requires a synchronous response is for the broker to create an appropriate class object, leave it empty, and pass a reference to it as a parameter in one or more calls to downstream interfaces (such as a provider or an outbound agent, references (220) and (22) in figures 2A and 2B) for communicating requests to a target service. An exemplary method of creating a response message object for a request that does not require a synchronous response and for the broker to pass a null reference (not just a reference to an empty output object, but a completely null reference) as a parameter in one or more calls to downstream interfaces to communicate requests to a target service. In these modalities, the downstream interface is programmed to interpret this null reference as an indication to wait only for an 'acknowledgment of receipt', before returning control to the caller.

[0084] The method of figure 4 also includes the issue (316) of the target service request (114) to the target service (118). In this example, issuing the target service request includes opening a TCP / IP connection to the target service endpoint at http://www.myTarget.com/ and sending the HTTP POST message over the TCP / IP connection to the target service.

[0085] It is useful to note that in at least some of the modalities of the present invention, in support methods of agnostic proxy regarding the type of port, such as that illustrated in figure 4, the target service request, as

Petition 870180049145, of 06/08/2018, p. 51/71

44/63 created and sent to the target service, it carries contents of messages not examined and not modified from the request received at the network's service intermediary. In the example discussed above, the proxy service at the intermediary identified an endpoint of a target service from the parametric data portType = A and redirected the message to the endpoint thus identified, all without touching, opening, examining, analyzing or otherwise disturbing the body of the message, the SOAP envelope, which remained unexamined and unchanged throughout the process or distribution of its requester to its target service. In the process, the proxy service provided one or more of the intermediary services, authentication, management reporting, load balancing, aggregation of services, and so on.

[0086] Through another explanation, an example request is presented for the GET / HTTP binding, addressed to an endpoint at http: //www.myintermediary/channelApps/GET-

HTTP / servlets / proxy. The request message that appears as an example takes this form:

GET / servlets / proxy? Message = messageContentString & operat ion = myOp & portType = A HTTP / 1.1 [0087] And in the URI space, the example request can be shown as:

http://www.myhtermediary.com/servlets/proxy?message=me ssageContentString & operation = myOp & portType = A [0088] In this example, the message is taken as the URI-Encoded query data message = messageContentString encoded as a name-value pair , the message content is a URIPetition chain 870180049145, from 06/08/2018, p. 52/71

45/63 coded. In this example, the information (107) from which an endpoint for a target service that supports the operation can be identified is all the query data that follows the message content chain. In this example, the query data includes port type A and the name of an operation on a target service.

[0089] In this example, the identification of the endpoint (110) of a target service that supports the operation is performed by retrieving an endpoint description from a business record, such as a UDDI record or an ebXML record. In this example, the intermediary retrieves a port type A endpoint from a record described as connected by GET / HTTP at http://www.myTarget.com network address.

[0090] The method of figure 4 also includes the creation (312) of a target service request (114) to perform the operation on the target service. In this example, the broker is programmed to create a target service request as an HTTP GET message by concatenating the endpoint address to the target service request with the name of the operation and parts of the message. The resulting target service request, expressed in URI space is:

http://myTarget.com/servlets/myOp?message=messageConte ntString.

[0091] As mentioned before, the method of figure 4 also includes the issue (316) of the request (114) from target service to target service (118). In this example, issuing the target service request includes opening a TCP / IP connection to the target service endpoint at http://www.myTarget.com/ and sending the HTTP GET message:

Petition 870180049145, of 06/08/2018, p. 53/71

46/63

GET / servlets / myOp? Message = messageContentString HTTP / 1.1.

[0092] The method of figure 4 also includes waiting (361) for a response from the target service, if the request requires a synchronous response (360). Figure 5 presents a flowchart illustrating a method of waiting (361) for a response from a target service that includes receiving (320), synchronously, at the intermediary, a response (122) from the target service; creation (324) in the intermediary, depending on the response of the target service, of a response (126) from the intermediary; and returning (328) the response (126) from the intermediary to a requester (102). In the method of figure 5, the receipt (320), synchronously, at the intermediary, of a response from the target service can be accomplished by invoking a blocking receive function on a data communication connection between the intermediary and the target service.

[0093] The following pseudocode segment is an example, for an HTTP binding, of transmitting a request from an intermediary to a target service and waiting for a response from the target service, if the request requires a synchronous response. The following segment exemplifies client operation for an HTTP binding, this is often provided in accordance with the modalities of the present invention through a provider or an outbound agent (220, 222, in figure 2) of an intermediary network services:

import java.io. *; import java.net. *;

BufferedReader in = null;

Petition 870180049145, of 06/08/2018, p. 54/71

47/63

URL uri = new URL (targetURL);

URLConnection connection = (HttpURLConnection) uri. openConnection ();

BufferedWriter out = new BufferedWriter (new

OutputStreamwriter (connection.getOutputStream ());

BufferedReader in = new BufferedReader (new

InputStreamReader (connection.getlnputStream ()));

out.println (request); if (synchRespReqd == TRUE) {

Message responseMessage = in.readLine (); return responseMessage;

} [0094] This example pseudocode segment creates a Java URL object and uses the URL object to open a TCP / IP connection called 'connection' to a target service identified as having the network address targetURL. The segment also opens a flow temporarily stored in the connection called out and an inlet flow in the connection called in. The thread transmits the request over the connection as out.println (request) and then, if a synchronous response is required, it makes a blocking call to receive a response message over the same connection, Message responseMessage = in.readLine () , and returns the reply message to the caller. This example is for an HTTP binding.

[0095] By way of another explanation, another example is presented below for a 'JMS' binding, that is, a binding to the Java Message Service. JMS provides two message 'domains', one for point-to-point messages

Petition 870180049145, of 06/08/2018, p. 55/71

48/63 and one for publication-subscription messages. This example discusses peer-to-peer messages between an intermediary and a target service, using a JMS message queue. In point-to-point JMS messages, a data communication connection, such as a socket, is encapsulated by a JMS 'connection' object. A JMS connection is created through an administrative object called a 'connection factory'. JMS connections are used to create one or more JMS 'sessions'. A session is a simple ordered context for producing and consuming messages. A session is used to create message producers, message and message consumers. A message producer is an object used to send messages to a queue. The point-to-point form of a message producer implements the JMS interface 'queueSender', which includes a send () method. A message consumer is an object for receiving messages from a queue. The point-to-point form of a message producer implements the JMS interface 'queueReceiver', which includes a block receive () method, which can be called with or without a waiting period.

[0096] The following pseudocode segment is an example, for a JMS binding, of transmitting a request from an intermediary to a target service and waiting for a response from the target service, if the request requires a synchronous response.

// get a connection

QueueConnection queueConnection = queueConnectionFactory.createQueueConnection ();

// use the connection to establish a session

Petition 870180049145, of 06/08/2018, p. 56/71

49/63 // the 'false' parameter means no transaction, and AUTO_

ACK is on.

QueueSession queueSession = queueConnection.createQueueSession (false, Session.AUTO _ACKNOWLEDGE);

// create a sender and send the request from the // intermediary to the target Service through a JMS queue

QueueSender queuesender = queueSession.createSender (myQueue);

queueSender.send (requestMessage);

// if synchronous response is required, create a receiver and // issue a blocking receive () on the receiver if (synchRespReqd == TRUE) {

QueueReceiver queueReceiver = queueSession.createReceiver (myQueue);

Message responseMessage = queueReceiver.receive (); return responseMessage;

} [0097] This example segment creates a connection called queueConnection, creates a session called queueSession, creates a sender called queueSender, sends the request message to the target service through a JMS queue and, if a synchronous request is required, creates a receiver called queueReceiver and issues a block receive () on queueReceiver to wait for a response message.

[0098] If the request does not require (362) a synchronous response, then methods of agnostic proxy support as

Petition 870180049145, of 06/08/2018, p. 57/71

50/63 to the type of port for network service intermediaries in accordance with the modalities of the present invention may include doing absolutely nothing but issuing the request to the target service. That is, if a request does not require (362) a synchronous response, it is well within the scope of the present invention according to preferred embodiments to do nothing with reference to acknowledgment of receipt, asynchronous responses and the like. Alternatively, as shown in Figure 4, methods according to the second embodiment of the present invention may include receiving (354) a target service (156) from an acknowledgment of receipt of the target service request and return (358) from the notification of (156) to a requester (102), without waiting for a reply message.

[0099] Here is an example pseudocode segment that returns an acknowledgment of receipt to an applicant, without waiting for a response message:

import java.io. *; import java.net. *;

URL uri = new URL (targetURL);

HTTPURLConnection connection = (HttpURLConnection) uri.openConnection ();

Bufferedwriter out = new BufferedWriter (new

OutputStreamWriter (connection.getOutputStream ()));

BufferedReader in = new BufferedReader (new

InputStreamReader (connection.getlnputstream ()));

out.println (request);

int acknowledgment = connection.getResponseCode (); if (acknowledgment == 200) return acknowledgment; else return ERROR;

Petition 870180049145, of 06/08/2018, p. 58/71

51/63 [0100] This example pseudocode segment creates a Java URL object and opens for the URL object, in the form of an HTTPURLConnection object, a TCP / IP connection called 'connection' to a target service identified as having a targetURL network. The segment also opens an output stream temporarily stored in the connection called out and an input stream in the socket called in. The segment transmits the request over the connection as out.println (request) and then makes a blocking call to receive an acknowledgment over the same connection, int acknowledgment = connection.getResponseCode (). The segment either returns an acknowledgment to the caller (HTTP response code '200' in this example) or returns an error message. The acknowledgment of receipt is a notice of procedural receipt from the target service that the request was received. The segment does not wait for a substantive response to the request.

[0101] The example pseudocode segment above is an example of transmitting a request from an intermediary to a target service and providing an acknowledgment of receipt, without waiting for a substantive response message. This segment exemplifies client operation for an HTTP binding, as it is often provided according to the modalities of the present invention through a provider or an outbound agent (220, 222, in figure 2) of a network service intermediary. .

[0102] Readers of skill in the technique are now surprised at how the applicant knows how to send to the intermediary

Petition 870180049145, of 06/08/2018, p. 59/71

52/63 a request for an operation on the target service. The answer is that the broker or a developer of the broker identifies for the requester an endpoint of the network services broker as an endpoint that supports the operation on the target service. An identifier of a broker's endpoint as an endpoint that supports operation on the target service can be implemented in a WSDL document that is registered in a corporate directory for discovery by the requester. Alternatively, this identification can be downloaded from the intermediary to the requester - or even simply emailed to the requester or the requester's administrator for installation by an administrator in the service configuration data of the requester's network.

[0103] Let us consider an example in which a target service is described by the following WSDL pseudocode segment:

<definitions targetNamespace = ...>

<message name = GetQuoteInput> ... </message>

<message name = GetQuoteOutput> ... </message>

<portType name = StockquotePT> ... </portType>

Cbinding name = SOAPBinding ...>

<operation name = getQuote> ... </operation>. . . </binding>

<Service name = StockquoteService>

<port name = SOAPPort binding = tns: SOAPBinding>

<soap: address location = http: // myTargetService / soap / servlet / getQuote />

</port>

</service>

</definitions>

Petition 870180049145, of 06/08/2018, p. 60/71

53/63 [0104] An intermediary for that target service can identify to a requester a network service intermediary endpoint as an endpoint that supports operation on the target service by replacing the location attribute of the address extension element in the service description target follows:

<soap: address location = http: //www.mylntermediary. com / Channel / SOAP / proxy? portType = StockquotePT />

[0105] Thus, creating a WSDL document exemplified by the following segment:

<definitions targetNamespace = ...>

<message name = GetQuoteInput> ... </message>

<message name = GetQuoteOutput> ... </message>

<portType name = StockquotePT> ... </portType>

Cbinding name = SOAPBinding ...>

<operation name = getQuotelT> ... </operation>. . .

</binding>

<Service name = portTypeAgnosticProxy>

<port name = intermediaryEndpointbinding = SOAPBinding>

<soap: address location = http://www.mylntermediary.com/Channel/SOAP/proxy?portType= StockquotePT />

</port>

</service>

</definitions>, which identifies a network service broker's endpoint as an endpoint that supports the getQuote operation on the target service. The provision of WSDL of the species exemplified by the latter segment to a requester,

Petition 870180049145, of 06/08/2018, p. 61/71

54/63 through a registration, a download, e-mail or by other means depending on those skilled in the art, it identifies for the requester an endpoint of the target services intermediary as an endpoint, which supports the operation on the target service.

[0106] In the method of figure 4, the identification (308), depending on the parametric information (107), of the endpoint for a target service that supports the operation can often include the identification not exactly of an endpoint for a target service, but two or more target service endpoints that support the operation. Let us consider an example in which an agnostic proxy regarding the type of door according to a modality of the method of the present invention receives as a parametric information (107) a type of door for an operation, queries a business register with the type of door as a parameter query and thus identifies two or more target service endpoints that support the operation. This identification of two or more endpoints can be accomplished, for example, by querying a UDDI record with the port type and receiving in response two or more WSDL documents that describe target services for the port type.

[0107] When two or more endpoints are thus identified, methods for supporting agnostic proxy as to the type of port for network service intermediaries according to the modalities of the present invention, typically include the selection of one of the endpoints according to selection rules. In a trivial case, a selection rule may be to select the first of the endpoints thus identified and neglect the others. Selection rules

Petition 870180049145, of 06/08/2018, p. 62/71

55/63 can be more complex, including, for example, load balancing selection rules. Load balancing rules can be implemented using a data structure similar to that shown in Table 1.

Table 1. Latency tracking Tip O in Per OK Endpoint URI Time in send Time to I received then Laten co in Travel m (ms) Latency The Cumulat vat (ms) THE http://www.ibm.com / a TargetService 12: 01: 0 1.1 12: 01: 0 1.2 100 100 THE http://www.ibm.com / a TargetService 12: 05: 0 2.3 12: 05: 0 2.45 150 250 THE http://www.ibm.com / another TargetService 01: 10: 0 1.5 01: 10: 0 1.57 70 70 THE http://www.ibm.com / another TargetService 01: 15: 0 2.5 01: 15: 0 2.8 30 30 - - - - - - - - - - - -

[0108] Each row in Table 1 represents a measurement of latency for a round trip request - response in network service data communications between an intermediary and a target service. The Table

Petition 870180049145, of 06/08/2018, p. 63/71

56/63 provides columns for the port type and the endpoint URI for each request and response cycle. The Send Time column records the time that a request message is sent from the broker to an endpoint on a target service for an operation of a type of port. The Receive Time column records the time that a corresponding reply message is received from the target service. Travel latency is the difference between Receive Time and Send Time. Cumulative Latency is a sum of Travel Latencies for each endpoint represented in the table. With a similar structure of Travel Latencies for each endpoint represented in the table. With a structure similar to Table 1, the selection rules for use when more than one endpoint for a request is identified can be implemented as the following example rules:

- as more and more requests for operations on the same type of port arrive at the intermediary, use one at a time each one of more than one of the identified endpoints;

- record latency data for each of these uses;

- for subsequent requests for operations of the same type of port, select the endpoint having the lowest cumulative latency from the latency table, send the request to that endpoint and record the relevant latency data, when the message is sent to the target service and when the corresponding response is received at the intermediary.

[0109] The sample data in Table 1 shows cumulative latency for requests recently sent to port type A for two endpoints, a first endpoint at URI http: /www.ibm.com/anotherTargetService. O

Petition 870180049145, of 06/08/2018, p. 64/71

57/63 first has a cumulative request latency of 250 milliseconds and the second has a cumulative request latency of 100 milliseconds. Using the exemplary selection rules presented above, a current request for an operation on port type A will be routed to the second endpoint, one at URI http: /www.ibm.com/anotherTargetService.

[0110] In the method of figure 4, the creation (312) of a target service request (114) to perform the operation on the target service can be performed by composing the request in a useful data structure in a neutral binding interface and calling the neutral binding interface, passing the request as a call parameter. Similarly, issuing (316) the target service request (114) to the target service comprises calling one or more elements on a neutral binding interface.

[0111] A neutral binding interface is one in which the use of the interface does not depend on a message binding request. That is, the data structure and calling methods used to implement the interface and carry out data communications through it, do not depend on the type of data encoding used in a message, nor do they depend on the data communication protocol used for a message. Developers of agnostic proxies as to the type of port for intermediaries in accordance with the modalities of the present invention will often build their neutral binding interfaces. There is an open standard for a neutral binding interface, however, known as WSIF, Web Service Invocation Framework. WSIF is now supported

Petition 870180049145, of 06/08/2018, p. 65/71

58/63 as part of the Apache Software Foundation's Web Services

Project.

[0112] The use of a neutral binding interface provides advantages for the modalities of the present invention. SOAP-HTTP binding is so common in current technique that users and developers sometimes forget that there are other bindings. This results in the development of systems that are difficult, if not impossible, to use with other bindings or to adapt for use with other bindings. As network services develop, however, other bindings will become more useful and more common. The use of a neutral binding interface for specifying modalities of the present invention, furthermore, also means that available bindings can be determined at processing time, thus providing a flexible, powerful and generally more useful network service intermediary .

[0113] One way to implement a neutral binding interface is to provide endpoint objects that are capable of invoking services on target services given a port type and an endpoint. One way to provide these endpoint objects is by using an endpoint factory similar to the one illustrated in the following pseudocode segment:

Endpoint Factory Class // Defines a parameterized factory method for creating endpoint objects // class EndpointFactory {

Petition 870180049145, of 06/08/2018, p. 66/71

59/63 public static Endpoint createEndpointObject (portType, networkAddress) {

// establish reference for new endpoint object

Endpoint anEndpoint = null;

if (portType == A && networkAddress == www.abc. com ”) anEndpoint = new Endpointl;

if (portType == B && networkAddress == wwww.def.

com ”) anEndpoint = new Endpoint2;

if (portType == C && networkAddress == www.ghi.

com) anEdpoint = new Endpoint3;

if (portType == LAST && networkAddress == www. IastSupported.com ”) anEndpoint = new Endpoint465; if anEndpoint == null) reportError (); else return anEndpoint;

} // end createEndpointObject ()} // end class EndpointFactory [0114] The classes of endpoints, Endpointl, Endpoint2, Endpoint3 and so on, are concrete classes that inherit an abstract endpoint class (or implement it as an interface) which provides element methods for creating message objects to contain message parts. This endpoint factor and other elements in this neutral binding interface can be used to perform the steps of creating (312) a target service request (114) and issuing (316) of the request (114)

Petition 870180049145, of 06/08/2018, p. 67/71

60/63 target service to the target service, as illustrated in the following pseudocode segment:

// Get endpoint object from endpoint factory

Endpoint ep = endPointFactory.createEndPoint (portType, networkAddress);

// Prepare an input message

Message input = ep.createlnputMessage ();

// use message accessor function to insert contents of message socketsetPart (symbol, IBM);

// Prepare a placeholder for a response value

Message output = null;

if (synchRespReqd == TRUE) output = ep.createOutputMessage ();

// execute the operation ep.executeRequestResponseoperation (getQuote, input, output);

// return the result if (synchRespReqd == TRUE) return output; else return ACK;

[0115] This example pseudocode segment, given a type of port and a network address for an endpoint, calls an endpoint factory to create an endpoint object. the segment then creates a target service request by loading parts of the message into the endpoint object and issues the target service request to the target service by calling the executeRequestResponseOperation () element method. The method in figure 5, if the request requires a synchronous response, includes receiving (320), at the intermediary, a response

Petition 870180049145, of 06/08/2018, p. 68/71

61/63 (122) of the target service; creation (324), in the intermediary, depending on the response (122) of the target service, a response (126) of the intermediary; and returning (328) the response (126) from the intermediary to the request client.

[0116] In this example pseudocode segment, the steps of receiving (320) a response (122) from the target service and creating (324) a response (126) from the intermediary are implemented by the call to executeRequestResponseOperation (). In this example, the reference value for the outgoing message is left null, if the request requires a synchronous response. The null parameter output in this kind of modality is taken by a provider (220, in figure 2A) to mean that a synchronous response is not required, the provider, therefore, issues the request to a target service and returns immediately, without waiting for a response .

[0117] Similarly, if the request requires a synchronous response, the reference value for the response message 'output' is set to non-null by: output = ep.createOutputMessage (). The fact that the parameter reference for the response message, here called 'output' (in the call:

ep.executeRequestResponseOperation ('getQuote, input, output) is non-null, it is taken by a provider (220, in figure 2A) to mean that a synchronous response is required. This provider is then programmed to place a blocking receive call on its outbound agent (222, in figure 2) and wait for a corresponding response message from the target service. In terms of the figure method

Petition 870180049145, of 06/08/2018, p. 69/71

62/63

5, then, this segment represents an exemplary method of creating (312) a target service request (114) to perform an operation on a target service, depending on a determination (152) whether the request requires a synchronous response.

[0118] The sample pseudocode segments above illustrate the use of a neutral binding interface (218) with ports referred to as endpoints. The WSL interface syntax, however, uses the term port when referring to endpoints. Through another explanation regarding the use of neutral bindings interfaces, however, another exemplary pseudocode segment is presented, adhering more closely to the WSF standard. In this example, port is used to signify endpoint and for consistency of explanation, the factory name is changed to portFactory.

// get a port (an endpoint) from the factory

WSIFPort port = portFactory_getport (portType, networkAddress);

// Prepare an input message

WSIFMessage input = port_createInputMessage ();

// insert message contents socketsetPart (symbol, new WSIFJavaPart (String.class, symbol));

// Prepare a placeholder for a response value

WSIFMessage output = null;

if (synchRespReqd == TRUE) output = port.createOutputMessage O;

// execute the operation port.executeRequestResponseOperation (getQuote, input, output, null);

Petition 870180049145, of 06/08/2018, p. 70/71

63/63 // extract and return the result if (synchRespReqd == TRUE) return output;

else return ACK;

[0119] Although this specification discusses exemplary methods of supporting agnostic proxies as to the type of port in network service intermediaries, mainly in terms of processing a request on its way from a requester to a target service, it is useful to note that intermediaries according to the modalities of the present invention are also typically able to process response messages, making their way back from a target service through the intermediary to the original requester. The method of figure 51, for example, includes receiving (320), at the intermediary, when a request requires a synchronous response, of a response (122) from the target service; creation (324), in the intermediary, depending on the answer (122) of the target service of an answer (126) of the intermediary; and return (328) of the intermediary's response (126) to the requesting customer.

[0120] It will be understood from the preceding description that modifications and changes can be made in various modalities of the present invention, without departing from its true spirit. The descriptions in this specification are for illustration purposes only and should not be construed in a limiting sense. The scope of the present invention is limited only by the language of the following claims.

Petition 870180049145, of 06/08/2018, p. 71/71

1/4

Claims (6)

1/6 t «2 202 118 s, Requester Request _t Intermediate Solicitation * Service  '» j ..... * Answer answer AIV0 FIGURE 1A 102 202 118 FIGURE 1B Petition 870170103480, of 12/29/2017, p. 80/85 1. Method for supporting agnostic proxy as to the type of port for web services intermediaries (202), the method comprising: receiving (104, 304) at a web services intermediary (202), a request (106) for execution of a web service operation, in which the request (106) includes parametric information (107) comprising a type of port identifying a collection of operations, characterized by the fact that an endpoint (110) for a target service (118) that supports the operation can be identified using the door type parametric information; identify (108, 308), depending on the parametric information, the endpoint for a target service that supports the operation; create (112, 312) a target service request (118) to perform the operation of the target service (118); and issuing (116, 316) the target service request to the target service (118). 2/6 FIGURE 2A Petition 870170103480, of 12/29/2017, p. 81/85 2/4 from the target service (118), an acknowledgment (156) of the target service request; and returning recognition to a requestor (102) without waiting for a response message. 2. Method, according to claim 1, characterized by the fact that it comprises: determining whether the request requires a synchronous response; and waiting for a response from the target service (118) if the request requires a synchronous response. 3/6 FIGURE 2B Petition 870170103480, of 12/29/2017, p. 82/85 Parametric 3/4, a multiplicity of target service endpoints (118) that support the operation, and select an endpoint from the multiplicity of endpoints according to the selection rules. 9. Method, according to any of the preceding claims, characterized by the fact that the creation of a target service request to perform the operation on the target service (118) comprises: composition of the request in a useful data structure in an interface of neutral binding (218) and calling the neutral binding interface (218), passing the request as a call parameter. 10. Method, in accordance with any of the preceding claims, characterized by the fact that the issuing of the target service request to the target service (118) comprises the call of one or more member methods on a neutral binding interface (218 ). 11. System to support agnostic proxy regarding the type of port for web services intermediaries (202), the system comprising: means to receive (104, 304), at a web services intermediary (202), a request ( 106) to perform a web service operation, in which the request includes parametric information (107) comprising a type of port identifying a collection of operations, characterized by the fact that an endpoint (110) for a target service (118) that supports the operation can be identified using the door type parametric information (107); means for identifying (108, 308), depending on the port type parametric information, the endpoint for a target service (118) that supports the operation; means to create (112, 312) a target service request to perform the Petition 870170103480, of 12/29/2017, p. 77/85 Μ operation in the target service; and means for issuing (116, 316) the target service request to the target service (118). Petition 870170103480, of 12/29/2017, p. 78/85 3. Method, according to claim 2, characterized by the fact that determining whether the request requires a synchronous response comprises determining depending on parametric information whether the request requires a synchronous response. 4/6 Petition 870170103480, of 12/29/2017, p. 83/85 4. Method, according to claim 2 or 3, characterized by the fact that the request does not require a synchronous response and the method still comprises: receiving (354), Petition 870170103480, of 12/29/2017, p. 75/85 5/6 Petition 870170103480, of 12/29/2017, p. 84/85 5. Method, according to claim 2, 3 or 4, characterized by the fact that waiting for a response from the target service (118) still comprises: receiving synchronously (320) at the intermediate (202) a response from the target service; create (324) in the intermediate (202), depending on the response from the target service (118), a response from the intermediate (202); and returning (328) the response from the intermediary (202) to a requester (102). 6. Method, according to claim 5, characterized by the fact that the synchronous receipt at the intermediary (202) of a response from the target service still comprises the invocation of a blocking receive function in a data communications connection between the intermediary (202) and the target service (118). 7. Method, according to any of the preceding claims, characterized by the fact that the target service request as created and issued to the target service (118) takes unexamined and unmodified message contents from the request received at the intermediary (202) of web services. 8. Method, according to any of the preceding claims, characterized by the fact that the identification (108, 308), depending on parametric information, of an endpoint for a target service (118) that supports the operation still comprises: identifying, depending on information Petition 870170103480, of 12/29/2017, p. 76/85 6/6 350 Determine whether a. request requires a synchronous response Determination 152 Create target service request Requester Target service request 316 Issue target service request 328 You Return intermediary response to the requester 324 _X Create Response - Proxy 123 γ t I Response from j 'target service / 320 V__T_ --fc Receive target service response synchronously FIGURE 5 Petition 870170103480, of 12/29/2017, p. 85/85