Patent Application
20230350697
The present disclosure relates to a computer-implemented method for a service framework to develop application services, a system that is implemented as a server-client-structure for a service framework, a computer program element and a computer readable storage.
In the prior art, service framework to develop application services are described which, for example, used to provide modules of a module stack, whereby these service frameworks providing the modules to requesting clients. In this context, each client may process one or more modules, and there may be dependencies between the respective modules of the module stack. Thereby, a modification due to a process of one module may cause difficulties in a dependent module.
In view of this, it is found that a further need exists to provide an improved method for a service framework to develop application services.
In the view of the above, it is an object of the present disclosure to provide an improved method for a service framework to develop application services.
These and other objects, which become apparent upon reading the following description, are solved by the subject matter of the present disclosure.
According to a first aspect, a computer-implemented method for a service framework to develop application services is provided, including:
The at least one module of a module stack may also be understood hereinafter as a module and/or a module of a module stack, although it is not intended to be described thereby as meaning only one module of the module stack.
Moreover, the service framework provide a module of a module stack and/or a service of the service framework. The client may be a computational entity that may request to use the service framework. For example, the service framework may compute and may provide a vehicle speed of a vehicle and the client, e.g., one or more clients, may connect to the service framework to request the vehicle speed.
In addition, the method may include a way to determine whether the provided module has been modified in such a way making it incompatible with the client.
In an implementation, the providing of the at least one module of a module stack and/or providing of the dependency data of the other modules of the module stack from the provided module may further include providing service interface data.
In an implementation, the service interface data may include service proxy data, whereby the service proxy data may include at least event values, method values and/or property values.
In an implementation, the service interface data may include service stub data, whereby the service stub data may include at least event values and/or property values.
In other words, the interface data may be an interface service that may be described in a service interface model. Whereby, that service interface model may be used to generate the service proxy data and/or the service stub data. With which the client may access to the service framework and/or the service framework may provide the module stack to the client.
Further, the interface service may be described with an interface definition language (IDL), preferably an IDL syntax may be created in a YAML format, whereby further formats can also be generated. Furthermore, the IDL may be used to generate a specific service proxy data and/or a specific service stub data. Thus, the interface data may provide defined services of a module of the module stack. Further, several specific service proxies and/or specific service stubs may be generated for the same interface.
Furthermore, the service proxy data and/or the service stub data may be used for at least connection management, buffer allocation and/or data serialization.
YAML is a human readable language for data serialization. The YAML formatted files are commonly used for configuration files and in applications where data is stored or transmitted.
The service proxy data and/or the service stub data may be used to provide features of communication between the service framework and the client. Moreover, the service proxy data and/or the service stub data may be used to provide similar features of communication between the service framework and the client. Whereby, the features of communication may include events from the service framework to the client, methods that the client may call on the service framework and/or properties that may be values that may be read and written by both, the client and the service framework. Further, it is also possible to subscribe to a property change in order to be notified when the client change a module of the module stack.
In an implementation, the providing of the at least one module of a module stack and/or providing of the dependency data of the other modules of the module stack from the provided module may further include providing dynamic runtime data.
Moreover, the dynamic runtime data may be used to provide a runtime and the client and a server of the service framework may use the runtime. Further, the dynamic runtime data may be used to control the transport between the client and a server of the service framework. Whereby, the controlling may be done by TCP/IP, QNX messaging, HTTP/HTTPS, direct method calls, in case the client and the service framework are in the same process and/or by other common used methods.
Further, the dynamic runtime data may be used to provide a part of a runtime on the client and another part of the runtime on a server of the service framework. Furthermore, the dynamic runtime data may be used to provide two or more runtimes, whereby the two or more runtimes may run parallel to each other. Moreover, the service framework may include more than one client and/or more than one server that may be running two or more runtimes.
Furthermore, the runtime or the two or more runtimes may be independent to the client and/or server of the service framework that may use them as well as the client and the server of the service framework may be independent to the runtime or the two or more runtimes.
Moreover, a service of the service framework may be used to provide a runtime for two or more clients of the service framework, which may be optimized to be located on the same processor of the service framework, to provide a runtime for two or more clients of the service framework, which may be optimized to be located on others processors, e.g., in a vehicle, of the service framework, and/or to provide a runtime for two or more clients of the service framework, which may be optimized for controlling a communicating of the two or more clients in the service framework, e.g., in a cloud.
In an implementation, the dynamic runtime data may include broker data, which may include at least a service framework value.
In other words, the broker data may be used to provide a broker in the service interface, which may be used as a separate process, whereby the broker may be configured to provide the service framework value to the client, which may provide an indication of an availability of more than one server of the service framework. For this purpose, the broker may consider different available versions of a module of the module stack.
In an implementation, the dynamic runtime data may include service configuration data, which may include at least a module value, a dynamic runtime value and/or a specific service value.
Moreover, the service configuration data may be used to verify the available modules of the module stack and/or services of the service framework, the availability of different instances of the same module of the module stack and/or service of the service framework, the availability of different runtimes of service framework and/or the availability of specific runtimes for a specific module of the module stack and/or service of the service framework.
In an implementation, the dynamic runtime data may include dynamically load data.
Moreover, the dynamically load data may be used to generate one or more runtimes, which may be configured to discover the service framework and communicate with it, whereby the client may generate a runtime which is most appropriate to connect to the service interface.
Further, the client and/or a server of the service framework may use the dynamic runtime data to generate one or more runtimes. Whereby, a server of the service framework may use a runtime configuration to load the runtime.
In an implementation, the dynamic runtime data may include service discovery data.
Moreover, the service discovery data may be used on the client or clients of the service framework to locate the service framework and/or connect to the service framework, whereby for example an IP and a port may be used. Further, some runtimes may also have their own running processes to support their specific implementation of service discovery and transport. Furthermore, a server of the service framework may dynamically load one or more runtimes that may be used to find and communicate with the service framework.
In other words, the service framework may decouple the client and server of the service framework from the transport and service discovery. The service framework may contain a default service discovery and/or transport implementation and/or multiple discovery mechanisms and/or multiple transport implementations.
In an implementation, the providing of the at least one module of a module stack and/or providing of the dependency data of the other modules of the module stack from the provided module may further include providing communication parameter data and/or system configuration data.
In an implementation, the at least one module may include program code for use in the application services, in particular C/C++, python, Java and/or HTTP.
Preferably, at least one module may be generated in C++, but the generating is not limited to that, any other common used program code may also be supported, such as Python and Java and/or HTTP REST.
A further aspect of the present disclosure relates to a system that is implemented as a server-client-structure for a service framework to develop application services, including:
Moreover, the client unit and the server unit may use different processes on different processors of a server unit, whereby the client unit and the server unit may be distant to each other, e.g., the client unit or the server unit may be in a vehicle and the client unit or the server unit may be in the cloud. Further, the client unit and the server unit may use different processes on the same processor unit of a server unit or the client unit and the server unit may use different processes and different processor units of a server unit or multiple server units. Furthermore, the client unit and the server unit may use different computational entities on the same processor unit of a server unit.
In an implementation, the system may further include a service stub unit, a service proxy unit, a dynamic runtime unit of the server unit and/or a broker unit of the server unit;
In other words, a service stub unit, preferably a specific service stub unit, and/or a service proxy unit, preferably a specific service proxy unit, may be used by every client of the service framework and/or by every server of the service framework. Further, the service stub unit and/or the service proxy unit may use the dynamically load data of the dynamic unit to generate one or more runtimes of the service framework.
Further, the service stub unit and/or the service proxy unit may be configured to connect/bridge the client unit and/or the server unit to an interface or an API of at least one runtime of the service framework so that the client unit and/or the server unit may communicate with the at least one runtime of the service framework.
A further aspect of the present disclosure relates to a computer program element with instructions, which, when executed on the at least one server and/or on the at least one client of a client-server-structure, is configured to carry out the steps of the herein disclosed method in a herein disclosed system.
A further aspect of the present disclosure relates to a computer readable storage/medium storing instructions of the herein disclosed computer program element.
In the following, the disclosure is described exemplarily with reference to the enclosed figures, in which:
Notably, the figures are merely schematic representations and serve only to illustrate examples of the present disclosure. Identical or equivalent elements are in principle provided with the same reference signs.
The server 100 includes a module stack unit 102 to provide at least one module 102.1 of the module stack unit 102 to the client unit 200. A first determining unit 103 to determine if the provided module has been modified by the client unit 200. A second determining unit 104 of the server unit 100 to determining dependency data, at least including information on the dependency of further modules of the module stack 102 from the provided module. As well as, a providing unit 105 of the server unit 100 to provide the dependency data of the other modules of the module stack unit 102 from the provided module. Further, the server 100 includes a service stub unit 101 and a dynamic runtime unit 106.
Thereby, data is transported between the client 200 and the server 100 and a service discovery is provided by the interface. However, these two functions are offered separately and decoupled from each other, so that several parallel transports are possible in parallel with service discovery.
Further, the broker unit 107 monitors the communication between the stub unit 101 and the proxy unit 201. Whereby, the broker unit 107 monitors the communication regarding the availability of the service framework based on the interface id, interface version and/or instance id to provide the availability of a service of the server to the client. Since this providing is decoupled from the actual data transport, allowing multiple parallel discovery of services in parallel with the transport.
Other variations to the disclosed example can be understood and effected by those skilled in the art in practicing the claimed subject matter, from the study of the drawings, the disclosure, and the dependent claims. In particular, respective parts/functions of the respective example described above may also be combined with each other. In the claims, the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. Any reference signs in the claims should not be construed as limiting the scope of the claims.
