Method and apparatus for providing a function-as-a-service platform

Abstract

Embodiments described herein provide methods and apparatus for enabling third-party developers to use functions in a function-as-a-service platform. The method includes storing, in a function catalog, one or more respective function descriptions associated with one or more functions available for use by third-party developers, wherein each function description includes an intent and a function name of the respective function; receiving, from a first function developer, a function call including an indication of a first intent; and selecting, from the function catalog, a first function description that matches the first intent.

Description

Technical Field

[0001] The embodiments described herein relate to methods and apparatuses for enabling third-party developers to use features in a features-as-a-service platform. For example, the methods described herein store one or more corresponding feature descriptions associated with one or more features that can be used by third-party developers in a feature catalog. Background Technology

[0002] Generally, all terms used herein should be interpreted according to their common meaning in the relevant art, unless explicitly given and / or implied by the context from which they are used. Unless otherwise expressly stated, all references to one / an / element, device, component, part, step, etc., should be openly interpreted as referring to at least one instance of that element, device, component, part, step, etc. Unless explicitly described as a step following or preceding another step and / or implying that a step must follow or precede another step, the steps of any method disclosed herein are not necessarily performed in the exact order disclosed. Where appropriate, any feature of any embodiment of the embodiments disclosed herein may be applied to any other embodiment. Similarly, any advantage of any embodiment of the embodiments may be applied to any other embodiment, and vice versa. Other objects, features, and advantages of the appended embodiments will become apparent from the following description.

[0003] The Function as a Service (FaaS) paradigm in cloud service offerings allows consumers (developers) to build and deploy applications without the complexities of managing provisioning and maintaining infrastructure, platforms, or software ecosystems. This model for developing and deploying services is well-suited for serverless architectures. Developers can define the individual functions that make up the service, deploy these functions on the cloud platform, and then invoke them when service functionality is needed. Functions in a FaaS platform can start within milliseconds to handle the tasks they are defined to perform. Consumers can pay the cloud provider only when the functions they have deployed are enabled. The FaaS paradigm is well-suited for microservices software development architectures.

[0004] Developers can break down the functionality of an application or microservice into a set of modular functions, which can then be uploaded to the FaaS platform. Each uploaded function can be enabled and executed independently. These functions can also be scaled independently. Figure 1 This illustrates an example of how a monolithic application can be broken down into a set of microservices, which can be decomposed into a set of modular functions.

[0005] Features can be enabled as a result of predefined triggers by the developer, or they can be enabled manually. A set of features can be chained together to accomplish complex tasks within a service or microservice.

[0006] Some of the advantages of a FaaS platform include, but are not limited to, reduced developer logistics, faster development and deployment, scalability, fault tolerance, and the ability to pay only for the active time of a feature and not for when it is idle.

[0007] Disadvantages include greater difficulty in tracking numerous functions, more challenging debugging, and a scarcity of debugging tools, as well as reduced transparency into the infrastructure. Currently, most of the leading cloud platform providers offer FaaS capabilities, such as AWS Lambda, Google Cloud Functions, and Azure Functions. Current FaaS frameworks are also subject to vendor lock-in. Summary of the Invention

[0008] According to some embodiments, a method is provided for enabling third-party developers to use features in a feature-as-a-service platform. The method includes: storing in a feature catalog one or more corresponding feature descriptions associated with one or more features available for use by third-party developers, wherein each feature description includes an intent and a feature name for the corresponding feature; receiving a feature call from a first feature developer including an indication of a first intent; and selecting a first feature description from the feature catalog that matches the first intent.

[0009] According to some embodiments, a Function as a Service (FaaS) platform is provided to enable third-party developers to use features. The FaaS platform includes processing circuitry configured to: store in a feature catalog one or more corresponding feature descriptions associated with one or more features available for use by third-party developers, wherein each feature description includes an intent and a feature name for the corresponding feature; receive from a first feature developer a feature invocation including an indication of a first intent; and select a first feature description from the feature catalog that matches the first intent. Attached Figure Description

[0010] To better understand the embodiments of this disclosure and to illustrate how it can be implemented, reference will now be made to the accompanying drawings by way of example only, wherein:

[0011] Figure 1 This example illustrates how a monolithic application can be broken down into a set of microservices, which can be decomposed into a set of modular functions.

[0012] Figure 2Examples of FaaS platforms according to some embodiments of the present invention are shown;

[0013] Figure 3 The presents a method, according to some embodiments, for enabling third-party developers to use features in a features-as-a-service platform;

[0014] Figure 4 A method for extracting a second intent from functional source code is illustrated according to some embodiments;

[0015] Figure 5 A method for storing a second function description in a function catalog is illustrated according to some embodiments;

[0016] Figure 6 An example of a functional catalog for maintaining intent hierarchy mappings according to some embodiments is shown;

[0017] Figure 7 The presents a method, according to some embodiments, for preprocessing source code of a function defined by a first function developer;

