JP6181185B2 - LDAP-based multi-customer in-cloud identity management system - Google Patents

Description

This application claims the benefit and priority of the following applications, the entire contents of which are hereby incorporated by reference for all purposes.

(1) US Provisional Application No. 61 / 698,413, filed September 7, 2012, entitled “Tenant Automation System”;
(2) US Provisional Application No. 61 / 698,459, filed September 7, 2012, entitled “Service Development Infrastructure”;
(3) US Provisional Application No. 61 / 785,299, filed March 14, 2013, entitled “Cloud Infrastructure”;
(4) US Provisional Application No. 61 / 801,160, filed March 15, 2013 entitled “Separation of Pod Provisioning and Service Provisioning”;
(5) US Provisional Application No. 61 / 794,427 filed March 15, 2013 entitled “Cloud Infrastructure”; and (6) “Separation of Pod Provisioning and Service Provisioning” U.S. Application No. 13 / 844,018, filed March 15, 2013.

BACKGROUND This disclosure relates to computer systems and software, and more particularly to techniques for facilitating and automating provisioning of services in a cloud environment.

  Cloud computing is a model for enabling convenient on-demand network access to a shared pool of configurable computing resources (eg, networks, servers, storage, applications and services). A service provided or accessed via the cloud (or network) is called a cloud service. There are many processes that a cloud service provider needs to do in order for a subscribing customer to be able to use a cloud service. Because of its complexity, much of this processing is still done manually. For example, provisioning resources for providing such a cloud service can be a very labor intensive process.

This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used alone to determine the scope of the claimed subject matter. Absent. The subject matter should be understood by reference to the entire specification of this patent, any or all drawings, and appropriate portions of each claim.

  According to some embodiments, a method for POD provisioning and service provisioning is disclosed. The method may include storing, by the cloud infrastructure system, subscription order information from a customer that identifies a service from a set of cloud services provided by the cloud infrastructure system. A cloud infrastructure system includes one or more computing devices. Subscription order information includes customer specific configurations. In addition, the method may include determining a service associated with the subscription order information by any of the one or more computing devices. Further, the method can include mapping a pre-provisioned anonymous deployment to subscription order information. A pre-provisioned anonymous deployment is specifically pre-provisioned for the determined service. In addition, the method creates a service instance specifically for a customer by any of the one or more computing devices by configuring a pre-provisioned anonymous deployment with a customer specific configuration. Steps may be included.

  According to another embodiment, the system includes one or more computing devices that can be configured to provide a set of cloud services and subscription order information from a customer that identifies the services from the set of cloud services. And memory configurable to store. Subscription order information includes customer specific configurations. Any computing device of the one or more computing devices can be configured to determine a service associated with the subscription order information and map a pre-provisioned anonymous deployment to the subscription order information. A pre-provisioned anonymous deployment is specifically pre-provisioned for the determined service. The optional computing device can be further configured to specifically create a service instance for a customer by configuring a pre-provisioned anonymous deployment with a customer specific configuration.

  According to another embodiment, one or more computer-readable media storing computer-executable instructions for a cloud infrastructure system configured to provide a set of cloud services are provided. The computer-executable instructions, when executed, cause one or more computing devices in the cloud infrastructure system to store subscription order information from a customer that identifies a service from a set of cloud services, and the subscription order information. Includes customer specific configuration; further, determines the service associated with subscription order information; maps pre-provisioned anonymous deployment to subscription order information, and pre-provisioned anonymous deployment is determined Specifically pre-provisioned for the service; and by configuring the pre-provisioned anonymous deployment in a customer-specific configuration, To create a Nsu.

  According to another embodiment, a system for providing a set of cloud services includes one or more resource assemblies for a first service of a plurality of cloud services provided by a cloud infrastructure system. Means for maintaining a first set, wherein each resource assembly in the first set of resource assemblies includes one or more resources for providing a first service; Means for storing a plurality of subscription order information, the subscription order information including a customer specific configuration and an order request for a first service, the system further providing a first service to the customer Resource assembly based on subscription order information Means for selecting a first resource assembly from the first set and a first customer specific resource for providing a first service to the customer by configuring the first resource assembly in a customer specific configuration; Means for creating an assembly.

  According to another embodiment, a computer readable program or cloud infrastructure system configured to provide a set of cloud services is provided. A computer executable program causes a cloud infrastructure system to create a first set of one or more resource assemblies for a first service from a plurality of cloud services provided by the cloud infrastructure system, and Each resource assembly in the first set includes one or more resources for providing a first service; further, after creation, the subscription order information from the customer is received, and the subscription order information is Including a specific configuration and an order request for a first service; and further providing a first resource from a first set of resource assemblies based on subscription order information to provide the customer with the first service. Select assembly; first By configuring the resource assembly in a customer specific configuration for providing a first service to a customer, to create a first customer-specific resource assembly.

BRIEF DESCRIPTION OF THE DRAWINGS Exemplary embodiments of the invention are described in detail below with reference to the accompanying drawings.

1 is a logical diagram of a cloud infrastructure system according to an embodiment of the present invention. 1 is a simplified block diagram of a hardware / software stack that can be used to implement a cloud infrastructure system according to an embodiment of the present invention. FIG. FIG. 1B is a simplified block diagram of a system environment for realizing the cloud infrastructure system shown in FIG. 1A. 6 shows a simplified flowchart 300 illustrating processing that may be performed by a TAS module in a cloud infrastructure system according to an embodiment of the present invention. FIG. 4 shows a simplified high-level diagram of one or more submodules in a TAS module in a cloud infrastructure system according to an embodiment of the present invention. Fig. 3 illustrates an exemplary distributed deployment of TAS components according to an embodiment of the present invention. FIG. 4 is a simplified block diagram illustrating SDI module interaction with one or more modules in a cloud infrastructure system according to an embodiment of the present invention. FIG. 4 shows a simplified high level diagram of sub-modules of an SDI module according to an embodiment of the present invention. FIG. 6 illustrates a simplified flowchart illustrating processing that may be performed by an SDI component in a cloud infrastructure system according to an embodiment of the present invention. FIG. 3 shows a simplified block diagram illustrating a high level architecture of Nuviaq system 710 and its relationship with other cloud infrastructure components according to an embodiment of the present invention. FIG. 4 shows an exemplary sequence diagram illustrating steps of a provisioning process using a Nuviaq system according to an embodiment of the present invention. FIG. 3 shows an exemplary sequence diagram illustrating the steps of a deployment process using a Nuviaq system according to an embodiment of the present invention. Fig. 4 illustrates an example of a database instance provisioned for a database service according to an embodiment of the present invention. FIG. 6 illustrates a simplified flowchart illustrating processing that may be performed by an SDI module in a cloud infrastructure system according to an embodiment of the present invention. FIG. 6 illustrates a simplified flowchart illustrating processing that may be performed by an SDI module in a cloud infrastructure system according to an embodiment of the present invention. Fig. 5 illustrates a provisioning request flow according to some embodiments. Figure 2 illustrates an end-to-end flow for provisioning both Java and database services for a customer. FIG. 4 illustrates Java cloud service instance provisioning according to one embodiment. FIG. FIG. 6 illustrates Java cloud service instance provisioning and fusion application association according to one embodiment. FIG. Fig. 4 illustrates a PaaS and SaaS service association process according to some embodiments of the present invention. FIG. 3 shows a high level logic diagram of a database cloud service according to some embodiments. FIG. 6 illustrates a service provisioning flow for a multi-tenant database service according to some embodiments. 1 is a simplified block diagram of a computing system 1000 that may be used in accordance with an embodiment of the present invention. Fig. 3 shows a physical architecture of a pre-provisioned pod 1500 according to an embodiment of the present invention. FIG. 6 illustrates an example of customer-specific customization of a pre-provisioned pod for service instance creation according to an embodiment of the present invention (sometimes referred to as customer personality assignment). 6 illustrates an example method for creating a personalized JAVA service pod or service instance and a personalized database service pod or instance using a pre-provisioned pod, according to one embodiment. 1 is a simplified block diagram of an electronic device 1800 according to an embodiment of the present invention.

