Abstract: Jobs submitted to a primary location of a service within a period of time before and/or after a fail-over event are determined and are resubmitted to a secondary location of the service. For example, jobs that are submitted fifteen minutes before the fail-over event and jobs that are submitted to the primary network before the fail-over to the second location is completed are resubmitted at the secondary location. After the fail-over event occurs, the jobs are updated with the secondary network that is taking the place of the primary location of the service. A mapping of job input parameters (e.g. identifiers and/or secrets) from the primary location to the secondary location are used by the jobs when they are resubmitted to the secondary location. Each job determines what changes are to be made to the job request based on the job being resubmitted.

Abstract: A secondary location of a network acts as a recovery network for a primary location of the service. The secondary location is maintained in a warm state that is configured to replace the primary location in a case of a failover. During normal operation, the primary location actively services user load and performs backups that include full backups, incremental backups and transaction logs that are automatically replicated to the secondary location. Information is stored (e.g. time, retry count) that may be used to assist in determining when the backups are restored correctly at the secondary location. The backups are restored and the transaction logs are replayed at the secondary location to reflect changes (content and administrative) that are made to the primary location. After failover to the secondary location, the secondary location becomes the primary location and begins to actively service the user load.

Abstract: Jobs submitted to a primary location of a service within a period of time before and/or after a fail-over event are determined and are resubmitted to a secondary location of the service. For example, jobs that are submitted fifteen minutes before the fail-over event and jobs that are submitted to the primary network before the fail-over to the second location is completed are resubmitted at the secondary location. After the fail-over event occurs, the jobs are updated with the secondary network that is taking the place of the primary location of the service. A mapping of job input parameters (e.g. identifiers and/or secrets) from the primary location to the secondary location are used by the jobs when they are resubmitted to the secondary location. Each job determines what changes are to be made to the job request based on the job being resubmitted.

Abstract: A computing system receives a web services request to invoke a method of web Application Programming Interface (API). In response to receiving the web services request, the computing system invokes a method of a language-dependent API of a client component in a collaboration system. The client component communicates with a collaboration server component in the collaboration system using a proprietary communications protocol. The method of the language-dependent API is a method to obtain data from the collaboration server component. After invoking the method, the computing system sends a web services response whose contents depend on the data obtained from the collaboration server component.

Abstract: A computing system receives a web services request to invoke a method of web Application Programming Interface (API). In response to receiving the web services request, the computing system invokes a method of a language-dependent API of a client component in a collaboration system. The client component communicates with a collaboration server component in the collaboration system using a proprietary communications protocol. The method of the language-dependent API is a method to obtain data from the collaboration server component. After invoking the method, the computing system sends a web services response whose contents depend on the data obtained from the collaboration server component.

Abstract: A target holding device according to an embodiment of the invention includes a plurality of target plates, each target plate having a first surface and an opposing second surface, wherein the first surface has a plurality of holes. A shaft may be used to facilitate the alignment and joinder of the target plates such that the first surface of one target plate contacts a second surface of an adjacent target plate. The target holding device may optionally include end plates arranged to sandwich the target plates therebetween and/or separator plates alternately arranged with the target plates. The target holding device may be used to produce brachytherapy and/or radiography targets (e.g., seeds, wafers) in a reactor core such that the targets have relatively uniform activity.

Abstract: A method and system for building an elastic cloud web server farm. The method includes registering a web application on a serving cloud and copying the web application to a distributed store. A load of the web application is specified, and a plurality of nodes is added for the web application based on the load. A web server corresponding to a node of the plurality of nodes is then initialized. A web request is received from a user and a web server is selected from a list of available web servers to process the web request. The web request is further transmitted to the web server. A web response, based on the web request, is transmitted back to the user. The system includes a central registry, a distributed store, a process coordinator, one or more web servers, and a router.

Abstract: Jobs submitted to a primary location of a service within a period of time before and/or after a fail-over event are determined and are resubmitted to a secondary location of the service. For example, jobs that are submitted fifteen minutes before the fail-over event and jobs that are submitted to the primary network before the fail-over to the second location is completed are resubmitted at the secondary location. After the fail-over event occurs, the jobs are updated with the secondary network that is taking the place of the primary location of the service. A mapping of job input parameters (e.g. identifiers and/or secrets) from the primary location to the secondary location are used by the jobs when they are resubmitted to the secondary location. Each job determines what changes are to be made to the job request based on the job being resubmitted.

Abstract: A secondary location of a network acts as a recovery network for a primary location of the service. The secondary location is maintained in a warm state that is configured to replace the primary location in a case of a failover. During normal operation, the primary location actively services user load and performs backups that include full backups, incremental backups and transaction logs that are automatically replicated to the secondary location. Information is stored (e.g. time, retry count) that may be used to assist in determining when the backups are restored correctly at the secondary location. The backups are restored and the transaction logs are replayed at the secondary location to reflect changes (content and administrative) that are made to the primary location. After failover to the secondary location, the secondary location becomes the primary location and begins to actively service the user load.

