In general the present invention relates to the fields of enterprise application software, machine-to-machine communication and enterprise application integration technology. In particular it relates to a method for accessing business object resources of a provider business application by at least one subscribed consumer application, and a corresponding machine-to-machine communication environment. Still more particularly, the present invention relates to a data processing program and a computer program product for accessing business object resources of a provider business application by at least one subscribed consumer application.
The trend to design, build and provide RESTful Web-APIs (Application-Programming-Interfaces) for business functionality is a success factor for enterprise applications in the future. REST (Representational State Transfer) is an architectural style, not a technology that describes several constraints to be applied when building Web-APIs. The web today works on the REST principles using HTTP (Hypertext Transfer Protocol) as application protocol.
Enterprise applications are either already using or are starting to use HTTP interfaces the REST way. One problem is that such a RESTful interface is not meant to call back a client because of its statelessness. The server doesn't maintain a list of clients but clients are expected to keep track of their state. A web-based business application is often confronted with customer requirements demanding that internal application business events should trigger an external system. This use case is not supported by a true RESTful API, except for polling which is only as consistent as the polling period. So in pure RESTful APIs there is no built-in solution to trigger events to connected clients. This is intended in REST interfaces and not a limitation.
A further problem comes from client SOAP (Simple Object Access Protocol) web services in the requesting applications. Often products are polluted by several customer specific implementations of consumer module interfaces like interfaces of ERP (Enterprise Resource Planning) systems. Each customer has different ERP interfaces using different technologies which lead to a huge combination of web service customized implementations in the products. Only a small proportion of such customized implementations are reusable. The maintainability and extendibility of such a product can be highly limited.
Furthermore, an application that generates information should—as the responsible system of that information—provide business interfaces of the functional domain with the correct scope and granularity. It should not be the other way round that the system being informed has to implement that interface. Also an application should clearly state which interactions are possible with it and which services can be offered.
In known solutions to these problems a general convention is to use polling by the client, which works perfectly with REST in the web, because of the caching capabilities of HTTP. Further a Web service client is implemented calling the system to be triggered directly, e.g. via SOAP (Simple Object Access Protocol) or REST. Also WS (Web service) reliable messaging and addressing like SOAP is used, which tends to act like a messaging solution.
In the enterprise world most access by users or systems to an application are protected, and a user or machine needs to authenticate before an access to the Web-API is allowed. So on these known solutions caching does not work for security reasons and therefore polling approaches become too expensive.
Therefore a substitution to polling is needed that informs a client and/or system of changes in the server application. This can be done by building out additional web services to call the clients, but this development effort will occur on the application side for implementing the client service. So for each client additional customized code within the product or an adapter would have to be built and supported, which does not scale with a large number of different clients.
Another known solution uses middleware that combines and implements custom interfaces and can include a message bus. Using such middleware solutions to adapt to customers specific interfaces moves or only temporarily solves the problem but it does not solve it in terms of reusability, maintainability and extendibility as it does not provide a process to approach the resolution of problems. Instead a second application has to be customized and continuously maintained leading to higher complexity and costs.
USPTO Backgrounds
USPTO Backgrounds