Patent Description:
Cloud storage provides an architecture for data storage that provides storage locations in logical pools, with the physical storage location often spanning multiple servers and/or multiple physical locations. Cloud storage includes public storage, private storage, and hybrid public/private storage options. Many cloud storage service providers allow users to control access to a portion of their cloud storage, such as through user credentials and user-configured permissions. <CIT> discloses systems and methods for providing template based output management. <CIT> discloses performing data storage operations with a cloud storage environment.

Specific embodiments are defined in the dependent claims. Examples of the disclosure provide a system and method for automatically generating an application using a template. Applications are generated automatically using templates and source data received within the developer environment, such as on the design surface. Control over the where application data is stored and how it may be accessed is provided to a designer, such that the designer may dictate where the application data will live, who may access the application data, and what type of access an application user may have to the stored data. Application data access represents runtime behavior of the application. The access, representing runtime behavior of the application to provide access to application data at the storage location, may be generated without having to write code. Because the application is generated automatically, including the data storage and access selected by the designer, they are likely to involve less error at generation and at runtime. In addition, because the application is generated automatically, including binding the stored data at the storage location to the application generated using the template, the application may also be optimized for runtime efficiency. Further, because the application is automatically generated, application behaviors such as application data storage and access may be generated with less intrinsic knowledge of the system, and of coding in general.

Aspects of the disclosure provide a developer environment that any user, regardless of development experience or lack thereof, may utilize to create applications. General workplace computing skills, similar to skills employed when using MICROSOFT OFFICE or similar programs, are translated into a development environment. Because the applications are generated automatically from templates and source data, they further increase efficiency of a developer or user in development of an application. In addition, the development environment is translated to a non-developer user in such a way as to provide application development for any user, increasing the speed of application development for the user.

For example, a template is received at a design surface, the template including a data schema. A set of data for the template is received, and the set of data is bound to the template based on the data schema. Based on the set of data, at least a portion of the set of data is identified for extraction. A location for the identified portion of the set of data is received and the identified portion is extracted and stored at the received location. The extracted data stored at the received location is bound to the template, such that access to the application generated from the template provides access to the extracted data at the storage location. Because the selected template, the source data, and the location are received via user interaction with a design surface, without having to write code, the developer environment provides increased user interface functionality, in addition to bringing developer capabilities to a non-developer for generating applications.

Referring to the figures, examples of the disclosure enable the creation of an application from a template. Generating an application using code generally requires a knowledge of programming, data capabilities and compatibilities, and so forth. Aspects of the disclosure provide for automatic generation of an application using a template, source data, and designer-selected data storage locations. Because the application is automatically generated from a template, there is reduced error rate at runtime of the application as there is less room for developer error because the code is auto-generated by the developer environment.

Aspects of the disclosure further enable increased user interaction performance and user efficiency via user interface interaction because user intent is inferred by the developer environment based on user interaction with visual elements of the design surface. This also contributes to reduced error rate in application development, which leads to reduced error rate at runtime as well.

Additionally, the examples described herein enable applications to be generated and/or modified in an efficient and effective manner with controlled data storage for increased performance. By generating and/or modifying an application as described in this disclosure, some examples reduce processing load and/or increase processing speed by strategically managing computational, processing, memory, and/or other resources. The effect of identifying and extracting portions of data from an automatically generated application for storage at one or more identified locations, and binding the extracted data at the identified locations to the generated application, improves performance of the application as well as the device hosting the application. Additionally, some examples may conserve memory, reduce network bandwidth usage, improve operating system resource allocation, and/or improve communication between computing devices by streamlining at least some operations, such as data storage and data access, by automating at least some operations.

Referring again to <FIG>, an exemplary block diagram illustrates a computing device for generating an application. In the example of <FIG>, the computing device <NUM> associated with a user <NUM> represents a system for application design. The computing device represents any device executing instructions (e.g., as application programs, operating system functionality, or both) to implement the operations and functionality as described herein. The computing device may include a mobile computing device or any other portable device. In some examples, the mobile computing device includes a mobile telephone, laptop, tablet, computing pad, netbook, gaming device, and/or portable media player. The computing device may also include less portable devices such as desktop personal computers, kiosks, tabletop devices, industrial control devices, wireless charging stations, and electric automobile charging stations. Additionally, the computing device may represent a group of processing units or other computing devices.

In some examples, the computing device has at least one processor <NUM>, a memory area <NUM>, and at least one user interface. The processor includes any quantity of processing units, and is programmed to execute computer-executable instructions for implementing aspects of the disclosure. The instructions may be performed by the processor or by multiple processors within the computing device, or performed by a processor external to the computing device. In some examples, the processor is programmed to execute instructions such as those illustrated in the figures (e.g., <FIG> and <FIG>).

