Patent Application
20130275958
Cloud computing is a widely adopted concept. Generally, cloud computing refers to a model for enabling ubiquitous, convenient, and on-demand access to shared pools of configurable computing resources such as networks, servers, storages, applications, functionalities, and the like. There are a number of benefits associated with cloud computing for both the providers of the computing resources and their customers. For example, customers may develop and deploy various business applications on a cloud infrastructure supplied by a cloud provider without the cost and complexity to procure and manage the hardware and software necessary to execute the applications. The customers do not need to manage or control the underlying cloud infrastructure, e.g., including network, servers, operating systems, storage, etc., but still have control over the deployed applications and possibly over the configuration settings of the application-hosting environment. On the other hand, the provider's computing resources are available to provide multiple customers with different physical and virtual resources dynamically assigned and reassigned according to clients' load.
Typically, cloud providers offer common computing resources as services to their customers. Providers may supply these services as demanded and requested by their customers to meet their specific needs and requirements. Generally, customers may choose to enrich their business applications with only some of the offered services. Usually, to do that, customers may have to manually select the desired services. This may be cumbersome and prone to errors. For example, a customer may fail to select the proper services on which functionality the business application actually depends on. This may cause the application to work improperly when deployed and installed on the cloud. Alternative scenario may be selecting and installing all available services regardless of what services the business application actually is configured to access. However, such an alternative results in higher total cost of ownership, since unnecessary computing resources are consumed and provisioned. Another negative effect may be obscuring the monitoring, controlling, and reporting of the actual usage of the computing resources, resulting in less transparency for both the provider and the consumer of the utilized services.
The claims set forth the embodiments of the invention with particularity. The invention is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. The embodiments of the invention, together with its advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings.
Embodiments of techniques for automatic identification of services are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention 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 to avoid obscuring aspects of the invention.
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 embodiment of the present invention. 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 one embodiment, the runtime platform 105 may include a number of services 115-125 which provide additional runtime functionality that the applications 130-140 may be configured to access and consume. A service may be any type of functionality or feature that may be accessed and used by applications 130-140 and other such services. Services may be logical entities that may be distinctly used, imported, accessed or otherwise referenced. Various types of computing resources may be represented as services. One example of service may be a persistency or database service such as illustrated service ‘1’ 115. The persistency service may provide access to a relational database for applications 130-140 to be deployed and hosted on cloud 150. The persistence service 115 may provide a default schema in which tables can be created and data stored for one or more applications from applications 130-140 that are configured to use the service. The persistence service may provide connection parameters, such as URLs, drivers, and users, and also may perform other tasks such as backup and recovery, load balancing, and scaling.
Another example of a service may be identity management such as illustrated service ‘2’ 120. The identity management service may provide a central user store for identities that require access to protected resources of one or more applications from applications 130-140 that are configured to use the service once deployed and installed on cloud 150. The identity management service may also provide a single sign-on (SSO) access to users of applications 130-140 that are configured to use the identity management service. Other examples may include, but are not limited to, connectivity service that provides a secure and reliable access to applications, document service that provides a content repository for unstructured or semi-structured content, mail service that may enable transmission of electronic mail messages from applications that are configured to access, import, or otherwise use the service, and the like. In one aspect, the runtime platform 105 may also be supplied and offered by the runtime platform provider 101 as a service.
A customer of cloud services may develop and deliver one or more applications to be executed in cloud environment. The functionality provided by such applications may be accessed on the cloud by a number of consumers, e.g., related to the customer. As illustrated in
In one embodiment, a consumer request or another event may invoke the execution of a customer application in a cloud environment. According to the characteristics of the cloud environment, the invocation of the application may cause its provisioning, installation and starting, together or after the deployment of the necessary runtime platform.
Typically, application ‘X’ 180, service ‘L’ 175 and application server 170 are described or merged together in product ‘X’ 160, according to one embodiment. The definition of product ‘X’ 160 may be based on the characteristics and the requirements of the application ‘X’ 180. The packaging of application ‘X’ 180 together with the prerequisite runtime platform components, e.g., application server 170 and service ‘L’ 175, facilitates the installation of the application ‘X’ 180 on the cloud 150. In one embodiment, the required services are determined in order to package application ‘X’ 180 together with the prerequisite runtime platform components. According to one embodiment, identification of services used and consumed by a computer application is implemented automatically, according to one embodiment. Once identified, only the necessary services together with other prerequisite platform components and the application are installed on cloud 150. Thus, no redundant computing resources are consumed. Further, the proper services used by the application are automatically determined and installed, eliminating possible errors associated with manually selecting the needed services. For example, instead of installing all available services 115-125 only service ‘L’ 175 is installed together with application ‘X’ 180.
There are different technology solutions that implement provisioning of applications to cloud environment together with a base product, e.g., the runtime platform such as runtime platform 105. One example for such technology includes p2® provisioning platform for Eclipse®-based applications. Eclipse® is an open source community, whose projects are focused on building an open development platform composed of extensible frameworks, tools and runtimes for building, deploying and managing software across lifecycle. The p2® platform is part of the Equinox® project of Eclipse®. An Eclipse®-based product is a stand-alone program, e.g., self-contained and installable software application, built using the Eclipse® development platform. In one embodiment, Eclipse® provisioning mechanism p2® may be utilized to generate, validate and install product ‘X’ 160 based on the definitions of application ‘X’ 180 provided by customer 145, and further based on the definitions of runtime platform 105.
The different functionalities and modules of an application may be related to and dependent on each other, e.g., two or more application modules may have to be executed in a specific order. Moreover, the different functionalities and modules of the application may be further configured to access, consume, and depend on one or more services offered by a runtime platform provider. In one embodiment, a graph or hierarchy may be defined among the functionalities and modules, where one functionality or module is subordinate to, dependent on, associated with, or included in another functionality or module. In one embodiment, a hierarchy may be defined among the functionalities, where one functionality is subordinate to, dependent on or included in another functionality. As
Further,
In one embodiment, a functionality or module of application ‘A’ 210 may be configured to access, use, or import a service provided by runtime platform ‘X’ 290. For example, functionality ‘N’ 280 may provide user authentication. The implementation of the user authentication may use service ‘2’ 235 part of runtime platform ‘X’ 290, which may be identity management service. Therefore, as illustrated, module 282 part of the user authentication provided by functionality ‘N’ 280 may refer to module 245 part of the identity management service ‘2’ 235 Similarly, functionality ‘Q’ 260 may refer to service ‘3’ 275. A functionality or module of an application may be configured to access other modules or functionalities part of a runtime platform that are not included in specified services, e.g., functionality ‘R’ 270 may be configured to access and use module 295.
In one embodiment, a service (e.g., modules 225, 245, 255, 265, 285) may include two parts, an application programming interface (API) and an implementation of the service. The API of a service is the part of the service that can be directly imported and referenced by an application that is to be installed on a runtime platform. Thus, the implementation may be modified without affecting how the service is referenced and used. Usually, a package such as Java® package represented by a Java® Archive (JAR) file representing the API and another package representing the implementation are grouped in one feature representing the service. A feature may correspond to a particular functionality of the product or the application, and usually groups a number of unitary software components that could be managed together as a single entity. According to the terminology adopted in Eclipse® projects, such unitary software components are called plugins. The plugins are the basic installable and executable units or software code structures.
In one embodiment, the metadata describes dependencies and relationships existing among the different modules and functionalities of the application. The relationships among the application modules may be defined during their development and/or their configuration. Two or more application modules may have to be executed in a specific order; the result of the execution of one module may be a condition for the execution of another; two or more unitary modules may be related in a composite module; etc.
In one embodiment, the metadata includes at least one installable unit. In the terms of the p2® provisioning platform, installable unit (IU) describes a component that can be installed, updated and uninstalled. The IUs do not contain actual artifacts, but information or metadata about such artifacts, including names, versions, identifiers, dependencies, capabilities, requirements, etc. An artifact may refer to the content or program code being installed or managed, e.g., bundles, binary archives, executable files, etc. A bundle refers to Open Services Gateway initiative (OSGi) file similar to JAR files. In one embodiment, the metadata of the application together with the installable artifacts of the application are stored in a p2® repository of the application.
Separate IUs may be generated for the modules and the functionalities of the application, and even for the application itself. In one embodiment, different modules and functionalities of the application may be represented as features and plugins in the context of the p2® provisioning platform. Usually, the application corresponds to a main or root IU, and the modules are the peripheral, subordinate, or leaf IUs.
At 340, at least one service referenced in the application metadata is determined Often, an IU of a module includes a requirement expression containing a reference to a functionality that is a prerequisite for the proper working of the module. Thus, one package may import another package. The required or imported at least one service may be determined based on such requirement expressions included in one or more IUs of the application metadata. At 350, additional metadata associated with the at least one service is identified in the metadata of the cloud runtime platform. In one embodiment, the IU describing the determined at least one service is added to a collection, group or list with IUs describing services that are prerequisite for the installation of the application.
At 360, the metadata of the application and the identified additional metadata associated with the service are stored in a composite repository. In one embodiment, the composite repository includes metadata of the application, installable artifacts of the application, and metadata of the service part of the runtime platform that are prerequisite for the installation of the application. At 370, based on the information included in the composite repository, the application is installed on the cloud runtime platform together with the at least one service. In one embodiment, at least one virtual machine is instantiated in a cloud runtime platform. The application and the at least one service are installed on the virtual machine
The application ‘A’ root IU 410 refers to module ‘1’ IU 420, module ‘2’ IU 430 and module ‘K’ IU 440. More specifically, application ‘A’ provides capabilities provided by the modules corresponding to the IUs 420-478. Further, module ‘1’ IU 420 refers to module IU 422; module ‘2’ IU 430 refers to module IU 432-438; module ‘K’ IU 440 refers to module ‘P’ IU 450 and to module ‘Q’ IU 460. Further, module ‘P’ IU 450 refers to module IUs 452-454 and module ‘Q’ IU 460 refers to module ‘R’ IU 470. These references specify dependencies or relationships among the functionalities corresponding to the modules of application ‘A’ as described in metadata. The relationships among the modules or functionalities of an application may form a graph structure different from a tree, where the IU corresponding to the application may still be on the highest hierarchical level.
Further,
As illustrated in
An IU describes, among other things, capabilities and requirements associated with the IU. Capabilities associated with an IU refer to functionality that the application module corresponding to the IU, provides. These capabilities may satisfy requirements of other IUs. On the other hand, the requirements associated with the IU refer to functionality that the corresponding module necessitates as a prerequisite in order to be installed or to work properly once installed. Dependencies among different modules of an application may be resolved based on capabilities and requirements of IUs. At 520, the modules including services required, imported or otherwise referenced by the application, but not included in the application, are identified based on the requirements specified in the IUs of the application.
At 530, metadata of the runtime platform is received. In one embodiment, the runtime platform may be a cloud runtime platform. The metadata of the runtime platform represents a second graph of dependencies or relationships among IUs, e.g., structure 401 of IUs in
At 550, a list is created including the identified IUs of the runtime platform that provide the modules required by the application. In one embodiment, a stack or other data structure may be used to store the list of identified IUs.
At 560, an IU from the list with identified IUs that is not traversed is selected. At 570, the selected IU is marked as traversed. In one embodiment, by marking selected IUs as traversed, repetition of traversing the same IUs is avoided. At 575, a check is performed if the selected IU describes a service. In one embodiment, an IU may include type information for the corresponding module that the IU describes, e.g., if the module is of type “service”. An example of such type information may be represented as follows:
<property name=“com.sap.jpaas.type” value=“service”/>
At 585, if the selected IU describes a service, the selected IU is added to a collection of IUs of the runtime platform that describe services. The collection groups identified IUs of services to be installed together with the application. At 590, a check is performed if all IUs that describe services are already identified and added to the collection. If all IUs in the metadata of the runtime platform that describe services are already identified, process 500 stops without further searching for services referenced by the application.
At 580, if the selected IU describes a module that is not a service, one or more IUs that provide the selected IU are added to the list with the identified IUs of the runtime platform that provide the required by the application modules. Thus, the one or more IUs that directly provide, export or otherwise reference the selected IU are added to the list to be checked whether describe services. At 595, a check is performed whether all the IUs in the list are traversed. If there are IUs in the list that are not traversed process 500 continues at 560. If all IUs in the list are traversed process 500 ends.
According to methods and techniques described herein, based on the metadata of application ‘A’, all modules required by IUs 610-640 of the application are identified. Once the requirements of the application are identified, modules that provide the required by the application functionality are searched for in the metadata of the runtime platform ‘X’. In other words, the capabilities of IUs 601 and 680-695 describing components of the runtime platform ‘X’ are traversed. As a result, it is identified that package ‘A’ described by IU 622 is provided by plugin ‘A’ described by IU 682.
In one embodiment, an application may access a service via an API of the service such as Java® API or Representational state transfer (REST) API. Thus, typically, the application is configured to access only the API of a service, without having access to the full implementation of the service. However, the implementation part of the service is also required for the application to work properly when deployed and installed on the cloud. In one embodiment, the feature representing the service is identified to be included in the installation of the application.
According to process 500, a check is performed if plugin ‘A’ is a service. As illustrated in
Some embodiments of the invention 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 maybe implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments of the invention 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 remotely located 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. Examples of 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 of the invention may be implemented using Java, C++, or other object-oriented programming language and development tools. Another embodiment of the invention 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 of the invention. One skilled in the relevant art will recognize, however that the invention 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 details to avoid obscuring aspects of the invention.
Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments of the present invention 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 present invention. 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 of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. These modifications can be made to the invention in light of the above detailed description. Rather, the scope of the invention is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.
