HK1224396B - Systems and methods for private cloud computing - Google Patents

Description

Systems and methods for private cloud computing

This application is a divisional application of Chinese patent application 201180039802.8, whose application date is July 11, 2011 and whose invention name is “System and method for private cloud computing”.

Technical Field

The present invention relates to computer-based systems and methods for cloud computing, and more particularly, to computer-based systems and methods for private cloud computing and for cloud application development and deployment within a private cloud.

Background Art

Generally, cloud computing refers to the use and access of multiple server-based computing resources using a digital network such as the Internet. Cloud system users access the cloud's network server services by using client devices such as desktop computers, laptop computers, tablet computers, smartphones, personal digital assistants (PDAs), or similar devices (hereinafter collectively referred to as "client devices" or "client devices").

In cloud computing, applications are provided and managed by cloud servers, and data is stored remotely in cloud databases. Generally, cloud system users do not download and install applications that exist in the cloud on their own computing devices, as processing and storage are maintained by cloud servers and cloud databases, respectively.

Typically, online services are provided by cloud providers or private organizations. This eliminates the need for cloud system users to install application software on their own individual client devices. Cloud computing differs from the classic client-server model in that applications are provided on cloud servers, executed and managed by client services, eliminating the need to install client versions of applications on client devices. The centralization of cloud services enables cloud service providers to control the versions of browser-based applications provided to clients. This also eliminates the need to upgrade application versions on individual client devices.

In action, a cloud system user would log into a public or private cloud. Computations would then be performed on a client/server basis using web browser protocols. The cloud would provide server-based applications and all data services to the cloud system user, and then display the results on the client device. Thus, the cloud system user would be able to access the desired application running remotely on a database that displays the work being completed using the cloud application on the client device.

The cloud database storage allocation client device is used to make the application appear on the client device display. However, all calculations and changes are recorded by the cloud server, and the generated and modified files are permanently stored in the cloud database storage.

When implemented, cloud computing involves the provision of dynamically scalable and virtualized resources. This process can be implemented by cloud providers without the cloud system user having any knowledge of the physical location and configuration of the systems delivering the requested services. Thus, cloud computing infrastructure involves services delivered through shared data centers. However, from the client side, the cloud appears as a single access point.

A typical cloud architecture encompasses the hardware and software systems involved in delivering cloud computing services. Two distinct components of a cloud computing architecture are the "front end" and the "back end." The front end is what a cloud system user sees on their client device. It typically includes client device applications used to access the cloud through a user interface such as a web browser. The back end of the cloud computing architecture is the cloud itself, consisting of various computers, servers, and data storage devices unknown to the cloud system user.

Shared services within a typical cloud computing environment are generally designated 100 in FIG1 . Client 102 is a client device that has its own internal software that relies on cloud computing for application delivery via a network service. Cloud application 104 is a cloud application service also known as "Software as a Service (SaaS)." This is software delivery over the Internet, eliminating the need to install and run applications on the computing devices of cloud system users. Because the applications are cloud applications, maintenance and support of these applications is greatly simplified.

Cloud platform 106 is a cloud platform service also known as "Platform as a Service (PaaS)". PaaS is the delivery of a computing platform and/or solution stack as a service using cloud infrastructure and cloud applications. This facilitates the deployment of applications from the cloud.

Cloud infrastructure 108 is a cloud infrastructure service also known as "Infrastructure as a Service (IaaS)." IaaS is the delivery of computer infrastructure as a service, typically in the form of platform virtualization. Cloud infrastructure services can take the form of a data center operating virtual machines running on physical machines.

Server 110 refers to the server layer of the cloud. This includes the computer hardware and software used to deliver cloud services to clients 102.

As mentioned above, a cloud can be a public or private cloud. There are also other cloud configurations that can contain elements of both. We will now briefly discuss some of the well-known cloud types.

A "public cloud" is a cloud that dynamically delivers resources over the Internet using web applications and services from third-party providers.

A "community cloud" is a cloud established when several organizations have similar needs and seek to share infrastructure to realize the benefits of cloud computing.

A "hybrid cloud" is a cloud that recognizes the need for companies to deliver services to some internal operating methods in a regular manner and provides technology to manage the complexity of managing the performance, security, and privacy issues that arise from the company's fixed delivery methods. A hybrid cloud uses a combination of public and private storage clouds.

A "composite cloud" is a cloud that joins two clouds together. In this configuration, there will be multiple internal and/or external cloud providers.

A "private cloud" is essentially an emulation of a public cloud operating on a private network. Through virtualization, a private cloud gives businesses the ability to host applications on enterprise-wide virtual machines. This offers the benefits of shared hardware costs, better service recovery, and the ability to scale up or down as needed.

However, there is a need for computer-based private cloud systems that implement better systems and methods for cloud computing and cloud application development and deployment on an enterprise-wide basis. The systems and methods of the present invention meet these needs.

Summary of the Invention

The present invention is a computer-based system and method for cloud computing and cloud application development and deployment in a private cloud within an enterprise. Furthermore, the present invention is directed to computer-based systems and methods for private cloud computing that allow the cloud infrastructure to automatically adapt to or respond to changes caused by the deployment and development of cloud applications using the private cloud system. The private cloud computing system and method of the present invention can be implemented in a high-level layer, such as the application and services layer, which can be included as part of the application layer 104 shown in FIG. 1 .

The private cloud computing system and method of the present invention preferably include a cloud controller, a cloud stack, a service registry, and a cloud application builder. The cloud controller provides intelligent control for the private cloud. The cloud controller includes a rules engine for analyzing information collected and stored in a cloud database. This database stores cloud application binaries and monitoring information. Therefore, in the computer-based private cloud system of the present invention, cloud applications are not typically stored in a file system, but rather in a database, allowing them to be consistently maintained across the cloud in a simple and efficient manner.

A cloud stack includes the operating software for the cloud. For example, a cloud stack may include operating system software, virtual machine software, network server software, application server software, network security software, network access management software, database driver software, application builder runtime software, and third-party libraries.

The service registry includes at least a registry of network services for cloud applications deployed in the private cloud. Network services can be searched for in a number of different ways, allowing developers to view network services and detailed information about network services that may be reused with cloud applications they are developing and deploying in the private cloud.

The cloud application builder provides developers with a means to build applications deployed in the private cloud using the cloud controller. The cloud application builder preferably includes tools for generating components of a cloud application. These components preferably include network services, user interfaces, and jobs for each cloud application deployed in the private cloud. Thus, the cloud application building tools include, but are not limited to, tools for developing network services, tools for developing user interfaces and registering network services in a service registry so that access levels to the cloud application are controlled, and tools for developing jobs. Using these tools, each cloud application developed and deployed will include a user interface for managing foreground tasks, data storage, and background tasks; however, it will be understood that more or fewer tools than these may be used and still remain within the scope of the present invention.

When it comes to building a cloud application, there are preferably two distinct parts. The first is the development time to build the cloud application, and the second is the cloud application architecture. The development time will include using the cloud application builder to build the application according to the cloud application architecture. The cloud application architecture, along with the resulting cloud application components, is deployed in the private cloud.

The system and method of the present invention includes Enterprise Security Foundation ("eSF") software that manages user roles that authorize cloud application access. Thus, access security is provided to the private cloud of the present invention through eSF.

According to the system and method of the present invention, cloud infrastructure resources are managed by load balancing incoming requests from client devices using cloud applications and web services and by routing these requests to various web servers and application servers in the private cloud.

In the private cloud of the present invention, there can also be the generation of business rules related to network services for cloud applications. This provides greater flexibility, management and control of cloud applications developed and deployed in the private cloud.

The private cloud computing system and method of the present invention supports external services. Therefore, it is possible to provide services for cloud databases by using self-service applications for accessing and controlling such external services.

The private cloud computing system and method of the present invention envisions a cloud monitoring service to analyze usage data in log files and health records related to cloud applications running in the private cloud, and utilize the results of the analysis to scale the cloud infrastructure, control alert processes, and facilitate capacity planning.

The computer-based private cloud computing system and method of the present invention provide for the development and deployment of cloud applications and network services within an enterprise.

The computer-based private cloud computing system and method of the present invention can also be implemented using a cloud controller, a cloud stack, a service registry, and a cloud application builder. In this implementation, the cloud application builder builds a cloud application based on a cloud application architecture. Once the cloud application is built, the cloud controller is used in conjunction with the cloud stack and service registry to deploy the cloud application in the private cloud.

The computer-based private cloud computing system and method of the present invention also provides PaaS through a cloud stack to extend IaaS by anticipating enterprise system needs, which helps standardize the enterprise's cloud application development and deployment process.

In the remainder of the specification with reference to the accompanying drawings, the computer-based private cloud computing system and method of the present invention will be described in more detail.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 shows a typical diagram of a hierarchical structure of shared services in a cloud environment.

FIG. 2A shows a typical diagram of the physical structure of the computer-based private cloud computing system of the present invention.

FIG. 2B is a typical diagram showing the logical structure of the computer-based private cloud computing system of the present invention shown in FIG. 2A .

FIG3 shows a typical diagram of cloud components of the computer-based private cloud computing system of the present invention.

FIG4 is a typical diagram showing the logical structure of components of the private cloud computing system of the present invention.