In some examples, the processor represents an implementation of analog techniques to perform the operations described herein. For example, the operations may be performed by an analog computing device and/or a digital computing device.

The computing device further has one or more computer readable media such as the memory area. The memory area includes any quantity of media associated with or accessible by the computing device. The memory area may be internal to the computing device (as shown in <FIG>), external to the computing device (not shown), or both (not shown). In some examples, the memory area includes read-only memory and/or memory wired into an analog computing device.

The memory area stores, among other data, one or more applications. The applications, when executed by the processor, operate to perform functionality on the computing device. Exemplary applications include developer environment <NUM>, which may represent an application for designing other executable applications. The applications may communicate with counterpart applications or services such as web services accessible via a network (not shown). For example, the applications may represent downloaded client-side applications that correspond to server-side services executing in a cloud. In some examples, applications generated may be configured to communicate with data sources and other computing resources in a cloud during runtime, or may share and/or aggregate data between client-side services and cloud services. The memory area may store data sources <NUM>, which may represent data stored locally at memory area <NUM>, data access points stored locally at memory area <NUM> and associated with data stored remote from computing device <NUM>, or any combination of local and remote data.

The memory area further stores one or more computer-executable components. Exemplary components include a user interface component. The user interface component <NUM>, when executed by the processor <NUM> of computing device <NUM>, cause the processor <NUM> to perform operations, including to receive user selections during user interaction with developer environment <NUM>, for example.

In some examples, the user interface component includes a graphics card for displaying data to the user and receiving data from the user. The user interface component may also include computer-executable instructions (e.g., a driver) for operating the graphics card. Further, the user interface component may include a display (e.g., a touch screen display or natural user interface) and/or computer-executable instructions (e.g., a driver) for operating the display. The user interface component may also include one or more of the following to provide data to the user or receive data from the user: speakers, a sound card, a camera, a microphone, a vibration motor, one or more accelerometers, a BLUETOOTH brand communication module, global positioning system (GPS) hardware, and a photoreceptive light sensor. For example, the user may input commands or manipulate data by moving the computing device in a particular way. In another example, the user may input commands or manipulate data by providing a gesture detectable by the user interface component, such as a touch or tap of a touch screen display or natural user interface.

Developer environment <NUM> provides design tools and a design environment for application design and generation. In some examples, developer environment <NUM> includes design surface <NUM>, template library <NUM>, design logic <NUM>, and set of policies <NUM>. Design surface <NUM> may be an interactive canvas or interactive design surface of developer environment <NUM>. In some examples, design surface <NUM> is part of an interactive graphical user interface displayed on an interactive computing device. For example, design surface <NUM> may be an interactive surface communicatively coupled to a gesture detection mechanism, such as gesture detection component of a touchscreen, such that gestures detected are used to communicate interaction with the developer environment, or elements of the developer environment.

Template library <NUM> may include one or more application templates, which may be selected or used in application design. In some examples, template library <NUM> may have representations of application templates that may be selected from template database <NUM> and customized via user interaction with design surface <NUM>. In this example, template database <NUM> may be located at a location remote from computing device <NUM> and accessible by developer environment <NUM>, such as in a cloud storage location. In other examples, template database <NUM> may be located at memory area <NUM>. Template library <NUM> periodically synchronizes with template database <NUM> to receive updated metadata associated with templates from the template database.

Example templates may include application templates for, without limitation, asset management applications, catalog applications, contract applications, customer relationship management (CRM) applications, dashboard and report applications, events and calendars applications, timesheet applications, expense tracking and/or reporting applications, media applications, multi-media applications, personal management applications, travel applications, project management applications, and so on. In general, the example templates may be template categories, with a number of application templates for each category. In some examples, each category may have multiple layers of subcategories. As one example, template library <NUM> includes an asset management application template category, with application templates for site inspector applications, image-tagging applications, and other applications pertaining to asset management. The template library may provide another layer of templates under site inspector applications, providing various different site inspector application templates as well. In some examples, the different application templates may provide different visual layout options or different data exposure components. A template includes a document and a schema, the document providing the visual layout and components along with sample data populated according to the schema. When a template is selected, and source data is received, the source data is wired to the visual layout and components of the template according to the template schema.

Design logic <NUM> is a component of developer environment <NUM> that binds source data to a selected template, identifies data storage locations, extracts and stores application data based on user selections and/or a set of policies <NUM>, and rewires, or re-binds, extracted data to the application generated using the template. Design logic <NUM> identifies data storage locations <NUM> and provides the identified data storage locations as connections list <NUM>. Connections list <NUM> may be provided to design surface <NUM> for user interaction and selection of a designated data storage location for application data, or a portion of application data.

In one example, data storage locations <NUM> may be discovered by developer environment <NUM> based on user credentials associated with user <NUM>. For example, user <NUM> may log-in to developer environment <NUM> with user credentials associated with a user profile accessible by developer environment <NUM>. In this example, the user profile may store data storage locations and associated credentials that user <NUM> has previously used in interacting with developer environment <NUM>. In other examples, developer environment <NUM> may detect a data storage location associated with user <NUM> based on user credentials, and prompt user <NUM> to provide access to the detected data storage location via design surface <NUM>. In still other examples, developer environment <NUM> may be associated with an enterprise network, and one or more data storage locations corresponding to the enterprise network may be provided as some of the data storage locations available for selection in connections list <NUM>. In another example, data storage locations <NUM> may be provided to developer environment <NUM> by a discovery service. In yet another example, data storage locations <NUM> may be provided to developer environment <NUM> by user <NUM>, for example.

Design logic <NUM> identifies storage locations, identifies application data for extraction, and identifies storage locations for extracted data based in part on set of policies <NUM>. Set of policies <NUM> may include, without limitation, rules and parameters associated with a file size, a distribution list, historical data storage locations associated with a user, historical data storage locations associated with a type of data, historical data storage locations associated with a data policy, capacity of a data storage location, a type of data, permissions, data sensitivity, data restrictions, target storage access restrictions, how the application is using the data, a type of data being captured by the application, or any other suitable parameter.

In addition to set of policies <NUM>, design logic <NUM> may identify data for extraction and storage based on policies attached to the data, such as enterprise data for example. In some examples, where policies attached to the source data are identified, design logic <NUM> may enforce the attached policies over a user selection. In the example of enterprise data, a data storage location may be based on the enterprise data policy, or a distribution (e.g. who the application is shared with) of the generated application may be limited based on enterprise data associated with the application for example.

As another example, design logic <NUM> may use set of policies <NUM> to determine that an application generated from a selected template is used to update records corresponding to inventory. Because the inventory records are dynamic, design logic <NUM> may determine that the inventory data is to be stored at a shared location, such as a cloud storage location. Design logic <NUM> may identify static application data, such as inventory categories for example, and determine that the static data is to be stored locally with the template, such that the static data is stored locally at the generated application.

<FIG> is an exemplary block diagram illustrating a developer environment for generating an application. Developer environment <NUM> is an illustrative example of one implementation of developer environment <NUM> in <FIG>. Developer environment <NUM> includes design surface <NUM> and design logic <NUM>.

Design surface <NUM> may be an interactive canvas for receiving templates, source data, and interactions with the templates and source data, which are used by design logic <NUM> to automatically generate an application. For example, design surface <NUM> may be a portion of developer environment <NUM> that is displayed via a user interface and is configured to receive user interaction. Design surface <NUM> may include design tools <NUM>, which may be application resources of developer environment <NUM>. For example, design tools <NUM> may include template library <NUM> of <FIG>.

Design logic <NUM> may include a number of algorithms, rules, and parameters for automatically generating an application using a template and source data, identifying portions of the source data for extraction and storage at identified storage locations and binding the extracted data at the identified storage locations to the generated application, such that access to the application provides access to the stored data regardless of the location of the stored data. For example, design logic <NUM> may include, without limitation, data storage location mechanism <NUM>, data extraction mechanism <NUM>, data binding mechanism <NUM>, data policy mechanism <NUM>, and set of policies <NUM>.

In an exemplary operation, design surface <NUM> may receive a template selection, as illustrated by template <NUM>. Template <NUM> may be an application template having document <NUM> and schema <NUM>. Document <NUM> includes visual components and visual layout for the application generated using template <NUM>, as well as sample data applied to the template using schema <NUM>. The sample data mapped based on schema <NUM> provides a visual representation of how source data may be applied to the visual layout and visual components of template <NUM>, for application design. As one illustrative example, document <NUM> may provide a table and the sample data may be mapped to the table based on schema <NUM>. In this example, the sample data may be formatted as spreadsheet data, with the spreadsheet data mapped to the table in the template based on schema <NUM> As another example, document <NUM> may provide a set of pages or set of screens of an application, and schema <NUM> may map sample data of images, with an individual sample image for an individual screen.

Design surface <NUM> also receives source data <NUM>. Source data <NUM> is provided by a user, in some examples by opening a file or dragging a file onto design surface <NUM>. Source data <NUM> may include one or more different source files, in these examples. For example, source data <NUM> may include one or more of user data, remote data, shared data, enterprise data, public data, dynamic data, local data, or any other accessible data.