[0018] Figure 8 This illustrates a method, according to some embodiments, for finding one or more candidate feature descriptions that match a first intent from a feature catalog;

[0019] Figure 9 This illustrates a method for invoking a first function according to some embodiments;

[0020] Figure 10 This illustrates a Function as a Service (FaaS) platform that includes processing circuitry (or logic). Detailed Implementation

[0021] For purposes of explanation and not limitation, specific details, such as particular embodiments or examples, are set forth below. Those skilled in the art will recognize that other examples may be employed in addition to these specific details. In some cases, detailed descriptions of well-known methods, nodes, interfaces, circuits, and apparatuses have been omitted to avoid obscuring this description with unnecessary detail. Those skilled in the art will recognize that the described functionality can be implemented in one or more nodes using hardware circuitry (e.g., analog and / or discrete logic gates, ASICs, PLAs, etc., interconnected to perform specialized functions) and / or in conjunction with one or more digital microprocessors or general-purpose computers using software programs and data. Nodes communicating using an air interface also have suitable radio communication circuitry. Furthermore, where appropriate, it may be additionally considered to implement this technology entirely within any form of computer-readable storage (such as solid-state storage, disk, or optical disk) containing a suitable computer instruction set that enables the processor to implement the technology described herein.

[0022] Hardware implementation may include, but is not limited to, digital signal processor (DSP) hardware, reduced instruction set processors, hardware (e.g., digital or analog) circuitry including but not limited to one or more application-specific integrated circuits (ASICs) and / or one or more field-programmable gate arrays (FPGAs), and (where appropriate) state machines capable of performing such functions.

[0023] Most current Functionality as a Service (FaaS) platforms provide developers with the capability to define their own functionalities, which can then be deployed to provide services or applications. Beyond a few standard functionalities, all the functionalities that make up a service need to be written / developed by the developer. To implement fairly complex services, using FaaS requires developing, testing, and validating a large number of functionalities, which can be quite an effort.

[0024] To date, there is no intuitive and straightforward way for developers to build services using a mix of features they define and features developed by other third-party developers. There is no system for discovering and invoking features defined by other parties as part of services deployed by developers. This, to some extent, limits the potential and speed of development in a FaaS environment.

[0025] Current FaaS platforms do not provide developers with a transparent way to expose the features they have developed to other developers on the FaaS platform. Developers also lack a transparent and dynamic way to discover and enable features exposed by other developers to build their services.

[0026] Therefore, the embodiments described herein provide methods and apparatus for enabling third-party developers to use features in a Functions-as-a-Service platform.

[0027] In particular, the methods and apparatus described herein enable developers to transparently expose their functionality for use by other developers within the FaaS platform. Furthermore, the methods and apparatus described herein enable the FaaS platform to catalog publicly available functionality based on the functionality provided by the exposed functionality. This cataloging of functionality can be performed in a searchable manner. The embodiments described herein also enable developers to dynamically search for and enable functionality exposed by other developers using intent-based invocation.

[0028] Figure 2 Examples of FaaS platforms according to some embodiments of the present invention are shown.

[0029] It will be recognized that the illustrated function blocks can be implemented by software code. In some cases, a single piece of software can implement one or more function blocks within the function blocks.

[0030] The FaaS platform supports the Functions as a Service (FaS) deployment paradigm. Specifically, the FaaS platform acts as a service deployment interface provided by cloud platform providers to consumers who use FaaS to build services.

[0031] The FaaS platform 200 includes a feature development and execution environment 201. The feature development and execution environment 201 includes functional blocks that allow developers to define and / or develop features, specify triggers for feature invocation (and chain features together to achieve service functionality), and execute features within the FaaS platform 200. The feature development and execution environment may also include the runtime environment required to execute features.

[0032] In this example, the feature development and execution environment 201 includes features 202a to 202m. Features 202a to 202m may include code (or software) that developers can write and deploy on the FaaS platform 200. Features 202 can be executed when pre-set conditions are triggered or when these features 202 are explicitly enabled.

[0033] Depending on the cloud platform provider, the FaaS platform allows developers to define functions in multiple languages.

[0034] In this example, the feature development and execution environment 201 also includes a feature enabler 203. The feature enabler 203 may include a function block responsible for enabling a feature and executing it on the runtime environment required by the feature. The function block can be commanded to enable the feature based on a predefined trigger, or the feature block can be explicitly requested to enable the feature.

[0035] In this example, the feature development and execution environment 201 also includes a feature compiler 204. The feature compiler 204 includes function blocks that can be used to compile features defined by the developer. The feature compiler 204 can also link features with other libraries into an executable form for activation by the feature enabler 203. The feature compiler 204 is only needed when the features are defined in a language that requires compilation for execution.