DETAILED DESCRIPTION In the following description, for the purposes of explanation, specific details are set forth in order to provide a thorough understanding of embodiments of the invention. However, it will be apparent that various embodiments may be practiced without these specific details. The drawings and description are not intended to be limiting.

  Certain embodiments of the present invention provide techniques for automating the provisioning, management and tracking of services provided by a cloud infrastructure system.

  In a particular embodiment, a cloud infrastructure system is a self-service, subscription-based, elastically scalable, reliable, highly available, secure set of applications, middleware and Database service offerings may be included. An example of such a cloud infrastructure system is the Oracle public cloud provided by the assignee.

  The cloud infrastructure system provides the ability to provision, manage and track customer subscriptions for services and resources in the cloud infrastructure system, the ability to provide predictable work costs to customers using services in the cloud infrastructure system, The ability to provide robust identity domain separation and protection of customer data in cloud infrastructure systems, the ability to provide customers with a transparent architecture and control of cloud infrastructure system design, data protection assurance and data privacy standards To build and deploy services in cloud infrastructure systems, functions that provide customers with regulatory compliance Many features, including but not limited to the ability to provide customers with an integrated development experience and the ability to provide customers with seamless integration between business software, middleware, databases, and infrastructure services in a cloud infrastructure system Can be provided.

  In certain embodiments, services provided by cloud infrastructure systems include online data storage and backup solutions, web-based email services, hosted office suites and document collaboration services, database processing, managed technical support services, etc. It may include a number of services that are available on demand to users of cloud infrastructure systems. The services provided by the cloud infrastructure system can be dynamically scaled to meet the needs of its users. A specific instantiation of a service provided by a cloud infrastructure system is referred to herein as a service instance. In general, any service that a user can use from a cloud service provider system via a communication network such as the Internet is called a cloud service. In general, in a public cloud environment, the servers and systems that make up the cloud service provider's system are different from the customer's own on-premises servers and systems. For example, a cloud service provider's system can host an application and a user can order and use the application on demand via a communication network such as the Internet.

  Services in a computer network cloud infrastructure are provided to users by cloud vendors or otherwise protected to storage, hosted databases, hosted web servers, software applications or other services known in the art. Computer network access included. For example, a service may include password protected access to remote storage on the cloud over the Internet. As another example, a service may include a web service-based hosted relational database and scripting language middleware engine for private use by networked developers. As another example, the service may include access to an email software application hosted on a cloud vendor's website.

  FIG. 1A is a logical diagram of a cloud infrastructure system according to an embodiment of the present invention. The cloud infrastructure system 100 can provide various services via a cloud or networked environment. These services include Software as a Service (SaaS) category, Platform as a Service (PaaS) category, Infrastructure as a Service (Infrastructure as a Service). a Service: IaaS) category, or may include one or more services provided under other categories of services including hybrid services. A customer may order one or more services provided by the cloud infrastructure system 100 via a subscription order. The cloud infrastructure system 100 then performs a process to provide a service in the customer's subscription order.

  The cloud infrastructure system 100 can provide cloud services through various deployment models. For example, the service is owned by an organization that sells cloud services (e.g., owned by Oracle), where the cloud infrastructure system 100 is sold, and the service is of a public cloud model where the public enterprise or various industrial companies can use it. May be provided below. As another example, the services are provided under a private cloud model where the cloud infrastructure system 100 is operated solely for a single organization and can provide services to one or more entities within the organization. May be. The cloud service may also be provided under a community cloud model in which the cloud infrastructure system 100 and the services provided by the system 100 are shared by several organizations in the associated community. The cloud service may also be provided under a hybrid cloud model that is a combination of two or more different models.

  As shown in FIG. 1A, the cloud infrastructure system 100 may comprise a plurality of components that operate in concert that allow provisioning of services provided by the cloud infrastructure system 100. In the example shown in FIG. 1A, the cloud infrastructure system 100 includes a SaaS platform 102, a PaaS platform 104, an IaaS platform 110, an infrastructure resource 106, and a cloud management function 108. These components may be implemented in hardware or software or a combination thereof.

  The SaaS platform 102 is configured to provide cloud services that fall into the SaaS category. For example, the SaaS platform 102 may provide functionality for building and delivering a set of on-demand applications on an integrated development and deployment platform. The SaaS platform 102 may manage and control the basic software and infrastructure for providing SaaS services. By utilizing the services provided by the SaaS platform 102, customers can utilize applications running on the cloud infrastructure system 100. Customers can obtain application services without the customer having to purchase separate licenses and support.

  A variety of different SaaS services can be provided. Examples include, but are not limited to, services that provide solutions for sales performance management, enterprise integration and business flexibility for large organizations. In one embodiment, the SaaS service includes a customer relationship management (CRM) service 110 (eg, a fusion CRM service provided by Oracle Cloud), a human capital management (HCM) / talent management service 112, etc. May be included. CRM services 110 may include services directed to reporting and managing sales activity cycles to customers. HCM / talent services 112 may include services directed to providing global workforce lifecycle management and talent management services to customers.

  A variety of different PaaS services may be provided by the PaaS platform 104 in a standardized, shared, elastically scalable application development and deployment platform. Examples of PaaS services include services that allow organizations (such as Oracle) to aggregate existing applications on a shared common architecture, and new services that leverage shared services provided by the platform A function for building an application may be mentioned, but is not limited thereto. The PaaS platform 104 may manage and control the basic software and infrastructure for providing PaaS services. The customer can obtain the PaaS service provided by the cloud infrastructure system 100 without the customer having to purchase separate licenses and support. Examples of the PaaS service include, but are not limited to, an Oracle Java (registered trademark) cloud service (Java Cloud Service: JCS), an Oracle database cloud service (Oracle Database Cloud Service: DBCS), and the like.

  By utilizing the services provided by the PaaS platform 104, customers can take advantage of programming languages and tools supported by the cloud infrastructure system 100 and can also control deployed services. In some embodiments, the PaaS service provided by the cloud infrastructure system 100 may include a database cloud service 114, a middleware cloud service (eg, Oracle Fusion middleware service) 116, and a Java cloud service 117. . In one embodiment, database cloud service 114 may support a shared service deployment model that allows organizations to pool database resources and provide database as a service to customers in the form of a database cloud. The middleware cloud service 116 provides a platform for customers to develop and deploy various business applications, and the Java cloud service 117 provides a platform for customers to deploy Java applications in the cloud infrastructure system 100. To do. The components in the SaaS platform 102 and PaaS platform 104 shown in FIG. 1A are shown for illustrative purposes only and are not intended to limit the scope of embodiments of the present invention. In an alternative embodiment, SaaS platform 102 and PaaS platform 104 may include additional components for providing additional services to customers of cloud infrastructure system 100.

  A variety of different IaaS services may be provided by the IaaS platform 110. The IaaS service facilitates management and control of basic computing resources such as storage, network and other basic computing resources for customers utilizing services provided by the SaaS platform and the PaaS platform.

  In particular embodiments, cloud infrastructure system 100 includes infrastructure resources 106 for providing resources that are used to provide various services to customers of cloud infrastructure system 100. In one embodiment, infrastructure resource 106 includes a pre-integrated, optimized combination of hardware such as servers, storage and networking resources to perform services provided by PaaS platform and SaaS platform. .

  In certain embodiments, the cloud management function 108 provides comprehensive management of cloud services (eg, SaaS, PaaS, IaaS services) in the cloud infrastructure system 100. In one embodiment, the cloud management function 108 includes functions for provisioning, managing and tracking customer subscriptions received by the cloud infrastructure system 100 and the like.

  FIG. 1B is a simplified block diagram of a hardware / software stack that may be used to implement a cloud infrastructure system 100 according to an embodiment of the present invention. It should be understood that the implementation shown in FIG. 1B may have other components than those shown in FIG. 1B. Further, the embodiment shown in FIG. 1B is only one example of a cloud infrastructure system that can incorporate embodiments of the present invention. In some other embodiments, cloud infrastructure system 100 may have more or fewer components than those shown in FIG. 1B, may combine two or more components, or components May have different configurations or arrangements. In particular embodiments, hardware and software components are stacked to provide vertical integration that provides optimal performance.

  Various types of users may interact with the cloud infrastructure system 100. These users may include end users 150 that may interact with the cloud infrastructure system 100 using various client devices such as desktops, mobile devices, tablets, and the like. In addition, the user can use a command line interface (CLI), an application programming interface (CLI), through various integrated development environments (IDE) and through other applications. An API) may be included to include a developer / programmer 152 that can interact with the cloud infrastructure system 100. The user may also include an operation staff 154. These may include staff of cloud service providers or staff of other users.

  The application service layer 156 identifies various cloud services that can be provided by the cloud infrastructure system 100. These services are mapped to respective software components 160 (eg, an Oracle web logic server for providing Java services, an Oracle database for providing database services, etc.) via service integration and connectivity layer 158, or Or it can be associated.

  In particular embodiments, several internal services 162 that are shared by various components or modules of the cloud infrastructure system 100 and services provided by the cloud infrastructure system 100 may be provided. These internal shared services include security and identity services, integration services, enterprise repository services, enterprise manager services, virus scanning and whitelist services, high availability, backup and recovery services, services to enable cloud support in IDEs, This may include, but is not limited to, email services, notification services, file transfer services, and the like.

  The runtime infrastructure layer 164 represents the hardware layer on which various other layers and components are built. In certain embodiments, the runtime infrastructure layer 164 may comprise a single Oracle Exadata machine for providing storage, processing and networking resources. Exadata machines can be composed of various database servers, storage servers, networking resources, and other components for hosting cloud service related software layers. In certain embodiments, Exadata machines can be designed to work with Oracle Exalogic, an engineered system that provides a collection of storage, computing, network and software resources. The combination of Exadata and Exalogic provides a complete hardware and software engineered solution that provides a high-performance, highly available, scalable, secure, and managed platform for delivering cloud services.

  FIG. 2 is a simplified block diagram of a system environment for realizing the cloud infrastructure system shown in FIG. 1A according to an embodiment of the present invention. In the illustrated embodiment, the system environment 230 includes one or more client computing devices 224, 226 and 228 that can be used by a user to interact with the cloud infrastructure system 100. The client device may be used by a user of the client device to interact with the cloud infrastructure system 100 to utilize services provided by the cloud infrastructure system 100, such as a web browser, a proprietary client application (eg, Oracle Forms) or It may be configured to run client applications such as other applications.

  It should be understood that the cloud infrastructure system 100 shown in FIG. 2 may have other components than those shown in FIG. Further, the embodiment shown in FIG. 2 is only one example of a cloud infrastructure system that can incorporate embodiments of the present invention. In some other embodiments, cloud infrastructure system 100 may have more or fewer components than those shown in FIG. 2, may combine two or more components, or components May have different configurations or arrangements.

  Client computing devices 224, 226 and 228 may be general purpose personal computers (including, by way of example, personal computers and / or laptop computers running various versions of Microsoft Windows® and / or Apple Macintosh operating systems), Runs software such as Microsoft Windows Mobile and is a mobile phone or PDA (such as the Internet, email, SMS, Blackberry or any other communication protocol that can be used), various commercial operating systems such as UNIX (R) or UNIX Any system (including but not limited to various GNU / Linux operating systems) Or workstation computers running or may be another computing device. For example, client computing devices 224, 226, and 228 are other electronic devices such as thin client computers that can communicate over a network, gaming machines capable of connecting to the Internet, and / or personal messaging devices. Also good. Although an exemplary system environment 230 is shown with three client computing devices, any number of client computing devices may be supported. Other devices, such as devices having sensors, may interact with the cloud infrastructure system 100.

  Network 232 may facilitate communication and exchange of data between clients 224, 226 and 228 and cloud infrastructure system 100. The network 232 is familiar to those skilled in the art that can support data communications using any of a variety of commercially available protocols including but not limited to TCP / IP, SNA, IPX, AppleTalk, etc. It can be any type of network. By way of example only, the network 232 includes a local area network (LAN), such as an Ethernet network, a token ring network, a wide area network, or a virtual private network (VPN). But not limited to virtual networks, Internet, intranets, extranets, public switched telephone networks (PSTN), infrared networks, wireless networks (eg, IEEE 802.1X series of protocols, known in the art) Network that operates under any of the Bluetooth® protocols and / or other wireless protocols), and / or these and / or other networks. It may be any combination of the work.

  The cloud infrastructure system 100 includes general-purpose computers, specialized server computers (including PC servers, UNIX servers, midrange servers, mainframe computers, rack mount servers, etc.), server farms, server clusters, or others. One or more computers and / or servers may be provided, which may be any suitable arrangement and / or combination. The computing devices making up the cloud infrastructure system 100 execute any of the operating system or various additional server applications and / or middle tier applications, including HTTP servers, FTP servers, CGI servers, Java servers, database servers, etc. Can do. Exemplary database servers include, but are not limited to, those commercially available from Oracle, Microsoft, Sybase, IBM, and the like.

  In various embodiments, the cloud infrastructure system 100 may be adapted to automatically provision, manage and track customer subscriptions to services provided by the cloud infrastructure system 100. In one embodiment, as shown in FIG. 2, the components in the cloud infrastructure system 100 include an identity management (IDM) module 200, a service module 202, and a tenant automation system (TAS) module. 204, Service Deployment Infrastructure (SDI) module 206, Enterprise Manager (EM) module 208, store user interface (UI) 210, cloud user interface (UI) 212 and support. One or more front-end web interfaces, such as a user interface (UI) 216, and an order management module 214; Including the sales staff 218, the operator staff 220, and the order database 222. These modules may include one or more computers and / or servers, which may be general purpose computers, specialized server computers, server farms, server clusters, or other suitable arrangements and / or combinations. May be provided using. In one embodiment, one or more of these modules may be provided by the cloud management function 108 or the IaaS platform 110 in the cloud infrastructure system 100. The various modules of the cloud infrastructure system 100 shown in FIG. 2 are shown for illustrative purposes only and are not intended to limit the scope of embodiments of the present invention. Alternative embodiments may include more or fewer modules than those shown in FIG.

  In an exemplary operation, in (1), a customer using a client device, such as client device 224 or 226, browses various services provided by the cloud infrastructure system 100 and is provided by the cloud infrastructure system 100. One can interact with the cloud infrastructure system 100 by placing an order for a subscription for one or more services. In certain embodiments, a customer may access store UI 210 or cloud UI 212 and place a subscription order through these user interfaces.

  The order information received by the cloud infrastructure system 100 in response to the customer placing an order includes the customer and one or more services provided by the cloud infrastructure system 100 that the customer intends to subscribe to. The information to identify may be included. A single order may include orders for multiple services. For example, a customer may log into the cloud UI 212 and request a subscription for CRM service and Java cloud service in the same order.

  In addition, the order may also include one or more service levels for the ordered service. As used herein and described in more detail below, the service level for a service refers to the service requested in the context of the subscription, such as the amount of storage, the amount of computing resources, data transfer facilities, etc. Determine the amount of resources allocated to provide. For example, a basic service level may provide a minimum level of storage, data transmission, or number of users, and a higher service level may include additional resources.

  Also, in some examples, the order information received by the cloud infrastructure system 100 may include information indicating the customer level and the period for which service is desired. The customer level defines the priority of the customer making the subscription request. In one example, the priority is a service that the cloud infrastructure system 100 guarantees or promises to the customer as defined by a Service Level Agreement (SLA) agreed between the customer and the provider of the cloud service. Can be determined based on quality. In one example, the various customer levels include a basic level, a silver level, and a gold level. The service period may specify the start date and time of the service and the period for which the service is required (for example, the service end date and time may be specified).

  In one example, the customer may request a new subscription via the store UI 210 or a trial subscription via the cloud UI 212. In certain embodiments, the store UI 210 may correspond to a service provider's e-commerce storefront (eg, www.oracle.com/store for an Oracle cloud service). Cloud UI 212 may represent a business interface for a service provider. Customers can investigate available services and sign up for services of interest via the cloud UI 212. The cloud UI 212 captures the user input necessary to order a trial subscription provided by the cloud infrastructure system 100. The cloud UI 212 can also be used to view account functions and configure a runtime environment located within the cloud infrastructure system 100. In addition to placing orders for new subscriptions, the store UI 210 can change subscription service levels, extend the duration of subscriptions, increase subscription service levels, terminate existing subscriptions, etc. It may also allow customers to perform subscription related tasks.

  After the order is placed per (1), in (2), order information received via either the store UI 210 or the cloud UI 212 is stored in the order database 222, and the order database 222 is stored in the cloud infrastructure system 100. It can be one of several databases that are manipulated by and used in conjunction with other system elements. Although the order database 222 is logically shown in FIG. 2 as a single database, in an actual implementation this may comprise one or more databases.

  In (3), the order is sent to the order management module 214. Order management module 214 is configured to perform billing and accounting functions associated with orders, such as order validation and order reservation upon validation. In certain embodiments, order management module 214 may include a contract management module and an install base module. The contract management module may store contract information associated with a customer subscription order, such as a customer service level agreement (SLA) with the cloud infrastructure system 100. The installed base module may include a detailed description of the service in the customer's subscription order. In addition to order information, the install base module may track installation details associated with the service, product status and support service history associated with the service. When a customer orders a new service or upgrades an existing one, the installed base module can automatically add new order information.

  In (4), information regarding the order is communicated to the TAS module 204. In one embodiment, the TAS module 204 utilizes order information to orchestrate the provisioning of services and resources for orders made by customers. In (5), the TAS component 204 orchestrates the provisioning of resources to support subscribed services using the services of the SDI module 206. In (6), the TAS module 204 provides the service module 202 with information related to the provisioned order received from the SDI module 206. In some embodiments, at (7), the SDI module 206 may also use the services provided by the service module 202 to allocate and configure the resources necessary to fulfill the customer's subscription order. .

  In (8), the service module 202 sends a notification regarding the status of the order to the customers on the client devices 224, 226 and 228.

  In certain embodiments, the TAS module 204 functions as an orchestration component that manages business processes associated with each other and applies business logic to determine whether an order should proceed to provisioning. In one embodiment, upon receiving an order for a new subscription, the TAS module 204 requests the SDI module 206 to allocate resources and configure those resources necessary to fulfill the subscription order. Send. The SDI module 206 allows allocation of resources for services ordered by the customer. The SDI module 206 provides a level of abstraction between the cloud service provided by the cloud infrastructure system 100 and the physical implementation layer used to provision the resources to provide the requested service. To do. Thus, the TAS module 204 can be decoupled from implementation details such as whether services and resources are actually provisioned on-the-fly, or whether they are pre-provisioned and simply allocated / assigned on demand.

  In certain embodiments, the user may use the store UI 210 to interact directly with the order management module 214 to perform billing and accounting related functions such as order validation and order reservation during validation. In some embodiments, instead of the customer placing an order, in (9) the order may instead be placed by a sales staff 218 representing the customer, such as a customer service representative or sales representative. . Sales staff 218 may interact directly with order management module 214 via a user interface (not shown in FIG. 2) provided by order management module 214 to place an order or provide a quote to a customer. . For example, this can be done for large customers where orders can be placed by customer sales representatives via order management module 214. The sales representative may prepare a subscription on behalf of the customer.

  The EM module 208 is configured to monitor activities related to managing and tracking customer subscriptions in the cloud infrastructure system 100. The EM module 208 collects usage statistics for services in the subscription order, such as the amount of storage used, the amount of data transferred, the number of users, the amount of system up time and system down time. In (10), the host operator staff 220, who may be an employee of the provider of the cloud infrastructure system 100, is an enterprise manager user to manage the systems and resources for which services are provisioned within the cloud infrastructure system 100. The EM module 208 may be interacted via an interface (not shown in FIG. 2).

  An identity management (IDM) module 200 is configured to provide identity services, such as access management and authorization services, in the cloud infrastructure system 100. In one embodiment, the IDM module 200 controls information about customers who want to use services provided by the cloud infrastructure system 100. Such information includes information that authenticates the identity of such customers, and what actions they perform on various system resources (eg, files, directories, applications, communication ports, memory segments, etc.) Information may be included that indicates whether the authorization is permitted. The IDM module 200 may also include management of descriptive information about each customer and who can access and modify the descriptive information.

  In one embodiment, information managed by the identity management module 200 can be split to create a separate identity domain. Information belonging to a particular identity domain can be isolated from all other identity domains. An identity domain can also be shared by multiple separate tenants. Each such tenant may be a customer that subscribes to services in the cloud infrastructure system 100. In some examples, a customer can have one or many identity domains, each identity domain can be associated with one or more subscriptions, and each subscription can have one or more subscriptions. Have service. For example, a single customer may correspond to a large business entity, and an identity domain may be created for a department / department within this large business entity. Further, EM module 208 and IDM module 200 may interact with order management module 214 at (11) and (12), respectively, to manage and track customer subscriptions in cloud infrastructure system 100.

  In one embodiment, support services may also be provided to the customer via the support UI 216 at (13). In one embodiment, the support UI 216 allows support staff to interact with the order management module 214 via the support backend system to perform support services at (14). Support staff and customers in the cloud infrastructure system 100 can submit bug reports and check the status of these reports via the support UI 216.

  Other interfaces not shown in FIG. 2 may also be provided by the cloud infrastructure system 100. For example, an identity domain administrator may use a user interface to IDM module 200 to configure domain and user identities. The customer can also log into a separate interface for each service that they want to use. In particular embodiments, customers who want to subscribe to one or more services provided by the cloud infrastructure system 100 may also be assigned various roles and missions. In one embodiment, the various roles and missions that can be assigned to a customer are for buyers, account administrators, service administrators, identity domain administrators, or users utilizing services and resources provided by the cloud infrastructure system 100. May include roles and missions. Various roles and missions are more fully illustrated in FIG. 4 below.

  FIG. 3A shows a simplified flowchart 300 illustrating processing that may be performed by a TAS module in a cloud infrastructure system according to an embodiment of the present invention. The process illustrated in FIG. 3A may be implemented in software (eg, code, instructions, program) executed by one or more processors, hardware, or a combination thereof. The software may be stored in memory (eg, on a memory device, non-transitory computer readable storage medium). The particular series of processing steps shown in FIG. 3A is not intended to be limiting. Other sequences of steps may also be performed according to alternative embodiments. For example, alternative embodiments of the invention may perform the above steps in a different order. Furthermore, the individual steps shown in FIG. 3A may include multiple sub-steps that may be performed in various sequences as appropriate to the individual steps. Furthermore, additional steps may be added or deleted depending on the particular application. Those skilled in the art will recognize many variations, modifications and alternatives. In one example, the process shown in FIG. 3A may be performed by one or more components in TAS component 204, as shown in detail in FIG. 3B.

  At 302, a customer subscription order is processed. The process may include order authentication in one example. Order verification ensures that the customer has paid for the subscription and ensures that the customer does not yet have a subscription with the same name, or Including ensuring that the customer does not attempt to create multiple subscriptions of the same type in the same identity domain for unauthorized subscription types. Processing may also include tracking the status of the order for each order being processed by the cloud infrastructure system 100.

  At 304, the business process associated with the order is identified. In some examples, multiple business processes may be identified for an order. Each business process identifies a series of steps for processing various aspects of the order. As an example, a first business process may identify one or more steps related to provisioning physical resources for an order, and a second business process creates an identity domain along with a customer identity for the order One or more steps related to doing can be identified, and the third business process is related to performing back office functions such as creating customer records for users, performing accounting functions related to orders, etc. One or more steps may be identified. In particular embodiments, various business processes may also be identified to handle various services in the order. For example, various business processes may be identified to handle CRM services and database services.

  At 306, the business process identified for the order at 304 is executed. Execution of the business process associated with the order may include an orchestration of a series of steps associated with the business process identified in step 304. For example, the execution of a business process related to provisioning physical resources for an order sends a request to the SDI module 206 to allocate resources and configure those resources necessary to fulfill a subscription order. It may include.

  At 308, a notification is sent to the customer regarding the status of the provisioned order. Further explanation relating to the execution of steps 302, 304, 306 and 308 is described in detail in FIG. 3B.

  FIG. 3B shows a simplified high-level diagram of one or more submodules in a TAS module in a cloud infrastructure system according to an embodiment of the present invention. In one embodiment, the module shown in FIG. 3B performs the process described in steps 302-308 shown in FIG. 3A. In the illustrated embodiment, the TAS module 204 includes an order processing module 310, a business process identifier 312, a business process executor 316, an excess framework 322, a workflow identification module 324, and a bundled subscription generation module 326. With. These modules may be implemented in hardware or software or a combination thereof. The various modules of the TAS module shown in FIG. 3B are shown for illustrative purposes only and are not intended to limit the scope of embodiments of the present invention. Alternative embodiments may include more or fewer modules than those shown in FIG. 3B.

  In one embodiment, order processing module 310 receives orders from customers from one or more input sources 321. For example, order processing module 310 may receive orders directly via cloud UI 212 or store UI 210 in one embodiment. Alternatively, order processing module 310 may receive orders from order management module 214 or order database 222. The order processing module 310 then processes the order. In a particular embodiment, the processing of an order is a customer record that includes information about the order, such as service type, service level, customer level, resource type, amount of resources allocated to a service instance, and the period for which service is required. Includes generation. As part of the processing, the order processing module 310 also determines whether the order is a valid order. This ensures that the customer does not yet have a subscription with the same name, or multiple of the same type in the same identity domain for unauthorized subscription types (such as in the case of a fusion CRM service) Including ensuring that the customer has not attempted to create a subscription.

  The order processing module 310 may also perform further processing on the order. Processing may include tracking order status for each order being processed by cloud infrastructure system 100. In one embodiment, order processing module 310 may process each order to identify a number of conditions related to the order. In one example, the various states of the order can be an initialization state, a provisioning state, an active state, a state that requires management, an error state, and so on. The initialization state refers to the state of the new order, and the provisioning state refers to the state of the order when the services and resources for the order are provisioned. When the order is processed by the TAS module 204 and a notification to that effect is given to the customer, the order becomes active. An order is in a state that needs to be managed if an administrator intervention is required to solve the problem. If the order cannot be processed, the order is in error. In addition to maintaining the order progress state, the order processing module 310 maintains detailed information about any failures encountered during the execution of the process. In other embodiments, as described in detail below, further processing performed by the order processing module 310 may include changing the service level of a service in a subscription, changing a service included in a subscription, It may also include extending the period and specifying different service levels over different periods in the cancellation or subscription of the subscription.

  After the order is processed by the order processing module 310, business logic is applied to determine whether the order should proceed to provisioning. In one embodiment, as part of an order orchestration, the business process identifier 312 receives a processed order from the order processing module 310 and applies business logic to identify the specific to be used in the order being processed. Identify business processes. In one example, business process identifier 312 may utilize information stored in service catalog 314 to determine a particular business process to be used in the order. In one example, as shown in FIG. 3A, multiple business processes may be identified for an order, each business process identifying a series of steps for processing various aspects of the order. In another example, as described above, different business processes may be defined for different types of services or combinations of services, such as CRM services or database services. In one example, service catalog 314 may store information that maps orders to specific types of business processes. Business process identifier 312 may use this information to identify a particular business process for the order being processed.

  Once the business process is identified, the business process identifier 312 communicates the specific business process to be executed to the business process executor 316. The business process executor 316 then operates in conjunction with one or more modules in the cloud infrastructure system 100 to execute the identified business process steps. In some embodiments, the business process executor 316 serves as an orchestrator for performing steps associated with the business process. For example, the business process executor identifies the workflow associated with the order and determines the service excess in the order, or executes the steps in the business process that identify the service component associated with the order. 310 may be interacted with.

  In one example, the business process executor 316 interacts with the SDI module 206 to perform steps in the business process for allocating and provisioning resources for the services requested in the subscription order. In this example, for each step in the business process, business process executor 316 may send a request to SDI component 206 to allocate resources and configure the resources necessary to implement a particular step. The SDI component 206 is responsible for the actual allocation of resources. Once all the steps of the order's business process have been executed, the business process executor 316 may send a notification of the processed order to the customer by utilizing the service of the service component 202. The notification may include sending an email notification with the details of the processed order to the customer. The email notification may also include deployment information associated with the order to allow the customer to access the subscribed service.

  In certain embodiments, the TAS module 204 may include one or more TAS application programming that allows the TAS module 204 to interact with other modules in the cloud infrastructure system 100 and allow other modules to interact with the TAS module 204. An interface (Application Programming Interface: API) 318 may be provided. For example, the TAS API interacts with the SDI module 206 via asynchronous Simple Object Access Protocol (SOAP) based web service calls to provision resources for customer subscription orders. A system provisioning API to be included. In one embodiment, the TAS module 204 may also utilize the system provisioning API to accomplish the creation and deletion of systems and service instances, switch service instances to enhanced service levels, and associate service instances. An example of this is the association of a Java service instance to a fusion application service instance to enable secure web service communication. The TAS API may also include a notification API that interacts with the service module 202 to notify the customer of the processed order. In certain embodiments, the TAS module 204 also periodically communicates subscription information, outages and notifications (eg, planned downtime) to the service component 202.

  In certain embodiments, the TAS module 204 uses the amount of storage used, the amount of data transferred, the number of users, and the usage for each provisioned service, such as the amount of system up and down time. Statistics are received periodically from the EM module 208. The excess framework 322 determines whether an overuse of the service has occurred and, if so, uses the usage statistics to determine how much is charged for the excess and orders this information. Provide to the management module 214.

  In certain embodiments, the TAS module 204 includes an order workflow identification module 324 that is configured to identify one or more workflows associated with processing a customer's subscription order. In certain embodiments, the TAS module 204 is a subscription order for generating a subscription order for a customer when the customer places a subscription order for one or more services provided by the cloud infrastructure system 100. A generation framework 326 may be included. In one embodiment, the subscription order includes one or more service components responsible for providing the services requested by the customer in the subscription order.

  In addition, the TAS module 204 may provide a tenant information system to allow provisioning of resources for one or more services subscribed to by a customer, taking into account historical information available to the customer, if any. One or more additional databases, such as a (Tenant Information System: TIS) database 320, may also be interacted with. The TIS database 320 may include historical order information and historical usage information related to orders subscribed by the customer.

  The TAS module 204 can be deployed using various deployment models. In certain embodiments, a deployment includes a central component that interacts with one or more distributed components. Distributed components may be deployed, for example, as various data centers and therefore may also be referred to as data center components. The central component includes functions for processing orders and organizing services in the cloud infrastructure system 100, and the data center component is functions for provisioning and operating a runtime system that provides resources to subscribed services. I will provide a.

  FIG. 4 illustrates an exemplary distributed deployment of TAS modules according to an embodiment of the present invention. In the example shown in FIG. 4, the distributed deployment of the TAS module 204 includes a TAS center component 400 and one or more TAS data center (DC) components 402, 404 and 406. These components may be implemented in hardware or software or a combination thereof.

  In one embodiment, the task of the TAS-centric component 400 is to receive a customer order and create a new subscription, change the service level of a service in the subscription, change the service included in the subscription, and the duration of the subscription Including, but not limited to, providing a centralized component for performing order-related business operations such as extension of subscriptions or cancellation of subscriptions. Also, the task of the TAS-centric component 400 is to maintain and supply the subscription data required by the cloud infrastructure system 100, as well as order management module 214, support UI 216, to handle all back office interactions, Interacting with the cloud UI 212 and the store UI 210 may also be included.

  In one embodiment, the duties of TAS DCs 402, 404 and 406 include performing runtime operations to orchestrate the provisioning of resources for one or more services subscribed to by a customer. It is not limited. TAS DCs 402, 404 and 406 also perform operations such as subscription order locking, unlocking, enabling or disabling, order-related metrics collection, order status determination, and order-related notification event transmission. The function for executing is also included.

  In the exemplary operation of the distributed TAS system shown in FIG. 4, the TAS-centric component 400 is initially through the cloud UI 212, the store UI 210, the order management system 214, or the order database 222. Receive orders from customers. In one embodiment, a customer represents a buyer who has the authority to order and / or change financial information and subscriptions. In one embodiment, the order information includes information identifying the customer, the type of service that the customer wants to subscribe to, and the account administrator responsible for handling the request. In certain embodiments, an account administrator may be appointed by a customer when the customer places an order for a subscription to one or more services provided by the cloud infrastructure system 100. Based on the order information, the TAS-centric component 400 determines the data area in the world, such as the United States, EMEA, or Asia Pacific where the order originates, and the specific TAS DC (eg, 402, 404 or 406) deployed to provision the order. ). In one embodiment, the particular TAS DC deployed to provision the order (eg, from within DCs 402, 404 or 406) is determined based on the geographic data region where the request originated.

  The TAS center component 400 then sends the order request to a particular TAS DC to provision a service for the order request. In one embodiment, the TAS DC 402, 404 or 406 identifies the service administrator and identity domain administrator responsible for processing order requests at a particular TAS DC. Service administrators and identity managers can be appointed by account administrators identified in the subscription order. The TAS DC 402, 404 or 406 communicates with the SDI module 204 to orchestrate provisioning of physical resources for the order. The SDI component 206 in each TAS DC 402, 404 or 406 allocates resources and configures those resources needed to fulfill the subscription order.

  In particular embodiments, TAS DC 402, 404 or 406 identifies the identity domain associated with the subscription. The SDI component 206 may provide identity domain information to the IDM component 200 (shown in FIG. 2) for identification of an existing identity domain or creation of a new identity domain. Once the order is provisioned by the SDI module in the respective TAS DC 402, 404 or 406, the TAS-centric component 400 may place information about provisioned resources in the support system via the support UI 216. The information may include, for example, a display of resource metrics and service usage statistics associated with the service.

  During operation, at each data center, the EM module 208 is responsible for the amount of storage used, amount of data transferred, number of users, and system uptime for each provisioned service provisioned at that data center. And regularly collect usage statistics such as the amount of system downtime. These statistics are provided to the TAS DC that is local to the EM module 208 (ie, in the same data center). In an embodiment, the TAS DC determines whether an overuse of the service has occurred and, if so, uses usage statistics to determine how much is charged for the excess, The order management system 214 may be provided.

  FIG. 5 is a simplified block diagram illustrating SDI module interaction with one or more modules in a cloud infrastructure system according to an embodiment of the present invention. In one embodiment, the SDI module 206 interacts with the TAS module 204 to provision resources for service in the subscription order received by the TAS module 204. In certain embodiments, one or more of the modules shown in FIG. 5 may be a module within the cloud infrastructure system 100. In other embodiments, one or more of the modules that interact with the SDI module 206 may be external to the cloud infrastructure system 100. Alternate embodiments may also have more or fewer modules than those shown in FIG. These modules may be implemented in hardware or software or a combination thereof.

  In one embodiment, the modules in SDI module 206 may include one or more modules in SaaS platform 102 and PaaS platform 104 in cloud infrastructure system 100. In order to provision resources for various services, the SDI module 206 may interact with various other modules, each customized to assist in provisioning resources for a particular type of service. For example, as shown in FIG. 5, the SDI module 206 may interact with the Java service provisioning control module 500 to provision Java cloud services. In one embodiment, the Java service provisioning control component 500 deploys a Java Cloud Service (JCS) assembly defined by the SDI module 206 that includes a set of tasks performed to provision a Java cloud service. Can do. The infrastructure resource 106 then determines the resources needed to provision the Java cloud service.

  As another example, the SDI module 206 includes a virtual assembly builder (VAB) module 502, an application express (APEX) deployer module 504, a virtual machine (VM) module 506, and an IDM. One or more modules such as module 200 and database machine module 118 may interact. VAB module 502 includes functionality for configuring and provisioning a complete multi-tier application environment. In one embodiment, the VAB module 502 is a MW service defined by the SDI module 206 to provision a middleware (MW) service in the cloud infrastructure system 100 using the service provided by the VM module 506. Deploy the assembly. The APEX deployer module 504 includes functionality for configuring and provisioning database services. In one embodiment, the APEX deployer module 504 deploys a database service assembly defined by the SDI module 206 to provision a database service in the cloud infrastructure system 100 using the resources provided by the infrastructure resource 106. To do. The SDI module 206 interacts with the IDM module 200 to provide identity services such as access management across multiple applications in the cloud infrastructure system 100.

  FIG. 6 shows a simplified high-level diagram of submodules of an SDI module according to an embodiment of the present invention. In the embodiment shown in FIG. 6, the SDI module 206 includes an SDI-Web Service (WS) module 600, an SDI request controller module 602, an SDI task manager module 604, an SDI monitoring module 606, and SDI data. The access module 608 includes an SDI common library module 610 and an SDI connector module 612. These modules may be implemented in hardware or software or a combination thereof. The SDI module 206 and its various modules shown in FIG. 6 are shown for illustrative purposes only and are not intended to limit the scope of embodiments of the present invention. Alternative embodiments may have more or fewer modules than those shown in FIG. These modules and their functions are described in detail below.

  The SDI-WS module 600 includes functionality for receiving steps in the business associated with the order from the business process executor 316 of the TAS component 204. In one embodiment, the SDI-WS module 600 parses each step of the business process and converts the step into an internal representation used by the SDI module 206. In one embodiment, each step of the business process associated with the order is performed in the form of a SOAP request to the SDI-WS module 600 via the web service processing layer (eg, via the system provisioning API shown in FIG. 3B). )arrive.

  The SDI request controller module 602 is an internal request processing engine in the SDI module 206, and functions for executing asynchronous request processing, simultaneous request processing, simultaneous task processing, fault tolerant recovery and plug-in support related to order requests. including. In one embodiment, the SDI request controller module 602 accepts each step of the business process associated with the order from the SDI-WS module 600 and submits the step to the SDI task manager module 604.

  The SDI task manager module 604 translates each step defined in the business process into a series of tasks for provisioning a particular step. Once a set of tasks for a particular step is provisioned, the SDI task manager module 604 may return the TAS module 204 with an operation result that includes an order payload with details of resources provisioned to implement the particular step. In response to the business process executor 316 at. The SDI task manager module 604 repeats this process until all steps of the specific business process associated with the order are completed.

  In a particular embodiment, the SDI task manager module 604 converts each step defined in the business process into a series of tasks by utilizing the services of the SDI connector module 612. The SDI connector module 612 includes one or more connectors for addressing the deployment of tasks defined by the SDI task manager module 604 to provision one or more services associated with order requests. In particular embodiments, one or more of the connectors can handle tasks specific to a particular service type, and other connectors can handle common tasks across various service types. In one embodiment, the SDI connector module 612 interacts with one or more of the external modules (shown in FIG. 5) in the cloud infrastructure system 100 to provision services and resources related to order requests. Includes connector (wrapper API). For example, Application Express (APEX) connector 614 interacts with APEX deployer module 504 to provision database services. A web center connector 616 (Web Center Connector: WCC) interacts with a web center module in the cloud infrastructure system 100 to provision web services. The web center module is a user engagement platform, and includes a function for providing connectivity between people and information in the cloud infrastructure system 100.

  In particular embodiments, a middleware application (MA) connector 618 interacts with the VAB module 502 in the cloud infrastructure system 100 to provision middleware application services. NUVIAQ connector 620 interacts with VAB module 502 to provision Java services. The IDM connector 622 interacts with the IDM module 200 to provide identity and access management to users who subscribe to services and resources in the cloud infrastructure system 100. Virtual assembly builder (VAB) connector 624 interacts with VAB module 502 in cloud infrastructure system 100 to configure and provision a complete multi-tier application environment. Plug-in connector 626 interacts with EM module 208 to manage and monitor components in cloud infrastructure system 100. The HTTP server connector 628 interacts with one or more web servers in the PaaS platform to provide connection services to users in the cloud infrastructure system 100.

  The SDI monitoring module 606 in the SDI module 206 provides an inbound interface for receiving Java Management Extensions (JMX) requests. The SDI monitoring module 606 also provides tools for managing and monitoring applications, system objects and devices in the cloud infrastructure system 100. The SDI data access module 608 provides an inbound interface for receiving Java Database Connectivity (JDBC) requests. The SDI data access module 608 supports data access in the cloud infrastructure system 100 and provides object relationship mapping, Java transaction API service, data access object and connection pooling. The SDI common library module 610 provides configuration support for modules in the SDI module 206.

  The embodiment of FIG. 6 above describes the modules in the SDI module according to an embodiment of the present invention. FIG. 7A shows a simplified flowchart 700 illustrating processing that may be performed by modules of an SDI module in a cloud infrastructure system according to an embodiment of the present invention. The processing shown in FIG. 7A may be implemented by software (eg, code, instructions, program) executed by one or more processors, hardware, or a combination thereof. The software may be stored in memory (eg, on a memory device, non-transitory computer readable storage medium). The particular series of processing steps shown in FIG. 7A is not intended to be limiting. Other sequences of steps may also be performed according to alternative embodiments. For example, alternative embodiments of the invention may perform the above steps in a different order. Further, the individual steps shown in FIG. 7A may include multiple sub-steps that may be performed in various sequences as appropriate to the individual steps. Furthermore, additional steps may be added or deleted depending on the particular application. Those skilled in the art will recognize many variations, modifications and alternatives. In one embodiment, the process shown in FIG. 7A may be performed by one or more modules in SDI module 206 shown in detail in FIG.

  At 702, a business process associated with a subscription order is received. In one embodiment, the SDI-WS module 600 in the SDI module 206 receives one or more steps in the business process associated with the subscription order from the business process executor 316. At 704, each step in the business process is converted into a series of tasks for provisioning resources for the subscription order. In one embodiment, the SDI task manager module 604 in the SDI module 206 converts each step defined in the business process into a series of tasks by utilizing the services of the SDI connector module 612. At 706, the subscription order is provisioned based on a series of tasks. In one embodiment, as shown in FIG. 6, the SDI connector module 612 handles the deployment of tasks defined by the SDI task manager module 604 to provision resources for services in the subscription order. One or more connectors.

  As described above with respect to FIG. 6, the SDI task manager module 604 utilizes the services of the SDI connector module 612 to convert each step defined in the business process into a series of tasks, and the SDI connector module 612 One or more connectors for addressing the deployment of tasks defined by the SDI task manager module 604 may be included to provision one or more services associated with the request. One or more of the connectors can handle tasks that are specific to a particular service type, and other connectors can handle tasks that are common across various service types. In one embodiment, the SDI connector module 612 interacts with one or more of the external modules (shown in FIG. 5) in the cloud infrastructure system 100 to provision services and resources related to order requests. Includes connector (wrapper API). For example, the NUVIAQ connector 620 interacts with the VAB module 502 to provision Java services.

  FIG. 7B shows a simplified block diagram illustrating a high level architecture of Nuviaq system 710 and its relationship with other cloud infrastructure systems according to an embodiment of the present invention. It should be understood that the Nuviaq system 710 shown in FIG. 7B may have other components than those shown in FIG. 7B. Further, the embodiment shown in FIG. 7B is only one example of a cloud infrastructure system that can incorporate embodiments of the present invention. In some other embodiments, Nuviaq system 710 may have more or fewer components than those shown in FIG. 7B, may combine two or more components, or have different components It may have a configuration or an arrangement.

  In certain embodiments, Nuviaq system 710 may be configured to provide a runtime engine for orchestrating PaaS operations. Nuviaq system 710 may provide a web service API to facilitate integration with other products and services. Nuviaq system 710 also provides support for complex workflows in system provisioning, application deployment and associated lifecycle operations, and integrates with management and monitoring solutions.

  In the example shown in FIG. 7B, the Nuviaq system 710 comprises a Nuviaq proxy 712, a Nuviaq manager 714, and a Nuviaq database 716. In certain embodiments, Nuviaq manager 714 provides an entry point to Nuviaq system 710 and provides secure access to PaaS operations via a web service API. Internally, Nuviaq manager 714 tracks the system state in the database and controls the execution of jobs on the workflow engine. In the public cloud, Nuviaq manager 714 can be accessed by the tenant provisioning system (SDI 206) and the tenant console to drive provisioning and deployment operations, respectively.

  In one embodiment, Nuviaq manager 714 executes jobs asynchronously via an internal workflow engine. A job may be a sequence of actions specific to a given PaaS workflow. Actions may be executed in order, and failure at any step results in failure of the entire job. Many workflow actions delegate authority to external systems associated with the workflow, such as the EM command line interface (cli). In one implementation, the Nuviaq manager 714 application may be hosted in a two-node web logic cluster with an associated HTTP server (eg, Oracle HTTP server or OHS) instance running within the firewall.

  In a particular embodiment, Nuviaq proxy 712 is a public access point to Nuviaq API. In one embodiment, only public APIs can be published here. Requests received by proxy 712 may be sent to Nuviaq manager 714. In one embodiment, Nuviaq proxy 712 runs outside the firewall, while manager 714 runs inside the firewall. In one implementation, the Nuviaq proxy 712 application runs on a web logic cluster that runs outside the firewall.

  In certain embodiments, Nuviaq database 716 tracks various domain entities such as, but not limited to, platform instances, deployment plans, applications, web logic domains, jobs, alerts, and the like. If necessary, the primary key may be aligned with the service database.

  In one embodiment, platform instance 718 may include all the resources necessary for web logic services for a given tenant.

  Nuviaq system 710 may rely on additional systems of cloud infrastructure system 100 to execute workflows used by web logic cloud services. These dependencies may include dependencies on the SDI 206, IDM 200, virus scanning system, service database, CRM instance, and the like. For example, Nuviaq system 710 may rely on functions performed by an assembly deployer at SDI 206. In one embodiment, the assembly deployer is a system for managing interactions with OVAB (Oracle Virtual Assembly Builder) and OVM (Oracle Virtual Machine). Assembly deployer functions used by Nuviaq system 710 may include functions for deploying assemblies, functions for undeploying assemblies, functions for describing assembly deployment, functions for scaling appliances, etc. However, it is not limited to these. In one implementation, the Nuviaq system 710 accesses an assembly deployer via a web service API.

  In certain embodiments, the security policy may require that certain artifacts be scanned for viruses before being deployed to the application. The cloud infrastructure system 100 can provide a virus scanning system for this purpose, providing scanning as a service for multiple components of the public cloud.

  In certain embodiments, the public cloud infrastructure may maintain a service database that includes information about tenants (eg, customers) and their service subscriptions. The Nuviaq workflow may access this data to properly configure the web logic service as a client to other services that the tenant also subscribes to.

  Nuviaq system 710 may rely on IDM 200 for its security integration. In certain embodiments, a Java service instance may be associated with a CRM instance. With this association, a user application deployed on the Java service instance can access the CRM instance via a web service call.

  Various entities may use the services provided by Nuviaq system 710. These clients of the Nuviaq system 710 include a tenant console which is a management server (eg, Oracle management server) based user interface that customers can access to manage applications on platform instances, and access to application lifecycle management operations. Several IDEs, such as Oracle IDEs (JDeveloper, NetBeans, and OEPE) that have been extended to provide one and more command line interfaces (Command Line) that can be used to access lifecycle operations on platform instances Interface: CLI).