FIG5 shows a typical diagram of cloud user interface management of foreground tasks, data storage, and background tasks of a computer-based computing system according to the present invention.

FIG6 is a typical diagram showing the logical structure of the private cloud computing system of the present invention including a service registry.

FIG. 7 is a typical diagram showing a service registration structure of the computer-based private cloud computing system of the present invention.

FIG8 is a typical diagram showing a process of developing a network service component of a cloud application in a computer-based private cloud computing system according to the present invention.

FIG. 9 shows a typical diagram of background job development and operation of a computer-based private cloud computing system according to the present invention.

FIG10 shows a typical diagram for implementing eSF security.

FIG. 11 shows a typical diagram related to the formation of a functional group of cloud applications and services, such that the functional group can access the cloud applications and services.

FIG. 12 shows a typical diagram related to cloud application roles for defining functional groups.

FIG. 13 shows a typical diagram of an eSF rights graph for the administrator role shown in FIG. 12 .

FIG. 14 shows a typical diagram of an eSF rights graph for the system user roles shown in FIG. 12 .

15-22 illustrate typical screen displays for creating a cloud application profile and changing the status of a cloud application from draft to published.

FIG. 23A shows a typical diagram relating to actions associated with the application of automated audit rules.

FIG23B shows a typical list of automated audit rules that are checked when changing a cloud application profile state.

FIG. 24 shows a typical display screen of a dashboard of a computer-based private cloud system according to the present invention.

FIG. 25 shows a typical service registration display screen of a computer-based private cloud system according to the present invention.

FIG. 26 illustrates a typical network service details display screen of a computer-based private cloud system according to the present invention.

27 to 32 show typical diagrams related to the cloud application deployment workflow.

DETAILED DESCRIPTION

(Related Applications)

This application claims priority under 35 U.S.C. §119(e) from U.S. Provisional Application Serial No. 61/363,092, filed on July 9, 2010, entitled “Self-Organizing Cloud Computing.”

The present invention is directed to computer-based systems and methods for cloud computing and cloud application development and deployment in a private cloud within an enterprise. The present invention is also directed to computer-based systems and methods for private cloud computing in which the cloud infrastructure adapts to, or automatically or substantially automatically responds to, changes resulting from the deployment and use of cloud applications developed by the private cloud system. The private cloud computing systems and methods of the present invention can be implemented in a higher-level layer, such as an application and services layer, which can be included as part of the application layer 104 shown in FIG. 1 .

Referring to FIG. 2 , a typical diagram of the physical structure of a computer-based private cloud computing system of the present invention is generally shown at 200. In FIG. 2 , a cloud cluster and routers forming a cloud application server are shown at 202. The cluster represents four server computers forming the cloud application server. Thus, due to the load balancing features of the present invention's private cloud provided services, any one of them can be provided to process requests for cloud applications or network services. However, a cluster may include more or fewer than four server computers and remain within the scope of the present invention.

External cloud service 204 is connected to cloud application server 202. The external cloud service shown includes a cloakware server 206 for providing network security to the cloud. External cloud service 204 also includes a messaging server 208 for controlling internal and external messaging associated with the private cloud of the present invention.

External cloud services 204 include file transfer services 210. Services handled by file transfer services 210 include, but are not limited to, client device-cloud, cloud-external system, and internal-cloud file transfers. These file transfers may be encrypted for security purposes, which is within the scope of the present invention.

The final server represented in external cloud services 204 is email server 212. This server is used to send email messages from client devices and to receive and process email messages therefrom. Specifically, email messages contemplated for processing by this server include email messages from the private cloud to external systems to notify, for example, of alert conditions or service level objective ("SLO") violations within the private cloud.

The cloud application server 202 is connected to an application database 214. Preferably, the database stores cloud application data including, for example, application transaction data, reports, and warehouse data.

The network server 216 is connected to the cloud application server 202 and is positioned between the client device 222 and the cloud application server 202. The network server 216 operates in a conventional manner to provide content to the client device and to process requests from the client device directed to the cloud application server 202. The network server 216 is also connected to the SiteMinder server 218. The SiteMinder server 218 preferably provides network access management to the network server 216 in the form of authentication services.

A load balancer 220 disposed between client devices 222 and web servers 216 provides a service for balancing the distribution of cloud applications running in the cloud in a cloud infrastructure. Specifically, the load balancer 220 load balances incoming HTTP requests among a large number of web servers, only one of which is shown in FIG2B .

2B , a typical diagram of the logical architecture of the computer-based private cloud computing system of the present invention shown in FIG. 2A is shown at 230. Load balancer 220 balances incoming HTTP requests to a pool of web servers and scales cloud infrastructure, such as web servers, up or down to meet traffic demands. Web servers 216/218 perform the functions of web servers and authentication agents on a single sign-on basis.

The web server routes the request to the application router. The application router takes the form of a router cluster that is part of the application server 202. The application router routes the request to the web service in the cloud application server cluster that is also part of the cloud application server 202. Each service is identified by a unique ID.

The application server cluster hosts network services and receives requests for such services from the application router cluster. The application server cluster also contains jobs. Jobs are batch jobs that are part of the cloud application that resides in the application server cluster.

The network services in the application server cluster are connected to the application database 214 containing enterprise data. The application database resides outside the private cloud. The enterprise data includes separately stored online transaction processing ("OLTP") and warehouse data. Preferably, a replicated instance, shown as an Oracle instance, holds the OLTP data.

3, the components of the computer-based private cloud computing system of the present invention are shown generally at 300. These components will now be discussed.

The primary components of the computer-based private cloud computing system of the present invention include a cloud controller 302, a cloud stack 324, a service registry 345, and a cloud application builder 350. As described, cloud controller 302 provides intelligent control for the computer-based private cloud computing system of the present invention. The general functions of cloud controller 302 include handling deployment workflows, setting times and dates for cloud application deployments, scaling platforms up or down based on the cloud applications to be run, setting times and dates for checking physical and virtual machines, setting times and dates for scanning cloud application logs, setting times and dates for monitoring cloud application transactions, and sending alerts when errors occur within the private cloud. The deployment workflow will be described in more detail below with reference to Figures 27-32.

Change control service 308 of cloud controller 302 is associated with cloud application configuration. Change control service 308 accepts packaged binaries generated for cloud applications and allows authorized system users to create and update cloud application profiles and view information about specific cloud applications. Cloud application profiles are generated for cloud applications deployed in a private cloud and specify the appropriate cloud application to run.

The change control service 308 allows authorized users to copy the description of an existing profile without identifying fields so that it can be used to describe a new cloud application. The change control service 308 also allows authorized users to browse existing cloud application profiles and preview the information they contain. Furthermore, the change control service 308 allows authorized users to modify existing application profiles including the associated application binary.

The change control service 308 allows authorized users to change the state of an application profile. For example, using this capability, an authorized user can change the state of a cloud application from "DRAFT" to "PUBLISHED." However, it will be appreciated that other state changes can be made and still be within the scope of the present invention.

The change control service 308 enables authorized system users to browse the application state record of the cloud application to preview the current and previous states of the cloud application. The change control service 308 also enables authorized system users to browse properties related to the cloud application and edit these properties.

The features of the change control service 308 described above are merely preferred features. It is contemplated that the change control service 308 may have more or fewer features than those described and still be within the scope of the present invention.

Referring back to cloud controller 302, automated audit rules are shown at 310. Automated audit rules 310 specify specific rules that are checked when the state of a cloud application profile changes. Automated audit rules 310 are system-configurable and generally only cloud administrators can change them. Automated audit rules 310 preferably contain a set of rules that apply to every change made to a cloud application profile. An alert is generated for each automated audit rule that fails. Automated audit rules 310 are discussed in more detail with reference to Figures 23A and 23B.

Cloud controller 302 represents provisioning services at 312. Provisioning services 312 are responsible for executing deployment-related commands issued by the cloud controller's rules engine. Provisioning services 312 automatically create, shut down, and restart cloud application instances, where an instance is a single copy of a running application. Provisioning services 312 interact with the platform infrastructure to implement provisioning. In action, before running a cloud application, provisioning services 312 will determine the assets required to run the cloud application and provision the infrastructure accordingly.

The features described above for providing service 312 are merely preferred features. It is contemplated that providing service 312 may have more or fewer features than those described and still be within the scope of the present invention.

Cloud controller 302 represents monitoring service 314 at 314. Monitoring service 314 captures operational performance information regarding at least various cloud applications and user interfaces using a cloud control panel and dashboard, and makes this captured information visible to system users on their client devices. Furthermore, this information can be made visible via zones. Zones are created by authorized users and, for the purposes of this invention, are defined as a predetermined group of computers. These computers can be geographically grouped, perhaps by enterprise divisions or other types of groupings. Thus, for example, zones are a means of separating and distinguishing segments of the cloud for purposes such as deployment, system testing, system user acceptance testing and production, identifying distinct physical locations and data centers, and isolating environments to facilitate rapid disaster mitigation.