[0036] In this example, the feature development and execution environment 201 also includes a feature preprocessor 205. The feature preprocessor includes function blocks configurable to preprocess developer-defined features to find intent-based feature call instructions. Intent-based feature call instructions can be in the form of keywords, which developers use to indicate intent-based feature calls. Instructions can take different forms based on the programming language (in which the feature is being written) and can be designed to be intuitive for developers.

[0037] Once the function preprocessor 205 detects an intent-based function call instruction, it can invoke the intent parser 206 to perform further processing. The function preprocessor 205 can be configured to preprocess functions after the developer has written them, or it can be configured to preprocess functions periodically while the developer is writing functions in real time to process and analyze intent-based function calls.

[0038] In this example, the FaaS platform 200 also includes an intent resolver 206. The intent resolver includes a function block that can be configured to resolve the intent indicated in a function call.

[0039] For example, intent parser 206 can determine a hierarchical search query that can be used to find available third-party functions that match a specified intent within the function catalog.

[0040] In this example, the FaaS platform 201 also includes an intent parser 207. The intent parser 207 includes functional blocks configured to prepare intent categories for functionality. For example, when developers want to make a feature available to other developers, they may have one or more intents, and the intent parser can use one or more intents along with the feature signature (parameters and return type) to prepare the intent category. Figure 5 A flowchart illustrating the functionality of this module.

[0041] In this example, the FaaS platform 201 also includes a feature catalog 208. Feature catalog 208 comprises a database of all features that can be configured by developers to be made available for invocation by other developers. Feature catalog 208 can be configured to store these features hierarchically based on intent classification performed by intent profiler 207. Feature catalog 208 can also store additional metadata information about the features, which can be used when searching for features based on intents indicated in feature invocations from third-party developers.

[0042] In this example, the FaaS platform 201 also includes a dynamic function mapper 209. The dynamic function mapper 209 includes a function block configurable to dynamically enable functions from a function catalog 208 based on an intent specified by the invoked function. The dynamic function mapper 209 can select from one or more candidate functions in the function catalog 208 that match the intent and satisfy the constraints specified by the invoked function.

[0043] In this example, the FaaS platform 201 also includes a feature publisher 210. Feature publisher 210 includes a function block configurable to add features to the feature catalog 208. Feature publisher 210 can use intent classifications prepared by intent profiler 207 to publish features in the feature catalog 208 along with information such as pricing, access levels, and other metadata related to the feature (e.g., version, geographic availability).

[0044] Figure 3 The presents a method, according to some embodiments, for enabling third-party developers to use features in a features-as-a-service platform. Figure 3 The method shown can be derived from Figure 1 The FaaS platform shown is executed.

[0045] In step 301, the method includes storing in a feature catalog one or more corresponding feature descriptions associated with one or more features available for use by third-party developers, wherein each feature description includes the intent and feature name of the corresponding feature. For example, the feature catalog could be... Figure 2 The functional catalog 208 is shown.

[0046] The function description may include sufficient information to allow the FaaS platform 201 to invoke the function associated with the function description. For example, the function name in the function description may include a Remote Procedure Call (RPC) stub.

[0047] s

[0048] The intent of a function can include instructions on what the function should do. As an example, one could envision a first function configured to receive a list as input and output a sorted version of the list as output. For instance, the first function could be configured to sort the list using the quicksort method.

[0049] Therefore, the intent of the first function can be simplified to the intent of "sorting" at the first level and the intent of "quicksort" at the second (fineer-grained) level. In other words, in this example, the intent of the first function is sorting, and more specifically, to perform quicksort.

[0050] In step 302, the method includes receiving a function call from a first function developer that includes an indication of a first intent.

[0051] In step 303, the method includes selecting a first functional description that matches the first intent from the functional catalog.

[0052] For example, step 303 may include finding one or more candidate function descriptions from a function catalog that match the first intent. A candidate function description may match the first intent if the intent in it, when implemented, would provide the first intent. In other words, the first intent could be "sorting," and the input parameter could be a list. A stored function description with intents that include two levels (e.g., "sorting" and "quick sort" as described above) can be considered to match the first intent because the intent of "sorting" is provided when the stored function is implemented.

[0053] In step 304, the method includes selecting a first functional description from one or more candidate functional descriptions.

[0054] For example, in some cases, there may be more than one storage function with an intent that matches the first intent. For example, the first storage function with the intent "sort" and "quick sort" and the second storage function with the intent "sort" and "heap sort" can both be considered to match the first intent "sort".

[0055] Therefore, if more than one candidate functional description is found in step 303, a first functional description can be selected from one or more candidate functional descriptions. For example, see the following reference. Figure 9 As described, this can be performed by the dynamic function mapper 209.

[0056] In some examples, step 301 may include receiving the functional source code of the second function from the second function developer, wherein the functional source code includes a function name and a second intent of the second function. The method may then further include: extracting the second intent from the functional source code; and storing a description of the second function, including the second intent and the function name, in a function directory. Specifically, for example, see the following reference... Figure 4 As shown, Figure 2 The intent parser 207 shown can be configured to extract a second intent from the functional source code.

