1. Application Packaging Standard Fundamentals
Introduction to APS
Application Packaging Standard (APS) was developed for Hosting Platforms to unify management of numerous cloud applications. Instead of adding a hard-coded plugin for each application to Hosting Platforms, APS allows application developers or their partners to integrate their applications with Hosting Platforms themselves.

2. Agenda Place and Role of APS in Hosting Platform Requirements to APS
APS Solutions
In this introductory document, we’ll consider the following topics:
Introduction to the place and role of APS in a Hosting Platform will identifies our expectations on APS.
Requirements to APS section defines the requirements the APS must meet to achieve the stated goals.
Finally, we’ll consider the APS solutions that cover the requirements.

3. APS Role in Hosting Platform
APS in Hosting Platform
APS Goals
In this section, we’ll identify the place, the role, the goals of APS in a Hosting Platform.

4. APS in Hosting Platform
VISA
BANK X
MasterCard
External System #N
VISA
Payment system - 1
BANK X Plugin
Payment Plugin #N …
APS Applications
O365
Online Store(s)
Billing
BSS
OSS
O365
Plugin
Hyper-V Cloud
Hyper-V Plugin
End-Users
SMBs …
Provisioning Plugin #N
Generally, an automated Hosting System consists of the following parts:
Sales Front-end implemented by means of Online Store, Sales Persons, and any affiliated partners. The goal here is to attract end-users and SMBs interested in getting hosted products, such as Office 365 and Hyper-V, and help them in their choice of the needed products and product parameters.
Business Support System (BSS) is a central engine in the automated system. Its workflow management system initiates payment, provisioning, billing, and other processes in a cycle.
Operations Support System (OSS) provisions the ordered services by means of internal and external hosts.
APS plays important role of integrating OSS with numerous applications adapting application native APIs to the standard interface used by APS.
In a Hosting System, APS is implemented by a special program component – APS controller.
Workflow
External System #N
Sales Person(s)

5. APS Purpose
REST API
Application
Hosting Platform
Provisioning Logic
Application
native API
View
Presentation Logic
Application native UI
View
View
View
APS defines a standard way to expose services of applications to the Hosting Platform. It’s a “bridge” or “adapter” between application UI and management UI on the Hosting Platform.
Being placed between the Hosting Platform and an Application, APS performs two integration operations:
It defines a standard way to expose services of applications to the Hosting Platform.
It’s a “bridge” or “adapter” between application UI and management UI on the Hosting Platform.

6. Requirements to APS API Adaptation
Resource Provisioning and Management
Resource Presentation
Communication
Integration Package
Once the APS goals are identified, let us consider the requirements that APS must meet.
How to adapt Hosting Platforms to various APIs?
How to provision and manage Application resources through APS?
How to present Application resources?
How the communication between internal and external parts will be arranged?
How an APS integration solution for an application will be presented for deployment?

7. API Adaptation How to adapt OSS to numerous “native” APIs? OSS
McAfee
API
McAfee UI
OSS
Resources
How to adapt OSS to numerous “native” APIs?
Provisioning application resources
Managing application resources
Symantec
API
Symantec UI
Resources
O365
API
Answer
O365 UI
APS endpoint for each application
Resources
Many services:
each with its own API and UI
Let’s get started with the first requirement.
A Hosting Platform must be adapted to numerous native APIs.
The question is – How to adapt OSS systems to numerous “native” APIs in order to perform two main operations with resources in a standardized way?:
Provisioning application resources
And managing them.
The answer to such questions - is setting an APS endpoint for each application that will be a bridge between the internal operations in the Hosting Platform and the “native” API.

8. Resource Provisioning and Management
McAfee
API
McAfee UI
OSS
Resources
How to manage and track application resource properties and states?
Sync resource creation
Represent “native” resources
Symantec
API
Symantec UI
Resources
O365
API
Answer
O365 UI
Unified Resource Management model
Resources
Many services:
each with its own API and UI
In Hosting Systems, a Resource represents a service available for a resource consumer. Disk space, virtual server, mail box, or the whole mail organization are examples of resources.
Resources created and managed in Applications, must be also somehow represented for the Hosting Platform in a unified way.
The question is – How to manage resource properties and states on both sides synchronously and how to represent application resources in the Hosting Platform?
The answer to this and related questions - is using a Unified Resource Management model that allows declaration of resource schemas for each application.