Monitoring service 314 also allows authorized users to browse cloud server configurations by region in a detailed format and view transaction lists that show how cloud applications are being used by region or other user-defined criteria. Furthermore, monitoring service 314 allows authorized users to view activity logs that show what specific cloud users are doing with the private cloud. Authorized users can also view graphical depictions of data on physical and virtual machines related to the cloud and SLO violations. Monitoring service 314 allows authorized users to view information related to cloud applications stored in the private cloud, view information related to currently active cloud applications, and view historical data related to cloud applications. Furthermore, monitoring service 314 allows authorized users to set and update SLO thresholds, preview SLO statistics, and take action based on how errors occur in cloud applications.

The features of the monitoring service 314 described above are merely preferred features. It is contemplated that the monitoring service 314 may have more or fewer features than those described and still be within the scope of the present invention.

The alert service 316 of the cloud controller 302 is generated to indicate changes in the state of cloud applications during the development and deployment process. Alerts generated by the alert service 316 are associated with automated audit rules. Alerts are categorized as "INFO," "WARN," "ERROR," and "FATAL" alerts. During the development of a cloud application, cloud application developers and approvers (cloud administrators) can view alerts associated with each change in the state of a cloud application profile. During the deployment process, all alerts require approval from the cloud administrator. However, it will be understood that the cloud administrator may include one or more levels of approvers and still be within the scope of the present invention.

After previewing, the cloud administrator can accept or decline the warning. If the cloud administrator chooses to accept the warning, the cloud application will be moved forward. However, if the cloud administrator declines the warning, the cloud application will be moved back by setting the status of the cloud application profile to Draft, and the reason will be "Rejected."

Alert service 316 allows authorized users to configure alerts for cloud application profiles by region. For example, alert service 316 can issue alerts when a cloud application scales up, when a predetermined number of health checks fail within a predetermined time period, or when an SLO violation exceeds an average. Alerts can be generated manually or automatically based on predetermined conditions, such as by email. Alerts related to automated audit rules are discussed in more detail below with reference to FIGURES 23A, 23B, and 32.

The features of the alert service 316 described above are merely preferred features. It is contemplated that the alert service 316 may have more or fewer features than those described and still be within the scope of the present invention.

The SLO observation and compliance service 318 of the cloud controller 302 allows authorized system users to view a summary of all SLO violations by individual cloud applications or by region. The SLO observation and compliance service 318 also allows authorized system users to view summary values for individual violations. Furthermore, the SLO observation and compliance service 318 allows authorized system users to view records of individual transaction violations. Furthermore, the SLO observation and compliance service 318 allows authorized system users to filter violations by user, region, cloud application, network service, or other predefined criteria.

The features described above for SLO observation and compliance service 318 are merely preferred features. It is contemplated that SLO observation and compliance service 318 may have more or fewer features than those described and still be within the scope of the present invention.

Log scanning service 320 of cloud controller 302 allows authorized system users to view activity associated with cloud applications, instances, hypervisors in virtual machine control, or other cloud elements. Using the log scanning service, authorized system users can request on-demand log scanning of any cloud application or component. Furthermore, using the log scanning service 320, authorized system users can view activity associated with deployed cloud applications.

The thread analyzer service 322 allows authorized system users to view transactions occurring within the private cloud with respect to specific nodes associated with a running cloud application.

The transaction explorer 323 allows authorized system users to filter transactions by user, region, cloud application, web service, or other predefined criteria. The transaction explorer 323 allows authorized system users to group transactions together to understand macro behavior, view timing statistics by cloud application and region, and compare current response time statistics for cloud applications and regions with typical timing statistics for cloud applications and regions.

The features of the thread analyzer service 322 and the transaction browser 323 described above are merely preferred features. It is contemplated that the thread analyzer service 322 and the transaction browser 323 may have more or fewer features than described and still be within the scope of the present invention.

Cloud stack 324 comprises a software stack for a private cloud. Cloud stack 324 comprises operating system software 326, which is preferably Linux software. Furthermore, cloud stack 324 comprises virtual machine operating software 328 for use by virtual machines running in the cloud managed by a hypervisor. Preferably, this software is the Java Development Kit ("JDK") software from Sun Microsystems, Inc./Oracle, Inc.

Cloud stack 324 includes network service software 330, which is preferably Apache Web server software from the Apache Software Foundation. Cloud stack 324 also includes application server software 332. Preferably, the application server software is JBoss software including the Tomcat applet container. JBoss software is from Red Hat, Inc. and the Tomcat applet container software is from the Apache Software Foundation.

The cloud stack 324 includes network security software 334, which is preferably Cloakware software from Irdeto B.V. The next software in the cloud stack 324 is network access management software 336, which is preferably SiteMinder software from Computer Associates, Inc.

The cloud stack 324 includes a database access driver 338, which is preferably a JDBC driver. The cloud stack 324 also includes a cloud application builder runtime software 340, which is the cloud application framework software to be deployed in the private cloud.

Finally, cloud stack 324 includes third party libraries 342. The number of libraries may include one or more such third party libraries and still be within the scope of the present invention.

The service registry 345 described above contains at least a registry of network services for cloud applications deployed in the private cloud. In order to deploy developed cloud applications in the private cloud, the service registry acts in conjunction with the cloud controller 302 and the cloud stack 324.

Preferably, the cloud controller 302 including the aforementioned services and the cloud stack 324 including the aforementioned software stack, together with a cloud application architecture for building cloud applications, form runtime components to prepare cloud applications for deployment in a private cloud. Certain components have been specified above with respect to the cloud controller 302 and the cloud stack 324, but it is understood that more or fewer components than these may constitute the cloud controller 302 and the cloud stack 324 and still fall within the scope of the present invention.

Cloud application builder 350 is used to develop cloud applications and web services deployed in the private cloud of the present invention. Cloud application builder 350 includes a service development toolkit 352 primarily used to develop web services for cloud applications deployed in the private cloud. The service development toolkit includes at least tools for developing web services and user interface components for cloud applications developed according to the cloud application architecture.

The Cloud Development Toolkit ("CDT") 354 of the cloud application builder 350 is used to develop user interfaces associated with cloud applications to be deployed in the private cloud.

Cloud application builder 350 includes software 356 for developing in web applications. Preferably, application development software 356 is Eclipse from the Eclipse Foundation plus the Google Web Toolkit ("GWT") from Google Inc., which provides an integrated development environment ("IDE") for application development.

The cloud application builder 350 includes testing software 358, which is preferably JUnit software from JUnit.org. Finally, the cloud application builder 350 includes web servlet software 360 for generating dynamic content for the web server of the developed cloud application deployed in the cloud. Preferably, the web servlet software is Apache Tomcat from the Apache Software Foundation.

4 , a typical diagram of the logical structure of the components of the private cloud computing system of the present invention is shown generally at 400. User interface 402 is the user interface of a client device. The interface includes an application control panel 404, which includes a dashboard 406. A typical application control panel is shown in FIG15 , and a typical dashboard is shown in FIG24 .

Application control panel 404 enables developers, cloud application administrators, cloud application owners, software quality assurance ("SQA"), system users, and others to view, use, and operate cloud applications in the cloud. Dashboard 406 enables authorized users to manage infrastructure components. User interface 402 is bidirectionally connected to CLDB 410 to access cloud applications and related information and other data and information stored in CLDB 410.

The user interface 402 is also connected to the cloud controller 408 for the purpose of sending messages to the cloud controller. Preferably, these messages will include, but are not limited to, requests for access to specific cloud applications and network services and SLO monitoring.

The eSF proxy 412 with the eSF database 413 provides security to the cloud. The eSF proxy 412 and the eSF database 413 provide access permissions to cloud applications and network services based on data groups, function groups, and user roles. Data groups, function groups, and user roles are discussed in more detail with reference to Figures 11 to 14.

Permissions include, but are not limited to, which users can access specific cloud applications and network services in the cloud, and which users can perform certain functions, such as providing approvals, changing cloud application profiles, or deleting cloud applications from CLDB 410. Furthermore, eSF 412/413 can provide the infrastructure that will contain and meet all security requirements for cloud applications running in the private cloud, as well as for the private cloud itself. At least a portion of the security eSF provides is function-level entitlements, and the eSF also contains data used to support this security provision. It will be appreciated that the above-mentioned permissions are not exhaustive, and additional permissions may exist and remain within the scope of the present invention.

The service registry 415 is connected to the cloud controller 408. The service registry 415, discussed in more detail later, enables developers to search for network services registered with the private cloud and view detailed information about them.

When processing a request from user interface 402 for a particular cloud application or web service, cloud controller 408 sends the request to provisioning services 414. Provisioning services 414 provide the hypervisors and virtual machines they control to meet the needs of client devices running within cloud applications in the cloud. As shown in FIG4 , hypervisor 420 manages web server instances 422, application instances 424, and application instances 426. Each of these software instances runs within a virtual machine instance managed by hypervisor 420. The private cloud computing system of the present invention may have one or more hypervisors controlling cloud applications and web server instances running within virtual machine instances and still remain within the scope of the present invention.

Referring to FIG. 4 at 416 , this represents Build.xml. Build.xml refers to the cloud build framework that enables developers to build cloud applications using the cloud application builder 350 ( FIG. 3 ) and its associated runtime libraries. When building such a cloud application, the binaries associated with the cloud application are provided to a binary packager 418 . The binaries are then sent for storage in the CLDB 410 and provided to a service 414 for provisioning via the hypervisor, making them available to system users, including client devices running the cloud application and authorized system users allowed to operate the cloud application.

