Key Concepts

Let's take a look at some concepts and terminology.

The default lifecycle

There are numerous software programs (applications) running in any IT infrastructure. These applications can be a diverse range of low-level system programs, middleware, or end-user programs running on different platforms from the Web to mobile devices. All applications typically go through a similar lifecycle from their inception to retirement.

Following are the lifecycle stages that come in WSO2 App Factory:

• Development: Application is still being built. Developers are writing code according to requirement specs given by stakeholders.
• Testing: After the application is built, it goes to the Testing stage. In this stage, the application's functionality is tested against requirement specs in environments separate from the development.
• Production: This is the final destination of the application and where the end users and stakeholders usually do the final acceptance tests before launching the application in the business. In extreme Agile development environments, applications can be pushed to the production stage several times a day.

Each of these stages is typically managed by the following IT roles:

• App Owner: The app owner creates an application and invites users to collaborate on it as any of the roles below. This role is automatically assigned to any user creating an application.
• Developers: Developers check out the source code from source control systems and write code for the application. They deploy and test the application in the development environment. Once certain standards are met, they promote the application to the Testing stage.
• QA: QA users deploy the application in the testing environment after developers promote it to testing. QA users run tests on the applications to verify that they satisfy the requirement specs or quality standards. If a defined percentage of tests pass, the application is promoted to Production. If not, it is demoted back to Development.
• DevOps: A DevOps person deploys the application to the Production environment after QA promotes it from the Testing stage. If necessary, DevOps can also demote the application to QA for further testing or retire (sunset) the application when it is no longer needed.

The following diagram provides an overall view of these lifecycle stages, IT roles, and the responsibilities of each role. This sample lifecycle can be completely adapted to your enterprise needs, should it be in terms of lifecycle stages, roles, or pre-conditions.

User roles and permissions

The App Factory has the following default user roles and permissions. You can assign multiple roles to the same member.

App Factory component

The figure below depicts the high-level components:

Figure: High-level components of the App Factory

The figure depicts,

1. API Store: APIs published on a storefront can be consumed through an API Gateway to build applications as well as to publish data into a shared storage server.
2. Multiple clouds to simulate different lifecycle stages and application management components integrated.
3. Team to perform daily tasks such as builds, deployments, source control, tests etc.
4. Tools to create, manage and govern applications and the runtime to execute these tools.
5. WSO2 Developer Studio as one of the IDEs. Developer Studio provides an inbuilt App Factory perspective to make the integrated development experience much simpler. But, you can also continue to use familiar IDEs because the runtime provides extension points to any third-party tool.

Given below are the key products and technologies used:

Figure: Key products and technologies of the App Factory

1. Jaggery Framework: All user interactions are handled by Jaggery, which is a server-side Javascript framework. It runs on WSO2 Carbon platform and manages all aspects of the application from front-end, communication, server-side logic to persistence in pure Javascript. Jaggery facilitates frequent Web services communication.
2. BPEL: Business processes that use atomic services are handled by BPEL. In order to properly orchestrate these services, business processes are created using BPEL. BPEL is a standards-based way for orchestrating several services. Using BPEL makes a workflow easily customizable as it enables the usage of existing services without doing big changes to the core system. These BPELs are deployed on the WSO2 Business Process Server. Some of the business processes that use BPEL are listed below:
   
   • Application creation
   • Addition of a user to an application
   • Creation and Deploying of application artifacts
   • Governance of applications
3. Governance: The lifecycle stage features are handled via WSO2 Governance Registry, which includes the governance rules plus context storage of each application. Adding a new lifecycle stage is a seamless experience.
4. Infrastructure interfaces: Allows to interface seamlessly with the different ecosystem products (e.g., repository and build systems) that are bundled together for application lifecycle management.This is achieved using deployers, which are interface definitions for ecosystem interfaces. When adding a particular ecosystem, a concrete deployer should be implemented to handle the interaction.
5. Maven Archetypes: Each application type is created as a maven archetype with the basic components within it. Once expanded, they can be used by the application developers. You add a new application type simply by creating an archetype for that application type.
6. Lifecycle stage environment: Once an application is created, a cloud for each lifecycle stage is created. It is within this cloud that all operations for that lifecycle stage execute.

The App Cloud leverages WSO2 PaaS, namely WSO2 Private PaaS. Private PaaS supports polyglot programming through its new and improved architecture. Also it offers multi-tenanted, shared container isolation for all platform components of WSO2 Carbon platform. Private PaaS also offers standard virtual machine and Linux container (LXC) isolation and tenancy for both Carbon and non-carbon components. A cartridge architecture supports a polyglot programming model that enables developers to mix-and-match programming languages (e.g., PHP, JavaScript, Java), frameworks (e.g., couchDb, MySQL, JEE), and application platform servers (e.g., Tomcat, Jetty, WSo2) in the PaaS.

Figure: Runtime architecture of the App Cloud

The social wall and notification framework

The App Factory provides three types of notifications:

• Information like a new branch that is created, successful builds etc. Information is rendered in the My Wall and App Wall sections of the App Factory that appear on the right-hand side of the screen. My Wall gives feeds of all your applications and the App Wall gives feeds of a selected application. 
• Errors such as application build failures, user provisioning issues etc. Error notifications are designed for users to take immediate action. You guarantee that the user sees the notification and acknowledges it by sending e-mails, SMSs, alerts at login etc.
• Actions such as adding a user to an application, creating a new branch etc. Actions are designed for guaranteed delivery. Even if the you log in to the App Factory after a few days, you still see the old notifications.

Implementation details of errors and actions

The App Factory uses WSO2 Message Broker to publish error and action notifications to topics such as APPLICATION_CREATION_FAILURE, FOO_APPLICATION/BUILD_ERROR, FOO_APPLICATION/DEPLOY_ERROR etc. There are durable subscribers who get error notifications from the Message Broker. When a user logs in to the AppFactory, durable subscribers are created with the subscriptionId as the userId. This happens for each topic to initiate the topic connection. When the user logs out, the topic connection is dropped.

From the Jaggery pages, the message listeners are polled to retrieve the received messages. When those messages are delivered to the user, the user acknowledges them after which the Message Broker is sent an acknowledgement. These implementation details are depicted in te diagram below: