FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
1. Title of the invention: INFORMATION GATEWAY FOR DATA EXCHANGE
2. Applicant(s)
NAME NATIONALITY ADDRESS
TATA CONSULTANCY Indian Nirmal Building, 9th Floor,
SERVICES LIMITED Nariman Point, Mumbai,
Maharashtra 400021, India
3. Preamble to the description
COMPLETE SPECIFICATION
The following specification particularly describes the invention and the manner in which it
is to be performed.

TECHNICAL FIELD [0001] The present subject matter relates, in general, to data exchange between applications and, in particular, to an information gateway for data exchange.
BACKGROUND [0002] An enterprise typically uses a variety of applications, such as customer management application, supply chain management application and business intelligence application, for various purposes, such as operation and data management, strategy formulation, etc. The applications may be built using disparate technologies and may use different communication protocols and data formats. These applications tend to be silos of information as they cannot communicate with each other, which leads to inefficiencies and redundancy of data. [0003] Enterprise Application Integration (EAI) frameworks are conventionally used to facilitate communication between different applications used across the enterprise. Current integration frameworks facilitate data exchange between the different applications by employing a common data format. For example, whenever a message is to be communicated from a sender application to a receiver application, the message is converted from the format of the sender application to a common format. The common format message is then communicated to the receiver application where it is converted to the format compatible with the receiver application. Such transmission of messages requires multiple format conversions and tends to be inefficient.
SUMMARY [0004] This summary is provided to introduce concepts related to information gateway systems and methods for data exchange. These concepts are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
[0005] Information Gateway systems and methods for data exchange are described. In one implementation, a method for data exchange comprises sending a plurality of service details of a

provider application to a requester application, from an application registry. A request message is received from the requester application based on the service details. The request message is transformed into a message format compatible with the provider application, based on the application registry, when an original message format of the request message is not compatible with the provider application. Further, the transformed request message is sent to the provider application.
BRIEF DESCRIPTION OF THE FIGURES [0006] The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and components.
[0007] Fig. 1(a) illustrates a network environment implementing an information gateway system, in accordance with an embodiment of the present subject matter.
[0008] Fig. 1(b) illustrates architecture of the information gateway system, in accordance with another embodiment of the present subject matter.
[0009] Fig. 1(c) illustrates data flow through the information gateway system, in accordance with another embodiment of the present subject matter.
[0010] Fig. 2 illustrates a method for data exchange between various applications, in accordance with an embodiment of the present subject matter.
[0011] It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.
DETAILED DESCRIPTION [0012] Systems and methods for facilitating data exchange between various applications through an information gateway are described herein. The systems or devices that can implement

the described method(s) include, but are not limited to, desktop computers, servers, laptops, other portable computers, and the like.
[0013] An enterprise may employ different applications with varied functionalities to fulfill different business requirements. In order to efficiently manage and process data, the applications may have to exchange data with each other. However, the different applications may employ different data formats or communication protocols, which may hinder effective data communication. Typically, data communication between a plurality of enterprise applications, such as customer management application, supply chain management application and business intelligence application, involves sending a request message from a requester application to a provider application and receiving a response message from the provider application. The request message may include one or more input parameters and the response message may include one or more output parameters.
[0014] For example, in an automobile enterprise, a customer management application may request data related to input parameters, such as item name, item number, selling date, etc., pertaining to a customer and a business intelligence application may provide an output in response to the request. However, the two applications may employ different data formats or communication protocols. As will be appreciated by a person skilled in the art, the data formats may include XML, SOAP, Binary, etc., and the communication protocols may include http, MQ, etc. In order to accomplish data exchange between the provider and requester application, a common data format and communication protocol may have to be adopted for both the provider and requester application. Conventionally, enterprise application integration frameworks, also referred to as application integration systems, are used for this purpose.
[0015] In conventional application integration systems, whenever a message is to be communicated between two applications, the message is first converted to a common format and then communicated to the provider application, where it is further converted to the compatible format of the provider application. As a result, the conversion of the data format and communication protocol to the common format takes place even when both the applications employ the same data format or communication protocol, thereby reducing the overall efficiency. [0016] Further, the requester application may have to send multiple messages to the provider application in order to determine the input parameters to be sent and the output parameters that can be received. For example, the requester application may first send a message requesting for