The provisioning use case for the Nuviaq system 710, ie the use case of the provisioning platform instance, is realized by the Nuviaq API creation platform instance operation. In the context of the cloud infrastructure system 100, a service instance for a Nuviaq system corresponds to a Nuviaq platform instance. A platform instance is assigned a unique identifier that is used on all subsequent operations associated with this instance. The platform deployment descriptor provided in the create platform instance action allows you to set properties that modify the configuration of the platform instance to meet tenant subscription requirements. These properties may include, for example:
Property # 1 : oracle.cloud.service.weblogic.size
Value: Basic, Standard, Enterprise Description: Specifies the subscription type. This affects the number of servers, database limits and quality of service settings.

Property # 2 : oracle.cloud.service.weblogic.trial
Value: True, False Description: Indicates whether this is a trial subscription.

Property # 3 : oracle.cloud.service.weblogic.crm
Value: CRM service ID
Description: Specifies the CRM service to be associated with this web logic service instance.

  FIG. 7C shows an exemplary sequence diagram illustrating the steps of the provisioning process using the Nuviaq system according to an embodiment of the present invention. The sequence diagram shown in FIG. 7C is only an example and is not intended to be limiting.

The install / update application use case, i.e., install application operation, deploys the application to a running weblogic server after confirming that the application archive meets the security requirements of the public cloud. In one embodiment, an application deployment descriptor provided in the install application action may set properties that modify the application configuration to meet tenant subscription requirements. These properties may include, for example:
Property : oracle.cloud.service.weblogic.state
Value: Run, Stop Description: Specifies the initial state of the application after deployment.

  FIG. 7D shows an exemplary sequence diagram illustrating the steps of the deployment process using the Nuviaq system according to an embodiment of the present invention. The sequence diagram shown in FIG. 7D is only an example and is not intended to be limiting.