Monitoring services 428 include health check service 430 and log scanning service 432. Health check service 430 monitors the physical and virtual resources of the private cloud. Log scanning service 432 performs automated and on-demand scans of logs for cloud applications and cloud infrastructure components looking for SLO violations. Information determined by health check service 430 and log scanning service 432 is stored in CLDB 410.

Before describing the development of cloud applications, user interface management of each cloud application is discussed with reference to FIG. 5 .

FIG5 shows a typical diagram of user interface management for foreground tasks, data storage, and background tasks for a cloud application on a private cloud at 500. Service consumers 502 are consumers of services that are internal or external to the cloud. Examples of consumers of services outside of the private cloud include services running on client devices, such as those shown at 504.

Data access 506 is directed to foreground services, such as those represented at 508 and 510, for user interface access to the private cloud. For example, developers will create lightweight user interface components in HTML, Adobe Flash, AJAX, and other tools for this purpose. However, it is understood that other services can be created and still be within the scope of the present invention.

Data store 512 is for online transaction processing ("OLTP") data stored in application database 214 separately from warehouse data. OLTP data is therefore associated with executing database transactions. Examples of OLTP data are shown at 514 and 516 of data store 512. Within data store 512, a mainframe Customer Information Control System ("CICS") 514 will leverage conventional CICS functionality for data storage purposes according to the present invention. Data store 512 also represents RDBMS 516, which is a relational database management system. For purposes of the present invention, the RDBMS will leverage conventional relational database management functions for data storage purposes according to the present invention. However, it will be understood that the system of the present invention may include other OLTP data components and still be within the scope of the present invention.

The background 518 is used to generate background processes such as jobs 520 and 522 and manage warehouse data. The generation of jobs will be described in more detail later.

The aforementioned eSF 526 provides security for the cloud. eSF 526 includes the components 412 and 413 in FIG4 . Through a user interface, eSF 526 enforces rights. Thus, regarding data access 506 and context 518, eSF 526 controls authorization to access and use cloud applications and network services by assigning user roles, preferably designed by associating stored data with functions within the enterprise.

Network registry 524 refers to the private cloud's service registry. The service registry enables developers to search for network services and view detailed information about them. Thus, a user interface can be used to browse the service registry for reusable network services. Furthermore, service registry 524 facilitates bringing applications and network services into the private cloud and monitoring their SLO compliance and usage. The service registry is discussed in more detail with respect to FIG6 .

FIG6 shows, generally at 600, an exemplary diagram of the architecture of a private cloud computing system of the present invention, illustrating service registry 524. In FIG6 , provisioning services 312, monitoring services 314, SLO viewing and compliance services 318, record scanning services 320, and transaction explorer 323 (not shown) are components of cloud controller 302 shown in FIG3 and previously described. User interface 406 is shown in FIG4 and previously described. It is understood that transaction explorer 323 could be shown in FIG6 and still be within the scope of the present invention.

At the center of Figure 6 is persistent state 606, which includes audit trail 608, data integrity 610, security 612, and scheduler 614. Audit trail 608 is used to track changes to cloud applications. Data integrity 610 is used to constrain the application database to ensure data integrity within the database. Scheduler 614 is used to schedule jobs. Security 612 is eSF access security.

The rules engine 602, which is part of the private cloud (cloud controller), is created by the cloud administrator and contains rules for operating actions for cloud applications running within the private cloud. These rules may include, for example, scaling up or down rules, warning rules, or zone rules. It may contain other rules and still be within the scope of the present invention.

6, each element is shown connected within an information transceiver environment 604. This enables communication between the elements.

6, it is contemplated that the service registry provides at least four services, however, it is understood that it may provide more or less than four services and still be within the scope of the present invention.

The first service that the service registry 524 preferably provides is an application programming interface ("API") that allows authorized developers to create and manipulate metadata related to network services. This allows authorized users to create or update metadata and information about functions and function groups. The API references this information, which is preferably the network service details in the service inventory file.

The second service is the Search Directory Service. The Search Directory Service enables authorized system users to search for and discover network services on the directory search page of the service registry.

The third service of the service registry 524 is the browse directory service. This service enables authorized system users to drill down from the cloud application functional group to the list of constituent network services on the application browser page of the service registry.

The fourth service of the service registry is the Web Service Details service, which provides metadata and other information that authorized system users can access on various tabs of the Web Service Details dialog box in the user interface shown in FIG26.

Referring to FIG. 7 , a typical service registry structure is generally shown at 700. Service registry 524 ( FIG. 5 ) is connected to cloud controller 408 ( FIG. 4 ). As shown, cloud controller 408 and service registry 524 are both located within the private cloud. Service metadata repository 704, a metadata repository, is also connected to service registry 524 from outside the cloud. Furthermore, eSF 412/413 ( FIG. 4 ) is connected to cloud controller 408 from outside the cloud. Although not shown, eSF proxy 412 is provided between eSF database 413 and cloud controller 408, but is located within the private cloud.

The cloud controller 408 interfaces with the browser client (user interface) 402. The browser client 402 provides content to the users 706 and allows them to access the service registry 524.

The integration of eSF with the service registry 524 ensures that access to cloud applications, network services, and user interface items such as buttons and menu options is limited to authorized system users. This is based on carefully defined roles that determine access for developers and users. Examples of this access control are discussed later.

Components of cloud applications developed in the cloud include a user interface, a registry of web services that provide potential reuse, and a registry of background jobs that can be reused. Developers creating cloud applications for deployment in a private cloud may also create business rules and/or Java classes related to the web services and jobs. Once the components of a cloud application are created, they can be stored in CLDB 410. The creation of these components can occur within the private cloud environment.

When developing network services, user interface components, and batch jobs, developers must perform a requirements analysis on cloud applications to identify the network services that embody their application, the user interface components needed to implement the cloud application's tasks, and the batch jobs needed to store the cloud application's data. While performing these tasks, within the cloud controller, developers can browse and search the service registry for registered services to determine if any can be reused in their cloud applications.

According to the system and method of the present invention, before a network service can be created for a cloud application, a developer must obtain an application identifier containing the cloud application code and its extensions. This allows the application to be tracked through the development process, including the generation of a cloud application profile for the cloud application. Preferably, before the cloud application can be further moved to a private cloud environment, the cloud application's source code is placed in a source code control system. Once this task is performed, the cloud application and its components can be developed using the cloud application builder 350 ( FIG. 3 ).

For a particular cloud application, the development of a network service component will involve developers generating metadata for the service definition and completing a service inventory file for the cloud application. Each cloud application will have an associated service inventory file that describes the functional groups in all member network services. The cloud controller 302 (Figure 3) uses this data to automatically update the service registry when the cloud application is deployed.

Preferably, developers build separate .war ("network archive") files for foreground and background processes (see Figure 5), package the binaries associated with the cloud application, and then generate a cloud application profile. The binaries associated with the foreground process relate to network services and user interface components. The binaries associated with the background process relate to jobs. However, before developers can deploy network services for use in the cloud, they must obtain appropriate approvals, which will trigger updates and adjustments to the service registration for the associated eSF roles stored in eSF. This development process is illustrated in Figure 8.

FIG8 shows, generally at 800, a typical diagram of the process for developing a web service component for a cloud application deployed in a private cloud. As part of the cloud application development and deployment process, a developer 801 will develop web services associated with the cloud application at 804. While developing the web service at 806, the developer will update metadata in the service definition to be used at 808 to update the service inventory file. This completes a portion of web service development associated with cloud application development.

After updating the service inventory file at 808, the developer builds application binaries for foreground and background processes at 810. The binaries associated with the cloud application are packaged, and a request to deploy a network service is made at 812 using the cloud application profile generated for the cloud application. The developer sends this request to the cloud controller 814 using the client device user interface. Approval from an appropriately authorized user is requested at 816. If approval is denied, a notification is sent back to the developer via appropriate messaging. However, if approval is granted, an update is sent to the service registry for the network service at 818, and an update is made to the eSF at 820, allowing appropriate use of the network service. The network service is then provisioned in real time in the private cloud at 822. Preferably, the private cloud uses metadata in the service definition and service inventory file to automatically update the service registry when deploying a network service.

As mentioned above, user interfaces are also components of cloud applications. Cloud application builder 350 develops user interface components associated with a specific cloud application using CDT 354 and appropriate panels on the user interface. This toolkit allows developers to extend the network services associated with a cloud application into the user interface. Preferably, the toolkit will support user interface development based on Flash and Microsoft Office.

The cloud application deployed in the private cloud can be embedded in a non-cloud web page. If this is done, all the functions of the cloud application can be accessed from the user interface as a pop-up web page, but the network services will run in the private cloud.

The final component of a cloud application is background jobs. These are batch jobs that run in the background and store information in the cloud and other databases. Background jobs for a cloud application can run in two instances, which can be located on different machines. For example, these jobs could be actively running in parallel in two separate data centers. Background jobs can include processing that helps the cloud application server operate scalably while suspending foreground threads.

9 , a typical diagram for background job development and operation is shown at 900. In FIG9 , external services 902 are connected to a background cloud 909. External services 902 include an RDBMS 904, a messaging service 906, and a file transfer service 908. Each of these has been previously described with respect to other figures, and thus, these descriptions are equally applicable here and are incorporated by reference.

Background cloud 909 contains three typical cloud application instances at 910, 916, and 922, respectively. Application instance 910 represents batch jobs 912 and 914; application instance 916 represents batch jobs 918 and 920; and application instance 922 represents batch jobs 924 and 926. A scheduler (not shown) manages the jobs and operates multiple application instances, such as those shown in FIG9 . The batch jobs represented in background cloud 909 can be packaged in separate .war files that can contain multiple jobs. These jobs can then be stored in CLDB 410 and associated with the appropriate cloud applications.

As mentioned above, eSF operates cloud application security. Preferably, cloud application developers will set up eSF roles and use the eSF agent API to ensure that protected items are used. Referring to Figure 10, the use of eSF security is explained in detail.

Referring to Figure 10 , a typical diagram for implementing eSF security is shown generally at 1000. When a system user requests access to a cloud application or network service, the system user, shown as a service consumer 1002, must be authenticated. Therefore, SiteMinder 1004 checks the system user's authentication by querying eDirectory 1006. If authentication is confirmed, the requested network service 1008 associated with the cloud application communicates with the eSF agent 1010 to check the system user's eSF rights in the eSF database 1012. These rights include whether the system user is authorized to perform the function specified in the service request. If the system user is authorized, the system user can access database information via the network service at 1014. If the system user is not authorized, access is denied.

We previously discussed how access to cloud applications and network services can be role-based. For the purposes of this invention, a functional group is a collection of functions that enables an authorized system user to perform actions on any data related to that system user's job description. Preferably, a functional group will have access to specific data defined by the cloud application developer. Functional groups and functions will be defined in the service inventory file and deployed as part of the application binary file, which will update the service registry and the eSF database. Figure 11 shows an example of the formation of functional groups and the services accessed by these functional groups.

FIG11 shows, generally at 1100, a diagram of functional groups associated with cloud applications and the services accessed by each of these groups. A cloud application labeled "Host Feeder" is shown in the cloud application block 1102. The developer of the Host Feeder cloud application 1104 has defined two functional groups in the functional group block 1106. The first functional group at 1108 is defined with management functionality, and the second functional group at 1110 is defined with browsing functionality.

At service block 1112, a registration service is shown on the host feeder cloud application 1104. With respect to the first functional group at 1108, the functional group is allowed to execute services registered as 791002, 791003, and 791004. This will allow the first functional group to create a host, add a feeder, and remove a feeder, respectively.

Regarding the second functional group at 1110, this functional group is allowed to execute the services registered as 792001 and 792002. This will allow the second functional group to find the host and get the feeder respectively. Note that the second functional group will not be allowed to access the services authorized for the first functional group.

The definition of functional groups is based on cloud application roles. Referring to Figure 12, the method of defining functional groups by these roles is discussed.

Referring to FIG. 12 , the use of cloud application roles to define functional groups is generally shown at 1200. Cloud application block 1202 represents a cloud application labeled "Host Feeder." In cloud application role template block 1206, application developers have defined roles associated with the Host Feeder cloud application. These roles are Host Feeder Administrator at 1208 and Host Feeder User at 1210. Cloud application role templates are preferably constructed by evaluating the functions that system users must perform, assembling these functions into functional groups, and identifying data groups containing all data that can be manipulated by system users.

12, at functional block 1214, the host feeder administrator role represented at 1208 can be divided into two functional groups. The first functional group is one of administrative functions that the system user would be allowed at 1216, and the second is only browsing functions at 1218.

As described above, the cloud application role defined by the developer of the cloud application also provides a host feeder user at 1210. The functional group assigned to the role is allowed browsing functions at 1220. These browsing functions can be the same or different than those for the host feeder administrator and still be within the scope of the present invention.

The cloud application role template will be part of the service inventory file and the eSF will be updated when the cloud application is deployed in the private cloud.

FIG13 shows the eSF rights diagram for the administrator role shown in FIG12 at 1300. Function block 1302 shows the functions available to the first function group at 1316 and the second function group at 1318 in function group block 1314. As shown, the first function group at 1316 is allowed the functions of editing a host at 1304, adding a feed at 1306, and removing a feed at 1308. Similarly, the second function group at 1318 is allowed the functions of browsing a host at 1310 and browsing a feed at 1312.

In role block 1320, it is indicated that the role at 1322 is for an administrator at ABC Company. In data block 1324, it is indicated that the administrator receives data at 1326 regarding ABC Company's funds, which may be mutual funds, for example. Data block 1328, which may be a repository for specific data regarding ABC Company's funds, contains data at 1330 for ABC1, data at 1332 for ABC2, and data at 1334 for ABC3, which the administrator at 1322 will access via data block 1324 at 1326. When previewing the entitlement graph for the host feeder cloud application, functional group-based restrictions are implemented according to the graph.

FIG14 shows the eSF rights graph for the user roles shown in FIG12 at 1400. Function block 1402 shows the functions available for a first function group at 1416 and a second function group at 1418 in function group block 1414. As shown, the first function group at 1416 allows the functions of editing a host at 1404, adding a feed at 1406, and removing a feed at 1408. Similarly, the second function group at 1418 allows the functions of browsing a host at 1410 and browsing a feed at 1412.

In role block 1420, it is indicated that the role at 1422 is for a system user at ABC Company. In data block 1422, it is indicated that the system user receives data at 1426 regarding ABC Company's funds, which may be mutual funds, similar to FIG13 . Data block 1428, which may be a repository for specific data regarding ABC Company's funds, contains data at 1430 for ABC1, data at 1432 for ABC2, and data at 1434 for ABC3, which the system user at 1422 will access via data block 1424 at 1426. When previewing the rights graph for the host feeder cloud application, functional group-based restrictions are implemented according to the graph. Therefore, since the role at role block 1420 is only for the system user, the system user is only allowed to browse the function at 1418 in functional block 1414. As part of this functional group, the system user is only allowed to browse the browse host at 1410 and the browse feeder at 1412 in functional block 1402.

The process for developing and deploying cloud applications in a private cloud was previously discussed with respect to Figure 8. This process is now described in more detail with reference to Figures 15-22.

Preferably, there are five main steps for deploying a cloud application in a private cloud. This process may be referred to as a cloud application promotion process. These five main steps include packaging the application binary and exporting the packaged application binary to the private cloud, generating and editing a cloud application profile for deploying the cloud application in the private cloud, obtaining appropriate approvals for deploying the cloud application in the private cloud, performing a proof-of-concept build of the application so that it can be promoted to user acceptance testing ("UAT"), and configuring and changing system properties in the cloud application profile for promoting the cloud application to the private cloud.

Before beginning the cloud application promotion process by deploying the cloud application to the development ("DEV") environment, the developer will preferably have obtained the application identifier for the application as discussed above. Furthermore, the developer will have requested that the appropriate cloud controller access eSF role rights be set up in the developer's eSF so that the developer has the appropriate role for deploying the cloud application. The developer will create a build project for the cloud application in the cloud application builder 350 ( FIG. 3 ) and run appropriate tests on the cloud application. The developer will then build the cloud application in the cloud application builder so that the developer is ready to package the binaries associated with the cloud application for export to the private cloud.

Once the above steps are completed, the cloud application binary is packaged, and the cloud controller promotes the approved, secure network services associated with the cloud application to the private cloud. According to the present invention, the binary packager can be called from the developer's client device after the build for proof of concept ("POC"), DEV, and system integration ("SYS") deployments. However, for UAT and production ("PROD") deployments, the binary packager can only be called through a high-level build machine, such as a ClearCase build machine or other certified build machine.

For the purposes of the present invention, in POC and DEV deployments, a developer can build a .war file from his/her client device. In order to promote the cloud application image to UAT in SYS, this is preferably done from a designated machine, such as an authorized machine where the developer can run ClearCase build scripts or other change control mechanisms.

Cloud applications deployed for UAT and PROD do not proceed directly from the build to the private cloud. When a developer creates a cloud application profile for UAT, they prefer to select the cloud application to be built for SYS on a certified build machine where the ClearCase build script can run. For PROD, the developer selects the cloud application to be promoted to UAT. This ensures that the cloud application deployed in UAT and PROD is identical to the cloud application tested in the environment during the previous application promotion process. While a preferred method for application promotion has just been described, it should be understood that other methods are possible and still within the scope of the present invention.

The four deployment environments described above are now discussed with respect to the promotion process related to the generation of cloud application profiles.

DEV - After the developer has completed deploying and testing the cloud application, they can export the cloud application's .war file to the private cloud. Using the user interface, the developer selects the Application Profile tab. The cloud application's initial status is Draft. The developer provides the appropriate information to complete the cloud application profile and selects the cloud application associated with it. The developer then changes the status to Public. Upon approval from the appropriate level of cloud administrator, the developer's cloud application will run in the DEV environment.

SYS - Only cloud applications running in DEV can be promoted to SYS. In SYS, cloud applications can be built on authenticated build machines, such as those running ClearCase build scripts.

UAT - Only cloud applications running in SYS can be promoted to UAT.

PROD - Only cloud applications running in UAT can be promoted to PROD, where such cloud applications will run live on the private cloud.

Now, a method for generating a cloud application profile and changing the status of a cloud application from draft to public will be described with reference to FIG. 15 to FIG. 22 .

15 , a typical cloud application control panel is shown at 1500 and 1502. To create a new application profile, activating the Application Profiles tab 1504 will provide a lower screen with an Add Application Profile tab 1506. As shown in status line 1508, the initial state is always Drafting. Activating the Add New button 1510 will result in the display of the Add New Application Profile window 1600.

16 , in Add New Application Profile 1600 , type the name of the cloud application in the Name field 1602 . Then, in the Application Code field 1604 , select the button to provide a drop-down list and select the appropriate application identifier assigned to that particular cloud application. The remainder of the profile must now be completed.

First, enter the version of the application in the Version field 1606. Then, in the Regional Environment field 1608, select the button to provide a drop-down list and select the environment appropriate for the deployment. Similarly, in the Regional Code field 1610, select the button to provide a drop-down list, such as the drop-down list generally represented by 1700 in FIG. 17 . When the appropriate regional code is selected, it will be entered into the Regional Code field 1610.

Next, select an effective date and time in the Effective Date field 1612. Selecting a date in the future will complete the approval process, and this will be the date the private cloud begins running the cloud application. If the effective date passes without approval, the private cloud will begin running the cloud application when the approval process is completed. You can also complete the Expiration Date field 1614, but this is optional.

The context column 1616 will contain the context of the cloud application. For example, the context column will provide the fully qualified path of the cloud application, such as, for example, http://Cloud.statestreet.com/Appl/[default].

In the request mode column 1616, add the service request prefix or other characters. For example, the service request prefix found in this column for routing is provided by the cloud controller.

To enter the application image bar 1620, activate button 1622, which will open the image browser dialog window 1800 in Figure 18. Here, select the appropriate cloud application. By selecting the information icon on 1802, the dialog window shown at 1900 in Figure 19 is displayed, which shows the cloud application details. Once it is confirmed that the cloud application details are correct, activate the relevant image tab 1902, which will open the display window at 2000 in Figure 20. After verifying the information in the display window shown in Figure 20, the window is closed together with the image browser window shown in Figure 19. Then, the Select Image button on 1804 in Figure 18 is activated, and then the Save button on 1624 in Figure 16 is activated to save the new application profile. When saving is completed, the status of the cloud application is set to Draft.

To change the status from DRAFT to PUBLISHED, button 1628 in status bar 1626 in Figure 16 must be activated. This will open the application change profile status display window shown in Figure 21 at 2100. In the new status bar 2102, the button at 2104 is selected to provide a drop-down list, and the appropriate status, in this example PUBLISHED, is selected.

Then, the View Warning button at 2106 is activated, which will open the Open Warning Dialog window 2200 shown in Figure 22. If the warning is accepted, the Accept button at 2202 is activated, and the cloud application's status becomes public, and once all approvals are obtained, it can be launched in the private cloud. However, if the Decline button at 2204 is activated due to the nature of the warning, the application's status becomes public, and it will not be launched in the private cloud.

[0014] The use of alerts in the development and deployment of cloud applications has been discussed generally. Now, alerts are discussed in more detail.

While the cloud application profile is in the draft state, cloud application developers can make changes to the cloud application profile. The automated audit service is a set of rules that are applied to each change made to the cloud application profile.

A warning is generated for each failed automated audit rule. As mentioned above, warnings are categorized as INFO, WARN, ERROR, and FATAL. Developers should preferably preview warnings associated with each cloud application profile change. Furthermore, if the warning is non-INFO and related to a specific cloud application profile, the appropriate approver, the cloud administrator, must preview the warning before the cloud application can be promoted to live on the private cloud.

As described above, the approver can accept or decline the warning after previewing it. If the approver accepts the warning, the cloud application will move forward in the development and deployment process. However, if the approver declines the warning, the cloud application will be moved back by setting the cloud application profile status to "Denied" with the warning reason code "Denied." The generated warning can be automatically sent to the approver via email or other messaging methods to notify them of the generation of the warning.

Generally, an automated audit mechanism is used to identify issues and problems in cloud application profiles. The automated audit mechanism contains rules that generate automatic alerts when any of the rules being checked result in a failure. The automated audit rules are generated by the cloud administrator.

Warnings are associated with issues and problems in the cloud application profile and, once generated, must be accepted or declined by the appropriate level of approval from the cloud administrator. If the cloud administrator accepts a warning associated with the cloud application profile, the cloud application moves forward toward live display in the private cloud. If the warning is declined, the cloud application is rejected and the cloud application profile status changes to Draft. If this is the case, the developer must fix the problem before the application can move forward to public.

Referring to FIG. 23A , a typical diagram illustrating actions related to applications to which automated audit rules are applied is shown at 2250 . At 2252 , when the associated cloud application profile changes while in the drafting state, automated audit rules are applied to the cloud application. During the "Detect" phase, a warning is generated for each failed automated audit rule. As described above, warnings are categorized as INFO, WARN, ERROR, or FATAL.

In the "Preview" phase at 2254, developers will preview warnings after each change to the cloud application profile. The cloud administrator's approver previews each warning. In the "Control" phase, the cloud administrator's approver must accept or decline the warning after previewing.

A typical set of automated audit rules is shown collectively at 2300 in FIG. 23B . Referring to FIG. 23B , a typical set of automated audit rules is shown at 2302 . Ten rules are shown, but this group of ten is merely exemplary. With respect to each rule, there is a severity of the rule shown at 2304 . The severity is defined by one of four warning states, INFO, WARN, ERROR, and FATAL. At 2306 , there is an explanation of the warning. Thus, when there is a change in any cloud application profile state, each of the automated audit rules is checked, and to the extent that there is any violation, a warning will be logged for that cloud application. Only when these warnings are accepted by the appropriate approval personnel can the cloud application move forward in the development and deployment process.

In FIG4 , user interface 402 represents dashboard 406. A typical dashboard display is generally shown at 2400 in FIG24 . As shown, cloud applications and regions can be viewed in detail or graphically, providing an overview of the health of cloud applications. In FIG24 , for a cloud application shown at 2401 , application details are shown at 2402 , virtual machine details are shown at 2406 , and virtualization details are shown at 2408 . Furthermore, a graphical display of regions is shown at 2410 .

The graphical display of the area at 2410 indicates that the health of the network with respect to TX/SLO at 2412 and users at 2418 is very good, as the indicator arrow has clearly entered the green zone. The health of the physical machine shown at 2416 is less good, as the indicator arrow is approaching the yellow or warning zone. Finally, the health of the virtual machine shown at 2414 is not good, as the indicator arrow is in the red zone. Preferably, since the indicator arrow is in the red zone, the cloud administrator is alerted to this and, if possible, corrects the load issue associated with the virtual machine.

It will be appreciated that there may be a selection of various tabs represented on the dashboard display 2400 and that this will provide additional health information regarding the system applications and infrastructure.

When describing the service registry 524 with respect to Figures 6 and 7, the contents of the service registry were discussed but not shown. Furthermore, as previously discussed, the service registry enables authorized system users to access network service details associated with a service registry entry. Typical screen displays of the service registry window and the network service details window are shown in Figures 25 and 26.

Referring to FIG. 25 , a typical service registry display window is generally shown at 2500. As shown at 2502, each registry entry has a number, name, description, and additional information related to the service. This information allows authorized system users to search for services. If an authorized system user desires detailed information about a particular entry in the service registry, they can obtain it by selecting the service entry, which will open a network service details window such as that shown in FIG. 26 .

26 , a service registration display 2602 is generally shown at 2600 with a network service details display 2604 window. If an authorized system user selects service registration number 511446 in service registration window 2602, a network service details display window 2604 for service registration number 511446 will open, providing specific details regarding that registration number. Display window 2604 shows basic information regarding service registration number 511446; however, by selecting any of the additional tabs, additional detailed information regarding that registration number will be provided.

27 to 32 , a typical cloud application deployment workflow will be described.

27 , a cloud application deployment workflow is shown for POC/DEV/SYS environments at 2700 . POC/DEV/SYS are unified into zones. This diagram shows the process a cloud application profile must go through when deploying a cloud application to POC, DEV, and SYS environments.

At 2702, the developer will be able to access the cloud application profile to edit the fields of the profile file as long as it has a draft status, as shown at 2704. Once the developer is satisfied with the changes to the cloud application profile, the status in the cloud application profile should be changed to public at 2706.

The lead developer will then preferably review the application profile and, when satisfied with it, change the cloud application's status to Lead Approved, as shown at 2208. However, if the lead developer is not satisfied, he or she can reject the application, as shown by the rejection at 2710, which will return the cloud application profile's status to Draft.

If the lead developer approves the cloud application, the cloud application profile will be forwarded to the cloud controller at 2711. The taking-over cloud controller now validates the cloud application profile and changes the state of the cloud application profile to scheduled, as shown at 2712. The application profile will remain in this state until it is time to deploy the private cloud.