information fields for which data can be provided by the provider application and input parameters required. Based on receipt of the information fields and list of input parameters, the requester application may then send a request message with the input parameters, and accordingly receive the output parameters. Such transmission of multiple messages for any data exchange results in an increase in the network traffic leading to further reduction in efficiency. [0017] Also, typically, any application that has access to the application integration system can interact with another application in the application integration system, resulting in a threat to network security. For example, a hacker may run an unauthorized application to gain access to the network and fetch data from business applications. The data thus accessed can be manipulated or disclosed to a third party, thereby posing a risk to the business. [0018] The present subject matter relates to an information gateway for data exchange, which provides a common interface for the applications to interact with each other. The information gateway can further include software and hardware modules to provide various functionalities, such as for authorization, message conversion, and interface points for integration.
[0019] In one implementation, to facilitate use of the information gateway for data exchange, an application registration process is used prior to allowing data exchange between the applications. Registering of the applications ensures security of the data exchange and also increases efficiency of the data exchange by making the information for data exchange available beforehand to applications, as will be discussed herein. In operation, a user can initiate registration of an application with an application registry by providing details, such as application name, component name, component request type, whether authorization is required, set of information required, and the like, of the application to be registered. The application registry acts as a central database for authorizing and facilitating efficient data exchange by registering applications and its services and exposing services at enterprise level for other applications to use. It will be appreciated that the application registry may be a part of the information gateway or may be communicatively coupled to the information gateway. [0020] The application details stored on registration can be used by other applications, which are already registered with the application registry, to exchange data. In one implementation, once the application details are saved in the application registry, an approval request is sent to an approver, such as an administrator. The approver can review the application details and approve

or reject the registration. In this implementation, other applications can view the registration details and exchange data with the registered application after the registration details are approved by the administrator.
[0021] In operation, when an application, referred to as requester application, has to obtain data from another application, referred to as provider application, the requester application can send a service request to the information gateway. The communication between the applications and the information gateway is facilitated by integration points that support specific combinations of communication protocols such as ftp, http, SOAP, etc., and data formats, such as XML, SOAP, binary, etc., and thus enable the applications to send and receive messages without requiring format conversion by the applications. Each application can select an appropriate integration point for communication based on the data format and communication protocol used by that application.
[0022] The information gateway helps the applications to communicate in an efficient and seamless way based on the registration details stored in the application registry, also referred to as registry. On receiving the service request, the information gateway provides service details regarding the provider application, from the registry, to the requester application. The service request includes, for example, a list of input parameters required by the provider application to provide the requested information. Based on the received service details, the requester application can send a request message for the provider application to the information gateway. [0023] The information gateway then determines the message format, such as data format, communication protocol, etc., used by the provider application, from the registry, and accordingly converts the original message format, i.e., data format and/or communication protocol, of the request message into the provider application’s message format before transmitting the request message to the provider application. Thus, applications can communicate with each other without being aware of each others message formats. Further, since the requester application and information gateway can obtain the input parameters and message format details from the registry directly without communicating with the provider application, the network traffic is significantly reduced. Thus, pre-registration quickens the data communication process and makes the communication seamless and efficient. Moreover, in case the communication protocol or data format of the requester and provider applications are the

