Verivo Akula’s Architecture Provides Flexible Options and Powerful Controls.

Verivo Akula consists of four main components:

  • The Akula server
  • Idiomatic client libraries/SDKs for each operating system platform or IDE
  • Server SDK
  • Management APIs

See details of each component below.

Akula Server

The Akula server lies at the heart of Akula’s platform. It provides a mechanism for companies to incorporate data access, authentication, role-based authorization, monitoring and usage information into their apps. Companies define mobile services (via REST endpoints) that make data and transactions available to the mobile client apps. These services can be configured to easily interact with various back-end systems like relational databases, web services, 3rd-party products like Siebel and Salesforce, or even proprietary data structures. By using the Server SDK, companies can embed custom business logic and any custom server-based processing the business needs.

While apps built with the Akula client SDKs are the most likely consumers of the services exposed by the server, services are available to any system that would like to use them and can include a variety of browsers and custom-built clients.

Internally, Akula’s server leverages several open and well-adopted frameworks including Apache Camel for data routing and Apache Shiro for security. Akula was built on Java EE 7 and runs in a variety of servlet containers like Tomcat and JBoss. As such, the Akula Server can be deployed on any Microsoft Windows, Linux, UNIX, or OS X server that supports Java EE 7. The Akula server can be installed on-premise or hosted, and it can be deployed virtually and in various high-availability configurations.

The Akula server makes it possible to connect to a variety of back-end and Internet-based systems via popular transport protocols including HTTP(S), REST, JMS, LDAP, JDBC and various web services. Akula provides connector modules for popular back-end systems like Oracle, SQL Server, MySQL and others. However Akula’s extensibility makes it possible for developers to leverage the Akula server SDK to connect to virtually any data source.

The Akula server is also typically configured to connect to one or more corporate Identity Management systems, such as Active Directory or Siteminder. The Akula Server leverages these connections to obtain user and group information, which does not need to be stored in the Akula system. Authorization definitions and assignments for the services exposed by the server can be based on users and groups stored in these Identity Management systems, allowing for simplified user and permissioning management.

Client SDKs

The Akula client SDKs offer iOS, Android and JavaScript developers common infrastructure on which to build their apps. The SDKs automatically handle some of the most complex aspects of development, like handling data storage, incremental sync, data encryption, log in, eventing), and more. The client SDKs follow the conventions and standards of their respective platforms, yet provide a consistent cross-platform programming model, so developers will be productive immediately. And, because Akula is based on open standards, companies have the freedom to choose their development framework. You might choose to build one app natively on iOS, a second app in Appcelerator, and a 3rd app as a hybrid using PhoneGap.

Components of the Akula client SDKs include:

  • Reliable, reusable infrastructure needed for most enterprise apps
  • Secure communications
  • Secure data storage
  • Encryption of local data
  • Offline login/logoff
  • Cross-Platform Collection/Model APIs
  • Incremental data sync for secure offline data usage
  • APIs
  • Eventing
  • Managed properties

Client apps communicate with the Akula server over HTTP(S). While any type of client can make direct requests to the endpoints on the Akula server, most developers will leverage the Akula client SDKs, which bundle many high-value pieces of functionality and structure into iOS, Android and JavaScript libraries.

Server SDK

The Akula server SDK provides tremendous extensibility. The SDK, which is Java-based, allows a wide variety of custom business logic or integration capabilities. Specialized SDK’s support the development of:

  • Custom connectors to Identity Management systems
  • Custom connectors to back-end corporate or internet-based systems
  • Custom business logic to handle synchronization conflicts
  • Custom processing of data, whether from the mobile device or back-end systems

The Akula server SDK allows enterprises to use standard Enterprise Integration Patterns (EIP) to build modules that extend the capabilities of the server. Built upon Apache Camel, a well-known and tested open-source Java framework, developers can incorporate integration logic into their apps. Acting as an execution engine, the server will process each modular custom block of code while managing the passing of data between processes.

Management Tools and APIs

The Akula management tools provide a mechanism to exercise oversight and control over the behavior of Akula-based mobile apps. These controls include the ability to set up the app environment and security by defining roles and permissions, and the ability to view and change values for server and app properties that change the app’s settings.

Akula’s management capabilities provide control over:

  • Role-based authorization of mobile users
  • Role-based authorization of administrators
  • Delegation of certain management to business owners
  • Deployment and updates of app services on the server
  • Centrally management of app properties (e.g. connection parameters, CORS whitelist, etc.)
  • Session management
  • License management

All management tool functions are also available through a well-defined set of Management Services. These are a set of APIs published by the Akula server as a set of REST endpoints which are still subject the Akula server’s Authentication, Authorization and Audit Trail capabilities. Because server management tools are implemented using these managements services, companies can either build their own custom tools or integrate with an existing platform such as Microsoft’s SCOM, IBM’s Tivoli and others.

The server has also been designed to cleanly separate the app services code from the environment it operates in. Environment components include:

  • The Identity Management system(s) being utilized
  • App Service Permissions
  • The specific back-end systems being connected to
  • App and Server Properties

Development, QA, Staging and Production environments can be set up in advance, each pointing to different backend systems, user databases and app settings. This separation helps ensure that, when services are promoted into production, all the environments in which those services will run remain consist and stable, reducing the chance of go-live and upgrade problems and failures.