9. Resource Presentation
McAfee
API
McAfee UI
Resources
Symantec
API
How to present resource management tools in UI?
Symantec UI
Resources
Provider admins:
configure applications
SMB admins:
configure resources for end-users
End-Users:
configure own resources
Answer
O365
API
O365 UI
APS UI for each application
Resources
Many services:
each with its own API and UI
As you know, each application has own set of resources and own specifics of managing them through different User Interface tools.
In a Hosting Platform, there different types of control panels used by the provider personnel, customer staff, and end-users.
The question is - How to represent the resource management tools in control panels of the Hosting Platforms?
The evident answer is – using customized APS User Interface for each application.

10. Communication OSS How to unify communications? Answer
McAfee
API
McAfee UI
OSS
Endpoint-1
Symantec
API
How to unify communications?
Endpoint-2
Symantec UI
Endpoint-3
Web Browser
Answer
O365
API
O365 UI
Standard application protocol
Many services:
each with its own API and UI
As stated earlier, for integrating Hosting Platforms with numerous applications, we need to have an APS application endpoint for each application. This increases the number of links inside the platform.
The question is – How to unify the communications in the system?
The answer is – Using a standard application protocol. It means, the Hosting Platform, User browsers, and endpoints are communicating by using the same language.

11. How to pack all the above integration stuff and deploy it in OSS?
Integration Package
How to pack all the above integration stuff and deploy it in OSS?
Answer
APS Package
By analyzing the previous requests, we clarified that the integration process requires deploying a number of parts into a Hosting Platform for each application.
-> The questions is – How to present the integration solutions for each application in a compact way?
-> The answer is – using an APS package that comprises all integration components of an application. Hosting Platforms must use a special program module, called APS Controller, to manage the deployment and provisioning of applications.

12. APS Solutions Unified Communication and APS Endpoints Resource Model
Service Declaration
APS UI
Package Contents
In this section, we’ll overview the main APS solutions following up the requirements raised in the previous section.
We’ll start with the APS communication infrastructure including the protocol and APS endpoints.
And proceed to the explanation of the Resource Model used in APS.
The next topic concerns declaration of services and their relation with APS resources.
The APS UI topic will overview the APS approach to creating custom UI in control panels of a Hosting Platform.
Finally, we’ll overview the contents of an APS package.

13. Unified Communication and APS Endpoints
McAfee
API
Hosting Platform
McAfee UI
APS Controller
APS McAfee
Endpoint
Symantec
API
APS
Symantec Endpoint
Symantec UI
REST
POST Create
GET Read
PUT Update
DELETE - Delete
Web Browser
APS
O365
Endpoint
O365
API
O365 UI
Hosting platform and numerous applications is the main focus in the communication infrastructure we are going to consider. Also, we add here web browsers providing User Interface. APS application endpoints must work as front-end of the applications.
APS controller is the central point in this communication schema. It is able to communicate with each of the other participants by sending REST requests. Therefore, each of the participant must expose their REST access point.
APS controller, in turn, exposes its own REST access point to receive REST requests from the communicating participants.
Pay attention to the following two aspects of REST requests as used by APS:
First, it presents resource parameters using the JSON schema.
Second, a REST request can contain one of the CRUD operation:
POST – to create a resource or request a custom operation
GET – to read a list of resources or resource properties, or request a custom operation
PUT – to update resource properties
DELETE – to delete a resource
CRUD operations

14. Resource Model APS Controller POST /vpses { “name”:“vps-1”, … }
“type”:”vps”,
APS Controller
APS
Application Endpoint:
/storages (type “storage”)
Native API:
create “vps-1”
Web Browser
APS
resources
APS
Application Endpoint:
/vpses ( )
Application
APS types
“type”:”vps”
Resources:
VPSes
POST /aps/resources/ {
“name”:“vps-1”, … }
APS
Application Endpoint:
/mboxes (type “mbox”)
“type”:”vps”,
Let us consider the communication on a simple example.
Suppose, a cloud application can provision Virtual Private Servers (VPSes).
To synchronize and track resource usage, APS controller needs to have the resource schema stored as an APS type in the database. The *vps* type in our example is used to create APS resources representing VPSes.
To create a VPS, the customer’s administrator will use the APS UI to send a POST request specifying all necessary parameters in a JSON object.
APS controller parses the request and performs the following:
It identifies the resource type to create a new APS resource. In this scenario, the type is “vps”.
APS controller identifies the application service that is responsible for the resources of type “vps”. In our example, it is the “vpses” service available on one of APS application endpoints.
APS controller sends the REST request for creating a VPS to the endpoint.
Once the REST request is received, the APS application endpoint will convert the request to the native API call. It causes the application to create the necessary VPS.