Returning to FIG. 2, in a specific embodiment, the TAS 204 and SDI 206 operating in concert are for one or more services ordered by a customer from a set of services provided by the cloud infrastructure system 100. Responsible for provisioning resources. For example, in one embodiment, to provision a database service, an automated provisioning flow may be as follows for a paid subscription:
(1) The customer orders a paid subscription for the service via the store UI 210.

(2) The TAS 204 receives the subscription order.
(3) When the service is available, the TAS 204 starts provisioning by using the service of the SDI 206. The TAS 204 may perform orchestration of business processes and execute related business processes to complete the provisioning aspect of the order. In one embodiment, the TAS 204 may use a Business Process Execution Language (BPEL) process manager to orchestrate the steps involved in provisioning and process lifecycle operations.

  (4) In one embodiment, to provision a database service, the SDI 206 may call the PSQL API in the CLOUD_UI to associate the schema with the requesting customer.

  (5) After successfully associating the schema with the customer, the SDI informs the TAS and the TAS sends a notification to the customer that the database service is currently available for use by the customer.

  (6) The customer may log into the cloud infrastructure system 100 (eg, using a URAL such as cloud.oracle.com) and activate the service.

  In some embodiments, the customer may also be allowed to subscribe to the service on a trial basis. For example, such a trial order may be received via the cloud UI 212 (eg, using cloud.oracle.com).

  In certain embodiments, the cloud infrastructure system 100 allows basic hardware and service instances to be shared between customers or tenants. For example, a database service may be provisioned as shown in FIG. 7E in one embodiment. FIG. 7E shows a plurality of Exadata compute nodes 730 and 732, each of which provides a database instance provisioned for database services. For example, compute node 730 provides a database instance 734 for database services. Each Exadata operation node may have a plurality of database instances.

  In particular embodiments, each database instance may comprise multiple schemas, which may be associated with different customers or tenants. For example, in FIG. 7E, database instance 734 provides two schemas 736 and 738, each of which has its own table. Schema 736 can be associated with a first customer or tenant that subscribes to the database service, and schema 738 can be associated with a second customer or tenant that subscribes to the database service. Each tenant gets a completely isolated schema. Each schema acts like a container that can manage database objects including tables, views, stored procedures, triggers, etc. for the associated tenant. Each schema can have one dedicated tablespace, and each tablespace has one data file.

  Thus, a single database instance can provide database services to multiple tenants. This not only allows basic hardware resource sharing, but also allows service instances to be shared between tenants.

  In certain embodiments, such a multi-tenancy system is facilitated by the IDM 200, which allows multiple separate customers, each with its own separate identity domain, to be shared in the cloud and It is advantageously possible to use software. As a result, each customer does not need to have their own dedicated hardware or software resources, and in some cases, resources that are not used by some customers at any given time are made available to other customers, This prevents waste of those resources. For example, as shown in FIG. 7E, a database instance can be served to multiple customers, each having a respective identity domain. Each such database service instance may be a separate abstraction or view of a single physical multitenant database system shared within many separate identity domains, but each such database A service instance may have a different and possibly different schema than each other database service instance has. Thus, a multi-tenant database system can store a mapping between customer-specified database schemas and the identity domains to which those database schemas relate. A multi-tenant database system may cause a database service instance for a particular identity domain to use a schema that is mapped to that particular identity domain.

  Multi-tenancy can be extended to other services such as Java services. For example, multiple customers may have JAVA service instances located within their identity domain. Each such identity domain may have a JAVA virtual machine that can be considered a virtual “slice” of hardware. In one embodiment, a job monitoring service (eg, Hudson) in the cloud to allow each separate identity domain to have its own separate virtual “slice” of the JAVA enterprise platform. It may be combined with a JAVA enterprise version platform (for example, Oracle Web Logic). Such a job monitoring service may monitor the execution of repetitive jobs such as, for example, software projects or job construction executed by an operating system time-based job scheduler. Such repeated jobs may include the continuous construction and / or testing of software projects. Additionally or alternatively, such repeated jobs may include monitoring the execution of an operating system boot job that is executed on a machine remote from the machine on which the job monitoring service is executed.

