...
| Code Block | ||||
|---|---|---|---|---|
| ||||
[celix/deploy/remote-services-cfg-client]$ export DISCOVERY_CFG_POLL_ENDPOINTS='http://localhost:9000/org.amdatu.remote.discovery.configured' [celix/deploy/remote-services-cfg-client]$ sh run.sh ... RSA: Import service org.apache.celix.calc.api.Calculator ... -> add 3 7 CALCULATOR_SHELL: Add: 3.000000 + 7.000000 = 10.000000 |
...
About proxies and endpoints
The Java runtime allows you to use introspection to determine what methods can or should be invoked. C, on the other hand, has no such facilities, and as such needs additional code to handle received method invocations (called an "endpoint") or to invoke remote methods (by using a "proxy"). For the calculator demo used in this example, the endpoint and proxy are already available and aligned with the Java code to make them work correctly. When creating new endpoints and/or proxies, you should consider the following:
- JSON is used as intermediary language for marshalling requests, meaning that subtle type differences (signed vs unsigned) get "lost" in translation;
- The RSA HTTP implementation of Amdatu only support primitive types, most of the Java collections and "simple" POJOs: all fields must have appropriate getters and setters and a default constructor must be present. The proxy and/or endpoint in Celix has no such limitation as it is hand-coded and can do all kinds of nifty stuff;
- Java supports exceptions, but in C there is no such concept (apart from using error result codes). Extra care needs to be given to handling exceptions;
- Java supports method/function overloading, but C does not (directly);
- Java strings are UTF-8 encoded by default, in C strings are just a series of characters: define a standard encoding and use this consistently.
Source code and other artifacts
...