[0057] For example, see the following reference Figure 5 As shown, the feature publisher 210 can be configured to store a second feature description in the feature directory.

[0058] Figures 4 to 6 This involves releasing new features for third-party developers to discover using intent-based invocations.

[0059] Figure 4 This illustrates a method for extracting a second intent from functional source code. This method can be... Figure 2 The intent parser 207 shown is executed.

[0060] In step 401, the intent parser 207 receives the functional source code of the second function.

[0061] In step 402, the intent parser 207 analyzes the function source code.

[0062] The source code for an example function can include the following structure in a single line of source code:

[0063] <KEY_WORD> .<THIRD_PARTY_ID> .<INTENT_LEVELl_0> .<INTENT_LEVEL_1> .<INTENT_LEVEL_N> . <functionname>.

[0064] In some examples, the intent profiler performs step 403. In step 403, the intent profiler searches the feature's source code for keywords that indicate that a second feature will be made available to developers of other features. In the example above, the keyword...<KEY_WORD> This can indicate that the second feature will be made available to developers of other features.

[0065] In some examples, steps 404 and 405 may be performed in response to finding keywords in the function's source code.

[0066] In step 404, the method includes extracting elements of a second intent from the functional source code. In the example shown above, the second intent may include the following portions:

[0067] source code<INTENT_LEVELl_0> .<INTENT_LEVEL_1> .<INTENT_LEVEL_N> .

[0068] As mentioned earlier, intents can be represented by one or more increasingly finer-grained intent levels. In the example above, the first intent level...<INTENT_LEVELl_0> Can indicate a higher level than the second intention<INTENT_LEVEL_1> Coarser-grained intents. Then, the granularity of the intent level can become increasingly finer, until...<INTENT_LEVEL_N> .For example,<INTENT_LEVELl_0> It could be "sorting", then,<INTENT_LEVEL_1> These could be, for example, "quick sort", "heap sort", or "bubble sort".

[0069] <THIRD_PARTY_ID> It can indicate the identity of the developer who provided the secondary functionality.

[0070] <functionname>The name of the second function can be indicated. Then, <functionname>It can be used to store a description of a second function and to invoke the second function later.

[0071] Step 404 may also include extracting indications of one or more input parameter types of the second function and one or more output parameter types of the second function, as well as any other metadata associated with the second function.

[0072] In step 405, the method includes forwarding the second intent extracted in step 404 to the feature publisher. Step 405 may also include forwarding one or more input parameter types of the second feature and one or more output parameter types of the second feature, as well as any other metadata.

[0073] Figure 5 This illustrates a method for storing a second function description in a function directory. Figure 5 The method can be derived from Figure 2 The function publisher 210 shown is executed.

[0074] In step 501, the function publisher 210 receives a second intent from the intent parser. In step 501, the function publisher may also receive one or more input parameter types of the second function and one or more output parameter types of the second function, and / or any other metadata associated with the second function.

[0075] In steps 502 and 503, the feature publisher 210 determines whether the feature catalog already includes a third feature description containing the second intent.

[0076] For example, in step 502, the feature publisher prepares a hierarchical search query based on the second intent and searches the feature directory to find directory entries with the same intent.

[0077] Therefore, in the example shown above, the feature publisher searches for directory entries with an intent that matches the second intent:

[0078] <INTENT_LEVELl_0> .<INTENT_LEVEL_1> .<INTENT_LEVEL_N> .

[0079] Then, in step 503, the feature publisher 210 determines whether the search has been successful.

[0080] The feature catalog may include a repository that stores features that can be invoked using intent-based feature calls.

[0081] Figure 6 This shows an example of a functional directory for maintaining intent hierarchy mappings.

[0082] In this example, the feature catalog maintains an intent hierarchy mapping. Each catalog entry 601a to 601r is stored in association with a branch of the hierarchy tree decomposed by intent levels.

[0083] For example, a branch of the hierarchy tree might be associated with intent level 1=A (where A is an intent function, such as "sorting"). In some cases, the intent specified by the function's source code might only include one level, and in those cases, the function's directory entry would be stored associated with this branch of the hierarchy tree. However, in such cases, other intent levels would be associated with the intent level 1=A branch. For example, there might also be intent level 2=B and intent level 3=C, etc.

[0084] Therefore, in this example, directory entries 601a to 601d include functional descriptions associated with intent level 0="A", intent level 1="B", intent level 2="C", and intent level 3="D".

[0085] In a similar manner, directory entries 601e through 601h are associated with intent levels 0="E", 1="F", 2="G", and 3="H". Among them, levels "E" through "H" define functional intents with increasingly finer granularity.

[0086] Directory entries 601i and 601j are associated with intent level 0="E", intent level 1="F", and intent level 2="G". Therefore, the intents defined by these functions are coarser in granularity than those of directory entries 601e to 601h.

[0087] The remaining directory entries 601k to 601r are similarly associated with intent levels in the hierarchy tree.

[0088] Storing catalog entries in this way saves memory in the function catalog because it is not necessary to repeat information related to the intent of the function for each catalog entry.

[0089] Along with the feature database, the feature catalog also stores RPC stubs for features in different languages, which may be required for operations such as calling a feature from another feature defined in a different language but using intent-based invocation.

[0090] The feature catalog also stores metadata associated with each feature, which can be used to determine when dynamically mapping intent-based calls to features. Metadata information may include information related to pricing, geographic availability, runtime statistics, and any other relevant information.

[0091] Return to Figure 5 In response to determining that the feature catalog includes a third feature description containing the second intent (e.g., in response to determining that the search was successful in step 503), the method proceeds to step 504, in which the feature publisher 210 stores the second feature description next to the third feature description associated with the second intent.

[0092] For example, refer to Figure 6 If the second intent is equal to intent level 1="E", intent level 2="F", and intent level 3="G", then the second function description will be stored next to directory entries 601i and 601j.

[0093] Alternatively, in response to determining that the feature catalog does not include a third feature description containing a second intent, the method proceeds to step 505, in which the feature publisher 210 stores the second feature description associated with the second intent. For example, if the second intent is intent level 0="E" and intent level 1="F", but not explicitly intent level 2="G", then the second feature description can be stored in association with intent level 1="F".

[0094] In some examples, the second intent may include intent levels that are not yet stored in the feature catalog. In these examples, new branches of the feature catalog tree can be created.

[0095] For example, a second intent could be equal to intent level 0="E", intent level 1="F", and intent level 2="O". In this example, a new branch could be created near intent level 1="F" (off), where intent level 2="O".

[0096] In step 506, the feature publisher may add any metadata associated with the second feature to the second feature description and then store it in the feature catalog.

[0097] In step 507, the feature publisher 210 can create one or more RPC stubs for the second feature using different languages, and can store the RPC stubs in the second feature description.

[0098] In step 508, the feature publisher appropriately inserts the second feature description into the feature catalog.

[0099] Figures 7 to 9 Intent-based invocations involving published functions.

[0100] Figure 7 This illustrates a method for preprocessing the source code of a function defined by the first function developer. Figure 7 The method can be derived from Figure 2 The preprocessor 205 shown in the figure executes the function.

[0101] Figure 7 The method shown can be executed after the developer has written the function, or it can run periodically while the developer is writing the function in real time to process and analyze whether intent-based function calls are being written into the function.

[0102] In particular, Figure 3 Step 302 may include the features of step 701.

[0103] In step 701, the function preprocessor 205 parses the source code of a function written or being written by the first function developer. The source code of the function may include function calls from the first function developer, and the function calls include instructions for a first intent. Therefore, function calls in the source code of the function may be calls to a third part for use within a function that the first function developer has already written or is writing.

[0104] In step 702, the function preprocessor 205 searches for keywords in the function's source code. Keywords may indicate that the function intends to invoke a third-party function using an intent call. Depending on the language the first function developer is using to write the function, the keywords may take different forms. In particular, the keywords may be designed to be intuitive for the first function developer.

[0105] In step 703, the function preprocessor 205 may extract the intent element from the function call.

[0106] A function call can have the following structure:

[0107] <KEY_WORD> .<THIRD_PARTY_ID> .<LEVEL_0_INTENT> .<LEVEL_1_INTENT> .<LEVEL_N_INTENT> .call([Param1, Param2, ...., ParamN], [ReturnParam1, ReturnParam2, ..., ReturnParamN], [Additional_Constraint]).

[0108] here,<KEY_WORD> Indication: The function is intending to use an intent call to invoke a third-party function.<THIRD_PARTY_ID> This is an optional parameter that indicates the identity of the third-party developer; the call is intended to invoke functionality from that developer.<LEVEL_0_INTENT> ,<LEVEL_1_INTENT> and<LEVEL_N_INTENT> The first intent that indicates the functionality the developer wants to invoke. The first intent includes intent levels, as described above.