same, the communication may take place without any protocol or format conversion, thus
reducing the processing time and improving the system’s efficiency.
[0024] In an implementation, in order to ensure data security, the information gateway can
verify whether the requester application is authorized to communicate with the provider
application based on the details stored in the registry, prior to delivering the request message to
the provider application. Once the requester application is authenticated, the request message is
delivered to the provider application. Further, in response to the request message, requested data
can be retrieved from the provider application and delivered to the requester application.
[0025] In one implementation, the request message may not be transmitted on account of
network issues, and therefore the request message can be stored in a message store in the
information gateway for transmission at a later time.
[0026] Thus the information gateway of the present subject matter makes application
integration more efficient, secure and reliable using pre-registration of the applications and need
based message format conversion.
[0027] These and other advantages of the present subject matter would be described in
greater detail in conjunction with the following figures. While aspects of described systems and
methods for the information gateway system can be implemented in any number of different
computing systems, environments, and/or configurations, the embodiments are described in the
context of the following exemplary system(s).
[0028] Fig. 1(a) illustrates a network environment implementing an information gateway
system 102. For the sake of explanation, the information gateway system 102 is referred to as the
system 102 hereinafter. In one implementation, the system 102 is connected to one or more
devices 104-1, 104-2, 104-3, 104-4, 104-5… 104-N, individually and commonly referred to as
device 104 hereinafter, through a network 106.
[0029] The system 102 can be implemented as a variety of communication devices, such as a
laptop computer, a desktop computer, a notebook, a workstation, a mainframe computer, a server
and the like. The system 102 described herein, can also be implemented in any network
environment comprising a variety of network devices, including routers, bridges, servers,
computing devices, storage devices, etc.
[0030] The devices 104 may be implemented as, but are not limited to, desktop computers,
hand-held devices, laptops or other portable computers, tablet computers, mobile phones, PDAs,

Smartphone, and the like. The devices 104 may be located within the vicinity of the system 102 or may be located at different geographic location as compared to that of the system 102. Further, the devices 104 may themselves be located either within the vicinity of each other, or may be located at different geographic locations.
[0031] The network 106 may be a wireless or a wired network, or a combination thereof. The network 106 can be a collection of individual networks, interconnected with each other and functioning as a single large network (e.g., the internet or an intranet). Examples of such individual networks include, but are not limited to, Global System for Mobile Communication (GSM) network, Universal Mobile Telecommunications System (UMTS) network, Personal Communications Service (PCS) network, Time Division Multiple Access (TDMA) network, Code Division Multiple Access (CDMA) network, Next Generation Network (NGN), Public Switched Telephone Network (PSTN), and Integrated Services Digital Network (ISDN). Depending on the technology, the network 106 includes various network entities, such as gateways, routers; however, such details have been omitted for ease of understanding. [0032] In one implementation, the system 102 includes processor(s) 108. The processor 108 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor(s) is configured to fetch and execute computer-readable instructions stored in a memory. It will be appreciated that the functions of the various elements shown in the figure, including any functional blocks labeled as “processor(s)”, may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared.
[0033] Further, the system 102 includes interface(s) 112. The interfaces 112 may include a variety of software and hardware interfaces that allow the system 102 to interact with the entities of the network 106 and the devices 104. The interfaces 112 may facilitate multiple communications within a wide variety of networks and protocol types, including wire networks, for example, LAN, cable, etc., and wireless networks, for example, WLAN, cellular, satellite-based network, etc.

[0034] In one implementation, the interfaces 112 include integration points 114 that act as point of data exchange between the system 102 and various applications of the devices 104. [0035] The system 102 may also include a memory 116. The memory 116 may be coupled to the processor 108. The memory 116 can include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.
[0036] Further, the system 102 may include module(s) 118 and data 120. The modules 118 may be coupled to the processors 108 and, amongst other things, include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular data types. The modules 118 may also be implemented as, signal processor(s), state machine(s), logic circuitries, and/or any other device or component that manipulate signals based on operational instructions. In another aspect of the present subject matter, the modules 118 may be machine-readable instructions or software, which, when executed by a processor/processing unit, perform any of the described functionalities. The machine-readable instructions may be stored on the memory 116, such as an electronic memory device, hard disk, optical disk or other machine-readable storage medium or non-transitory medium. In one implementation, the machine-readable instructions can be also be downloaded to the memory 116 via a network connection. [0037] In an implementation, the modules 118 include an authorization module 122, a message handler 124, and other module(s) 126. The other module(s) 126 may include programs or coded instructions that supplement applications or functions performed by the system 102. In said implementation, the data 120 includes requester data 128, provider data 130, and other data 132. The other data 132 includes data generated or used by the modules 118. [0038] Further, the system 102 is communicatively coupled to an application registry 134, also referred to as registry 134. It will be appreciated that the system 102 may communicate with the registry 134 directly or indirectly. For example, in one implementation, the registry 134 can be a part of the system 102. In another implementation, the system 102 may be directly communicating with the registry 134. In yet another implementation, the system 102 may communicate with the registry 134 through the network 106.

