Write Chat APIs in Java: Phase 1

We need to develop an abstract chat service (as an application server) for the students of an online university in Java using QuickBlox APIs. The requirement is to provide front-end clients (mobile, web) with connectivity to back-end services including messaging/chat, classrooms, training content, etc. To enable this, an intermediate "common API" layer will be developed to allow any and all front-end clients to access the business functions provided by the back-end. The "common chat API" layer will provide a level of abstraction between the front-end and the back-end, so that each of the front-end clients (desktop, web and mobile) will not need to invoke separate/different APIs to use business services provided by the back-end. There will be no need for enterprise-level scalability at this stage, since there are expected to be no more than 300 users, totaling no more than 35,000 transactions every day. The layered architecture combined with the P2P connectivity between layers will be enough to allow the solution to scale to the expected load and greater (up to 1 million transactions). At the back-end, the QuickBlox messaging server will provide chat, messaging, video and audio exchange services, which are expected to face the heaviest load. The application server that we develop will provide traditional user management, application administration, configuration, security and analytics services. These 2 servers will remain in sync, where the synchronization will be driven by the application server, which will also be the "source of truth" or the master data repository. The intermediate or abstraction APIs will be written in Java, and will support REST-JSON APIs. The APIs will be secure so that unauthorized apps will not be able to access them. Both the invocations and the transport will be secure - SSL based. The APIs will not implement comprehensive business functions; instead, they will be "wrappers" or "shells" around the functions provided by the back-end servers. While the Java-based REST APIs appear to be "physically" separate from the servers, in reality, they will be served by the back-end application server. The chat/messaging services will be provided (outsourced) to a 3rd party service called QuickBlox. QuickBlox is a robust, industry standard messaging/chat/IM server that is used by several client chat applications worldwide. It is cloud-based and highly scalable. QuickBlox exposes its functions as secure REST APIs which will be used/invoked both by the Java API layer and the application server. The application server, which needs to provide user management, content/training and user administration, analytics and solution behavior (configuration)will be provided by the skeleton of an industry-standard, open source tool called Canvas. Canvas natively provides classrooms, courses, tests, groups and certification, that are stored in its internal database. The development will de divided into phases, each phase of no more than 40 hours each. Freelancers must work and will be paid in phases.