15. APS Type – JSON Schema schemas/vpses.schema General section
“apsVersion”: “2.0”,
“name”: “vps”,
“id”: "
General section
“implements”: [" ],
"properties": {
"name": {...},
"description": {...},
...
"memoryusage": {...} },
Resource structure
“operations": {
"start": {
"verb": "GET",
"path": “/start",
... },
"stop": {...} }
Custom operations
As follows from the previous example, APS controller needs to have a resource schema (known as Type in APS) to manage application resources.
In APS, each type must be processed by a dedicated service exposed on the APS application endpoint.
An APS type is defined in a schema file, which contains the following sections:
The *General* section declares the APS version, the name of the type, the unique type ID, and other general parameters of the type.
APS types can implement (inherit) other types and, particularly, the core types declared by APS. Special attention in the *General* section requires the “implements” string. It declares an array of APS types inherited by the type we consider now. In our example, the type implements the APS core type, called *resource*.
The *Properties* section declares all possible resource properties, no matter optional or required. For example, when creating a VPS, you need to specify the VPS name, limit on disk space, and other technical parameters.
The *Operations* section must declare all custom operations exposed by the APS application endpoint. For example, the “start” and “stop” operations are needed to bring a VPS into a required state.

16. Classification of Resources
Provider
Customer
/vpscloud/cloud
/vpscloud/context
App
/vpscloud/offer
/vpscloud/vps
To manage resources, APS provides a separate management environment for each account.
The Provider works in own environment for managing global resources.
A Customer works in own environment for managing own resources available from a subscription.
For each deployed APS application, the Provider always creates the application root resource that represents the application instance.
The subscription normally allows the customer to work in their own environment by means of the *context* resource. Actually, in different implementations, the resource can be called differently.
The customer may have a number of other resources, e.g. VPS resources, that the customer staff can manage and provide to end-users.
In addition to the Application resource, the Provider can also create other global resources that can be used by all subscribers. For example, the Provider can create reference resources, called *Offers*, to propose various VPS configurations to customers.

17. Resource Relations Provider Customer /vpscloud/cloud /vpscloud/context
account
account
/vpscloud/cloud
contexts
cloud
/vpscloud/context
app
subscription
subscription
vpses
context
/vpscloud/vps
Often, APS resources must be bound to each other by means of APS links.
In the diagram, the customer’s *context* must be linked with the application root resource. Generally, all resources of an application must be bound directly or indirectly with the application root resource.
Possible links of resources are declared in the APS Type by means of relations. A relation has own name and describes the links by two attributes:
The *required* attribute defines if the link must be created just during the process of creation of a new resource. In the diagram, a *required* link is represented by the red rectangle. The optional links are represented by the blue rectangles.
The *collection* attribute defines if a resource may have more than one links based on the same relation. In the diagram, each link *collection* is represented by multiple blue rectangles.
The context also is linked with the *account* and *subscription* resources. Due to the links, the application can get needed data from the linked resources.
At last, when a VPS is created, it is linked with the customer context. For example, each *VPS* must have a single link, called “context”. The customer’s *context* may have multiple links, called “vpses”.

18. Resource Type – Declaration of Relations
schemas/vpses.schema
“apsVersion”: “2.0”,
“name”: “vps”,
“id”: "
“implements”: [" ],
"properties": {
... },
“operations": {
... }
“relations": {
"context": {
"type": "
"required": true,
"collection": false }
Relations
Earlier, we considered three sections in the resource schema. The “relations” is one more section needed to declare all possible relations of resources based on this type.
In the example, the declaration of a relation for the “vps” Type contains the following attributes:
Unique *name* is “context”.
*Type* defines the type of resources that this relation will bind with a VPS.
The *“required”=true* attribute makes the link mandatory for each VPS. Important to emphasize that due to this setting, a VPS neither appears, nor exists without the link.
The *“collection”=false* attribute makes the link singular, meaning each VPS must have only one link.

19. Service Declaration APP-META.xml
Listening on the APS endpoint “/vpses/” path
Binding with JSON schema
<service id="vpses">
<schema path="schemas/vpses.schema"/>
<presentation>
<name>Virtual Private Server</name>
<summary>Cloud VPS</summary>
</presentation>
</service>
As you already know, each APS type must be processed by a dedicated service. Actually, a service is a *resource factory*, as it performs all operations with resources based on a certain type. APS controller must be aware of the binding between a resource type and a service.
Such a binding is specified in the service declaration inside the APP-META.xml file.
In the sample declaration, The “vpses” service ID means, the service must be exposed by the APS application endpoint on the “.../vpses” relative path.
The service must process resources of the type defined in the *vpses.schema* file.

20. APS UI – Integration with Control Panel
Navigation Components
<navigation> plugged into
"
<item> plugged into <navigation>
<view> of the <item>
APS allows creating custom UI that can be plugged into different types of control panels (CP), such as provider CP and customer CP. Each type of CP has own socket to which the APS custom UI navigation tree can be plugged.
In the example, the navigation tree *VPS Management* is plugged into the customer CP as specified by the <navigation> element. At the top level, two navigation items, *Servers* and *Network* are presented by the corresponding tabs.
A navigation item may have one ore more *view* components. Each *view* is implemented by an HTML file. In the example, the *Servers* item contains a *view* that displays a list of VPSes and the toolbar for managing them.
controls inside view
HTML file

21. APS UI – Navigation Diagram
VPS Management
Servers
Network
View “servers”
servers.html
New
Step-1
IP Addresses
Firewall
Start
Step-2
View “ip-addresses”
View “firewall”
Stop
ip-addresses.html
firewall.html
Delete
View “server.new-1”
View “server.new-last”
APS UI can be represented by a navigation tree similar to this diagram. It contains a number of navigation items: Servers, Network, IP Addresses, and Firewall.
The diagram also specifies *views* in each navigation item and the HTML files implementing the views.
For example, the *Servers* item contains several views:
The “servers” view displays a list of servers and provides the toolbar widgets.
Since creation of a VPS, started from the “servers” view, may require more than one step, a separate view is declared for each step, e.g. “server.new-1” view is used at the first step.
The same way, the other views are implemented.
server.new-1.html
server.new-last.html

22. Navigation Tree Declaration
<navigation id="ccp" label="VPS Management"> <var name="context" type-id=" <plugs-to id=" <item id="servers" label="Servers"> ... </item> <item id="network" label="Network”> <item id=“network-ip” label=“IP Addresses”> … <item id=“network-firewall” label=“Firewall”> </navigation>
Once the navigation tree is clearly outlined, it must be defined in the package metadata. It is possible to declare a few navigation trees, one per a control panel.
In this example, a navigation tree labeled as “VPS Management” is defined for the customer CP as specified by the <plugs-to> element.
It declares two top level items, “Servers” and “Network”.
Under the “Network” item, the “IP Addresses” and “Firewall” items are declared.
Inside a navigation item, the views must be specified, but such details are not presented in this excerpt.

23. Package Contents Metadata: Schema of APS resources: PHP scripts:
Application and package general data
Application services
Presentation
Schema of APS resources:
Source code is in PHP scripts
Generated by aps build utility
PHP scripts:
For each service defined in metadata
Business logic
Source code for generating schemas
Custom UI scripts
We observed the provisioning and presentation logic along with their declaration in metadata. Now, all these parts of an APS solution for an application must be collected in a single APS package, which structure is presented here.
*APP-META.xml* is the key file of an APS package. It declares the general parameters of the application and package itself. Also, it contains declaration of provisioning scripts, resource schemas, and binding between them. Inside the file, the UI navigation trees are defined.
Each service declared in metadata, must be defined in provisioning scripts. In the example, the provisioning logic is implemented by the PHP scripts.
There are two ways of creating resource schemas. One way is to create the schema files directly, manually. The other way is to declare the resource schema in the file where the corresponding service is defined, and then generate the schema file from it. This is possible if you use the APS PHP runtime library. In the example, the types were declared in the PHP scripts. The schema files, e.g. *clouds.schema.gen*, were generated from the PHP scripts, e.g. from *clouds.php*.
The scripts, implementing APS UI, are collected in a separate folder, which is the *ui* folder in our example.
Such a package compressed into a single file is shipped to a Hosting Platform for deployment. This process is not considered in this document.

24. Thank you! Need more details?
APS Specification:
Integration with PA:
This completes the Introduction to Application Packaging Standard.
Hope you enjoy it.
If you need more details, please follow the links presented here.
Thanks for your interest to APS and for watching us.