Abstract:
A platform on a platform system has a first platform that provides deployment and configuration settings for applications developed on the platform; and a second platform developed using the deployment and configuration settings provided by the first platform. The second platform provides second deployment and second configuration settings, and the second platform also provides services that allow second applications to interact with the first platform through the second platform services.

Description:
BACKGROUND 
       [0001]    Platform technology enables the creation of applications and processes using the properties of the existing platform. Oracle, Amazon, VMWare, Microsoft, and Salesforce all produce platforms, and particular cloud-based platforms, that they sell as a service. This business model is called Platform as a Service (PaaS). 
         [0002]    The advantage of platforms is that they provide an already-developed backend for running complex applications. Thus, for someone familiar with the platform, they save significant hours of programming by providing application developers with a feature-laden environment that they do not have to develop for themselves. 
         [0003]    In this platform as a service model, the application developer creates the software using tools and libraries from the platform provider, for example Salesforce. The developer may also control software deployment and configuration settings. The platform provider provides the networks, servers, storage, and other services that are required to host the developer&#39;s application. 
         [0004]    One of the challenges that a developer faces, however, when using a PaaS is that he is slave to the platform&#39;s rules. Thus, it may require many unnecessary steps to perform an installation or update to the application because the developer must meet all the PaaS&#39;s requirements. Or an update or new application may get hung up in deployment due to delays or triggers set out in the PaaS that the developer did not know about. 
       SUMMARY OF THE EMBODIMENTS 
       [0005]    A platform on a platform system comprises: a first platform that provides deployment and configuration settings for applications developed on the platform; and a second platform developed using the deployment and configuration settings provided by the first platform, wherein the second platform provides second deployment and second configuration settings, wherein the second platform provides services that allow second applications to interact with the first platform through the second platform services. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0006]      FIG. 1  shows a representation of the platform, developer, and user interface. 
           [0007]      FIG. 2  is a flowchart showing the configuration service. 
           [0008]      FIG. 3  is a flowchart showing the license manager service. 
           [0009]      FIG. 4  is a flowchart showing the dispatcher service route. 
           [0010]      FIG. 5  is a flowchart showing the dispatcher service extension. 
           [0011]      FIG. 6  is a flowchart showing the domain meta service. 
           [0012]      FIG. 7  is a flowchart showing the install service. 
       
    
    
     DETAILED DESCRIPTION OF THE EMBODIMENTS 
       [0013]    The platform on a platform (PoP) described herein seeks to overcome some of the challenges described above. For the sake of the application discussed herein, the platform is shown as a cloud-based platform although non-cloud-based platforms are possible. 
         [0014]      FIG. 1  shows an overview of the PoP architecture including a PaaS  100  that provides its platform for application development. An application developer of APP 1   110  develops an application using the PaaS  100  in the known manner and this application would be available and updatable through the PaaS to a user 1  120 . This is the known model. 
         [0015]    Similar to developing an application, a platform on a platform (PoP) developer would program its own PoP  140  on top of the PaaS  100 . Such a PoP  140  would have to maintain the integrity of following the PaaS rules and protocols, but it could choose how best to do that, and/or provide different (often improved) rules and protocols for its own developers. The PoP  140  would provide a unique platform to allow an APP 2  developer  150  to develop its own applications. A user2  160  could use the APP 2  developer  150 &#39;s application through the PoP  140 . In this way, the user2  160  may have no direct interaction with the PaaS  100 , and only interact with the PoP  140 . This can be an advantage to the user2  160  because the PoP  140  may have features that are better than the PaaS  100 , such as easier updating of applications, which may allow for faster updates that do not require software reinstallation, for example. 
         [0016]    As shown in  FIG. 1 , a user3  170  may use applications from both the PoP  140  and PaaS  100 . 
         [0017]      FIGS. 2-7  describe several services that allow the PoP  140  to work on top of the PaaS  100 , and interact with the APP 2  developer  150  and users  160 ,  170 . The concept is that through configuration changes and less code manipulation, objects can be coupled together using metadata in a multi-tenant environment, and thus grant control to the PoP  140  that exists independent as a platform from the PaaS  140 . 
       Configuration Service 
       [0018]      FIG. 2  shows a configuration service that could run on the PoP  140 . The configuration service confirms that an application developer can update or create an application on the PoP  140 . 
         [0019]    The configuration service may be always listening for a developer&#39;s installation or update  205 . When a developer tries to perform an installation or update, the PoP first checks to ensure that the developer&#39;s object or application includes an app namespace  215 , which may be a requirement. If the developer&#39;s application or object does not include the app namespace, the PoP generates an error  230  and returns to listening  205 . 
         [0020]    If the developer&#39;s object or application has an app namespace, the PoP checks to see if the namespace matches an installed package  225 . This is a check to make sure the namespace exists if it does not, the PoP then checks to see if the namespace matches the global registry  240 , and if it does, generates a namespace exception  230 , and returns to listening  205 . If there is no match in the global registry, the PoP may prompt the user to register a new namespace  245  (or this prompt may not be necessary as it may be predetermined by the developer). If the new namespace is not to be registered, the PoP generates the namespace exception  230  and returns to listening  205 . 
         [0021]    If the new namespace is to be registered, the PoP will proceed to register the namespace  250  and return to listening  205 . 
         [0022]    If the namespace matches the installed package, the PoP checks to see if the developer has permission to perform the installation or update  255 . This check may be done by confirming a permission flag related to the developer account performing the update or installation configuration. If the developer does not have permission to perform the update or installation, a PoP license manager generates an exception  260  and the PoP returns to listening  205 . 
         [0023]    If the developer has permission, the PoP checks to see if the developer&#39;s object or application is a new instance or an update  265 . If it is an update, the PoP updates the configuration requested and returns to listening. If it is a new installation, the PoP creates a new configuration  275  and returns to listening  205 . 
       License Manager Service  
       [0024]    The license manager service, shown in  FIG. 3 , checks to see if certain installation and activity activities are permitted. This is an ongoing check of the developer&#39;s installation and update against rules set up in the PoP. 
         [0025]    The service begins with the license manager listening for an installation  305 . Upon an installation or update initiated by a developer, the PoP first checks to see if the developer is licensed to perform the install  310 . If the developer is licensed, the PoP then confirms that the app is enabled  315  and if it is, the PoP confirms that the object is enabled  320 . If the developer is licensed with an enabled application and object, the license manager returns to listening  305 . 
         [0026]    If, however, the developer is unlicensed, the application is not enabled, or the object is not enabled, the PoP then checks to confirm if the core configuration is enabled  325 . (This could be important in an instance where the core is disabled.) If the core configuration is not enabled, the PoP returns an error message  330  and resumes listening  305 . 
         [0027]    If the core configuration is enabled, the PoP then checks to see if a trigger is executing  335 . This check could also be a check to confirm that a trigger is not awaiting execution. Examples of such triggers may be for a data or code update. 
         [0028]    If a trigger is executing or pending execution, the PoP confirms whether core triggers for generating objects are enabled  340 . If not, the PoP returns an error  330 . If the core triggers for generating objects are enabled, the PoP confirms that object configuration triggers are enabled  345 . If they are not, the PoP returns an error  330  and returns to listening  305 . 
         [0029]    If a trigger is not executing  335  or if the object configuration triggers are enabled  345 , the PoP then confirms that object configuration is enabled  350 , application configuration is enabled  355 , and that the object type is accessible  360  and if all of these are confirmed, the PoP returns to listening  305 . If any of these are not true, the PoP returns an error  330  before returning to listening  305 . 
       Dispatcher Service 
       [0030]      FIGS. 4 and 5  show the dispatcher service route and dispatcher service extension. These logic flows are in place to oversee how the application developer&#39;s application has access to the PaaS  100  though the PoP  140 , and ensure that the application being developed or updated meets the requirements of the PaaS  100 . 
         [0031]    Routing rules, mentioned in more detail in  FIG. 5 , control the behavior of how the PoP routes logic for processing when objects are inserted, updated, and deleted from a database. The rules might include triggers, batches, and schedule types. Every new object installed needs a new rule. 
         [0032]    The dispatcher route service in  FIG. 4  starts with the dispatcher service listening for a developer installation or update  405 . If there is an update or install, the PoP first checks if the core is enabled  410  and if it is not, the PoP generates an error message  415  and returns to listening  405 . If the core is enabled, the PoP confirms that the core has triggers enabled  420 , registered object triggers enabled  425 , and that the registered application is enabled  430 . If any of these cannot be confirmed, there is no routing to the PaaS  435 , and the PoP returns to its listening state  405 . If all of these are confirmed, the PoP routes the object-specific trigger logic through to the PaaS  440 . 
         [0033]      FIG. 5  shows the dispatcher service extension that works with the dispatcher service route of  FIG. 4  by adding logic steps to it. 
         [0034]    The dispatcher service extension begins by listening for a developer installation or update  505 . During an installation, the PoP confirms (1) that the object has a routing rule  510 , (2) that the rule is enabled  515 , (3) that the corresponding extension application is registered  520 , (4) and that the registered application is enabled  525 . If any of the first three cannot be confirmed, the PoP returns to its listening status  505 . If the registered application is not enabled, the PoP generates an error  530  before returning to listening  505 . 
         [0035]    If the PoP confirms all of these, it will then add and/or update the rules required by the developer&#39;s application to insure that it can access the PaaS resources via the PoP  535 . 
       Domain Meta Service 
       [0036]      FIG. 6  shows the domain meta service that determines which service or function the PoP should call. 
         [0037]    The domain meta service begins by listening for an installation or update  605 . After an installation or update is confirmed, the PoP determines if what is being requested in the installation is before data manipulation  610 . If it is, the PoP then decides in turn, if the request is an insert  615 , update,  620 , or delete  625 . If any of these are confirmed, the PoP processes the before-insert operations  630 , before-update operations  635 , or before-delete operation  640 . If the answer is no to all of them, the PoP domain meta service returns to its listening state  605 . 
         [0038]    If what is being requested is after data manipulation, the same confirmation as to insert, update, and delete occurs  645 ,  650 ,  655  with corresponding after-insert, after-update, and after-delete processing  660 ,  665 ,  670 . 
       Install Service 
       [0039]    The install service shown in  FIG. 7  describes the steps taken in order to install an application. The first step is listening for installation  705 . Following the installation initialization, the PoP confirms whether the application or update is already installing  710 . If it is, the PoP returns to its listening state  705 . If the application is not already installing, the PoP confirms if organizational defaults are initialized  715 . If they are not, the PoP enables the defaults and triggers  720 . The PoP then proceeds to register objects, routing rules, apps, and scripts  725 . 
         [0040]    After registration, the PoP confirms that there are registered objects  730 , apps  740 , rules  750 , and scripts  760 . If any of these are not present, the PoP installs them  735 ,  745 ,  755 ,  765 , and returns to its listening state  705 . 
         [0041]    The above described embodiments are merely illustrative of numerous and varied embodiments which may constitute applications of the principles of the invention.