The data extraction mechanism <NUM> identifies data types for source data <NUM>, including local data <NUM>, dynamic data <NUM>, and remote data <NUM>. Local data <NUM> is static data, which is maintained locally at the generated application. Dynamic data <NUM> is data that may have local origination but may change at runtime of the application. Dynamic data may be identified based on rules associated with the schema <NUM>, such as data that is mapped to a read/write component of document <NUM> for example. Remote data is data that is already stored in a cloud storage location. Examples of remote data may include enterprise data or public data.

Data storage location mechanism <NUM> identifies data storage locations, such as data storage locations <NUM> in <FIG>, and provides the identified locations as connections list <NUM> to design surface <NUM>. Connections list <NUM> may be an interactive list of available storage locations. User selection of a storage location from connections list <NUM> triggers data extraction mechanism <NUM> to analyze source data <NUM> and identify at least a portion of source data <NUM> for extraction to send to the selected storage location. Data storage location mechanism may also use any of set of policies <NUM>, telemetry data <NUM> and user profile <NUM> to determine the available storage locations, provide the connections list, and infer a default storage location to provide as a suggested location at the connections list.

Telemetry data <NUM> may include machine learning information derived from analysis of a distributed developer environment and previous applications generated using templates. For example, telemetry data <NUM> may include information on where data gets stored, what types of data get stored at what types of locations, what types of data get extracted, and so no. User profile <NUM> may include historical information corresponding to user interaction with developer environment <NUM>, as well as other user information, such as user credentials <NUM>. Historical information may include who a user has shared previously generated applications with, where a user has previously selected to store data or a portion of data, and other historical application design and development information associated with the user. In some examples, the user intent may be determined in part based on past user interactions with the developer environment or past user selections corresponding to the selected template, the received data, or both. The user intent may be inferred by data on past user selections or interactions via data collected through application analytics in association with the user profile. In other examples, the user intent may be determined based on telemetry, a data storage location match for the type of data received, the available data storage locations, and/or the other parameters, selections, and data used in the current application design.

Data extraction mechanism <NUM> uses set of policies <NUM> and identified storage location <NUM> to determine which portion of source data <NUM> to extract and where to store the extracted portion. In some examples, identified storage location <NUM> is a default storage location identified by data storage location mechanism <NUM> and provided as a suggested storage location at connections list <NUM>. Absent selection of a different storage location, the suggested storage location may become the identified storage location for storage of extracted application data. In other examples, identified storage location <NUM> may be a user selected storage location from a list of locations provided in connections list <NUM>. Data extraction mechanism <NUM> may also access a service, such as a back-end service of a data storage location, and optionally provide credentials to the service in order to access and store the extracted data. In some examples, user credentials may be stored in a user profile or otherwise identified based on other user credentials identified by developer environment <NUM>.

In an illustrative example, data extraction mechanism identifies local data <NUM> and dynamic data <NUM> of source data <NUM>, and using set of policies <NUM> maintains local data <NUM> at document <NUM> while extracting dynamic data <NUM>, sending the extracted dynamic data to the identified storage location <NUM>. Data binding mechanism <NUM> rewires, or re-binds, dynamic data <NUM> located at identified storage location <NUM> to document <NUM>. Application generation transforms document <NUM> into a published application and binds the source data to the application regardless of the storage location of the source data, or the storage location of portions of the source data. For example, if document <NUM> is shared as a published application with another user, that other user will have access to the storage location(s) where dynamic data and/or remote data is stored, via the application.

Data policy mechanism <NUM> enforces policies attached to source data <NUM>, as well as set of policies <NUM>. As an example, remote data <NUM> may include enterprise data, with associated enterprise policies. Distribution list <NUM> may be an interactive portion of design surface <NUM> that provides for selection of one or more recipients of the published application. Distribution list <NUM> may include recipients such as set of users <NUM>, user-A <NUM> and user-B <NUM>. In this example, set of users <NUM> may be a group of recipients with an enterprise network, while user-A <NUM> and user-B <NUM> are recipients outside the enterprise network. Data policy mechanism <NUM> may identify enterprise data policies associated with remote data <NUM>, such as policies limiting access of enterprise data to in-network users for example. Data policy mechanism <NUM> may generate data access expressions for generated application <NUM>, providing access of remote data <NUM> via generated application <NUM> to set of users <NUM> while restricting access to user-A <NUM> and user-B <NUM>. In this same example, user-A <NUM> and user-B <NUM> may have access to dynamic data <NUM> and local data <NUM> of generated application <NUM>, without having access to remote data <NUM>.

<FIG> is an exemplary diagram illustrating data storage for an application. Developer environment <NUM> may be an illustrative example of one implementation of developer environment <NUM> in <FIG> and/or developer environment <NUM> in <FIG>.