Typically, the cloud application profile indicates when to deploy the cloud application. When the deployment time arrives, the cloud controller changes the cloud application profile's status to Installed at 2713, simultaneously implementing the cloud application's provisioning. The cloud controller retrieves the service inventory file, reads the service metadata and access control information, updates the eSF at 2715, and updates the service registration at 2714. Once the installation is complete, the cloud application profile's status changes to Running at 2716. Preferably, Running means the cloud application is currently running in the private cloud.

Referring to FIG. 28 , a cloud application deployment workflow for the POC/DEV/SYS environment is shown at 2800. POC/DEV/SYS are unified into a single zone. In FIG. 28 , the workflow processes involving drafting at 2704, publishing at 2706, team leader approval at 2708, rejection at 2710, scheduling at 2712, installation at 2713, updating eSF at 2715, and registering updates at 2714 are identical to those in FIG. Therefore, the descriptions of these items in FIG. 27 apply equally here and are incorporated by reference.

When the cloud application is deployed to the UAT and PROD environments, the workflow requires three additional approvals after the team leader approval at 2708. These approvals include the administrator approval at 2802, the SQA approval at 2804, and the business approval at 2810. There may be more or less than three additional approvals and still be within the scope of the present invention.

29 , a cloud application deployment workflow for an emergency condition is shown at 2900. In FIG29 , the drafting at 2704, the publishing at 2706, the team leader approval at 2708, the rejection at 2710, the administrator approval at 2802, the SQA approval at 2804, the business approval at 2810, and the scheduling at 2712 are the same as those shown in FIG28 , except that the team leader approval at 2708 and the administrator approval at 2802 are part of the developer 2702, and the SQA approval at 2804 and the business approval at 2810 are grouped in an alternative process 2904 that includes the emergency approval 2904. Therefore, the description of these items in FIG28 is equally applicable here and is incorporated by reference.

If a developer requests that a cloud application profile be moved as an emergency deployment, the workflow of Figure 29 will be used. In the emergency deployment workflow, SQA and business approvals can be skipped by personnel who have access to the emergency approval authorization at 2904. Preferably, the emergency workflow is used to deploy unexpected but critical technical changes that need to be moved forward urgently for deployment.

30 , a paused cloud application deployment workflow is collectively shown at 3000. In FIG29 , the workflow processes involving drafting at 2704, publishing at 2706, team leader approval at 2708, rejection at 2710, administrator approval at 2802, SQA approval at 2804, business approval at 2810, scheduling at 2712, and emergency approval at 2904 are the same as those shown in FIG29 . Therefore, the descriptions of these items in FIG29 are equally applicable here and are incorporated by reference.

Use the Pause workflow when you need to move cloud applications within a monthly or other fixed time period. For example, it can coincide with the last and first business days of a month. During this time, changes to live cloud applications are restricted.

30, alternative workflow 2902 includes Suspend Approval 1 at 3002 and Suspend Approval 2 at 3004. These latter approvals are obtained from higher-level entities within the enterprise.

31 , a cloud application deployment workflow for removing an application from a deployment process is generally shown at 3100. When cloud application deployment results in an unexpected failure of the cloud application, it may be necessary to remove the deployed version of the cloud application from the private cloud.

When a problem is detected in a deployed cloud application, a decision is made as to whether to remove the application. This can be accomplished by generating an application "removal" file. This file can be generated using the binaries of the cloud application deployed before the problem occurred. Using these binaries, developers can generate a removal profile.

31 , a teardown application deployment workflow is illustrated. At 3102 , once there is a problem with the detection of a deployed version of a cloud application, a decision must be made whether to generate and use a teardown profile.

If a decision is made to create a teardown profile, the process proceeds to 3104. At 3104, the teardown profile can be created using the application control panel. When creating a teardown profile, only previously deployed cloud applications can be used. Furthermore, once a teardown profile is created, it cannot be changed. An activity log keeps track of the history associated with the teardown profile.

Once the removal document is generated, the process moves to 3106 where appropriate approvals must be obtained. These approvals are obtained in a manner consistent with at least the workflows shown in Figures 27 to 30 and 32.

32 , an alternative cloud application deployment workflow incorporating automated alerts is collectively shown at 3200. In FIG32 , the workflow processes involving drafting at 2704, publishing at 2706, team leader approval at 2708, rejection at 2710, administrator approval at 2802, SQA approval at 2804, business approval at 2810, and scheduling at 2712 are identical to those shown in FIG29 . Therefore, the descriptions of these items in FIG29 are equally applicable here and are incorporated by reference.

The workflow shown in Figure 32 incorporates the use of automated audit rules at each stage. At 2704, a cloud application with a Draft status has its cloud application profile changed at 3202. Consequently, the automated audit rules evaluate the change at 3204. This generates an application profile warning at 3206. The developer then fixes the issue causing the warning at 3208. If the fix is deemed appropriate, the cloud application is published at 2706. However, at each stage in the alternative workflow at 3205, each approval level must accept the warning for the application to move to the next approval stage, as shown at 3010, 3012, 3014, and 3016. If the warning is rejected at any of the approval stages, the workflow moves to Reject Warning at 3218, and the application is rejected at 2710. When an application is rejected in this manner, its status returns to Draft, and the process must begin again to move the cloud application to deployment in the private cloud.

Embodiments of the systems and methods of the present invention, or portions thereof, may be implemented in computer hardware, firmware, and/or computer programs executed on a programmable computer or server, each comprising a processor and a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements). Any computer program may be implemented in a high-level procedural or object-oriented programming language to communicate within or outside a computer-based system.

Any computer program may be stored on an article of manufacture such as a storage medium (e.g., a CD-ROM, hard disk, or magnetic disk) or device (e.g., a computer peripheral) that can be read by a general-purpose or special-purpose programmable computer, so as to configure and operate the computer to perform the functions of the embodiments when the storage medium or device is read by the computer. The embodiments or portions thereof may also be implemented as a machine-readable storage medium configured by a computer program, where, when the computer program is executed, the instructions in the computer program cause the machine to act to perform the functions of the embodiments described above.

The embodiments of the systems and methods of the present invention described above, or portions thereof, may be used in a variety of applications. The embodiments or portions thereof are not limited in this respect, but rather, may be implemented using memory devices in microcontrollers, general-purpose microprocessors, digital signal processors (DSPs), reduced instruction set computing (RISC), complex instruction set computing (CISC), and other electronic components. Furthermore, the embodiments or portions thereof may also be implemented using integrated circuit blocks called main memory, cache memory, or other types of memory that store electronic instructions executed by a microprocessor or store data that can be used in arithmetic operations.

The description is applicable in any computing or processing environment. The embodiments or portions thereof may be implemented in hardware, software, or a combination of both. For example, the embodiments or portions thereof may be implemented using circuits such as one or more of programmable logic (e.g., ASICs), logic gates, processors, and memories.

Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles set forth below may be applied to other embodiments and applications. Therefore, the present invention is not intended to be limited to the embodiments shown or described herein.

Claims (51)