Pod Provisioning and Service Provisioning According to some embodiments, the SDI can coordinate separate POD provisioning and service provisioning for services. A POD is a logical entity that can represent one of the following: An anonymous single tenant deployment pre-provisioned (as with Java services); or multiple tenants (as with database services) Multi-tenant stack that works for (physical or virtual). For example, POD is the deployment of services on a physical stack. A POD can contain one or more service instances. The POD can be created a priori or can be created on demand when a service instance is created for a given customer.

  In some examples, a POD is an instantiation of a software stack to run a service. For this reason, the service is executed using the POD. For example, a POD corresponding to a Java service may include a stack of virtual machines. As another example, a POD for a database service may include an instance of a database. A POD may be viewed as a subsystem that can host a service. Different pods may be used for different services.

  The task of creating a POD for a service is called POD provisioning. As shown in FIG. 8B, POD provisioning can be facilitated by the SDI module 206. POD provisioning is an operation that creates an anonymous instance of a software component. From an infrastructure perspective, the POD may be fully installed and wired. The POD has no customer-specific configuration data or integration (eg, not connected to any customer stripe).

Physical POD provisioning can include three broad aspects.
1. POD definition schema for defining the physical footprint of the service;
2. 2. Service definition schema for incorporating service specific plug-ins; Service configuration schema to capture enterprise management (EM), identity management (IDM), Uniform Resource Locator (URL) routing, and other service specific configurations.

  Different PODs may be created for each service. For example, in the case of Java services, the POD may map to a set of VMs that execute middleware technology (eg, execute fusion middleware). A separate automation flow may be used by the SDI module 206 for POD provisioning. In some examples, POD can also be an almost completely virtual concept.

  An example of a POD may include a set of data center resources that are wired together to provide a specific service to a specific customer. A POD may include dedicated resources in a shared infrastructure. For example, in the case of services deployed using VAB technology such as Oracle Virtual Assembly Builder (OVAB) technology, the OVAB assembly is a POD. As another example of POD, a domain may include a core set of VMs that make up a Java assembly. In the case of a fusion application, the POD may be a set of virtual machines that are specifically for installing a fusion application that may include a database and a VM. For database services, a POD can include both Exadata and a DB instance on that Exadata.

  FIG. 8A shows a simplified flowchart 800 illustrating processing that may be performed by the SDI module 206 in a cloud infrastructure system according to an embodiment of the present invention. The processing shown in FIG. 8A may be implemented by software (eg, code, instructions, program) executed by one or more processors, hardware, or a combination thereof. The software may be stored in memory (eg, on a memory device, non-transitory computer readable storage medium). The particular series of processing steps shown in FIG. 8A is not intended to be limiting. Other sequences of steps may also be performed according to alternative embodiments. For example, alternative embodiments of the invention may perform the above steps in a different order. Furthermore, the individual steps shown in FIG. 8A may include multiple sub-steps that may be performed in various sequences as appropriate to the individual steps. Furthermore, additional steps may be added or deleted depending on the particular application. Those skilled in the art will recognize many variations, modifications and alternatives. In one embodiment, the process shown in FIG. 8A may be performed by one or more modules in SDI module 206 shown in detail in FIG.

  The flowchart 800 may be executed for each pre-provisioned POD assembly. The SDI module 206 can provision the POD in the background using management and selection algorithms, and then determine the POD for a particular tenant when a request is received. For example, as shown in FIG. 8B, the SDI module 206 can pre-provision a POD before receiving a customer order. When a service request is received, the SDI module 206 can then add customer information to the POD and customize the POD based on the request, as shown in FIG. 8A.

  At 802, the SDI module 206 can store subscription order information from a customer that identifies a service from a set of services. For example, the subscription order information may be a customer request for a database service from the store UI 210. Subscription order information may include customer specific configurations.

  At 804, the SDI module 206 can determine a service associated with the subscription order information. For example, the SDI module 206 can determine that the customer order is for a database service. Thus, when a customer order is received, the SDI module 206 determines the type of service required to map the customer specific POD to the customer request.

  At 806, the SDI module 206 can map the pre-provisioned anonymous deployment to subscription order information. The pre-provisioned anonymous deployment can be a POD. As described herein, a POD can be pre-provisioned and created for a specific service.

  Services can be mapped to specific customer subscriptions. For example, the service may be a Java instance for a particular customer. A service instance is a specific subscription ID for a specific type of service, such as a Java service. A service instance can belong to a specific customer and exists on a pod. Only one service instance may exist on a single tenant POD, and multiple instances may exist on multiple tenant PODs. Furthermore, service instances always exist in the POD, but do not span two pods. On the other hand, a service instance may need more than just the presence of a POD.

  At 808, the SDI module 206 can create a service instance specifically for a customer by configuring a pre-provisioned anonymous deployment with a customer-specific configuration. For example, the SDI module 206 can introduce customer specific configuration into the POD using personality injection. Service provisioning is the process of combining a specific customer with a specific POD. This introduces a customer specific configuration into the POD (eg, personality injection). A POD may support one or more tenants simultaneously (single tenant or multi-tenant). For a POD that supports multiple tenants, multiple personalities may be injected into the POD, and each personality may correspond to each supported tenant.

  According to another embodiment, a particular service can use multiple PODs. For example, a Java service may be requested. The SDI module 206 may have a plurality of pre-provisioned Java PODs. Based on the requested size of service, the SDI module 206 may determine that multiple PODs are needed to support the requested service.

  The service provisioning and POD provisioning processes are separate, independent of each other and coordinated by the SDI module 206. Thereby, for example, POD provisioning can be executed in the background. Preliminary pooling of pods may be based on administrator configurable options to anticipate future demand. Service provisioning is generally much faster than POD provisioning and occurs on demand when the SDI receives an order from the TAS. The SDI coordinates POD provisioning and service provisioning while processing pooling and registration.

Pre-provisioning pods According to some embodiments, fully automated POD provisioning handled by SDI may create instances of software components without a request from TAS. This can be a background activity performed prior to customer ordering. Since POD can be launched slowly, POD provisioning is completed in advance, so when a customer orders a service, the customer receives the order promptly (eg within seconds or minutes) be able to. A POD may support one or more tenants simultaneously (single tenant or multi-tenant). These processes are independent so that POD provisioning can be performed in the background. Preliminary pooling of pods is based on administrator configurable options to anticipate future demand.

  With fewer resources, the SDI module 206 can create a new POD. As will be explained later, by using the Min_Used threshold, the SDI module 206 can monitor usage and allocation. Based on the monitoring, the SDI can pre-provision a new POD.

  For example, the SDI timer job is executed and the number of free assemblies for a given service size (basic, standard, enterprise) falls below the Min_Used threshold specified in the current configuration. , Additional assemblies can be pre-provisioned until a threshold is reached.

  FIG. 8B shows a simplified flowchart 850 illustrating processing that may be performed by the SDI module 206 in a cloud infrastructure system according to an embodiment of the present invention. The processing illustrated in FIG. 8B may be implemented by software (eg, code, instructions, program) executed by one or more processors, hardware, or a combination thereof. The software may be stored in memory (eg, on a memory device, non-transitory computer readable storage medium). The particular series of processing steps shown in FIG. 8B is not intended to be limiting. Other sequences of steps may also be performed according to alternative embodiments. For example, alternative embodiments of the invention may perform the above steps in a different order. Furthermore, the individual steps shown in FIG. 8B may include multiple sub-steps that may be performed in various sequences as appropriate to the individual steps. Furthermore, additional steps may be added or deleted depending on the particular application. Those skilled in the art will recognize many variations, modifications and alternatives. In one embodiment, the process shown in FIG. 8B may be performed by one or more modules in SDI module 206 shown in detail in FIG.

  The flowchart 850 can be executed for each pre-provisioned assembly. An assembly is a type of POD. For example, assembly is a unique technique used by OVAB for creation. OVAB creates or deploys an assembly. The POD can continue to be preprovisioned indefinitely until the Min_used threshold is reached or until the timer job is interrupted by the operator.

  In addition, if a failure occurs at any step, the previous operation can be rewound. The SDI module 206 can then retry the sequence.

  At 852, the SDI module 206 can obtain an IP address to pre-provision the POD assembly. For example, 8 IP addresses (eg, 4 from Frontend and 4 from BACKEND) can be stored in the SDI database. Operations can be at the atomic level. In some examples, if the system does not have enough IP addresses, the administrator can add more capacity to the environment.

  At 854, the SDI module can create a virtual assembly builder home (eg, Oracle Virtual Assembly Builder (OVAB)). For example, a new directory can be created under the root (eg, ovab.virtual.root) directory, and various sylinks can be recreated up to the home directory (eg, ovab.master.home). The home directory can be used as a virtual assembly builder home for single deployment. This allows the SDI module 206 to execute virtual assembly builder (eg OVAB) operations in parallel without causing locking problems.

  At 856, the SDI module 206 can create a deployment plan (eg, deploymentPlan.xml) file in a new virtual assembly builder (eg, OVAB) home. A deployment plan is an IP address, a network file sharing (NFS) mount, and a VM that will be injected into a virtual machine (VM) deployed by a virtual assembly builder (eg OVAB) for deployment. It may include configuration information such as, but not limited to, a bridge name.

  At 858, the SDI module 206 can create a ZFS volume. ZFS is a complex file system and logical volume manager. ZFS features include protection from data corruption, high storage capacity support, integration of file system and volume management concepts, snapshots and copy-on-write clones, continuous integrity checking and automatic repair. For example, 3 volumes are created in the ZFS filer for deployment. These volumes are mounted on each VM booted as part of this deployment.

  At 860, the SDI module 206 may issue a deploy command (eg, abctl deploy) to deploy the assembly. For example, the deploy command can boot one to four VMs by the VM manager.

  At 862, the SDI module 206 can set the assembly free in the SDI database. For example, the SDI module 206 can set USED = 0 for the PRE_PROV_JAVA_ASSEMBLY line. This indicates that the POD assembly is read to be assigned to the service instance.

  As mentioned earlier, the POD can be launched slowly so that the POD assembly is completed in advance, so when a customer orders a service, the customer promptly places the order (eg within a few seconds or Within a few minutes). Preliminary pooling of pods is based on an administrator configurable option (eg, Min_Used threshold) to anticipate future demand.

Service Instance Creation The SDI module 206 automates the creation and destruction of service instances and provides service instance monitoring capabilities to support specific business activities such as expiration of trial periods.

  The service instance creation API can be used to create a new system and / or service instance. The service instance creation API can be used to create a new system with one or more service instances belonging to the system, or can be used to create one or more service instances for an existing system. it can. The API can be asynchronous. Because APIs can be long-lasting operations that take minutes or hours depending on our implementation decisions and potential obstacles that require manual intervention to resolve. is there. Therefore, this API can adopt a callback address as one of its arguments. The immediate return value of the call may simply be a request ID that identifies a request for identification over the fulfillment period of the request. The result of the request can be given by calling back to the provided address. When a callback is made on the response body, the system and service instances created by the request can be fully operational and ready for use.