Developer environment <NUM> includes developer environment network <NUM>, data storage location <NUM> and data storage location <NUM>. Developer environment network <NUM> may include cloud storage and one or more network devices for implementing components of the developer environment, for example. In this example, template database <NUM> is maintained at developer environment network <NUM>, and is accessible to instances of the developer environment. For example, template library <NUM> in <FIG> may be populated from template database <NUM>. Upon publication via user selection to create an application from a selected template and source data, an application is automatically generated and stored in developer environment network <NUM>, represented by generated application <NUM>. Generated application <NUM> may be accessible to any user the application is shared with, such as users selected from the distribution list <NUM> in <FIG>, or may be published for public access in some examples.

Connection service <NUM> provides for communication between developer environment network <NUM> and data storage locations <NUM> and <NUM>, having knowledge of protocols and other information needed to communicate with the back-end services associated with data storage locations.

As illustrated in <FIG>, portions of source data <NUM> in <FIG> are stored in one or more locations as determined by design logic <NUM>. In this example, generated application <NUM> is depicted with local data <NUM> stored at the generated application, dynamic data <NUM> stored at data storage location <NUM>, and remote data <NUM> stored at data storage location <NUM>.

<FIG> is an exemplary flow chart illustrating operation of the computing device to generate an application. The exemplary operations presented in <FIG> may be performed by one or more components described in <FIG> or <FIG>, for example.

The process begins by receiving a template at a design surface at operation <NUM>. The template is received by user selection from a template library, for example. The template may represent an application template for a type or category of application being designed.

The process receives a selection of data from a data source at operation <NUM>. The selection of the data may be received from a user opening a file, or dragging a file onto the design surface, in some examples. The data may also be received from more than one data source, in some examples.

The process binds the data from the data source to the template using a schema of the template at operation <NUM>. The schema is a data schema that maps the received data to components of the selected template, for example. The process determines a location where the data is to be stored at operation <NUM>. The location may be one or more data storage locations, determined based at least in part on a set of policies.

The process extracts at least a portion of the data from the template at operation <NUM>. The portion may be the entire selection of data from the data source, or less than the entire selection of data from the data source. The process stores the extracted data at the determined location at operation <NUM>. Additionally, more than one portion of the selected data may be extracted for storage at different locations, in some examples. The process re-binds the stored data to the template to generate a distributed application at operation <NUM>, with the process terminating thereafter.

<FIG> is an exemplary flow chart illustrating operation of the computing device to identify storage locations for application data. The exemplary operations presented in <FIG> may be performed by one or more components described in <FIG> or <FIG>, for example.

The process begins generating an application using a selected template and selected data at operation <NUM>. The template and data may be received by a user selecting the template at a design canvas of the design surface, and selecting data from a data source, for example, through a gesture such as a tap to select the template from a template list displayed on the canvas for inclusion into the application design.

The process identifies data types for the application data of the generated application at operation <NUM>. The data types include, without limitation, local data, dynamic data, and remote data.

The process determines whether a portion of the application data is local data at operation <NUM>. If the process determines that a portion of the application data is local data, the process maintains the local data with the application at operation <NUM>. Maintaining local data with the application may refer to binding the data location of the local data to the application, for example. The process may then proceed to operation <NUM>.

If the process determines that a portion of the application data is not local data at operation <NUM>, the process may proceed to operation <NUM>. The process determines whether a portion of the application data is dynamic data at operation <NUM>. If the process determines that a portion of the application data is dynamic data, the process extracts and stores the dynamic data at a selected storage location at operation <NUM>. The selected storage location is an identified storage location received from a user selection, or a default storage location suggested by the developer environment, in some examples.

If the process determines that there is no dynamic data as part of the application data, the process determines whether a portion of the application data is remote data at operation <NUM>. If a determination is made that a portion of the application data is remote data, the process maintains the remote data at a current storage location at operation <NUM>. The process then rewires the application data at the one or more storage locations to the application at operation <NUM>, and distributes the application at operation <NUM>, with the process terminating thereafter.

<FIG> is an exemplary diagram illustrating an interactive design surface, such as design surface <NUM> in <FIG>. Design surface <NUM> may be an illustrative example of a graphical user interface displaying a developer environment, for example.

Design surface <NUM> may include a template component <NUM>, which may be a selectable component to enter a template mode of an application designer. Template component <NUM> may be one example of a design tool, such as design tools <NUM> in <FIG>. Selection of template component <NUM> may provide an interactive list of templates from template library <NUM>, for example.

<FIG> depict an exemplary diagram illustrating user selection of data storage locations for an application. Design surface <NUM> illustrates a design surface displaying a default data storage location for application data. Designer intent or user intent is factored into the storage location mechanism to achieve a suggested storage location in this illustrative example. User selection <NUM> may be a user selection to change a data storage location from a default location, or assign a new data storage location.

Design surface <NUM> illustrates a design surface displaying a connection list, such as connections list <NUM> in <FIG>. A current storage provider, or a default or suggested storage provider may be indicated, as well as recent connections (e.g. based on past user interactions or user credentials) and new connections (e.g. based on discovery of other available data storage locations). User selection <NUM> may be a user selection to control the storage of application data to a selected location.

In some examples, based on login credentials of a user, the design logic may know or may infer possible data locations for storage of application data. For example, based on login credentials associated with a shared storage location in the cloud, design logic may infer the shared storage location as a default storage location for dynamic data identified in the application data.

In other examples, an application template may include individual logic for applying data to the template schema, as well as policies for the template that may be enforced by the data policy mechanism. These template policies and/or logic may also be used by the data extraction mechanism to determine what portion of the application data to extract, and where extracted portions of data are to be stored. For example, the data extraction mechanism may infer that a table having associated rules for updating, augmenting, or otherwise manipulating data is to be extracted and pushed to a shared location when the application is published, such that users of the application have access to the dynamic data of the table at the shared location.

User intent for data storage may also be inferred based on telemetry or machine learning. In an example scenario, a default storage location for a user may be based upon machine learning from past user behavior, or based on telemetry for a new user. Additionally, repeated gestures of a same type, such as repeated taps on an interactive connections list, may be interpreted as an indication that user intent is for a different selection, such as to rotate through location options, for example.

In addition, extracted data does not have to be stored at the same location, subsets of extracted data may be stored at different locations. A user may select to store some data in one location and other data at another location, for example. In some examples, the data extraction mechanism may determine to store data at multiple locations based on the set of policies, such as due to storage capacity or data types, for example. In still other examples, the data extraction mechanism may decide not to extract data or portions of data based on the set of policies, but rather to keep certain portions of data local, such as due to bandwidth restrictions for example.

Alternatively or in addition to the other examples described herein, examples include any combination of the following:.

In some examples, the operations illustrated in <FIG> and <FIG> may be implemented as software instructions encoded on a computer readable medium, in hardware programmed or designed to perform the operations, or both. For example, aspects of the disclosure may be implemented as a system on a chip or other circuitry including a plurality of interconnected, electrically conductive elements.

While no personally identifiable information is tracked by aspects of the disclosure, examples have been described with reference to data monitored and/or collected from the users. In some examples, notice may be provided to the users of the collection of the data (e.g., via a dialog box or preference setting) and users are given the opportunity to give or deny consent for the monitoring and/or collection. The consent may take the form of opt-in consent or opt-out consent.

<FIG> illustrates an example of a suitable computing and networking environment <NUM> on which the examples of <FIG> may be implemented. The computing system environment <NUM> is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the disclosure. Neither should the computing environment <NUM> be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment <NUM>.

The disclosure is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with the disclosure include, but are not limited to: personal computers, server computers, handheld or laptop devices, tablet devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.

The disclosure may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and so forth, which perform particular tasks or implement particular abstract data types. The disclosure may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in local and/or remote computer storage media including memory storage devices and/or computer storage devices. As used herein, computer storage devices refer to hardware devices.

With reference to <FIG>, an exemplary system for implementing various aspects of the disclosure may include a general purpose computing device in the form of a computer <NUM>. Components of the computer <NUM> may include, but are not limited to, a processing unit <NUM>, a system memory <NUM>, and a system bus <NUM> that couples various system components including the system memory to the processing unit <NUM>. The system bus <NUM> may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus.

The computer <NUM> typically includes a variety of computer-readable media. Computer-readable media may be any available media that may be accessed by the computer <NUM> and includes both volatile and nonvolatile media, and removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Memory <NUM> and <NUM> are examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which may be used to store the desired information and which may accessed by the computer <NUM>. Computer storage media does not, however, include propagated signals. Rather, computer storage media excludes propagated signals. Any such computer storage media may be part of computer <NUM>.

Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.

By way of example, and not limitation, <FIG> illustrates operating system <NUM>, application programs, such as developer environment <NUM>, other program modules <NUM> and program data <NUM>.

The computer <NUM> may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only, <FIG> illustrates a hard disk drive <NUM> that reads from or writes to non-removable, nonvolatile magnetic media, a universal serial bus (USB) port <NUM> that provides for reads from or writes to a removable, nonvolatile memory <NUM>, and an optical disk drive <NUM> that reads from or writes to a removable, nonvolatile optical disk <NUM> such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that may be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive <NUM> is typically connected to the system bus <NUM> through a non-removable memory interface such as interface <NUM>, and USB port <NUM> and optical disk drive <NUM> are typically connected to the system bus <NUM> by a removable memory interface, such as interface <NUM>.