[0039] The devices 104 may have multiple applications running on them. The system 102 facilitates data communication between the applications, such as between a requester application and a provider application, without requiring the applications to have prior information about each other. The requester application may be understood as an application that requests for data from the provider application. It will be understood that the requester and provider applications may be running on the same device or may be on different devices 104.
[0040] To facilitate the data communication between the applications, the system 102 uses a registration process, also referred to as pre-registration since it happens before any communication between applications can take place. In an implementation of the present subject matter, one or more of the devices 104 include or have access to an application registration module 136. The application registration module 136 is configured to register applications in the registry 134 of the system 102. Further, the application registration module 136, at the time of registration, receives a plurality of application details, such as application name, component name, component request type (example search, update), component transfer mode (example http, jms), authorization required, component interface name, mandatory set of information required by interface, input parameters, etc. pertaining to the application to be registered and stores the application details in the registry 134. In one implementation, the application registration module 136 receives the information from a user and notifies an approver, such as an administrator to approve the registration. The application may be considered to be registered on receipt of approval from the administrator.
[0041] According to an example of the present subject matter, an automobile enterprise may include of a large number of clients, workers, cars, etc. In order to ensure efficient working of the enterprise, various types of data is maintained using various applications. For example, the automobile enterprise may employ several applications, such as client application, workers management application, insurance application, inventory application, etc. These applications act as silos of information. Sometimes, one application may require information from other application. For example, client application may require information from the inventory application regarding the availability of a particular car model. In such a scenario, the client application can be understood to be the requester application and the inventory application can be understood to be the provider application. It is possible that the requester and provider

applications may be developed using different technologies and may use different communication protocols, data formats, etc.
[0042] According to the described example of the present subject matter, the system 102 facilitates the information exchange between the requester and provider applications. The requester and provider applications may communicate with the system 102 through integration points 114 that support their respective communication protocols and data formats. In one implementation, the integration points 114 can support point to point, publish and subscribe communication methods. As will be understood by a person skilled in the art, in point to point communication, a requester application can invoke a provider application’s method if the provider application’s communication protocol is supported by it. Also, if there is no data transformation required, requester application can directly invoke provider application. Further, publish and subscribe methods are used when the message has to be broad casted to multiple receivers, for example, using Java Message Service (JMS).
[0043] In operation, the requester application sends a service request to the message handler 124 through an integration point 114. The service request includes request for service details including parameters required for communication with the provider application. The message handler 124 retrieves the service details from the registry 134 and sends the details to the requester application. Based on the service details, the requester application sends a request message to the message handler 124 for communication to the provider application. [0044] In order to ensure the security of the data communication, the authorization module 122 determines whether the requester application is authorized to send the request message, based on the registration details of the requester application stored in the registry 134. On successful authorization, the request message can be sent to the provider application. [0045] For sending the request message, the message handler 124 determines, from the registry, whether the requester application and provider application employ different message formats, such as data formats or communication protocols. In one example, the message handler can determine whether an original message format, also referred to as original format, of the request message is compatible with the provider application. It will be understood that a message format includes data format and communication protocol. If the message formats are found to be different or non-compatible, the message handler 124 performs the data format and/or communication protocol conversion and sends the transformed message to the provider