The callback address and service order document are inputs for the service instance creation API. The callback address may be an address for calling back to the TAS when the operation is completed. The service order document may be an XML document that describes an order that is processed by the TAS system. The service order document can give the following information:
Callback address: An address for calling back to the TAS when the operation is completed.

  System name: name for a new or existing system. The system name can be unique across the cloud architecture because this value will be used for the tenancy name within the shared IDM instance.

  Is this a new system indicator: a Boolean value that indicates whether this is an order to create a new system or an order to add a service instance to an existing system.

  • (Optional) System Admin User Name: The name of the system / tenancy administrator account that should be created when a new system is created.

  Service instance order list: 1-N system instance order. In this case, each system instance order includes:

-Service instance name: The name of the service instance to be created.
System instance names are unique within a given system.

    Admin user name: The name of the service instance administrator account to be created for this service instance.

    -Service instance type: the type of service to be created, such as FACRM, FA HCM, Java, WCC, APEX.

    -Service instance size: small / medium / large. All service instances now have some notion of size.

    Service specific properties: A set of properties specific to the type of service being created.

  The service order fulfillment document may be the output for the service instance creation API. As described above, the return value from this asynchronous call may be a request id that can be used to track this request during its duration. The response to the request can be sent as a callback to the callback address given as input. The service order fulfillment document may be an XML document that includes the following information:

Request id: Request id returned synchronously to the original API call.
System name: The system name generated or added by this request.

  (Optional) System / Tenancy Management Username and Temporary Password: If a new system is created with this request, these values can be returned as part of the response. These values may not be returned if the request only results in a new service being added to the existing system.

  (Optional) System IDM console URL: If this request creates a new system, the URL for the IDM console for this system can be returned.

  Service instance order list: Each service instance order includes:

-Service instance name: The name of the created service instance.
-Service instance management user name and temporary password: Service instance management account information.

    -(Optional) Service instance management URL: URL to the management console for the service instance, if applicable for the service. For example, in the case of a Java service, this should be a URL that leads to an EM console for the Java service.

    Service instance URL: URL that directs users to their newly created service instance.

  In addition, the SDI module 206 may have the ability to pre-deploy and associate service instances. Depending on the length of time required to deploy the various service instances, the assembly may be pre-deployed for these services. Thus, when a user requests a service instance, what the SDI module 206 should do is put any user-specific “personality” into the assembly and return it to the user.

Request Flow Provisioning When a customer requests an order, an SDI provisioning request is requested by the TAS during a single SOAP operation. A provisioning request may include a bundle of system / service create, read, update and delete (CRUD) operations. The provisioning request can be uniquely specified by the request Id.

  FIG. 9 illustrates a provisioning request flow according to some embodiments. For example, a provisioning request can be initiated by the TAS module 204. At 902, the TAS module 204 can set the request id by invoking the associated provisioning SOAP operation (CRUD) and sending a SOAP request. At 904, upon receiving a SOAP request, the SDI can respond with an HTTP 202 code and begin processing the request asynchronously. In addition, at 906, the SDI module 206 can first check whether this is a new request that can be determined by the request Id. Checking at 906 prevents the same request (ie, a request with the same request Id) from being reprocessed (eg, when the request is resubmitted, the “response to” and “correlation ID” values for the address. (Used for TAS callback) is updated to the value of its most recent SOAP request).

  If the request is not new, at 908, the SDI module 206 checks the request status (eg, from an existing SDI database entry). For example, if the status is “complete”, the request has been processed by that time. The SDI module 206 can then call the associated TAS “orderCompleteCallback” at 910. Alternatively, if the state is “cancelled”, the request has not been processed by that time. Then, at 912, the SDI module 206 can call the associated TAS “onFaultCallback” with the fault information.

  If the request is new, at 914, the request continues to be processed. The TAS module 204 can notify when processing is complete. The SDI module 206 can confirm the request. For example, there may be three confirmation categories such as input confirmation, status confirmation and confirmation lock. If the request is invalid at 916, the SDI module 206 can call the TAS “onFaultCallback” with the associated fault information.

  If the request is valid, at 918, the SDI module creates a new request, sets the state, and prepares. The SDI module 206 starts executing the request and continues to execute. For example, the next task in the task queue is executed, and then the next task is executed, and so on until all tasks are completed.

  If, at 920, all tasks associated with this request have been performed, the SDI module 206 can call the associated TAS “orderCompleteCallback” upon fulfillment of the order.

  In the error scenario, if the request is not completed and the single task fails, the subsequent task in the request may not be executed. At 922, the SDI module 206 can determine whether the error is recoverable. If the error is unrecoverable at 924, the request state is changed to a canceled state and the SDI module 206 can call the TAS “onFaultCallback” with the associated fault information. In addition, the SDI module 206 can add entries to the internal error queue. This queue will be polled by the EM module 208 to update the dashboard and send an alert email to the administrator. If the error is recoverable at 926, the SDI module 206 can change the state to a paused state and change from that state to a stopped state. In addition, the SDI module 206 can add entries to the internal error queue. This queue will be polled by the EM module 208 to update the dashboard and send an alert email to the administrator.

  When a new request for a service is received and confirmed by the SDI module 206, the SDI module 206 provisions the requested service. FIG. 10 shows a detailed flow of an example provisioning according to some embodiments. The provisioning process is managed by the SDI module 206.

  For example, TAS can be integrated with the system provisioning module from within the BPEL process. Specifically, the system provisioning interface can be exposed as an asynchronous SOAP-based web service call, and the TAS BPEL process for various lifecycle operations directly calls the system provisioning endpoint to perform provisioning tasks can do.

  In addition, system provisioning can use a callback API to send a result of success to the BPEL process or notify the BPEL process that the operation failed due to a failure. Upon receipt of the callback, the BPEL process either continues its normal flow with the result or follows a fault policy that handles the fault.

Example of Provisioning Java and Database Services FIG. 10 shows an end-to-end flow for provisioning both Java and database services for a customer. For example, at 1050, the customer can order a trial subscription. Customers using the cloud UI can sign up and use the Java service for free. The cloud UI can submit an order by making a PSQL call. In this case, this call may be for two different subscriptions, including a Java service subscription and a database service subscription, and may be submitted to the TAS module 204 via PSQL.

  At 1055, onboarding can begin and the TAS module can create a tenant call. At the tenant, the service type and size can be passed. In this example, there are two types as orders are for Java and database services. The corresponding size for the trial may be equally small. Alternatively, the size may be larger if the order was a paid order. The created tenant call is passed to the SDI module 206 for provisioning.

  At 1060, a loop call of a local candidate machine allows the SDI module 206 to reference available resources and possibly find a pre-provisioned POD. Depending on the service type, the resources may have been pre-pooled and already largely set up. Alternatively, if the service has not been pre-provisioned, the SDI module 206 may have to start from scratch to provision the requested service. For example, in the case of a Java service, the SDI module 206 can support preprovisioning a POD. In this case, all of the tasks of creating virtual machines and starting them up have been completed in advance. Thus, upon receiving a customer request, the SDI module 206 simply has a smaller step of personality injection. Personal injection involves customizing a pre-provisioned POD with a configuration for a particular customer at runtime. For database services, the SDI module 206 can create customer footprints on demand. On the other hand, the customer footprint can be a very virtual footprint because the database service uses a schema in an existing database. In the case of a fusion application, personality injection may include reconnecting the configuration to match specific customer details. In this example, the SDI module 206 may select an existing VM that has been pre-provisioned for Java services, or it may provision a new Java service, which is sufficient to launch a new VM. Including the selection of racks with the right resources.

  At 1065, the SDI module 206 may update the registry. The SDI module 206 can record on-board physical hardware resources to keep track of the underlying virtual machine manager and virtual machine pool. In addition, the SDI module can keep track of all created assemblies and VMs, and anonymous assemblies that are not assigned to customers or assemblies that are bound to a particular customer subscription, for example. You can keep track of whether or not.

  At 1070, the build ID returns to the onboard layer. This can notify the TAS module 204 that a system or service has been created for a particular request. The TAS module can asynchronously determine whether provisioning is complete. At 1075, the TAS module 204 can poll the SDI module 206 to check if a particular request is complete. Alternatively, an asynchronous SOAP request by the TAS module 204 can determine if the request is complete when the TAS 204 is waiting for a callback.

  At 1080, the SDI module can deploy a web logic server (WLS) assembly using an API (eg, OVAB Java API). For example, OVAB can internally call a VM manager to create individual VMs in the assembly. In addition, OVAB can have additional logic when there are multiple VMs to interface multiple VMs to allow the VM to support the overall WLS domain topology. At 1080 and 1085, the SDI module 206 can create a WLS machine pool and a DB machine pool. If the WLS assembly is actually deployed and can be returned via the VM manager and then back via OVAB, the SDI module can determine that an anonymous assembly has been created.

  In addition, anonymous assemblies can be incorporated into Nuviaq-based personality injection. For example, the SDI module 206 can call a Nuviaq connector and pass physical details and customer-specific details to allow Nuviaq to make runtime calls to the running VM. Nuviaq can reconfigure the web logic domain to match customer specific information (eg, the identity domain name to the URL selected by the customer).

  At 1085, the SDI module 206 can provision a database service. For example, the database service can be supported by an Exadata hardware database instance that can be pre-configured on Exadata hardware. As further described in FIG. 12, each instance can support many customers. The SDI module 206 can register Exadata in the DB service itself and manage ExadataPOD. Further, the SDI module 206 can provision database services using an APEX connector. APEX is an application express programming engine that sits on top of a database. The SDI module 206 can pass relevant information such as the size of the database service, customer identity domain name, etc. to the APEX connector to provision the database. The APEX connector can then add additional schema for the customer during execution. And table space can be allocated. In addition, a particular Exadata machine may be selected based on load, sizing, etc. The actual schema is returned to the SDI module 206, which can include connection information for the schema. The SDI module 206 generates a random credential and returns this credential to the TAS module 204.

  At 1090, the SDI module 206 can initiate a restart of the soft HTTP server (eg, OHS). The SDI module 206 can dynamically generate a configuration file with specific bindings for specific customers that may require a soft restart of the OHS. Soft restart allows all in-flight requests to be completed before restart. When OHS is resumed, inbound traffic to the POD through the routing layer can be realized.

  At 1095, a response is sent back to the TAS module 204 with a URL for the requested service and the generated password. The password may be a service administrator or may be an identity domain administrator password that can be given to a customer via email to access the service environment.

Service to Provision Java Cloud Service Instances FIG. 11A illustrates provisioning of Java cloud service instances according to one embodiment. Java cloud service instance provisioning can be performed by Java Service Provisioning Control (JSPC). For example, a provision platform instance use case may be realized by a create platform instance operation of a Java service that provisions a control API. In the public cloud context, a Java cloud service instance corresponds to a JSPC platform instance. A platform instance is assigned a unique identifier that can be used for all subsequent operations on this instance.

  The platform deployment descriptor provided for creation platform instance behavior allows setting properties that modify the configuration of the platform instance to meet the tenant subscription requirements. Properties can be used for the following purposes: Define subscription type / size (subscription type / size can affect the number of servers, database limits and quality of service settings); Indicates whether this is a trial subscription; identifies the CRM service to be associated with this web logic service instance.

  According to one embodiment, the SDI module 206 can use a continuous integration server (eg, Hudson) as a configuration manager. A continuous integration server makes it possible to automate builds and deployments. In addition, a continuous integration server can be used with cloud services and virtualization technologies so that users can improve resource utilization, reduce maintenance overhead, and automatically respond to sudden system load spikes. Can allow an interface.

  FIG. 11B shows a high-level schematic of various interactions for Java cloud service instance provisioning and fusion application association according to one embodiment. Provisioning Java services can be a process that can personalize VMs based on customer or tenant requirements. As shown in FIG. 11B, the Java service can extend the fusion application SaaS environment.

  FIG. 11B illustrates how anonymous assemblies are hydrated with tenant personalization information. For example, a Java service VM image can be provided as an OVAB assembly. Such assembly deployment results in an anonymous instance. As mentioned in FIG. 8B, the SDI module can pre-provision an anonymous instance of the service. An anonymous instance is a live VM, but is not associated with any tenant. As previously described, the SDI module 206 can pre-provision an anonymous VM to facilitate the process of creating a tenant environment or service instance.

  At 1101, the TAS module 204 can send a tenant request for the Java service to the SDI module 206. At 1102, the SDI module 206 can request an anonymous assembly from the assembly builder via the assembly builder connector. At 1103, the assembly builder can use OVM to deploy an anonymous assembly. At 1104, the anonymous assembly is sent to the SDI module 206. At 1105, the SDI module 206 can create an IDM slice via an IDM connector. At 1106, the IDM can return IDM coordinates to the SDI module 206. At 1107, the SDI module 206 can create a database slice via a database connector. At 1108, the database can return database coordinates to the SDI module 206. In some examples, the database may be an APEX database service.

  At 1109, the SDI module 206 can request via the Nuviaq connector to configure a Java service with the received IDM, database and EM coordinates. At 1110, Nuviaq can store all service instance data in the Nuviaq database. At 1111, Nuviaq can configure a Java service instance that can also include the start of an EM agent. In some examples, Nuviaq may be a Java service orchestrator.

  Furthermore, when using a Fusion application (FA) SaaS environment, it may be necessary to properly provision Java services according to the FA SaaS tenant. Thus, the provisioning process described in FIG. 11B may have to account for some differences in identity management.

  In a typical cloud PaaS (eg, Java service, database service) provisioning environment, there may be a single shared IDM that addresses all tenants. Each tenant's security information can be separated by IDM stripes (eg, identity domains) that can be separated from other tenants. In the case of FA SaaS, the IDM may be different and may be dedicated to each SaaS instance. Therefore, when the Java service and the FA service are integrated, it may be necessary to have an interaction between IDMs in order to support a function such as single sign-on.

  According to some embodiments, during provisioning of associated services, the SDI module can use a shared IDM between SaaS and PaaS services. Based on the shared IDM between SaaS and PaaS services, the following supportable use cases are shown: Partner / customer building application in Java cloud service integrated with FA web service; User interface embedded in FA Partner / customer-built applications in Java cloud services with: Impact from test and generation instances; Migration between test and generation instances; User integration with on-premises; and Cloud identity for other users Integration of real users with on-premises for some users using the store.

  FIG. 11C illustrates a PaaS and SaaS service association process according to some embodiments of the present invention. PaaS (eg, Java) service and SaaS (eg, FA) service association process may include PaaS environment hydration. For example, a Java service PaaS environment may include a hydration script that is invoked during provisioning. Scripts can perform various tasks such as configuring a PaaS domain. The task modifies the firewall rules to allow PaaS and SaaS interactions; investigates the changes required for the authentication servlet filter; adds the hooks needed to run during hydration to the puppet repository; Shared IDM integration; as well as web service configuration changes.

