Core schema and its use in services about exonum HOT 4 OPEN

The code like

pub fn execute(&self, context: &ExecutionContext) {
    // narrow() notation is taken from CORBA
    let service = context.get_service(CoreService::SERVICE_ID).narrow<CoreService>();
    let validators = service.get_validators(context);
}

is fragile and depends on constants like SERVICE_ID. In my humble opinion we needs something like rtti then for each Service associates its own service_id.
It is also suggests that each service has only single instance in blockchain:

pub fn execute(&self, context: &ExecutionContext) {
    let schema = context.create_schema::<Core>();
    let anchoring_schema = context.create_schema::<AnchoringService>();
    let globals = context.get_current_globals::<AnchoringService>();
    let following_globals = context.get_following_globals::<AnchoringService>();
}

from exonum.

@alekseysidorov By SERVICE_ID I did not mean an integer ID, but rather a vendor-provided GUID of the service (like, say, qualified package names work in Java; or resource naming in JNDI). But of course, something like

let core = context.get_service::<Core>();

would work too, if its implementable.

In your code, there is this notion of schemas again (including external ones). I don't quite get why they are there; it seems (at least to me) that accessing getter methods of services may do a better job, at least from the separation of concerns perspective and encapsulation. For example, one can imagine a case in which a getter method returns a constant value (i.e., does not access blockchain), or performs some manipulations with blockchain data before returning, etc.

Are schemas accessed explicitly for performance reasons? Note that even if we're talking about accessing a local schema, it could be hidden from the service developers by using something like

impl AnchoringService {
    // could be generated automatically as a service skeleton
    pub fn get_fee(&self) -> u64 {
        // Execution context is injected into the service during transaction execution
        AnchoringSchema::new(self.execution_context.view)
               .get_actual_configuration().get_fee()
    }
}

impl MsgAnchoringSignature {
    pub fn execute(&self, service: &AnchoringService) {
        let fee = service.get_fee();
        // ...
    }
}

from exonum.

Transaction execution is one of the most resource intensive tasks. I want to use abstractions with zero or close to it cost.
For example, comparison of guids slower than of numbers.
Construction of schema may be not zero cost, and I want to reduce this cost.
But I like the idea of separating schema into low-level interface with data tables and high-level interface with some getters and setters.

struct AnchoringBlockchain<'a> {
    schema: &'a AnchoringSchema
}

impl AnchoringBlockchainInterface
{
    pub fn get_fee(&self) -> u32 {
        schema.get_actual_configuration().get_fee()
    }
}

...

let iface = context.create_interface::<AnchoringBlockchainInterface>();
let fee = iface.get_fee();

from exonum.

Got it; I am proponent of clarity of code at the expense of speed (in reasonable margins) - that's probably why I'm not an expert Rust coder :) But I understand that the speed matters too. As for comparisons of guids specifically, an external service (stub) may be injected (using the guid) into the service a single time when the service is created, so this shouldn't probably be a problem. Probably.

from exonum.