Af-Arch Framework features

Here is a complete list of features supported by Af-Arch

Here is a list of features supported, which may show you if Af-Arch can help you on building your distribuited application:

Remote services invocation

Af-Arch allows you to invoke services running on a remote server avoiding you to write socket, buffer handling and more error prone code, needed to communicate a message to a remote node. Server location is handled by the framework making your code easy to write and maintainable.

Here is an example on how to get the list of users already created:

         AfDalAfKernelAfUser * a_user;
         gint                       i;

         // initilize Af-Arch framework
         afdal_init ();
 
         // log in inside the Af-Arch. Af-kernel central server
         // is located at: host barbol:55000
         AfDalNulData * login_response = afdal_sync_session_login ("aspl", "test",
                                                                   "barbol", "55000");
         if (AFDAL_IS_ERROR (login_response)) {
               g_print ("Login failed, error was: %s\n", 
                        AFDAL_RESPONSE (login_response));
               afdal_nul_free (login_response);
               return;
         }
         afdal_nul_free (login_response);

  
         // get Af-Arch users list
         AfDalList * users = afdal_af_kernel_af_user_list_sync (0, 0); 
         if (AFDAL_IS_ERROR (users)) {
               g_print ("Unable to get actual user list, error was: %s\n",
                        AFDAL_RESPONSE (users));
               return;
         }
        
         // iterate over all users created
         for (i = 0; i < afdal_list_length (users); afdal_list_next (users)) {
               // Get a reference to a well-defined Gobject structure
               a_user = afdal_list_data (users);
               g_print ("#%d: login=%s description=%s\n", 
                         a_user->id, a_user->nick, a_user->description);
         }

         // free user list
         afdal_list_destroy (users);

Support both invocation models: Synchronous and Asynchronous

As oposed to other middle-ware environment, Af-Arch default service invocation method is Asynchronous. This means, your code can keep on doing other computational work while request is sent and response is received and processed.

This is particular useful while programming client applications using a Graphical User interface. Application can keep on updating its interface, implement a status bar or making several petitions at the same time.

User space code is notified through a callback which is provided at request time. Here is an example about requesting Af-Arch users using Asynchronous method invocation:

       // my callback which will be invoked when request answer is received
       gboolean my_callback (AfDalList * users, gpointer user_data) {

           // check request status
           if (AFDAL_IS_ERROR (users)) {
                 g_print ("Unable to get actual user list, error was: %s\n",
                          AFDAL_RESPONSE (users));
                 return;
           }
            

           // iterate over all users created
           for (i = 0; i < afdal_list_length (users); afdal_list_next (users)) {
                 // Get a reference to a well-defined Gobject structure
                 a_user = afdal_list_data (users);
                 g_print ("#%d: login=%s description=%s\n", 
                           a_user->id, a_user->nick, a_user->description);
           }

           // free user list
           afdal_list_destroy (users);
           return TRUE;
       }
 
       // request code
       void my_request () {
             // we have already logged in
 
             // request user list
             if (afdal_af_kernel_af_user_list (0, 0, my_callback, NULL)) {
                   g_print ("Unable to perform request.\n");
                   return;
             }
            
             // request doesn't blocks caller, applications keeps on
             // running
             return;
       }

Transparent services and servers location

Af-Arch provides mechanisms to transparently bind request at runtime with the appropiate service and server.

User space code is written with no knowledge about where are services and servers executing, making user code maintainable and easy to be produced.

Af-Arch provides a runtime host location service and a runtime remote service binding through the central server Af-Kernel which is transparent, and need no user especial code to be activated or used. Af-Arch care about this.

There are only two data which have to be know by Af-Arch clients: host and TCP port where is running Af-Kernel central server.

Native support for users and groups

Af-Arch framework, as oposed to most middle-ware products, provided native support for users and groups using and executing services across the environment.

Af-Arch developer will no need to implement more users and group stuff for each project. Af-Arch users and groups are integrated into the security and service execution, allowing to program services at server side without paying attention to which users and groups will be able to execute them.

Af-Arch users and groups service permissions are handled by Af-Key tickets. This elements allows to have a decoupled security model making Af-Kernel central server to generate Af-Key tickets which are used by the rest of Af-Arch nodes to validate users requests.

This decoupled model works pretty much like Kerberos security access. Af-Kernel and the rest of Af-Arch server nodes do not need to communicate each others for every service executed by users. Af-Arch server nodes uses generated Af-Key tickets.

Af-Arch groups enable to configure execution level profiles for a set of users making it easy to manage users execution profiles because users inherits groups permissions.

Native users and groups permissions

Once a server is developed, it is registered against the central Af-Kernel server. As part of the register process, Af-Arch server node provides services actually exported. This services exported are used as the very basic atom element for Af-Arch security model.

Each service exported is actually a permissions. This gives higher level to control which services can be executed by users and groups.

Both client and server code developed do not need to pay attention to service execution permission. Using a tool such as aspl-clm, administrators can configure permission for each users and groups.

Af-Arch permissions set to groups are inherited by users inside them, allowing to create a set of groups to implement users security profiles.