The drives and their associated computer storage media, described above and illustrated in <FIG>, provide storage of computer-readable instructions, data structures, program modules and other data for the computer <NUM>. In <FIG>, for example, hard disk drive <NUM> is illustrated as storing operating system <NUM>, developer environment <NUM>, other program modules <NUM> and program data <NUM>. Note that these components may either be the same as or different from operating system <NUM>, developer environment <NUM>, other program modules <NUM>, and program data <NUM>. Operating system <NUM>, developer environment <NUM>, other program modules <NUM>, and program data <NUM> are given different numbers herein to illustrate that, at a minimum, they are different copies. A user may enter commands and information into the computer <NUM> through input devices such as a tablet, or electronic digitizer, <NUM>, a microphone <NUM>, a keyboard <NUM> and pointing device <NUM>, commonly referred to as mouse, trackball or touch pad. Other input devices not shown in <FIG> may include a joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit <NUM> through a user input interface <NUM> that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A monitor <NUM> or other type of display device is also connected to the system bus <NUM> via an interface, such as a video interface <NUM>. The monitor <NUM> may also be integrated with a touch-screen panel or the like. Note that the monitor and/or touch screen panel may be physically coupled to a housing in which the computing device <NUM> is incorporated, such as in a tablet-type personal computer. In addition, computers such as the computing device <NUM> may also include other peripheral output devices such as speakers <NUM> and printer <NUM>, which may be connected through an output peripheral interface <NUM> or the like.

The computer <NUM> may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer <NUM>. The remote computer <NUM> may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer <NUM>, although only a memory storage device <NUM> has been illustrated in <FIG>. The logical connections depicted in <FIG> include one or more local area networks (LAN) <NUM> and one or more wide area networks (WAN) <NUM>, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

The modem <NUM>, which may be internal or external, may be connected to the system bus <NUM> via the user input interface <NUM> or other appropriate mechanism. A wireless networking component such as comprising an interface and antenna may be coupled through a suitable device such as an access point or peer computer to a WAN or LAN. In a networked environment, program modules depicted relative to the computer <NUM>, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, <FIG> illustrates remote application programs <NUM> as residing on memory device <NUM>. It may be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

With regard to <FIG>, an exemplary block diagram illustrates a cloud-computing environment for application development. Architecture <NUM> illustrates an exemplary cloud-computing infrastructure, suitable for use in implementing aspects of the disclosure. Architecture <NUM> should not be interpreted as having any dependency or requirement related to any single component or combination of components illustrated therein. In addition, any number of nodes, virtual machines, data centers, role instances, or combinations thereof may be employed to achieve the desired functionality within the scope of examples of the present disclosure.

The distributed computing environment of <FIG> includes a public network <NUM>, a private network <NUM>, and a dedicated network <NUM>. Public network <NUM> may be a public cloud, for example. Private network <NUM> may be a private enterprise network or private cloud, while dedicated network <NUM> may be a third party network or dedicated cloud. In this example, private network <NUM> may host a customer data center <NUM>, and dedicated network <NUM> may host an internet service provider <NUM>. Hybrid cloud <NUM> may include any combination of public network <NUM>, private network <NUM>, and dedicated network <NUM>. For example, dedicated network <NUM> may be optional, with hybrid cloud <NUM> comprised of public network <NUM> and private network <NUM>.

Public network <NUM> may include data centers configured to host and support operations, including tasks of a distributed application, according to the fabric controller <NUM>. It will be understood and appreciated that data center <NUM> and data center <NUM> shown in <FIG> is merely an example of one suitable implementation for accommodating one or more distributed applications and is not intended to suggest any limitation as to the scope of use or functionality of examples of the present disclosure. Neither should data center <NUM> and data center <NUM> be interpreted as having any dependency or requirement related to any single resource, combination of resources, combination of servers (e.g. server <NUM>, server <NUM>, and server <NUM>) combination of nodes (e.g., nodes <NUM> and <NUM>), or set of APIs to access the resources, servers, and/or nodes.

Data center <NUM> illustrates a data center comprising a plurality of servers, such as server <NUM>, server <NUM>, and server <NUM>. A fabric controller <NUM> is responsible for automatically managing the servers and distributing tasks and other resources within the data center <NUM>. By way of example, the fabric controller <NUM> may rely on a service model (e.g., designed by a customer that owns the distributed application) to provide guidance on how, where, and when to configure server <NUM> and how, where, and when to place application <NUM> and application <NUM> thereon. In one example, one or more role instances of a distributed application may be placed on one or more of the servers of data center <NUM>, where the one or more role instances may represent the portions of software, component programs, or instances of roles that participate in the distributed application. In another example, one or more of the role instances may represent stored data that is accessible to the distributed application.