Service Provisioning Database Cloud Service FIG. 12 shows a high level logical diagram of a database cloud service according to some embodiments. The cloud database service can be provisioned by the SDI module 206. A database cloud service can have three main components: web service access that allows you to access data in the database cloud service with a simple URI; create and deploy all the many different applications in a browser-based environment Application Express for; and a set of business production efficiency applications that can be easily installed (for example with just a few clicks).

  Some key attributes of the architecture shared by multi-tenants may include: each tenant acquires a fully isolated schema; each Exadata compute node has multiple database instances; An instance has multiple schemas (eg tenants); each schema / tenant is a container that can manage database objects including tables, views, stored procedures, triggers; each schema has one dedicated tablespace Each tablespace has one data file.

  FIG. 12, similar to FIG. 7E, illustrates an example having multiple computing nodes (eg, EXADATA computing node 1202, EXADATA computing node 1204) in the same physical machine. In addition, database instance 1206 can reside within each compute node. In addition, two separate schemas (eg, schema 1208, schema 1210) can be included in each database instance 1206. According to another embodiment, more than two schemas can be included in one database instance. Each schema (eg, schema 1208, schema 1210) may be for a different customer. Thus, in some embodiments, multiple schemas associated with different customers can reside in the same database instance.

  In this database implementation, only one customer can reside in each database instance. Thus, multiple customers require multiple database instances. Alternatively, according to an embodiment of the present invention, a database instance can be shared among multiple customers because multiple schemas are included in a single database instance. Each schema can represent a tenant, so one database instance can have multiple tenants.

  For example, the fusion application and Java service are single tenant services. Single tenant services are assigned to one customer. The database service is a multi-tenant service. The POD for database service is an Exadata rack with a few database instances for the rack. In this case, many customers can use one POD. Therefore, since the POD can have multiple customers, the database service is a multi-tenant service. This allows a POD to be set up once and then run-time provisioned by the SDI module 206 to add multiple tenants to the POD at run-time.

  FIG. 13 illustrates a service provisioning flow 1300 for a multi-tenant database service according to some embodiments. As shown in FIG. 12, the database service is an example of a multi-tenant service. This is because a single database instance can have multiple schemas associated with different customers.

  At 1302, the customer requests a database service from the cloud UI 212 for a trial service. Alternatively, the customer can request a database service from the store UI 210 for paid services. At 1304, the cloud UI 212 sends a customer request to the TAS module 204. At 1306, the TAS module 204 can initiate provisioning by calling the SDI module 206 via BPEL. In some examples, the TAS module 204 can initiate provisioning only if the service is available. At 1308, the SDI module 206 can call the PSQL API in the CLOUD_UI to associate the schema for the requesting customer. At 1310, after successful association, the SDI module 206 can notify the TAS module 204, which can notify the customer (eg, via email). The customer then logs into the web server and starts the database service.

  According to another embodiment, service provisioning for a fusion application may be realized. For example, a new fusion application subscription order is received by the SDI module 206. Once the order is approved, the fusion application POD is provisioned. A customer (eg, a tenant) provides important information to allow a tenant to be set up in its pod. When the initial user is created, the fusion application cloud service sends the user ID and password to the initial user by e-mail. In addition, the tenant provisioning to the allocation pod is a subset of the standard setup process that on-premises customers will employ.

  FIG. 15 illustrates the physical architecture of a pre-provisioned pod 1500 according to an embodiment of the present invention. As shown in FIG. 15, multiple pods may be pre-provisioned for one or more services provided by the cloud infrastructure. For example, as shown in FIG. 15, a set of pods 1505 may be pre-provisioned for JAVA services and a set of pods 1510 may be pre-provisioned for database services.

  As described above, a pod is a modular assembly of resources (eg, processing resources, networking resources, memory resources) that are wired together to provide a particular service. For example, as shown in FIG. 15, pre-provisioned pod 1500 includes one or more virtual machines for Java service 1505 (eg, Oracle Virtual Machine (OVM)) and one or more database resources 1510 (eg, Oracle). Exadata database) can be logically grouped. Database resources may include storage, infrastructure and network components. Pre-provisioned pods may be configured for single-tenancy service or multi-tenancy service.

  A pod is considered pre-provisioned because it is created before receiving a subscription order requesting the service that the pod will be used for. In one embodiment, for a specific service, each pre-provisioned pod is a fixed pod size or set of resources, such as a fixed number of virtual machines, managed servers, and deployed servers. And so on. A pod pre-provisioned for one service can be different from a pod pre-provisioned for another service. This is because the type and number of resources used to provide one service (eg JAVA service) may be different from the type and number of resources used to provide another service (eg database service). Because there is. For example, pods 1505 pre-provisioned for JAVA services may be similar to each other, but they may be different from pods 1510 pre-provisioned for database services.

  Cloud infrastructure system 100 may create a pool of pre-provisioned pods 1500. Creating such pods reduces the amount of processing required to provision resources in response to customer subscription orders for services. This reduces the amount of time required to provision resources for the services requested in the subscription order. Reduce the time required to create a new service instance for a customer in response to a customer subscription order for the service.

  Upon receiving an order from a customer requesting a service, the cloud infrastructure system 100 can use one or more pods from a pre-provisioned pool of pods pre-provisioned for that service. In some embodiments, in response to a service order, a pre-provisioned pod for that service is selected, and then customer specific information (eg, customer specific information determined from the customer order) is injected. Then, a customized pod for the customer may be created. For a customer, a new service instance may be created from one or more of these customized pods.

  The number of service specific pre-provisioned items selected for a particular service request and customized for the customer may depend on the size of the requested service. In some embodiments, the number of pre-provisioned pods assigned to a service request is directly proportional to the size of the requested service. In addition, as customer demand increases (eg, tenant service level agreement (SLA) requirements increase), additional pre-provisioned pods are selected and assigned to customers (ie, customer To get customized).

  As new orders for services are received and processed and / or as customer service requirements increase, more and more pre-provisioned pods can be customized for those orders. This can drastically reduce the number of pods in the pre-provisioned available pool of pods for that service. In one embodiment, the cloud infrastructure system 100 can create a new pre-provisioned for the service in the background when the number of pre-provisioned pods falls below a certain user-configurable minimum threshold for the service. May be configured to create a pod. Such thresholds may be defined for various services provided by the cloud infrastructure system 100.

  FIG. 16 illustrates an example of customer-specific customization of a pre-provisioned pod for service instance creation according to an embodiment of the present invention (sometimes referred to as customer personality assignment). For example, a subscription order may have been received from a customer “us” requesting JAVA and database services. In response to the order, the cloud infrastructure system 100 requires a single pre-provisioned JAVA service pod to create a Java instance to provide the requested JAVA service requested by “we”. As well as determining that a single pre-provisioned database service pod is required to create a database service instance to provide the requested database service. As shown in FIG. 16, a pre-provisioned pod (pre-provisioned JAVA pod # 1) from a pool of pre-provisioned pods for JAVA services is selected and requested by customer “our”. Was assigned to the customer “our company” to provide JAVA services. In addition, the database service is selected so that a pre-provisioned pod (pre-provisioned DB Pod # 1) from the pool of pre-provisioned pods 1510 for the database service is selected and requested by the customer “we”. Assigned to customer “our company” to provide. The pre-provisioned JAVA pod # 1 is created by injecting “we” specific information (eg configuration information) into the pod to create a personalized pod # 1 1605 for the customer for the JAVA service. Personalized for “our company”. In this manner, a JAVA service instance configured to provide a JAVA service to the customer “our company” may be created using a pre-provisioned JAVA service pod. With respect to the database service, the pre-provisioned DB pod # 1 uses “our company” specific information (eg configuration information) in the pod to create a personalized DB pod # 1 1610 for the customer for the database service. By personalization, it was personalized for the customer “our company”. In this manner, a database service instance configured to provide a database service for customer “our” may be created using a pre-provisioned database service pod.

  FIG. 17 illustrates an example of a method for creating a personalized JAVA service pod or service instance and a personalized database service pod or instance using a pre-provisioned pod, according to one embodiment.

  In some embodiments, pre-provisioning of pods may be performed by SDI module 206. For example, the SDI module 206 may be configured to create each pre-provisioned JAVA service pod by pre-saving resources and wired (eg, creating and launching a virtual machine). Good. This pool of pre-provisioned Java service pods may then be used by the SDI module 206 to create a customer specific service instance for providing the JAVA service requested by the customer. Upon receiving customer service requests, SDI module 206 uses these pre-provisioned pods to make these pods customer-specific by injecting customer-specific personalities into these pods. Personality injection may include customizing a pre-provisioned pod with specific customer-specific configuration information at runtime. For database services, the SDI module 206 can create customer footprints on demand.

  In one embodiment, the TAS module 204 may submit a service order document to the SDI module 206 at 1705, as shown in FIG. As previously mentioned, the service order document may include information such as a callback address; a system name; a Boolean value for the new system indicator; a system administrator username; and a list of service instance orders. The list of service instance orders may further include service instance name; administrator user name; service instance type; service instance size; service specific properties. With respect to the example shown in FIG. 16, the requested service instance types in the service order document may be JAVA service instances and database service instances.

  At 1710, after receiving the service order document, the SDI module 206 may determine the number of pre-provisioned pods needed to meet the requirements specified in the service order document. In one embodiment, this determination may be made based on service instance type, service instance size, and service specific properties.

  At 1715, based on the data in the service order document, the SDI module 206 uses the SDI connector module 612 to create one of the pre-provisioned pods to create a personalized service instance for the customer. You can customize these pods. Pre-provisioned pod customization may include injecting personality information (eg, callback address, system name, system administrator username) received from a customer order into a pre-provisioned pod.

  In this example, based on the service order document, the specific SDI connector module 612 may be an APEX connector 614 for creating a database service instance 1610 and an NUVIAQ connector 620 for creating a JAVA service instance 1605. .

  At 1720, when a personalized service instance (eg, JAVA service instance 1605, database service instance 1610) is created, SDI module 206 may submit a service order fulfillment document to TAS module 204. As mentioned above, the service order fulfillment document may be an XML document, which includes a request identifier; system name; system / tenancy administrator username and password; system IDM console URL; A list of available services may be included. Further, for each ordered service, the service order fulfillment document may include a service instance name; a service instance administrator username and password; a service instance management URL; a service instance URL.

  FIG. 14 is a simplified block diagram of a computing system 1000 that may be used in accordance with an embodiment of the present invention. For example, the cloud infrastructure system 100 may include one or more arithmetic devices. The system 1000 shown in FIG. 14 may be an example of one such arithmetic device. A computer system 1000 is shown that includes hardware elements that can be electrically coupled via a bus 1024. The components include one or more processing units 1002, an input subsystem 1004, an output subsystem 1006, a storage device 1008, a computer readable storage medium reader 1012 connected to a computer readable storage medium 1010, a communication subsystem 1014, and a processing acceleration. Subsystem 1016 and working memory 1018 may be included.

  The bus subsystem 1024 provides a mechanism for communicating various components and the subsystems of the computer system 1000 with each other as expected. Although the bus subsystem 1024 is shown schematically as a single bus, alternate embodiments of the bus subsystem may utilize multiple buses.

  Input subsystem 1004 may include one or more input devices such as a mouse, keyboard, pointing device, touchpad, and the like. In general, input subsystem 1004 may include any device or mechanism for entering information into computer system 1000.

  The output subsystem 1006 may include one or more output devices for outputting information from the computer system 1000. Examples of output devices include, but are not limited to, display devices, printers, projection devices, and the like. In general, output subsystem 1006 may include any device or mechanism for outputting information from computer system 1000.

  Processing unit 1002 may include one or more processors, one or more cores of processors, combinations thereof, and the like. In some embodiments, the processing unit 1002 may include a general purpose main processor, as well as one or more dedicated coprocessors such as a graphics processor, a digital signal processor, and the like. In some embodiments, some or all of the processing units 1002 may be customized circuits such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). It can be realized using. In some embodiments, such an integrated circuit executes instructions stored in the circuit itself. In other embodiments, processing unit 1002 may execute instructions stored in working memory 1018 or storage device 1008. In various embodiments, the processing unit 1002 can execute various programs or code instructions and can maintain multiple programs or processes running simultaneously. At any given time, some or all of the program code to be executed may reside in system working memory 1018, in storage device 1008, and / or on computer readable storage medium 1010. With appropriate programming, the processing unit 1002 can provide the various functions described above to perform event stream related processing. In some embodiments, the computer system 1000 may also include a processing acceleration unit 1016 that may include a digital signal processor (DSP), a dedicated processor, and the like.

  Storage device 1008 may be a disk drive, optical storage device, and solid state storage device, eg, random access memory (RAM) and / or read only memory (ROM), which may be programmable, flash updatable, and the like. -only memory) may be included. Software (programs, code modules, instructions) executed by the processing unit 1002 to provide the functions described above may be stored in the storage device 1008. Storage device 1008 may also provide a repository for storing data used in accordance with embodiments of the present invention.

  Further, the computer readable storage media reader 1012 is a remote, local, fixed for containing computer readable information both temporarily (and optionally in combination with the storage device 1008) temporarily and / or more permanently. And / or connectable to a computer readable storage medium 1010 representative of a removable storage device plus storage medium.

  Communication system 1014 may allow data to be exchanged with networks and / or other computers. The communication subsystem 1014 serves as an interface for receiving and transmitting data to other systems in the computer system 1000. This communication may be provided using a wired protocol or a wireless protocol. For example, the communication subsystem 1014 may allow the computer 1000 to connect to client devices over the Internet. The communication subsystem 1014 may include a modem, a network card (wireless or wired), an infrared communication device, a GPS receiver, and the like.

  The working memory subsystem 1018 includes a number of memories including a main random access memory (RAM) for storing instructions and data during program execution and a read only memory (ROM) in which certain instructions are stored. obtain. Software elements such as operating system 1020 and / or other code 1022 such as application programs (which may be client applications, web browsers, middle tier applications, RDBMSs, etc.) may be stored in working memory 1018. In the exemplary embodiment, working memory 1018 includes executable code and associated data structures (such as a cache) that are used to process events and allow variable duration windowing as described above. May be included.

  It should be understood that alternative embodiments of computer system 1000 may have some components with numerous variations from those described above. For example, customized hardware may be used and / or certain elements may be implemented in hardware, software (including highly portable software such as applets) or both. Further, connections to other computing devices such as network input / output devices may be utilized.

  FIG. 18 is a simplified block diagram of an electronic device 1800 according to an embodiment of the present invention. The electronic device 1800 includes a first resource assembly set creation unit 1802. The first resource assembly set creation unit 1802 includes a first set of one or more resource assemblies for a first service from a plurality of cloud services provided by a cloud infrastructure system that includes one or more computing devices. Configured to create. Each resource assembly in the first set of resource assemblies includes one or more resources for providing a first service. The electronic device 1800 further includes a receiving unit 1804. The receiving unit 1804 is configured to receive subscription order information from the customer after creation. The subscription order information includes a customer specific configuration and an order request for the first service. The electronic device 1800 further includes a first resource assembly selection unit 1806. First resource assembly selection unit 1806 is configured to select a first resource assembly from a first set of resource assemblies to provide a first service to a customer based on subscription order information. . The electronic device 1800 further includes a first customer specific resource assembly creation unit 1808. A first customer-specific resource assembly creation unit 1808 creates a first customer-specific resource assembly to provide a first service to a customer by configuring the first resource assembly in a customer-specific configuration. Configured.

  In one example, the subscription order information requests a second service from a plurality of cloud services provided by the cloud infrastructure system. The electronic device 1800 further includes a second resource assembly set creation unit 1803. The second resource assembly set creation unit 1803 is configured to create a second set of resource assemblies for the second service from a plurality of cloud services provided by the cloud infrastructure system. Each resource assembly in the second set of resource assemblies includes one or more resources for providing a second service. Creation of the second set of resource assemblies is performed before receiving subscription order information from the customer. The electronic device 1800 further includes a second resource assembly selection unit 1805. The second resource assembly selection unit 1805 selects one or more second resource assemblies of the second set of resource assemblies based on the subscription order information to provide a second service to the customer. It is comprised so that it may select from the arithmetic unit of. The electronic device 1800 further includes a second customer specific resource assembly creation unit 1807. The second customer specific resource assembly creation unit 1807 is further adapted to create a second customer specific resource assembly to provide a second service to the customer by configuring the second resource assembly in a customer specific configuration. Configured. The electronic device 1800 further includes an integration unit 1809. The integration unit 1809 adjusts one or more firewalls associated with the first customer-specific resource assembly and the second customer-specific resource assembly to provide a first customer-specific resource assembly and a second customer-specific resource assembly. Is configured to integrate the first customer specific resource assembly and the second customer specific resource assembly.

  In one example, the first service is a database service, and the first customer specific resource assembly creation unit 1808 further uses a virtual assembly builder to provide a database service comprising one or more virtual machines (VMs). Create a first resource assembly specifically provisioned for the virtual assembly builder associated with the virtual assembly builder to allow the virtual assembly builder to operate in parallel Create a home; configured to create a deployment plan file. The deployment plan file includes configuration information for injecting customer specific configuration into one or more VMs.

  In one example, each resource assembly in the first set of resource assemblies is configured for multi-tenant service.

  In one example, the first service is a database service. Multiple schemas are included in the first resource assembly. The plurality of schemas includes a first schema associated with the first customer and a second schema associated with a second customer different from the first customer.

  In one example, each resource assembly in the first set of resource assemblies is configured for a single tenant service.

  In one example, the subscription order information includes a service instance size. The electronic device 1800 further includes a determination unit configured to determine the number of resource assemblies to be used for the customer from the first set of resource assemblies based on the service instance size.

  In one example, the electronic device 1800 further includes a storage unit configured to store a registry to keep track of the first set of resource assemblies provisioned for the first service. The registry is further configured to track one or more resource assemblies that are customer specific.

  The unit indicated by the dotted line is arbitrary. The various units disclosed herein may be implemented in or performed by hardware, software, or a combination thereof. They are general-purpose single-chip or multi-chip processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), fields designed to perform the functions described herein. A programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic circuit, a discrete hardware component, or any combination thereof, or can be implemented by May be. A general purpose processor may be a microprocessor, or any conventional processor, controller, microcontroller, or state machine. The processor may be realized as a combination of arithmetic devices, for example, a combination of a DSP and a microprocessor, a combination of a plurality of microprocessors, a combination of one or more microprocessors used in combination with a DSP core, or other such configuration. May be. In some implementations, the unit may be implemented by circuitry that is specific to a given function.

  While specific embodiments of the invention have been described, various modifications, changes, alternative configurations and equivalents are also encompassed within the scope of the invention. Embodiments of the present invention are not limited to operation within a specific specific data processing environment, but can operate freely within a plurality of data processing environments. Further, while embodiments of the present invention have been described using a specific sequence of transactions and steps, it is to be understood that the scope of the present invention is not limited to the set of transactions and steps described. Should be obvious to the contractor.

  Further, although embodiments of the invention have been described using specific combinations of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of the invention. Embodiments of the present invention may be implemented in hardware only, software only, or a combination thereof. The various processes described in this specification can be implemented on the same processor or on any combination of processors. Thus, although a component or module is described as being configured to perform a number of operations, such a configuration can be operated by, for example, designing an electronic circuit to perform the operations. This can be accomplished by programming electronic circuitry (such as a microprocessor) that is programmable to execute, or a combination thereof. Processes can communicate using a variety of techniques, including but not limited to conventional techniques for inter-process communication, and different pairs of processes may use different techniques, or the same pair of processes The process may use different techniques at different times.

  The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense. However, it will be apparent that additions, reductions, deletions and other variations and modifications may be made thereto without departing from the broader spirit and scope described in the claims. Thus, although specific embodiments of the invention have been described, they are not intended to be limiting. Various modifications and equivalents are within the scope of the appended claims.