application, thereby facilitating data exchange between the requester and provider application. If the message formats are not found to be non-compatible, the message handler 124 can send the request message as it is to the provider application without any transformation. The message handler 124 can use methods well known in the art for the transformation of the data format and communication protocol.
[0046] The provider application can send the requested information in response to the request message to the message handler 124 via an appropriate integration point 114. The message handler 124 may transform the response to the message format of the requester application, if required and dispatch the response to the requester application. [0047] In one implementation, the message handler 124 may store the request message and the requested information as the requester data 128 and the provider data 130, respectively, in case there is a transmission error, for example, due to network issues. The stored request message or information can then be transmitted at a later point in time as soon as possible, as will be understood by a person skilled in the art.
[0048] Fig. 1 (b) and 1(c) are described in conjunction and illustrate the data flow between a requester application 160-1 and a provider application 160-2. For explanation purposes, it is considered that the flow of data takes place through integration point 114-1 used by the requester application 160-1 and the integration point 114-2 used by the provider application 160-2. [0049] The requester application 160-1 requests service details from the application registry 134. The application registry 134 sends the service details corresponding to the provider application 160-2 to the requester application 160-1. In response to the service details, a request message is generated by the requester application 160-1 and sent to the message handler 124. The authorization module 122 validates the requester application in order to ensure that only authorized applications are allowed to interact with the provider application. [0050] On successful authorization, the authorization module 122 generates a token, which is sent to the message handler 124. On receiving this token, the message handler 124 generates a success message which is sent to the requester application 160-1 and the request message is stored in a message store 144. The message store 144 provides a temporary storage unit for the request message. In case there is a network failure or transmission error, the request message can be retrieved from the message store 144 and sent at a later time.

[0051] On receiving a success message from the message store 144, the message handler 124 sends the request message to the transformer 146. The transformer 146 can convert the data format or communication protocol of the request message sent by the requester application 160-1 to the data format or communication protocol used by the provider application 160-2, if required. The transformer 146 can use methods well known in the art for the transformation of the data format or the communication protocol. The transformed request message is sent back to the message handler 124. The message handler 124 sends the transformed request message to a dispatcher 148, which further sends it to the provider application 160-2. On sending the request message, the dispatcher 148 sends a success message to the message handler 124, which further sends a success message to the requester application 160-1. In case of non receipt of the success message from the dispatcher 148, for example, on account of network failure and the like, the request message stored by the message handler 124 can be re-sent at a later time. While the message store 144, the transformer 146 and the dispatcher 148 are shown as separate modules, it will be understood that these modules can be a part of the message handler 124 also. [0052] Based on the request message, the provider application 160-2 can send a response message with the requested information to the requester application 160-1 through the message handler 124 of the system 102. The data format or communication protocol of the response message can also be converted by the message handler 124, if required, before transmitting it to the requester application 160-1.
[0053] Fig. 2 illustrates an exemplary method 200 for data exchange between various applications. According to an embodiment of the present subject matter, the method 200 may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, and modules, functions that perform particular functions or implement particular abstract data types. The method 200 may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communication network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media and devices. [0054] The order in which the method 200 is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method 200, or alternative method. Additionally, some of the individual blocks

may be deleted from the method 200 without departing from the spirit and scope of the subject
matter described herein. Furthermore, the method 200 can be implemented in any suitable
hardware, software, firmware, or combination thereof.
[0055] Referring to method 200, at block 202, a plurality of service details may be sent to a
requester application from an application registry based on receipt of a service request from the
requester application. The service details may include the input parameters required by a
provider application. In an implementation, the service details are stored in the registry when an
application is registered with the registry. In one implementation, an application registration
module 136, registers the application. The registration process can involve storing the
information, such as application name, component name, component request type (example
search, update), component transfer mode (example http, jms), authorization required,
component interface name and mandatory set of information required by interface, pertaining to
the application in a database. The application may be registered subject to approval from an
administrator.
[0056] At block 204, a request message may be received from the requester application for a
provider application based on the service details.
[0057] At block 206, the requester application sending the request message is authorized
based on application standards like SAML and standard encryption and decryption methods. In
an implementation, the authorization module 122 may be used to authorize the requester
application sending the request message. The request message may be stored in the requester
data 128 by the message handler 124 based on the authorization.
[0058] At block 208, the request message is transformed based on the information stored in
the application registry. In case an original format of the request message is not compatible with
a message format of the provider application, it may be required to transform the data formats or
communication protocols to facilitate data exchange between various applications. In an
implementation, the message handler 124, transforms the requester data 128 as required to
permit the data exchange between the applications.
[0059] At block 210, the transformed request message is sent to the provider application. In
an implementation, the message handler 124 may send the transformed requester data 128 to the
provider application.

