Naming convention inside the Af-Arch

Introduction

This document describes actual naming schema used inside the Af-Arch platform. This is considered standard and should not be avoided. Naming convention is a really important issue.

Server Naming

Because Af-Arch is a distribuited software platform, it is posible to figure out where is going to be located a server component. This means that Af-Arch programmer doesn't use machine real names or IP addresses to refer actual Af-Arch server nodes location. They use a Server Logical Name to refer to which is resolved at runtime executing.

This runtime name resolving is based on a host location table run and maintained by Af-Arch central server: af-kernel.

This host location table, among other things, is a 3-tuple data containing the Server Logical Name, the IP address or internet host name and a TCP/IP port.

Server naming should follow the next considerations:

Valid server names are:

Services name convention

Service name have the following schema:

     server_name::server_module::service_name

Where:

This naming convention allows to find and execute a service by only knowing the service full name because it contains the logical server naming hosting the service.

You should use action names only on service part. If you use action names on module or server names you will get ugly interfaces for client STUB connectors. Think about naming a module as get_list. Now, inside the module we have a service called get_list. Result full service name will be:

    // logical service name
    my_server::get_list::get_list

    // c interface
    afdal_my_server_get_list_get_list (..)

    // c# interface
    class GetList {
           AfDalList GetList (..)
    }

Naming convention enforced politics

Actually, Af-Gen tool enforces described politics, but server naming and service naming keeps on the Af-Arch programmer selection.

Try to use self describing names which will produce better interfaces and more maintainable code.