1. A computer-based system having a virtual machine infrastructure for hosting multiple virtual machine environments in a cloud computing environment, the system comprising: At least one system user interface connected to the cloud computing environment, wherein the at least one system user interface initiates a virtual machine environment in the cloud computing environment by sending a request to the cloud computing environment for accessing and using applications and/or virtual machine services that can be accessed through the cloud computing environment; At least one provider connected to the at least one system user interface in the cloud computing environment, wherein the at least one provider is used to balance the distribution of requests for application and/or virtual machine services from the at least one system user interface among a plurality of active first server types and a plurality of active second server types in the cloud computing environment. At least one active first server type connected to the provider is used to route requests received from the at least one system user interface for accessing and/or using virtual machine services stored in or accessible through the cloud computing environment; A plurality of second server types are connected to the at least one active first server type, wherein the second server types are used to route requests for application and/or virtual machine services received from the at least one system user interface; and A cloud database connected to the second server type and the at least one system user interface, wherein the cloud database receives a request for accessing a virtual machine service in the cloud database and makes the requested virtual machine service available to the at least one system user interface for running in a virtual machine environment in the cloud computing environment, wherein the cloud computing environment is associated with an active first server type and one or more active second server types. 2. The system according to claim 1, wherein the cloud computing environment includes a public cloud. 3. The system according to claim 2, wherein the at least one system user interface is connected to the cloud computing environment via wired or wireless connection. 4. The system according to claim 1, wherein the cloud computing environment includes a private cloud. 5. The system according to claim 4, wherein the cloud computing environment includes an enterprise-wide private cloud. 6. The system of claim 4, wherein the at least one system user interface is connected to the cloud computing environment via a wired or wireless connection. 7. The system of claim 1, wherein the at least one system user interface comprises a personal computer, a personal digital assistant, a tablet device, or a smartphone. 8. The system of claim 1, wherein the provider includes a load balancer for providing services to balance the distribution of requests for application and/or virtual machine services from the at least one system user interface among a plurality of first server types and second server types. 9. The system of claim 8, wherein the plurality of first server types include at least two web servers, and the load balancer balances the distribution of requests for application and/or virtual machine services from the at least one system user interface between the two web servers. 10. The system of claim 1, wherein the request sent from the at least one system user interface to the cloud computing environment includes a request formatted according to the Hypertext Transfer Protocol (HTTP). 11. The system according to claim 1, wherein the first server type includes a web server. 12. The system according to claim 1, wherein the second server type includes an application server. 13. The system according to claim 1, wherein the virtual machine service includes a virtual desktop service. 14. A computer-based system having a virtual machine infrastructure for hosting multiple virtual machine environments in a cloud computing environment, the system comprising: Multiple system user interfaces connected to the cloud computing environment, wherein each system user interface initiates a virtual machine environment in the cloud computing environment by sending a request to the cloud computing environment for accessing and using applications and/or virtual machine services that can be accessed through the cloud computing environment; At least one provider connected to the plurality of system user interfaces in the cloud computing environment, wherein the at least one provider is used to balance the distribution of requests for application and/or virtual machine services from the plurality of system user interfaces among a plurality of active first server types and a plurality of active second server types in the cloud computing environment. A plurality of first server types are connected to the provider, wherein each active first server type is at least used to route requests received from the plurality of system user interfaces for accessing and/or using application and/or virtual machine services stored in or accessible through the cloud computing environment and provided by the provider to each active first server type; and A plurality of second server types are connected to each first server type, wherein each active second server type is used to route requests for application and/or virtual machine services received from the plurality of system user interfaces to a plurality of hosted web services in each active second server type, wherein the hosted web services are selected based on the requests for application and/or virtual machine services from each of the plurality of system user interfaces. 15. The system of claim 14, wherein the cloud computing environment includes a public cloud. 16. The system of claim 15, wherein each of the plurality of system user interfaces is wired or wirelessly connected to the cloud computing environment. 17. The system of claim 14, wherein the cloud computing environment includes a private cloud. 18. The system of claim 17, wherein the cloud computing environment includes an enterprise-wide private cloud. 19. The system of claim 17, wherein each of the plurality of system user interfaces is wired or wirelessly connected to the cloud computing environment. 20. The system of claim 14, wherein each of the plurality of system user interfaces comprises a personal computer, a personal digital assistant, a tablet device, or a smartphone. 21. The system of claim 14, wherein the provider includes a load balancer for providing services to balance the distribution of requests for application and/or virtual machine services from the plurality of system user interfaces among a plurality of first server types and second server types. 22. The system of claim 21, wherein the plurality of first server types include at least two web servers, and the load balancer balances the distribution of requests for applications and/or web services from the plurality of system user interfaces between the two web servers. 23. The system of claim 14, wherein requests sent from the plurality of system user interfaces to the cloud computing environment include requests formatted according to the Hypertext Transfer Protocol (HTTP). 24. The system of claim 14, wherein each of the plurality of first server types includes a web server. 25. The system of claim 14, wherein each of the plurality of second server types includes an application server. 26. The system of claim 14, wherein the system further comprises a monitor for monitoring the number of requests for application and/or virtual machine services received by the cloud computing environment from the plurality of system user interfaces, for controlling the number of a first server type and a second server type that are activated and available to the provider for sending requests for application and/or virtual machine services from the plurality of system user interfaces. 27. The system of claim 14, wherein the virtual machine service includes a virtual desktop service. 28. A computer-based system having a virtual machine infrastructure for providing multiple virtual machine environments in a cloud computing environment, the system comprising: In the cloud computing environment, the provider receives multiple requests for desktop applications from multiple system user interfaces, wherein the provider is configured to balance the distribution of requests for desktop applications among multiple active first server types and multiple active second server types based on the number of requests received from the multiple system user interfaces for operating one or more virtual machine environments associated with active first server types and second server types in the cloud computing environment. A cluster of multiple first server types connected to the provider, wherein each of the multiple first server types can be activated and deactivated by the provider, and when activated, processes requests according to the provider's distribution of one or more requests to desktop applications from the multiple system user interfaces, and each activated first server type should be associated with a virtual machine environment running in the cloud computing environment; and A cluster of multiple second server types, wherein the cluster is connected to each of the multiple first server types, each of the multiple second server types being able to be activated and deactivated by the provider, and when activated, processing such requests according to the provider's distribution of one or more requests to desktop applications from the multiple system user interfaces, and each activated second server type, together with the connected activated first server type, should be associated with a virtual machine environment in the cloud computing environment. 29. The system of claim 28, wherein the cloud computing environment includes a public cloud. 30. The system of claim 29, wherein each of the plurality of system user interfaces is wired or wirelessly connected to the cloud computing environment. 31. The system of claim 28, wherein the cloud computing environment includes a private cloud. 32. The system of claim 31, wherein the cloud computing environment includes an enterprise-wide private cloud. 33. The system of claim 31, wherein each of the plurality of system user interfaces is wired or wirelessly connected to the cloud computing environment. 34. The system of claim 28, wherein the provider includes a load balancer for providing services for the plurality of first server types and the plurality of second server types to balance the distribution of requests for desktop applications from the plurality of system user interfaces among the plurality of first server types and second server types. 35. The system of claim 34, wherein each of the plurality of first server types includes a web server. 36. The system of claim 35, wherein the plurality of first server types include at least two web servers, and the load balancer balances the distribution of requests for desktop applications from the plurality of system user interfaces between the two web servers. 37. The system of claim 36, wherein the plurality of second server types comprises a cluster of application servers, wherein the cluster of application servers is connected to each of the web servers. 38. The system of claim 30, wherein the system further comprises a monitor for monitoring the number of requests for desktop applications received by the cloud computing environment from the plurality of system user interfaces, and for controlling the number of activated first server types and activated second server types available for the provider to send requests for desktop applications from the plurality of system user interfaces. 39. A computer-based system having a virtual machine infrastructure for hosting multiple virtual machine environments in a cloud computing environment, the system comprising: Multiple system user interfaces connected to the cloud computing environment, wherein each system user interface initiates a virtual machine environment by sending a request to the cloud computing environment for accessing and using applications and/or virtual machine services in the cloud computing environment; The cloud controller connects to the plurality of system user interfaces to provide services for receiving requests for application and/or virtual machine services from the plurality of system user interfaces, and for providing virtual machine environments and associated virtual machine environment controls in the cloud computing environment based on the number of requests received from the plurality of system user interfaces. Multiple virtual machine environments and associated virtual machine environment controls are activated and deactivated by the service provided. Each activated virtual machine environment and associated virtual machine environment control runs a web server instance and an application instance based on the number of requests for application and/or virtual machine services provided to each activated virtual machine environment and associated virtual machine environment control by the service provided. The cloud controller connects to the monitoring service that provides the service, for monitoring the number of requests for application and/or virtual machine services from the plurality of system user interfaces, and for controlling the service to activate or deactivate a specific and associated virtual machine environment control in the plurality of virtual machine environments based on the number of requests for application and/or virtual machine services received from the plurality of system user interfaces; and A cloud database for storing virtual machine services, which can be retrieved or run in an associated virtual machine environment, controlled by an associated virtual machine environment control based on the number of requests for applications and/or virtual machine services received from the plurality of system user interfaces. 40. The system of claim 39, wherein the cloud computing environment includes a public cloud. 41. The system of claim 40, wherein each of the plurality of system user interfaces is wired or wirelessly connected to the cloud computing environment. 42. The system of claim 39, wherein the cloud computing environment includes a private cloud. 43. The system of claim 42, wherein the cloud computing environment includes an enterprise-wide private cloud. 44. The system of claim 42, wherein each of the plurality of system user interfaces is wired or wirelessly connected to the cloud computing environment. 45. The system of claim 39, wherein the service provision includes a load balancer for balancing the distribution of requests for applications and/or virtual machine services from the plurality of system user interfaces among a plurality of active virtual machine environments and associated virtual machine environment controls. 46. The system of claim 39, wherein the virtual machine environment control includes a management program for controlling the associated virtual machine environment. 47. The system of claim 39, wherein the virtual machine service includes a virtual desktop service. 48. A computer-based method for operating a virtual machine infrastructure for hosting multiple virtual machine environments in a cloud computing environment, the method comprising the steps of: (a) Multiple system user interfaces send requests for applications and/or web services to the cloud computing environment; (b) The cloud computing environment receives requests for application and/or virtual machine services from the plurality of system user interfaces, and activates or deactivates the virtual machine environment and associated virtual machine environment controls based on the number of requests for application and/or virtual machine services received from the plurality of system user interfaces. (c) The active virtual machine environment and associated virtual machine environment control run web server instances and application instances based on the number of requests for applications and/or virtual machine services provided to each active virtual machine environment and associated virtual machine environment control; and (d) The monitoring service of the cloud computing environment monitors the number of requests for application and/or virtual machine services received from the multiple system user interfaces at a given point in time, and controls the service to activate or deactivate one or more virtual machine environments and associated virtual machine environment controls based on the number of requests for application and/or virtual machine services received from the multiple system user interfaces. 49. The method of claim 48, wherein the virtual machine environment control includes a management program for controlling the associated virtual machine environment. 50. The method of claim 48, wherein the service provision includes a load balancer for balancing the distribution of requests for applications and/or virtual machine services from the plurality of system user interfaces among a plurality of active virtual machine environments and associated virtual machine environment controls. 51. The method of claim 48, wherein the virtual machine service includes a virtual desktop service.