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.

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.

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.

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)

APS Purpose https://app.isv.com/ 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.

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?

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.

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.

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.

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.

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.

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.

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

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.

APS Type – JSON Schema schemas/vpses.schema General section “apsVersion”: “2.0”, “name”: “vps”, “id”: "http://event-mgmt.demo.apsdemo.org/vpsclouds/vpses/1.0”, General section “implements”: ["http://aps-standard.org/types/core/resource/1.0” ], "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.

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.

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”.

Resource Type – Declaration of Relations schemas/vpses.schema “apsVersion”: “2.0”, “name”: “vps”, “id”: "http://event-mgmt.demo.apsdemo.org/vpsclouds/vpses/1.0", “implements”: ["http://aps-standard.org/types/core/resource/1.0” ], "properties": { ... }, “operations": { ... } “relations": { "context": { "type": "http://edu.tst/vpscloud/context/2.0", "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.

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.

APS UI – Integration with Control Panel Navigation Components <navigation> plugged into "http://www.aps-standard.org/ui/service" <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

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

Navigation Tree Declaration <navigation id="ccp" label="VPS Management"> <var name="context" type-id="http://edu.tst/vpscloud/context/2.0"/> <plugs-to id="http://www.aps-standard.org/ui/service"/> <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.

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.

Thank you! Need more details? APS Specification: http://doc.apsstandard.org/spec/ Integration with PA: http://doc.apsstandard.org/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.