Remote Method Invocation

Services in las2peer should reuse code and communicate with each other. This is done by method invocations.

The service may be executed on any node in the network, depending on availability of resources.

If you want to call the method with the current context's main agent as calling agent, use

Serializable Context.getCurrent().invoke("[email protected]", "myMethod", (int) param1, (String) param2, ...)

(in older versions than 0.6.1, you have to use Service.invokeServiceMethod())

The current service agent can also be used as executing entity to handle service-related requests (e.g. metadata):

Serializable Context.getCurrent().invokeInternally(String serviceIdentifier, String method, Serializable... parameters)

(in older versions than 0.6.1, you have to use Service.invokeInternally())

Do not use invokeInternally for user-related actions as this will bypass las2peer's permission system.

Specifying versions

The first parameter serviceIdentifier of the methods shown above allows to specify a service version to be invoked. Specifying a service version is recommended since a service A might change the API in a newer version and all services invoking service A may break.

Service versions have the format major.minor.sub-build where minor, sub and build are optional. When specifying a version, an appropriate version will be picked as follows: If version 1.0 is specified, all versions starting with 1.0 fit (e.g. 1.0.5-123, but not 1.1). las2peer tries to invoke the newest version that fits to the specified version, but this is not guaranteed as full knowledge of all services is not possible in a p2p network and other factors (e.g. node load, response time, ...) play a role in the service selection.

If no version has been specified (e.g. i5.las2peer.services.exampleService.ServiceClass), any version (= the newest possible version) is used. You should not assume that the newest version will be chosen in this case - especially if there exist many versions in the network.