Patent Application
20150180729
Software as a service (SaaS), also referred to as “on-demand software” is a software delivery model, in which software and associated data are centrally hosted on the cloud. SaaS is typically accessed by customers using a thin client via a web browser. SaaS has become a common delivery model for many enterprise applications and has been incorporated into the strategy of all leading enterprise software companies.
Globally acting SaaS providers run different data centers spread over several geographic locations. Data centers are usually product or enterprise application oriented and not customer location oriented. This means the same customer can be served by different data centers in case the customer is subscribed to different on-demand enterprise applications or even in case the customer is subscribed to an on-demand solution composed of different on-demand applications that run in different data centers.
An on-demand enterprise solution composed of different on-demand enterprise applications that are running in different data centers may have integration challenges related to the virtual geographic distance between the different data centers and the associated data latency. It would be advantageous to optimize integration between the involved on-demand applications, it would be advantageous to lower the total cost of development by enabling developers to deploy an application without having to be concerned about the physical location of the on-demand components of the application.
The claims set forth the embodiments with particularity. The embodiments are illustrated by way of examples and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. The embodiments, together with its advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings.
Embodiments of techniques for distributed application adaptation auto-adjustment are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of the embodiments. One skilled in the relevant art will recognize, however, that the embodiments can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail.
Reference throughout this specification to “one embodiment”, “this embodiment” and similar phrases, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one of the one of more embodiments. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
In the cloud, the software applications are rarely stand-alone applications. In fact, typically there are several applications within an on-demand software product including, for example, Application 115 and Application 120 within Data Center 110 in
Sometimes the physical distance between data centers, hosting applications part of a software product, may be extremely large. This is, for example, the distance between Data Center 110 and Data Center 140 in
A calculation about the location (within which data center) an application is going to be deployed may not be pre-calculated, because of the huge number of applications and also several options for the deployment, concerning the relevant data centers.
The data center map 215 contains information about the locality of data centers and their distances to each other. The distances between data centers may be measured in logical units, which correlate to different categories of data latency. For example a logical unit may correspond to certain time delay when data is transferred between two locations.
In one embodiment, when the distance or logical unit between two data centers is zero, the logical unit indicates that it takes less than 100 milliseconds to transfer 100 kilobytes of data. In one embodiment, when the distance or logical unit between two data centers is one, the logical unit indicates that it takes between 100 and 200 milliseconds to transfer 100 kilobytes. When the distance or logical unit between two data centers is two, the logical unit indicates it takes between 200 and 400 milliseconds to transfer 100 kilobytes. When the distance or logical unit between two data centers is three, the logical unit indicates it takes more than 400 milliseconds to transfer 100 kilobytes.
The logical units provide flexibility in the calculation of the data center map. The calculated result is impacted by latency and throughput. In the above example, the data center map uses measure packets based on 100 kilobytes since this is a typical packet size, however other sizes may be used depending on the implementation.
Based on the data center map and deployed applications or components, a predefined integration between the applications may be automatically adjusted to provide best end user experience. The automatic adjustment ensures that the composed software solution behaves as a single product with no interruption or long response time during end user interaction even if the applications are deployed in different data centers.
The auto adjustment may take place, for example, in the following three domains: backend services, user interface, and data caching.
Backend services: service based integration 220 can be implemented via synchronous and/or asynchronous services. Asynchronous services take place outside real time, while synchronous services are real time services, in case of application integration across data centers with long virtual geo-distance, integration via synchronous services may result in long latencies. Fine granular service calls may be avoided and replaced via coarse granular services. Both approaches reduce the number of necessary service calls needed to invoke services located in data center with long virtual geo-distance during an end user session. For each synchronous service that is part of a predefined application integration scenario, an asynchronous variant may be available. Also, for each predefined choreography and set of fine granular services, an alternative coarse granular service may be provided. Depending on data center map 215, optimized application integration may be automatically set up to provide best achievable system behavior from the end user's perspective. Service discovery may also be optimized by ranking the service depending on virtual geo-distance provided in the data center map 215.
User interface integration 225: user interface (UI) elements and UI behavior may be automatically adjusted to the deployment situation and data center map 215 in order to ensure the best user experience. UI features like backend-based auto-completion or auto-validation may be automatically deactivated in order to avoid blocking user entry due to service call latency. Instead, UI elements for explicit validation triggering may be automatically offered, such as push button and menu entry. UI tiles or widgets used in a mash up UI and bound to services provided by a data center with very long virtual geo-distance may also be considered as sources of optimization in case they contain no better than related information to the main data and main context. Such UI tiles/widgets may be removed and replaced by navigation links, so that the end user may get the information on an explicit request if the user is interested in. Also, session behavior may be accurately adapted such as setting generically the best-fit save mode for a UI. In case of long virtual geo-distance, a save and exit UI mode may be more adequate than save and continue mode.
Data caching 230: static data retrieved during service calls may be cached in the target system to avoid data latency and associated long response time. Code lists (e.g. region, currency code) may be good candidates as they are static and not session dependent. In case of application integration across data centers with long virtual geo-distance, code lists may be retrieved once and cached on the target system. In this case, code list services will not be invoked each time when the end user pushes a drop down list box but only once in the session. Also, a pre-retrieval of the code lists can be done during session initialization so that code lists or relevant static data may be made available in the target data center in advance. However, extensive caching may influence system resources negatively. Therefore, a dynamic data caching decision may offer the best ratio between response time optimization and resource consumption.
In one embodiment, the data center map 215 is a collection of tables containing information about the virtual geo-distance between applications needed to be integrated with each other in order to build a holistic software solution. The information in Table 1 may be partially maintained as master data and may be partially derived. Table 1 below contains master data about existing data centers and anti the virtual geo-distance between them.
Table 2 below contains deployment related information. This information is about applications deployed per customer and per data center.
Table 3 may be derived via data center map calculator. The calculator may be triggered automatically in an after deployment phase. Based on the data maintained in Table 1 and Table 2, the map calculator derives the virtual geo-distance between the deployed applications as shown in Table 3.
The data center map may be defined and derived once in a designated system in the system landscape. The designated system maybe a cloud landscape directory 210 or another system having this role. The data center map may be then replicated in a push approach to other related systems A 240, B 250, C 260 in the different data centers or exposed as a service that can be invoked from other systems in the same or in different data centers.
In one embodiment, the service integration auto adjustment component 220 is responsible for guiding and executing the best integration approach based on the data retrieved in the data center map 215. In order to achieve this, a new metadata model for application integration may be introduced. The metadata model references the relevant services and their different variants that may be used in a pre-defined application integration scenario. Services variations may depend on communication method such as synchronous or asynchronous services or depending on service granularity such as CRUD (Create, Read, Update, Delete) or compound services.
The metadata model may enable the defining of different application integration variants by defining corresponding associations between service variants. The associations may link CRUD services to their compound services and synchronous services with their asynchronous variants.
For application integration over long virtual geo-distance, coarse granular as well as asynchronous services may be favored. For integration within same data center or over small virtual geo-distance, synchronous as well as fine-granular services may be favored, because they enable the system to provide a better user experience.
In case of out of the box integration deployment, the auto-adjust component may read the data center map 215 and may run appropriate application integration variants for integration application scenarios. Also, in case manual integration configuration is needed, the auto adjustment component may facilitate the configuration by guiding the system administrator to use the right service variants. Based on the data center map, the auto adjustment component may influence the discovery and expositions of services. Synchronous services may be kept hidden and only their associated asynchronous variants may be made visible for the administrator in case the integration goes over long virtual geo-distance.
Composed User Interface for distributed applications may use service-based communication to communicate with different backend systems in order to retrieve or modify data. A composition UI metadata model may be enhanced to reference the application integration metadata model. Based on the available data center map and the referenced application integration model, the UI model may be automatically adapted to offer the best user experience.
The appropriate service variants may be bound to the UI elements at deployment time. UI elements may also be switched on or off in accordance with bounded service variants and in accordance with the derived user interface behavior that fits best to the data center map. A generic implementation of the UI auto adjustment may be possible by extending the UI metadata model and corresponding UI runtime engine to react adequately on the available application integration model and data center map.
Development platforms may offer caching mechanisms for the different runtime engines that cover different domains, such as user interface, business object or web service. These caching mechanisms may be enhanced in order to provide a meaningful data caching strategy based on data center map.
Caching mechanism of the UI runtime engine may be enhanced to leverage the information available in data center map and in the application integration model in order to build the UI cache. An application service that is tagged in the application integration model as static read-only data-service may be considered as a candidate for preload and caching. The UI runtime engine may invoke static data services and cache the retrieved data locally in case that these services are located in data center with long virtual geo-distance and in case they are bound to UI elements of the UI model. The retrieved data will be instantly available and with zero-latency, when a user initiated process needs this data. The good response time made possible via such caching mechanism may lead to better user experience although distributed application are integrated over different data centers with long virtual geo-distance.
At 320, the virtual geo-distances of the data centers are derived from a data center map. In one embodiment, the deriving includes identifying the plurality of deployed applications for a user, identifying the data centers hosting the plurality of deployed applications, and deriving the virtual geo-distances between the data centers of the plurality of deployed applications.
In some embodiments, the virtual geo-distances between the data center are categorized into different types. In one embodiment, when the deployed application are within the same or neighboring data centers equal to zero logical units, the virtual geo-distance between the data centers is given a first categorization or label. In such case the data latency may be neglected. In one embodiment, when the data centers containing the deployed applications are at least one logical unit away from each other, the virtual geo-distance between the data centers is given a second characterization.
At block 330, based on the derived virtual geo-distance, the configuration of the plurality of deployed applications is adjusted. In one embodiment, adjusting the configuration of the plurality of deployed applications includes substituting asynchronous services with synchronous services and substituting coarse granular services with fine granular service, when the first characterization is identified. In one embodiment, adjusting the configuration of the plurality of deployed applications includes substituting synchronous services with asynchronous services and substituting fine granular service with coarse granular services, when the second characterization is identified. In one embodiment, adjusting the configuration of the plurality of deployed applications includes substituting backend based auto-validation and auto-completion services with user interface (UI) elements for validation, and substituting UI widgets in a mash up UI with navigation links on request, when the second characterization is identified. In one embodiment, adjusting the configuration of the plurality of deployed applications includes caching static data retrieved via service calls and pre-retrieving of code lists during session initialization, when the second characterization of the virtual geo-distance is identified between the data centers.
The receiving module 430 is operable to identify a composed on-demand application 410 for a user. The composed on-demand application 410 includes a plurality of deployed applications running in a plurality of data centers.
The data center map module 440 is operable to persist virtual geo-distance data for the data centers hosting the plurality of deployed applications part of the composed on-demand application 410.
The configurator module 450 is operable to derive virtual geo-distances of the data centers from the data center map module 440 for integration of the plurality of deployed applications and adjust the configuration of the plurality of deployed applications based on the derived virtual geo-distance data, thus creating an adjusted on-demand application 460.
In one embodiment, the configurator module 450 is further operable to identify the plurality of deployed applications for the user from the receiving module 430, identify the data centers hosting the plurality of deployed applications from the data center map module 440, and derive the virtual geo-distances between the data centers of the plurality of deployed applications.
In one embodiment, the configurator module 450 is further operable to determine a first characterization of the virtual geo-distance, if the deployed applications are within the same or neighboring data centers and a second characterization of the virtual geo-distance, if the distance between the data centers is at least one logical unit, wherein the at least one logical unit correlates with data latency.
In one embodiment, the configurator module 450 is further operable to substitute asynchronous services with synchronous services and substituting coarse granular services with fine granular service, when the first characterization is identified. In one embodiment, the configurator module 450 is further operable to substitute synchronous services with asynchronous services and substitute fine granular service with coarse granular services when the second characterization is identified for the virtual geo-distance between the data centers.
In one embodiment, the configurator module 450 is further operable to substitute backend based auto-validation and auto-completion services with user interface (UI) elements for validation, and substitute UI widgets in a mash up UI with navigation links on request, when the second characterization is identified for the virtual geo-distance between the data centers.
In one embodiment, the configurator module 450 is further operable to cache static data retrieved via service calls and pre-retrieve code lists during session initialization, when the second characterization is identified for the virtual geo-distance between the data centers.
Some embodiments may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as, functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components may be implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is located remotely from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.
The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term “computer readable storage medium” should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term “computer readable storage medium” should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform any of the methods or process steps described, represented, or illustrated herein. A computer readable storage medium may be a non-transitory computer readable storage medium. Examples of non-transitory computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”) and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment may be implemented using Java, C++, or other object-oriented programming language and development tools. Another embodiment may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.
A data source is an information resource. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open DataBase Connectivity (ODBC), produced by an underlying software system (e.g., ERP system), and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on.
In the above description, numerous specific details are set forth to provide a thorough understanding of embodiments. One skilled in the relevant art will recognize, however that the embodiments can be practiced without one or more of the specific details or with other methods, components, techniques, etc. In other instances, well-known operations or structures are not shown or described in detail.
Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the one or more embodiments. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated.
The above descriptions and illustrations of embodiments, including what is described in the Abstract, is not intended to be exhaustive or to limit the one or more embodiments to the precise forms disclosed. While specific embodiments of and examples for, the one or more embodiments are described herein for illustrative purposes, various equivalent modifications are possible within the scope, as those skilled in the relevant art will recognize. These modifications can be made in light of the above detailed description. Rather, the scope is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.