Abstract: A secondary location is configured as a recovery service for a primary location of the service. The secondary location is maintained in a warm state that is configured to replace the primary location in a case of a failover. During normal operation, the secondary location is automatically updated to reflect a current state of the primary location that is actively servicing user load. Content changes to the primary location are automatically reflected to the secondary location. System changes applied to the primary location are automatically applied to the secondary location. For example, removing/adding machines, updating machine/role assignments, removing adding/database are automatically applied to the secondary location such that the secondary location substantially mirrors the primary location. After a failover to the secondary location, the secondary location becomes the primary location and begins to actively service the user load.

Abstract: Content that is stored at a secondary location for a service is crawled before it is placed in operation to assist in maintaining an up to date search index. The content that is crawled at the secondary location includes content that is obtained from the primary location of the service. When a crawler at the secondary location attempts to access content that is stored at the primary location, the crawler is directed to access the corresponding copy of the content that is stored at the secondary location instead of accessing the content at the primary location. The content may be crawled at the secondary location at different times, such as when the information is updated, according to a schedule, and the like.

Abstract: During an outage at a primary location for an online service that is temporary in duration (e.g. a “temporary outage”), requests are temporarily switched from the primary location to a secondary location for the online service. The temporary outage may be caused by many different reasons (e.g. power outage, planned maintenance, and the like). The secondary location may be configured as read only during the temporary outage such that users are still able to access their data during the temporary without causing changes to be made to the data. The requests to the primary location of the online service are automatically redirected to be handled by the secondary location. When the temporary outage ends, the requests are automatically switched back to the primary location.

Abstract: A history of locations of tenant data is maintained. The tenant data comprises data that is currently being used by the tenant and the corresponding backup data. When a tenant's data is changed from one location to another, a location and a time is stored within the history that may be accessed to determine a location of the tenant's data at a specified time. Different operations trigger a storing of a location/time within the history. Generally, an operation that changes a location of the tenant's data triggers the storing of the location within the history (e.g. upgrade of farm, move of tenant, adding a tenant, load balancing of the data, and the like). When tenant data is needed for an operation (e.g. restore), the history may be accessed to determine the location of the data.

Abstract: A computing system receives a web services request to invoke a method of web Application Programming Interface (API). In response to receiving the web services request, the computing system invokes a method of a language-dependent API of a client component in a collaboration system. The client component communicates with a collaboration server component in the collaboration system using a proprietary communications protocol. The method of the language-dependent API is a method to obtain data from the collaboration server component. After invoking the method, the computing system sends a web services response whose contents depend on the data obtained from the collaboration server component.

Abstract: A smart algorithm for processing transaction from a crawl queue. If the crawler has in memory a predetermined number of URLs for a given host, the crawler reads from the crawl queue URLs from other hosts. As a result the crawler processes multiple hosts concurrently, and thus, uses machine resources more effectively and efficiently to process the URLs. The smart algorithm can further consider other criteria in deciding which URLs to read from the queue. These criteria can include the response time for each repository (host) the crawler processes. Additionally, the crawler can allocate its resources according to content groups (e.g., two pools), one group for faster content delivery and the second group one for slower content delivery. Thus, crawler resources can be partitioned or divided across different pools depending on repository response time. Other criteria can be provided and considered as well.

Abstract: A target holding device according to an embodiment of the invention includes a plurality of target plates, each target plate having a first surface and an opposing second surface, wherein the first surface has a plurality of holes. A shaft may be used to facilitate the alignment and joinder of the target plates such that the first surface of one target plate contacts a second surface of an adjacent target plate. The target holding device may optionally include end plates arranged to sandwich the target plates therebetween and/or separator plates alternately arranged with the target plates. The target holding device may be used to produce brachytherapy and/or radiography targets (e.g., seeds, wafers) in a reactor core such that the targets have relatively uniform activity.

Abstract: Various techniques are disclosed for creating a snapshot of application data. A snapshot is taken by pausing parts of the application over time. Modifications are paused to a first part of data and the first part is copied into a snapshot. After the first part has finished copying, modifications are paused to remaining data, and the remaining data is copied. The application is unpaused. A snapshot can be taken by unpausing parts of the application over time. Modifications to data in an application are paused. A first part of data is copied, and after the first part has finished copying, modifications to the first part are unpaused. The final part of data is copied, and after the final part has finished copying, modifications to the final part are unpaused. Techniques for creating a snapshot of data residing in multiple locations are described.

Abstract: Feed Processing. An example method of processing a feed stored in a storage device includes receiving an input feed. Each record of the feed is associated with one or more unique identifiers. A first unique identifier for each record of the input feed is then generated. Each record of the input feed and each record of the feed is grouped as changed or not changed based on the first unique identifier for each record of the input feed and a first unique identifier for each record of the feed. A second unique identifier for each record of the input feed grouped as changed is also generated. Each record of the input feed grouped as changed and each record of the feed grouped as changed are then regrouped based on the second unique identifier for each record of the input feed and a second unique identifier for each record of the feed. Further, the feed is updated based on the regrouping, whereby a user accessing a record from the storage device obtains updated version of the record.

Abstract: This patent discloses a computing platform to process structured data. The computer platform may include a component layer having a workflow engine to execute a workflow definition. The workflow engine may receive feed data from a user system. The workflow engine may send a business logic application and feed data to a distributed computation environment to batch process the feed data through the business logic application as part of executing the workflow definition.