[0109] List the types of the input parameters of the function that the first function developer wants to call as ([Param1, Param2, ..., ParamN); and list the types of the expected output parameters of the function that the first function developer wants to call as [ReturnParam1, ReturnParam2, ..., ReturnParamN].

[0110] A function call may also include one or more additional constraints relating to the function to be called, as indicated by the first function developer. For example, additional constraints may relate to the cost of using the called function, the location of the called function, the operating speed of the called function, or any other metadata that may be associated with the called function.

[0111] An example of an intent-based invocation following the format described above would be:

[0112] THIRD_PARTY_FN.Ericsson.Sort.Quic_Sort.call([original_list], [sorted_list], ["location": "SE"])

[0113] here:

[0114] <KEY_WORD> == THIRD_PARTY_FN

[0115] <THIRD_PARTY_ID> == Ericsson

[0116] <LEVEL_0_INTENT> == Sort

[0117] <LEVEL_1_INTENT> == Quic_Sort

[0118] <param1>== original_list (This is the input for the function, and the data type can be derived from this variable)

[0119] <returnparam1>== sorted_list (This is the output from the function, from which you can derive the data type)

[0120] <Additional_Constrain> == "location": "SE" (This is an example of a constraint that indicates the expected functionality should be able to operate within location: SE)

[0121] Another example:

[0122] THIRD_PARTY_FN.*.Sort.*.call([_list], [sorted_list], ["location": "SE", "Price": "Lowest"])

[0123] The intention here is to find a sorting algorithm and any sorting method (fast, heap, bubble) from any vendor, with the constraint that it must run in SE and enabling it should be inexpensive.

[0124] Here is another example of intent-based function calls:

[0125] THIRD_PARTY_FN.*.hash.sha-2.512-bits.call([Message, Len], [Digest],["Time": "Fastest"])

[0126] Here, the developers are attempting to enable hashing functionality using the SHA-2 standard with a 512-bit digest; they are passing the message to be hashed and its length as input parameters and expecting the digest as the return value. The developers have also specified that the selected functionality should be the fastest available implementation; in the example above, the developers have also...<THIRD_PARTY_ID> Use the wildcard '*' to specify that the FaaS platform can select features from any available third-party developers.

[0127] In step 704, the function preprocessor enables the intent resolver 206 to retrieve candidate third-party functions that match the first intent. For example, the function preprocessor may transmit the first intent to the intent resolver. The function preprocessor may also transmit other parameters indicated in the function call.

[0128] In step 705, in response to intent resolver 206 finding one or more candidate functions, function preprocessor may indicate to first function developer that potential third-party functions can be used to implement function calls in the source code of functions that first function developer has already written or is writing.

[0129] Figure 8 This demonstrates a method for finding one or more candidate feature descriptions that match the first intent from a feature catalog. Figure 8 The method shown can be derived from Figure 2 The intent parser 206 shown is executed.

[0130] In step 801, the intent parser 206 prepares a search query based on the first intent. For example, in... Figure 6 In the case where the feature catalog shown includes a hierarchical mapping, the search query may include a hierarchical search query based on the granularity order of the intent level in the first intent.

[0131] In step 802, intent resolver 206 searches feature catalog 208 to find candidate feature descriptions that match the first intent. For an example where a hierarchical mapping is used as the feature catalog, the intent resolver can locate the first intent in the hierarchical mapping and can select any catalog entry stored in association with the first intent as a candidate feature matching the first intent.

[0132] For example, suppose the first intent specifies intent level 0="E", intent level 1="F", and intent level 2="G". In this example, from Figure 6 As shown in the hierarchy mapping, the intent parser can determine that directory entries 601i and 601j match the first intent. The intent parser can also determine that directory entries 601e through 601h also match the first intent, because they also provide the same first three intent levels.

[0133] In some examples, the intent resolver may only search for the feature description provided by the third-party developer indicated in the feature call.

[0134] In step 803, intent resolver 206 may optionally test one or more candidate function descriptions to check the expected functionality of the one or more candidate function descriptions. For example, the intent resolver may input the input parameters indicated in the function call into one or more candidate functions and may check the output returned by one or more candidate functions with the expected output type.

[0135] In step 804, intent resolver 206 may filter one or more candidate functions found in step 802. For example, the intent resolver may filter candidate functions based on one or more additional constraints indicated in the function call. For example, if the function call includes additional constraints that the function should be as inexpensive as possible, then the intent resolver may select only the cheapest candidate function.

[0136] In step 805, intent resolver 206 transmits the remaining list of candidate functions to dynamic function mapper 209. In some examples, intent resolver 206 may also transmit any metadata associated with the candidate functions stored in the function catalog.

[0137] Figure 9 The method for invoking the first function is shown. Figure 9 The method shown can be derived from Figure 2 The dynamic function mapper 209 shown is executed.

[0138] In step 901, the dynamic function mapper 209 receives a list of candidate functions from the intent parser 206.

[0139] In step 902, the dynamic function mapper selects a first function description from one or more candidate functions. In some examples, the selection of the first function description from one or more candidate function descriptions may be based on additional constraints included in the function call.

[0140] In step 903, the dynamic function mapper can ensure that the first function can be enabled. If the first function cannot be enabled, the dynamic function mapper can go through some process to ensure that the first function can be enabled, or it can select a different function from one or more candidate functions.

[0141] In step 904, the dynamic function mapper 209 invokes the first function using the first function name in the first function description and one or more input parameters indicated in the function call. For example, the dynamic function mapper may marshall the input parameters from the function call onto the RPC call of the first function.

[0142] In step 905, the dynamic function mapper 209 waits for a call to the first function and receives one or more outputs of the first function.

[0143] In step 906, the dynamic function mapper 209 unmarshalls one or more outputs of the first function.

[0144] In step 907, the dynamic function mapper 209 sends one or more outputs to the first function developer. For example, the dynamic function mapper may populate one or more outputs into the return variable of a function call.

[0145] Figure 10 A Function as a Service (FaaS) platform 1000 is illustrated, including processing circuitry (or logic) 1001. It will be appreciated that the FaaS platform 1000 may include one or more virtual machines running different software and / or processes. Therefore, the FaaS platform 1000 may include one or more servers, switches, and / or storage devices, and / or may include cloud computing infrastructure running software and / or processes.

[0146] FaaS platform 1000 may include FaaS platform 310 as described above. Processing circuitry 1001 controls the operation of FaaS platform 1000 and can implement the methods described herein with respect to FaaS platform 1000. Processing circuitry 1001 may include one or more processors, processing units, multi-core processors, or modules configured or programmed to control FaaS platform 1000 in the manner described herein. In a particular implementation, processing circuitry 1001 may include multiple software and / or hardware modules, each configured to perform or be used to perform various or multiple steps of the methods described herein with respect to FaaS platform 1000 or FaaS platform 310.

[0147] Briefly, the processing circuitry 1001 of the FasS platform 1000 is configured to: store in a function catalog one or more corresponding function descriptions associated with one or more functions available for use by third-party developers, wherein each function description includes the intent and function name of the corresponding function; receive a function call including an indication of a first intent from a first function developer; and select a first function description matching the first intent from the function catalog.

[0148] In some embodiments, the FaaS platform 1000 may optionally include a communication interface 1002. The communication interface 1002 of the FaaS platform 1000 can be used to communicate with other nodes, such as other virtual nodes. For example, the communication interface 1002 of the FaaS platform 1000 may be configured to transmit and / or receive requests, resources, information, data, signals, or the like from other nodes or network functions. The processing circuitry 1001 of the FaaS platform 1000 may be configured to control the communication interface 1002 of the FaaS platform 1000 to transmit and / or receive requests, resources, information, data, signals, or the like from other nodes or network functions.

[0149] Optionally, the FaaS platform 1000 may include a memory 1003. In some embodiments, the memory 1003 of the FaaS platform 1000 may be configured to store program code that the processing circuitry 1001 of the FaaS platform 1000 can execute to perform the methods described herein with respect to the FaaS platform 1000 or FaaS platform 310. Alternatively or additionally, the memory 1003 of the FaaS platform 1000 may be configured to store any requests, resources, information, data, signals, or the like described herein. The processing circuitry 1001 of the FaaS platform 1000 may be configured to control the memory 1003 of the FaaS platform 1000 to store any requests, resources, information, data, signals, or the like described herein.

[0150] It should be noted that the above embodiments are illustrative and not limiting of the invention, and those skilled in the art will be able to devise many alternative embodiments without departing from the scope of the appended claims. The word "comprising" does not exclude the presence of elements or steps different from those listed in the claims, and "a" or "an" does not exclude a plurality, and a single processor or other unit may perform the functions of the plurality of units recited in the claims. Any reference numerals in the claims should not be construed as limiting their scope. < / functionname> < / functionname> < / functionname>

Claims

1. A method executed by a processing circuit in a Function as a Service (FaaS) platform to enable third-party developers to use functions in the FaaS platform, the method comprising: The feature catalog stores one or more corresponding feature descriptions associated with one or more features that can be used by third-party developers, wherein each feature description includes the intent and feature name of the corresponding feature; Receive function calls from the first function developer, including instructions on the first intent; Preprocess the source code of the function to search for keywords that indicate the function is intending to invoke a third-party function using intent invocation; as well as Select a first function description that matches the indicated first intent from the function catalog; The storage includes: Receive the source code of the second function from the second function developer; Search the source code of the second function for keywords that would make the second function available to developers of other functions; and The source code of the function in response to the second function includes the keyword, and the associated function description is stored in the function directory.

2. The method of claim 1, further comprising: The first function is invoked using the first function name in the first function description and one or more input parameters indicated in the function call; Receive output from the first function; as well as The output is transmitted to the developer of the first function.

3. The method as described in any of the preceding claims, in, The source code of the second function includes the function name and the second intent of the second function; The method further includes: The second intent is extracted from the source code of the second function, wherein the stored associated function description includes the extracted second intent and the function name; and The source code of the function in response to the second function includes the keyword, and performs the extraction and storage steps.

4. The method of claim 3, wherein, The source code for the function also includes indications of one or more input parameter types and one or more output parameter types for the second function.

5. The method of claim 4, further comprising: Extract one or more input parameter types and one or more output parameter types of the second function; as well as Add the one or more input parameter types and the one or more output parameter types of the second function to the description of the second function, and then store the description of the second function.

6. The method of claim 3, further comprising: Extract metadata related to the use of the second function from the source code of the function; as well as The metadata is added to the second function description, and then the second function description is stored.

7. The method of claim 3, wherein, The steps of storing the second functional description include: Determine whether the function catalog already includes a third function description containing the second intent; In response to determining that the feature catalog includes a third feature description containing the second intent, the second feature description is stored next to the third feature description associated with the second intent; and In response to determining that the function catalog does not include a third function description containing the second intent, the second function description associated with the second intent is stored.

8. The method of claim 3, wherein, The second intent is represented by one or more increasingly finer levels of intent.

9. The method of claim 2, wherein, The steps for selecting the first function include: Find one or more candidate function descriptions that match the first intent from the function catalog; and Select the first function description from the one or more candidate function descriptions.

10. The method of claim 9, wherein, The step of selecting the first functional description from the one or more candidate functional descriptions includes: The expected functionality of the one or more candidate function descriptions is checked by inputting the input parameters indicated in the function call into the one or more candidate functions and checking that the output returned by the one or more candidate functions has the expected output type.

11. The method of claim 9 or 10, wherein, The step of selecting the first functional description from the one or more candidate functional descriptions includes selecting the first functional description based on the following: Metadata related to the use of the corresponding function in the descriptions of the one or more candidate functions, and One or more constraints in the function call.

12. A Function as a Service (FaaS) platform for enabling third-party developers to use functionality, the FaaS platform including processing circuitry configured to: The feature catalog stores one or more corresponding feature descriptions associated with one or more features that can be used by third-party developers, wherein each feature description includes the intent and feature name of the corresponding feature; Receive function calls from the first function developer, including instructions on the first intent; Preprocess the source code of the function to search for keywords that indicate the function is intending to invoke a third-party function using intent invocation; as well as Select a first function description that matches the indicated first intent from the function catalog; The processing circuit is configured as follows: Receive the source code of the second function from the second function developer; Search the source code of the second function for keywords that would make the second function available to developers of other functions; and The source code of the function in response to the second function includes the keyword, and the associated function description is stored in the function directory.

13. The FaaS platform as described in claim 12, wherein, The processing circuit is further configured to: The first function is invoked using the first function name in the first function description and one or more input parameters indicated in the function call; Receive output from the first function; as well as The output is transmitted to the developer of the first function.

14. The FaaS platform as described in any one of claims 12 or 13, in, The source code of the second function includes the function name and the second intent of the second function; The processing circuit is further configured to: The second intent is extracted from the source code of the second function, wherein the stored associated function description includes the extracted second intent and the function name; and The source code of the function in response to the second function includes the keyword, and performs the extraction and storage steps.

15. The FaaS platform as described in claim 14, wherein, The source code for the function also includes indications of one or more input parameter types and one or more output parameter types for the second function.

16. The FaaS platform as described in claim 15, wherein, The processing circuit is further configured to: Extract one or more input parameter types and one or more output parameter types of the second function; as well as Add the one or more input parameter types and the one or more output parameter types of the second function to the description of the second function, and then store the description of the second function.

17. The FaaS platform as described in claim 14, wherein, The processing circuit is further configured to: Extract metadata related to the use of the second function from the source code of the function; and The metadata is added to the second function description, and then the second function description is stored.

18. The FaaS platform as described in claim 14, wherein, The processing circuit is configured to perform the step of storing the second functional description by the following operations: Determine whether the function catalog already includes a third function description containing the second intent; In response to determining that the feature catalog includes a third feature description containing the second intent, the second feature description is stored next to the third feature description associated with the second intent; as well as In response to determining that the function catalog does not include a third function description containing the second intent, the second function description associated with the second intent is stored.

19. The FaaS platform as described in claim 14, wherein, The second intent is represented by one or more increasingly finer levels of intent.

20. The FaaS platform as described in claim 13, wherein, The processing circuit is configured to perform the step of selecting the first function by the following operations: Find one or more candidate function descriptions that match the first intent from the function catalog; and Select the first function description from the one or more candidate function descriptions.

21. The FaaS platform as described in claim 20, wherein, The processing circuit is configured to perform the step of selecting the first functional description from the one or more candidate functional descriptions by: The expected functionality of the one or more candidate function descriptions is checked by inputting the input parameters indicated in the function call into the one or more candidate functions and checking that the output returned by the one or more candidate functions has the expected output type.

22. The FaaS platform as described in claim 20 or 21, wherein, The processing circuitry is configured to perform the step of selecting the first functional description from one or more candidate functional descriptions by selecting the first functional description based on the following: Metadata related to the use of the corresponding function in the descriptions of the one or more candidate functions, and One or more constraints in the function call.

23. A computer-readable storage medium having a computer program thereon storing instructions that, when executed on at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 11.

24. A computer program product comprising a non-transitory computer-readable medium on which a computer program is stored, the computer program comprising instructions that, when executed on at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 11.

Images