Data center <NUM> illustrates a data center comprising a plurality of nodes, such as node <NUM> and node <NUM>. One or more virtual machines may run on nodes of data center <NUM>, such as virtual machine <NUM> of node <NUM> for example. Although <FIG> depicts a single virtual node on a single node of data center <NUM>, any number of virtual nodes may be implemented on any number of nodes of the data center in accordance with illustrative examples of the disclosure. Generally, virtual machine <NUM> is allocated to role instances of a distributed application, or service application, based on demands (e.g., amount of processing load) placed on the distributed application. As used herein, the phrase "virtual machine" is not meant to be limiting, and may refer to any software, application, operating system, or program that is executed by a processing unit to underlie the functionality of the role instances allocated thereto. Further, the virtual machine <NUM> may include processing capacity, storage locations, and other assets within the data center <NUM> to properly support the allocated role instances.

In operation, the virtual machines are dynamically assigned resources on a first node and second node of the data center, and endpoints (e.g., the role instances) are dynamically placed on the virtual machines to satisfy the current processing load. In one instance, a fabric controller <NUM> is responsible for automatically managing the virtual machines running on the nodes of data center <NUM> and for placing the role instances and other resources (e.g., software components) within the data center <NUM>. By way of example, the fabric controller <NUM> may rely on a service model (e.g., designed by a customer that owns the service application) to provide guidance on how, where, and when to configure the virtual machines, such as virtual machine <NUM>, and how, where, and when to place the role instances thereon.

As discussed above, the virtual machines may be dynamically established and configured within one or more nodes of a data center. As illustrated herein, node <NUM> and node <NUM> may be any form of computing devices, such as, for example, a personal computer, a desktop computer, a laptop computer, a mobile device, a consumer electronic device, server(s), the computing device <NUM> of <FIG>, and the like. In one instance, the nodes host and support the operations of the virtual machines, while simultaneously hosting other virtual machines carved out for supporting other tenants of the data center <NUM>, such as internal services <NUM> and hosted services <NUM>. Often, the role instances may include endpoints of distinct service applications owned by different customers.

Typically, each of the nodes include, or is linked to, some form of a computing unit (e.g., central processing unit, microprocessor, etc.) to support operations of the component(s) running thereon. As utilized herein, the phrase "computing unit" generally refers to a dedicated computing device with processing power and storage memory, which supports operating software that underlies the execution of software, applications, and computer programs thereon. In one instance, the computing unit is configured with tangible hardware elements, or machines, that are integral, or operably coupled, to the nodes to enable each device to perform a variety of processes and operations. In another instance, the computing unit may encompass a processor (not shown) coupled to the computer-readable medium (e.g., computer storage media and communication media) accommodated by each of the nodes.

The role instances that reside on the nodes support operation of service applications, and may be interconnected via application programming interfaces (APIs). In one instance, one or more of these interconnections may be established via a network cloud, such as public network <NUM>. The network cloud serves to interconnect resources, such as the role instances, which may be distributably placed across various physical hosts, such as nodes <NUM> and <NUM>. In addition, the network cloud facilitates communication over channels connecting the role instances of the service applications running in the data center <NUM>. By way of example, the network cloud may include, without limitation, one or more local area networks (LANs) and/or wide area networks (WANs). Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. Accordingly, the network is not further described herein.

The examples illustrated and described herein as well as examples not specifically described herein but within the scope of aspects of the disclosure constitute exemplary means for automatically generating an application from a template. For example, the elements illustrated in <FIG> and <FIG>, such as when encoded to perform the operations illustrated in <FIG> and <FIG>, constitute exemplary means for receiving a selection of a template, exemplary means for receiving source data, and exemplary means for determining a portion of the source data to extract and store at an identified location when automatically generating an application from the template.

Claim 1:
A method for generating a distributed application in a developer environment, the method comprising:
receiving a selection (<NUM>) of a template at a design surface implemented on a user interface the template including a data schema;
receiving a set of data for the template;
binding (<NUM>) the set of data to the template based on the data schema;
identifying a least a portion of the set of data for extraction;
determining (<NUM>) a location where to store the extracted portion of data, wherein a data storage location mechanism identifies a default storage location;
extracting (<NUM>) the identified portion of the set of data;
storing (<NUM>) the extracted data at the determined location;
re-binding (<NUM>) the extracted data at the determined location to the template, such that access to the template provides access to the extracted data at the determined location;
wherein identifying the portion of the set of data for extraction further comprises:
identifying one or more data types of the set of data, the one or more data types including at least one of local data, dynamic data, or remote data, and
wherein determining a location (<NUM>) where to store the extracted portion of data comprises:
maintaining local data, which are static data, at the application by binding the data location to the application,
storing (<NUM>) dynamic data, which have local origination but may change at runtime of the application, at the default storage location as suggested by the developer environment, wherein the default storage location is a shared storage location, wherein dynamic data are accessible by different users, and
maintaining remote data at the current storage location.