In recent years, there has been a proliferation of computer software languages that use a variety of manners of communication to interact and exchange data. One manner of communication is client-server communication. In client-server based communication, a client application interacts with a server by first making a service request. The server then remits a response to the client application service using the initial communication type. This request and response interaction facilitates a complete end-to-end communication between client and server systems.
The service request made by the client application may comprise a communication protocol, a protocol method for that communication protocol, and a data format used to submit data over that protocol. For example, a client application may send a service request via the HTTP protocol using the HTTP protocol's POST method and the XML data format. A server would return a response using the same communication type. On the other hand, another client application, could send a service request via the HTTP protocol using the HTTP protocol's GET method and a name-value-pair (NVP) data format. Again, a server would return a response using the same communication type.
The proliferation of computer languages and disparate manners of communication has created interoperability issues amongst different software applications. This is because computer languages and their respective manners of communication may be incompatible with each other.
One contemporary solution to deal with this issue is Service Oriented Architecture (SOA). SOA allows disparate software languages to communicate with each other by providing interoperable services. Each service implements a single task. For example, a client application, using one underlying software language, can make a service request to a SOA service, based on another underlying software language, that returns information about a user's account password. Many other SOA services, each with varying types of information and complexity, are possible. Such SOA services provide a wide range of functionality to outside requesting computer applications.
SOA services achieve interoperability because they accept a single communication standard from client applications. For example, one popular communication standard for SOA is the extensible markup language (XML). XML is a general-purpose specification that allows users to create custom markup languages. Given XML's customizable format, other computer languages utilizing XML can facilitate data exchange amongst one another. This is achieved by defining an agreed upon XML data format that two or more applications are to exchange. The applications can then use that defined format to exchange data. Such a language is ideal for interoperability issues that SOA seeks to solve. A SOA based server could specify that it receives only a given XML based data format. All client applications communicating with that server would need to make service requests using XML data format.
Computer systems that implement SOA also provide a means to discover the services offered. A computer application interacting with the SOA based server can request a list of services that the server provides. The application can then subsequently request that the server perform anyone of those listed services, such as the account password verification service mentioned above. The computer software applications and the services that use SOA based systems to interact are then “loosely coupled” because both remain independent of one another. Loose coupling is preferred when either disparate systems can be changed independently of one another.
A popular implementation of the SOA concept is Web Services. Web Service implementations host SOA based services on a computer server. Web Services also facilitate communication among computer applications via standard internet protocols, e.g., HTTP. The typical communication standard used for software application interaction is the Simple Object Access Protocol (SOAP). SOAP is an XML based specification that that relies on an XML data format for its data payload and can use HTTP for message transmission. Software applications may create SOAP based requests and send them to Web Service Servers for purposes of data exchange. This enables software client applications to make service requests to web service servers in remote locations via the internet. Because of the loose coupling of the underlying SOA scheme, software applications using different computer languages and methods can communicate with each from a distance.
For example, using Web Services, a client application based upon the Java computer language can communicate with a server application based upon the C++ computer language. To send a service request, the Java based client application would create a SOAP message and send it via the HTTP protocol over the internet to the C++ based server application. The C++ application would then implement a Web Services front-end application that would receive the SOAP messages. From the SOAP message the C++ based server application could consume the transmitted data for further processing. The client and server applications could communicate despite their disparate underlying languages, i.e. Java and C++, respectively.
However, Web Services create issues for older, legacy based applications that predate SOA. This is because SOA based architectures, such as Web Services, require the aforementioned single communication standard. For example, with web services, that single communication standard is the SOAP data format sent via the HTTP protocol. Thus, all service requests to a typical Web Service server must be in the SOAP data format. But legacy applications that predate SOA typically use other legacy formats, e.g. HTTP GET with NVP data formats and HTTP POST with XML data formats. This creates issues when Web Service servers do not accept these older formats. Because Web Service based servers generally accept SOAP formatted requests, this creates a communication barrier for legacy applications that use other communication types.
One solution would be to upgrade older client applications and the devices upon which they are implemented. The client applications and devices would be upgraded from their legacy communication types, e.g. HTTP GET with NVP, to facilitate newer SOAP based communication types. Such an upgrade would allow legacy devices to communicate with newer Web Services based servers. As discussed earlier, this would achieve interoperability between devices with underlying disparate languages. However, modification of existing devices could be unduly burdensome or expensive. This is because such modification could require the development of new SOAP enabled software for the client application, the delivery and installation of the software on the client devices upon which the client applications exist, and the cessation of services provided by the client applications while the installation of the software occurs.
For example, and at a high level, consider two different types of client application programs that make service requests to servers using disparate communication types. Each client application is installed on a large number of devices already in use. The server or network device, to which each client application program sends service requests, is newly configured to receive SOAP messages only. In this scenario, a company could modify, or reprogram, the client application programs to use SOAP. This would allow each client application program to communicate with the newly configured server or network device. But, this would not only be burdensome to the stakeholders of the client applications, as they would need to update their respective client application software, but also potentially expensive, as the stakeholders would need to expend time and resources making the modifications to the client application programs.
Alternatively, another solution would be to modify the server or network device to handle each different type of request protocol received from the different client application programs. Such as solution would forgo the need to modify client application programs. That is, the client applications would not need to be upgraded. Instead, client application programs would continue to operate as originally designed. To accomplish this, the stakeholders could place an intermediate communication layer to mediate between disparate client application communication types and Web Service server based applications. Again, this solution would overcome the need to upgrade legacy client applications because the communication from client application to server would be transparent to both entities.
For example, an enterprise service bus (ESB) could act as the intermediate layer placed between the Web Service server and the legacy client application devices. Generally, an ESB refers to a software infrastructure that facilitates the conversion from one communication type to another. ESBs can also route data or other such client-server communications to other endpoints. Said another way, the role of an ESB is to provide a common interface and mediations that handle communication between disparate transport mechanisms, leaving applications to deal only with business logic. In the computer science context, this can be referred to as a “layer of indirection” because the transport mechanisms communicate indirectly through the ESB. The ESB sits between and facilitates communication between both transport mechanisms. An ESB can be implemented as a software only solution—requiring installation on an existing server—or as hardware and software solution—existing as a physical and independent network device with software installed within, e.g. IBM's WebSphere DataPower (WSDP).
In one example, the ESB could receive incoming service requests from the legacy client applications and convert them into SOAP format. The ESB would have its own programmed services, called ESB services, that perform the conversion. By providing an intermediate layer that facilitates the conversion of disparate service requests into the SOAP format required for the Web Service server, the ESB would make the service requests transparent to the Web Service server.
However, an ESB may have limitations of its own. Despite the ability to convert disparate application request types into SOAP format, an ESB may be limited in how it performs this function. For example, ESBs may require each different type of service request to have a different corresponding ESB service. Each ESB service may require a unique communication port be assigned. A communication port is a logical channel or channel endpoint in a communications system at which a server can receive communication requests, e.g. a TCP/IP port. Because of this one-to-one service request type to ESB service limitation, multiple communication ports and multiple corresponding ESB services would have to be used and implemented, respectively, to receive the disparate types of service requests from legacy client applications. This could potentially necessitate an unmanageable or burdensome array of ESB services and corresponding communication ports in order to process disparate service request types received from different client applications. This increase in the number of ESB services and communication ports may cause an increase in the costs associated with the purchase, maintenance and development pertaining to additional server or network devices that house the communication ports and their corresponding ESB services.
For example, as the number of service requests and respective communication types from client applications grow, a company would need to implement more corresponding ESB services. This could create expensive software development costs as ESB services are created and maintained for the purpose of handling each type of service request.
Hence, a need exists for systems and methods that provide a means to reduce the number of servers or network devices and corresponding ESB services required to process client service requests having a variety of communication types.
USPTO Backgrounds
USPTO Backgrounds