Claims (17)

A method,
Creating a first set of one or more resource assemblies for a first service from a plurality of cloud services provided by the cloud infrastructure system by a cloud infrastructure system including one or more computing devices; Each resource assembly in the first set of resource assemblies includes one or more resources for providing the first service, the method further comprising:
Receiving, by the cloud infrastructure system, receiving subscription order information from a customer, wherein the subscription order information includes a customer specific configuration and an order request for the first service, the method comprising: further,
In order to provide the customer with the first service, any one of the one or more computing devices may provide a first from the first set of resource assemblies based on the subscription order information. Selecting a resource assembly for
In order to provide the customer with the first service by configuring a first customer-specific resource assembly in the customer-specific configuration, the first customer-specific resource assembly is configured by any of the one or more computing devices to Creating a customer specific resource assembly;
Provisioning said first service by said computing device based at least in part on said customer specific configuration identified in said first customer specific resource assembly. The subscription order information requests a second service from the plurality of cloud services provided by the cloud infrastructure system, and the method further comprises:
Creating by the cloud infrastructure system a second set of resource assemblies for a second service from the plurality of cloud services provided by the cloud infrastructure system, the second set of resource assemblies Each resource assembly includes one or more resources for providing the second service, and the creation of the second set of resource assemblies is performed prior to receiving the subscription order information from the customer. The method further comprises:
In order to provide the customer with the second service, any one of the one or more computing devices may receive a second from the second set of resource assemblies based on the subscription order information. Selecting a resource assembly for
In order to provide the customer with the second service by configuring the second resource assembly in the customer-specific configuration, any computing device of the one or more computing devices may provide a second Creating a customer-specific resource assembly;
Adjusting the first customer specific resource assembly and the second customer specific resource assembly by adjusting one or more firewalls associated with the first customer specific resource assembly and the second customer specific resource assembly; Integrating the first customer-specific resource assembly and the second customer-specific resource assembly by any of the one or more computing devices to enable data flow between the first customer-specific resource assembly and the second customer-specific resource assembly. The method of claim 1 comprising:   The method according to claim 1 or 2, wherein the step of configuring the resource assembly with the customer specific configuration comprises customizing the resource assembly with information contained in the customer specific configuration. The first service is a database service, and the step of creating the first customer specific resource assembly further comprises:
Creating the first resource assembly specifically provisioned for the database service with one or more virtual machines (VMs) using a virtual assembly builder;
Creating a virtual assembly builder home associated with the virtual assembly builder to enable parallel virtual assembly builder operation;
Creating a deployment plan file, wherein the deployment plan file includes configuration information for injecting the customer specific configuration into the one or more VMs. The method according to claim 1.   The method of any one of claims 1-4, wherein each resource assembly in the first set of resource assemblies is configured for multi-tenant services. The first service is a database service;
A plurality of schemas are included in the first resource assembly, the plurality of schemas being associated with a first schema associated with the first customer and a second customer different from the first customer. 6. The method of claim 5, comprising a second schema.   The method of any one of claims 1-4, wherein each resource assembly in the first set of resource assemblies is configured for a single tenant service. The subscription order information includes a service instance size, and the method further includes:
Determining the number of resource assemblies to be used for the customer from the first set of resource assemblies based on the service instance size by any of the one or more computing devices. The method according to claim 1, comprising:   Storing a registry to keep track of the first set of resource assemblies provisioned for the first service by the cloud infrastructure system, the registry being further customer specific 9. A method according to any one of the preceding claims, configured to track one or more resource assemblies. A system,
One or more computing devices configurable to provide a set of cloud services;
A first set of one or more resource assemblies for a first service of a plurality of cloud services provided by a cloud infrastructure system, wherein each resource assembly in the first set of resource assemblies is , Including one or more resources for providing the first service, the system further comprising:
A memory configurable to store subscription order information from a customer, wherein the subscription order information includes a customer specific configuration and an order request for the first service;
An arbitrary arithmetic device among the one or more arithmetic devices is:
Selecting a first resource assembly from the first set of resource assemblies based on the subscription order information to provide the customer with the first service;
Creating the first customer specific resource assembly to provide the first service to the customer by configuring the first customer specific resource assembly in the customer specific configuration;
A system configurable to provision the first service based at least in part on the customer specific configuration identified in the first customer specific resource assembly. The subscription order information requests a second service from the plurality of cloud services provided by the cloud infrastructure system, the system further comprising:
Configured to create a second set of resource assemblies for a second service from the plurality of cloud services provided by the cloud infrastructure system, wherein each resource assembly in the second set of resource assemblies is , Including one or more resources for providing the second service, wherein the creation of the second set of resource assemblies is performed prior to receiving the subscription order information from the customer, the system further comprising: ,
Selecting a second resource assembly from the second set of resource assemblies based on the subscription order information to provide the customer with the second service;
Creating a second customer-specific resource assembly to provide the second service to the customer by configuring the second resource assembly in the customer-specific configuration;
Adjusting the first customer specific resource assembly and the second customer specific resource assembly by adjusting one or more firewalls associated with the first customer specific resource assembly and the second customer specific resource assembly; The system of claim 10, wherein the system is configured to integrate the first customer specific resource assembly and the second customer specific resource assembly to allow data flow between the first customer specific resource assembly and the second customer specific resource assembly. The subscription order information includes a service instance size, and
12. A system according to claim 10 or 11, configured to determine the number of resource assemblies to be used for the customer from the first set of resource assemblies based on the service instance size. Further configured to store a registry to keep track of the first set of resource assemblies provisioned for the first service, the registry further comprising one or more resources that are customer specific 13. A system according to any one of claims 10 to 12, configured to track an assembly. A system for providing a set of cloud services,
Means for maintaining a first set of one or more resource assemblies for a first service of a plurality of cloud services provided by a cloud infrastructure system, the first set of resource assemblies Wherein each resource assembly includes one or more resources for providing the first service, the system further comprising:
Means for storing subscription order information from a customer, wherein the subscription order information includes a customer specific configuration and an order request for the first service, the system further comprising:
Means for selecting a first resource assembly from the first set of resource assemblies based on the subscription order information to provide the first service to the customer;
Means for creating the first customer specific resource assembly to provide the first service to the customer by configuring the first customer specific resource assembly in the customer specific configuration;
Means for provisioning the first service based at least in part on the customer specific configuration identified in the first customer specific resource assembly. The subscription order information requests a second service from the plurality of cloud services provided by the cloud infrastructure system, the system further comprising:
Means for creating a second set of resource assemblies for a second service of the plurality of cloud services provided by the cloud infrastructure system, wherein in the second set of resource assemblies Each resource assembly includes one or more resources for providing the second service, and the creation of the second set of resource assemblies is performed prior to receiving the subscription order information from the customer; The system further includes:
Means for selecting a second resource assembly from the second set of resource assemblies based on the subscription order information to provide the second service to the customer;
Means for creating a second customer specific resource assembly to provide the second service to the customer by configuring the second resource assembly in the customer specific configuration;
Adjusting the first customer specific resource assembly and the second customer specific resource assembly by adjusting one or more firewalls associated with the first customer specific resource assembly and the second customer specific resource assembly; 15. The system of claim 14, comprising means for integrating the first customer specific resource assembly and the second customer specific resource assembly to allow data flow between the first customer specific resource assembly and the second customer specific resource assembly. A computer readable program for a cloud infrastructure system configured to provide a set of cloud services, the cloud infrastructure system comprising:
Creating a first set of one or more resource assemblies for a first service from a plurality of cloud services provided by the cloud infrastructure system, wherein each resource assembly in the first set of resource assemblies includes: Including one or more resources for providing the first service;
After creation, subscription order information is received from the customer, including customer specific configuration and order request for the first service,
Selecting a first resource assembly from a first set of resource assemblies based on the subscription order information to provide the customer with the first service;
Configuring the first customer specific resource assembly to provide the first service to the customer by configuring the first customer specific resource assembly in the customer specific configuration;
A computer readable program for causing the first service to be provisioned based at least in part on the customer specific configuration identified in the first customer specific resource assembly. The subscription order information requests a second service from the plurality of cloud services provided by the cloud infrastructure system, and the computer readable program further requests the cloud infrastructure system,
Creating a second set of resource assemblies for a second service from the plurality of cloud services provided by the cloud infrastructure system, wherein each resource assembly in the second set of resource assemblies is the second The creation of the second set of resource assemblies is performed prior to receiving the subscription order information from the customer, further comprising:
Selecting a second resource assembly from a second set of resource assemblies based on the subscription order information to provide the customer with the second service;
Creating a second customer-specific resource assembly to provide the customer with the second service by configuring the second resource assembly in the customer-specific configuration;
Adjusting the first customer specific resource assembly and the second customer specific resource assembly by adjusting one or more firewalls associated with the first customer specific resource assembly and the second customer specific resource assembly; The computer readable program of claim 16, wherein the first customer specific resource assembly and the second customer specific resource assembly are integrated to allow data flow between the first customer specific resource assembly and the second customer specific resource assembly.