Af-Arch permission can be associated each others making posible to implement permissions cascading association when a permission is set.

Native users session

Af-Arch provides a mechanism to make users session to expire using actual timestamps inside the Af-Keys tickets. It is also provided an interface to refresh current session.

Session are controled from server nodes, allowing to configure if they are activated, or to set how long a session is.

Bindings support to other languages

Af-Arch is being built keeping in mind that it has to be easy to build Af-Arch bindings to other languages.

Currently there are fully support to C and C# to develop client application.

Cross-platform development

Af-Arch client platform is actually running on Microsoft Windows platforms and GNU/Linux.

Server side components only runs on GNU/Linux server side.

Af-Arch also comes with an IDL compiler (with some useful features)

As every middle-ware platform Af-Arch provides an IDL compiler which allows to define services exported by servers. This IDL compiler is af-gen tool. Here is a server interface definition example:

     server interface af-contact {
             
         // type definition using implicit id as index
         type addresses is data (string address, string city,
                                  string postal_code) index (id);
                 
         // module definition with three services
         module address () {
             // list all address created
             public get_list (int initial, int max_row_number) return addresses;
 
             // create a new address
             public create (string address, string city, string postal_code) return simple;
 
             // remove the given address
             public remove (int id) return nul;

         }
         
         // also generate synchronous interface
         sync interface address;
    }

But, af-gen also allows you to integrate your code inside the idl defintion, making more easy to keep synchronized user code generated with IDL definition:

     server interface af-contact {
             
         // type definition using implicit id as index
         type addresses is data (string address, string city,
                                  string postal_code) index (id);
                 
         // module definition with three services
         module address () {
             // list all address created
             public get_list (int initial, int max_row_number) return addresses {
                    CoyoteDataSet * result; 

                    // make database request
                    result = afgs_command_execute_single_query ("SELECT * FROM address");

                    // check result
                    if (!result)  {
                         AFGS_ERROR ("Error while getting addresses", COYOTE_CODE_ERROR);
                         return FALSE;
                    }
 
                    AFGS_OK ("Addreses available", COYOTE_CODE_OK, result);
                    return TRUE;
             }
 
             // create a new address
             public create (string address, string city, string postal_code) return nul {
                    gboolean result;

                    #define QUERY "INSERT INTO address (address, city, postal_code) VALUES ('%s', '%s', '%s')"

                    result = afgs_command_execute_non_query (QUERY, address, city, postal_code);
                    // check result
                    if (!result)  {
                         AFGS_ERROR ("Error while creating the address", COYOTE_CODE_ERROR);
                         return FALSE;
                    }
 
                    AFGS_OK ("Address created", COYOTE_CODE_OK, NULL);
                    return TRUE;
             }
 
             // remove the given address
             public remove (int id) return nul {
                    gboolean result;

                    #define QUERY "DELETE FROM address WHERE id = '%s'"

                    result = afgs_command_execute_non_query (QUERY, id);
                    // check result
                    if (!result)  {
                         AFGS_ERROR ("Error while creating the address", COYOTE_CODE_ERROR);
                         return FALSE;
                    }
 
                    AFGS_OK ("Address deleted", COYOTE_CODE_OK, NULL);
                    return TRUE;
             }
         }
         
         // also generate synchronous interface
         sync interface address;
    }

But af-gen goes furthermore ahead with its capabilities to create implicit definitions due to module definitions and relations set between them.

Automatic services definition

af-gen also supports to not only to create the service skeleton but also provides common used services already complated such as: new, edit, remove, list...and much more. Here is an example:
   server interface af-contact {
                             
         // relation definition
         relation located;     
                          
         // module definition for addresses
         module address (string address, 
                         string city, 
                         string postal_code) implicit definition {
                address located identity with 0..n;                                            
         }                                         
          
         // enum definition
         enum IdentityType {organization, friend, people};
                                                          
         // module definition for identities              
         module identity (string name, 
                          string description, 
                          enum IdentityType identity_type) implicit definition {
               identity located address with 0..n;                                                               
         }                                        
          
         // also generate synchronous interface
         sync interface address, identity;     
   }

Automatic SQL database definition

af-gen creates for you the database schema needed to support services defined by implicit operators.

Automatic autoconf support

Products generated by af-gen are created with fully support for autoconf files. To compile your STUB client connectors and your servers you only will have to type:
         ./autogen.sh
         make
         make install

Af-Arch comes with a command-line administration tool: aspl-clm

This tool allows to manage users and groups, permissions installed and server locations. aspl-clm support regular expressions to manage permissions making more easy to set or unset a set of permission following a pattern. Auto-completion is also supported for commands and data required while requesting operations.

Platform license allows Open Source and commercial (closed source) developments

Af-Arch license schema is designed to allow both development models. If you develop a closed source application, you will not need to pay a license development cost, royalty or any fee.

We encourage you to follow the development model you wish. There is no going to be any distintion on helping projects developing Open Source application or Commercial ones. Both are wellcome.

Of course, we will appreciate earing you mentioning Af-Arch framework from your project.