[0060] At block 212, requested information is received from the provider application and sent to the requester application. In an implementation, the message handler 124 may receive the requested information and store it in the provider data 130. Further, the message handler 124 may also transform the data format and communication protocol of the requested information, if required, before sending it to the requester application.
[0061] Although implementations for information gateway system have been described in language specific to structural features and/or method, it is to be understood that the appended claims are not necessarily limited to the specific features or method described. Rather, the specific features and method are disclosed as exemplary implementations for information gateway system.

I/We claim:
1. A method for data exchange, the method comprising:
sending a plurality of service details of a provider application to a requester application, from an application registry;
receiving a request message from the requester application based on the service details;
transforming the request message into a message format compatible with the provider application, based on the application registry, when an original message format of the request message is not compatible with the provider application; and
sending the transformed request message to the provider application.
2. The method as claimed in claim 1, wherein the method further comprises registering applications, wherein the registering includes storing at least an application name and the message format of the applications.
3. The method as claimed in claim 1, wherein the method further comprises authorizing the requester application based on registration details in the application registry.
4. The method as claimed in claim 1, wherein the message format includes a data format and a communication protocol; and the transforming comprises transforming at least one of the data format and the communication protocol.
5. The method as claimed in claim 1, wherein the method further comprises storing the request message in a message store.
6. The method as claimed in claim 5, wherein the method further comprises
determining whether at least one of the request message and the transformed request message have been delivered to the provider application; and
re-sending the request message from the message store when at least one of the request message and the transformed request message have not been delivered.
7. The method as claimed in claim 1, wherein the method further comprises receiving a
response message from the provider application and sending the response message to the
requester application.

8. The method as claimed in claim 7, wherein the method further comprises transforming
the response message into the message format compatible with the requester application.
9. An information gateway system (102) comprising:
a processor (108); and
a message handler (124) coupled to the processor (108), wherein the message handler (124) is configured to:
receive a request message from a requester application for a provider application, wherein the request message is based on service details of the provider application available from an application registry (134);
transform the request message into a message format compatible with the provider application, based on the application registry (134), when an original message format of the request message is not compatible with the provider application; and
send the transformed request message to the provider application.
10. The information gateway system (102) as claimed in claim 9, wherein the message handler (124) is configured to send the request message without transformation when the original message format of the request message is compatible with the provider application.
11. The information gateway system (102) as claimed in claim 9 further comprising an authorization module (122) configured to authorize the requester application based on registration details in the application registry (134).
12. The information gateway system (102) as claimed in claim 9, wherein the message handler (124) is configured to transform at least one of a data format and a communication protocol of the request message.
13. The information gateway system (102) as claimed in claim 9, wherein the message handler (124) is configured to store the request message in a message store and re-send the request message from the message store when at least one of the request message and the transformed request message have not been delivered.

14. The information gateway system (102) as claimed in claim 9 further comprising a plurality of integration points (114) for communicating with applications, wherein each of the plurality of integration points supports a combination of data format and communication protocol.
15. A non-transitory computer-readable medium having embodied thereon a computer readable program code for executing a method for data exchange, the method comprising:
receive a request message from a requester application for a provider application, wherein the request message is based on service details of the provider application available from an application registry;
transforming the request message into a message format compatible with the provider application, based on the application registry, when an original message format of the request message is not compatible with the provider application; and
sending the transformed request message to the provider application.