Browse Prior Art Database

Remote Call Invocations with Progress Heartbeats

IP.com Disclosure Number: IPCOM000205174D
Original Publication Date: 2011-Mar-18
Included in the Prior Art Database: 2011-Mar-18
Document File: 2 page(s) / 120K

Publishing Venue

Siemens

Related People

Juergen Carstens: CONTACT

Abstract

Modern software is architected as client-service applications (see Figure 1). Thus, a client application communicates with a corresponding service via defined interface API (Application Programming Interface). A client calls API functions, which are processed by a service returning a response back to the client. Within the conventional client-service communication scheme, a client waits for the response from service with a specified timeout. The client-service architecture is often chosen due to the following advantages: • Clients and services are standalone processes running in different address spaces excluding memory corruptions of each other. • Clients and services may run on different computers: services normally run on powerful back-end machines, clients on front-end machines. • Services may process requests from many clients in a load-balanced fashion. A serious problem appears when time to process a request varies depending on performance and sizing parameters of the request processing. Then it is almost impossible to specify a proper timeout on the client side because if timeout is too short then the client fails during the remote call invocation and if timeout is too long then the client would wait for the service that possibly failed and never responded.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 2

(This page contains 01 pictures or other non-text object)

(This page contains 00 pictures or other non-text object)

Remote Call Invocations with Progress Heartbeats

Idea: Dr. Oleksandr Pochayevets, DE-Nuremberg

Modern software is architected as client-service applications (see Figure 1). Thus, a client application

communicates with a corresponding service via defined interface API (Application Programming

Interface). A client calls API functions, which are processed by a service returning a response back to

the client. Within the conventional client-service communication scheme, a client waits for the

response from service with a specified timeout.

The client-service architecture is often chosen due to the following advantages:
• Clients and services are standalone processes running in different address spaces excluding

memory corruptions of each other.
• Clients and services may run on different computers: services normally run on powerful back-

end machines, clients on front-end machines.
• Services may process requests from many clients in a load-balanced fashion.

A serious problem appears when time to process a request varies depending on performance and

sizing parameters of the request processing. Then it is almost impossible to specify a proper timeout

on the client side because if timeout is too short then the client fails during the remote call invocation

and if timeout is too long then the client would wait for the service that possibly failed and never

responded.

An example is control center software where client applications and services run fully distributed on

many computers processing control center data of different sizes. In 32-bit software holding entire

control center data model in shared memory, the size of control center data is limited to specific data

storage. This explains on why it is still possible to use the conventional client-service communication

scheme with the hard-coded timeouts. For 6...