Dynamic validation of object attributes

Abstract

To provide a non-transitory computer readable medium, a system and a method capable of enhancing a programming language framework in order to accomplish dynamic validation.SOLUTION: A framework is provided for dynamic validation that allows a validator for any variable to be selected at runtime rather than statically declared at programming-time. Instead of annotating a variable with an annotation that refers to a specific validator function or constraint type, programmers can annotate a variable with an annotation that indicates that the validator function will be selected dynamically at runtime. When a runtime instance of the variable is created, the programming language framework identifies the dynamic validation annotation on the variable, and then uses the runtime values in the variable so as to determine which validator functions should be used.SELECTED DRAWING: Figure 4

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims the benefit and priority of U.S. Patent Application No. 16 / 809,025, titled "DYNAMIC VALIDATION FRAMEWORK EXTENSION", filed on March 4, 2020, which is hereby incorporated by reference in its entirety.

Background Art

[0002] Background Programming languages have recently provided advanced mechanisms for enforcing constraints on member variables, classes, and functions. Constraints may be used to verify different data fields to ensure that they meet some one or more predefined requirements. Conventionally, constraints have been enforced using customized error - checking code included throughout the software. However, modern programming languages are beginning to provide a mechanism for validating data against a set of constraints as part of the programming language framework. Instead of rewriting the constraints and validation code for each project and dataset, a programmer can instead use the constraint - enforcement mechanism of the programming language framework to improve the efficiency of software development and the consistency with which common data types can be verified.

[0003] For example, the Java programming language enforces constraints imposed on class modules or "beans". It provides validation for approximately Beans. Bean validation is defined in the JSR380 standard, which enables static validation of Java beans. Static validation ensures that the internal attributes of a bean (e.g., member variables) meet several predefined criteria, such as being non-null, non-empty, and within a specified numerical range. If these predefined criteria are not met, the framework reports a constraint violation. The validation framework also allows users to create user-defined constraints and user-defined validators. These allow users to customize various validation routines to fit their desired data formats. [Overview of the project]

[0004] overview Modern programming language frameworks provide configurations that perform static validation on runtime values ​​using predefined constraints. When a runtime instance is created, runtime values ​​stored in variables and / or member attributes may be provided to validator functions that ensure the runtime values ​​conform to predefined constraints. These predefined constraints may include numeric ranges, acceptable string patterns, date ranges, specific formatting, and / or other requirements that may be enforced on data values. To activate the constraints, the variable or member attribute may be annotated with a text string that points to a specific validator function. Thus, the validator function to be used for a particular variable is set at programming time, not runtime.

[0005] The embodiments described herein enhance the programming language framework to provide dynamic validation. Dynamic validation allows validators for any variable to be selected at runtime rather than being declared statically at programming time. Instead of annotating a variable with an annotation that points to a specific validator function or constraint type, a programmer can annotate a variable with an annotation that indicates the validator function is dynamically selected at runtime. When a runtime instance of a variable is created, the programming language framework identifies the dynamic validation annotation on the variable and then uses the runtime value in the variable to determine which validator You may decide whether a data function should be used.

[0006] The programming language framework may be modified to include additional annotation definitions. One annotation definition may be used to annotate a variable that should undergo dynamic validation as described above. Another annotation definition may be used to annotate the user-defined dynamic value validator function itself. The second annotation may receive the name and / or value of an attribute that should be dynamically validated. For example, a class definition may include two member attributes that act as key-value pairs (e.g., string key, string value). The second annotation would be "key(key)". Refer to the attribute, and the value in the "key" attribute is the phone number in this key-value pair (for example, key = It may be determined whether to indicate that "phone"; value = "571-555-1534" will be stored. An annotation used on the validator function may specify that it should be used when an attribute named "key" has the value "phone", and the code within the validator function then validates the "value" attribute to determine if it is a properly formatted phone. It can determine whether to remember the number. The "key" value is either "date" or "time". If it is trying to remember something different, such as "[...]", this validator will not be executed on this class instance. This decision is made by the framework at runtime.

[0007] When a programming language framework receives a variable annotated for dynamic validation at runtime, the framework may first perform optional conventional static validation. If static validation fails, dynamic validation may not be necessary. After static validation is complete, the programming language framework may generate a list of all available dynamic validator functions in the classpath or program directory. The list of available dynamic validators may include any custom dynamic value validator functions defined by the programmer. The framework may then iterate through the list of available dynamic value validator functions and identify any dynamic value validator function whose runtime value of the annotated variable satisfies the annotated constraints for that dynamic value validator function. Continuing the example above, the framework identifies a phone number value validator function in the classpath and compares the attributeName = "key" and attributeValue = "phone" constraints in the function annotation to the runtime value of the variable. This may be done. Then, any identified validator function may be executed against the runtime value. In some embodiments, the framework may provide an abstract base class containing protected helper functions for performing dynamic validation, which may be overridden in a custom dynamic value validator written by the programmer.

[0008] These programming language framework improvements allow programmers to encapsulate different dependencies between member attributes in different validator functions that are dynamically selected at runtime. When only static validation was used, validator functions were required to include branching if / then statements comparing different possible values. Maintenance of validations becomes difficult over time as the code evolves. However, when using dynamic validation, each variable dependency for validation can be handled separately and independently, and new dependencies can be easily added without restriction by annotating the new validator function with the added dependency.

[0009] Brief explanation of the drawing A further understanding of the nature and merits of various embodiments can be achieved by referring to the remainder of the specification and the drawings, where similar reference numbers are used to point to similar components through several drawings. In some cases, sublabels are associated with reference numbers to indicate one of several similar components. When a reference number is referred to without specifying an existing sublabel, it is intended to refer to all such several similar components. [Brief explanation of the drawing]

[0010] [Figure 1] The diagram shows constraint verification frameworks for programming languages ​​in several embodiments. [Figure 2A] This document presents examples of beans using built-in constraint annotations, using several embodiments. [Figure 2B] This shows the definition of custom validators / constraints. [Figure 3] This document presents a program for verifying constraints in a bean, using several embodiments. [Figure 4] The diagram shows a framework extension for dynamic verification through several embodiments. [Figure 5] This figure shows dynamic verification constraint annotations in several embodiments. [Figure 6] This document presents examples of beans using dynamic validation, based on several embodiments. [Figure 7] This section presents new annotations added to the framework that define relationships between dynamic values, using several embodiments. [Figure 8]An example of an abstract class for DynamicValueValidator according to some embodiments is shown. [Figure 9A] A definition for the DynamicValidator class according to some embodiments is shown. [Figure 9B] An isValid( ) function for DynamicValidator according to some embodiments is shown. [Figure 9C] A method for DynamicValidator to perform static validation and matching between metadata defined in DynamicValue annotations and corresponding beans is shown according to some embodiments. [Figure 10A] An example of a user-defined custom dynamic value validator for dynamic validation according to some embodiments is shown. [Figure 10B] An example of a custom dynamic value validator with multiple constraint annotations according to some embodiments is shown. [Figure 11] An example of a program where dynamic validation may be called according to some embodiments is shown. [Figure 12] A flowchart of a method for dynamically validating variable dependencies at runtime according to some embodiments is shown. [Figure 13] A simplified block diagram of a distributed system for implementing some of the embodiments is shown. [Figure 14] A simplified block diagram of the components of a system environment where services provided by the components of the embodiment system may be provided as cloud services is shown. [Figure 15] A diagram showing an exemplary computer system in which various embodiments may be implemented.

Best Mode for Carrying Out the Invention

[0012] Constraints generally consist of two separate parts. The first part of the constraint includes constraint annotations, which are annotations that may be added to the code to identify runtime constraints. Generic constraint annotations may target fields, methods, constructors, parameters, types, etc. The second part of the constraint may include a set of validators that implement the constraint. For example, the constraint may include an acceptable numerical range for a member variable, and the validator may include an isValid() function that contains code to determine whether the runtime value of the member variable falls within the acceptable numerical range. Thus, the constraint annotation and its validator for the constraint annotation work together to perform runtime validation of the constraints against program data.

[0013] Figure 1 shows Figure 100 of constraint validation frameworks 102 for programming languages ​​in several embodiments. In computer programming, a software framework is an abstraction that provides general-purpose functionality and can be extended by user code. Framework 102 generally provides standardized libraries and methods for building and deploying applications and may provide functionality that is part of a larger software platform to facilitate the development of software applications. For example, framework 102 may include support programs, compilers, code libraries, toolsets, application programming interfaces (APIs), and other components or development environments. For example, the Java programming language may be combined with various frameworks that provide utilities, programming language features, and code libraries that may be used to implement constraint validation. As used herein, framework 102 itself may be distinguished from user code or custom, user-defined validators and constraint annotations.

[0014] User program 106 may include user code that is compiled, assembled, interpreted, and / or executed as a software application. For example, program 106 may include a main() function that instantiates class objects, executes functions, stores variables, and / or implements various aspects of a software application in other ways. Program 106 may be considered user code. Furthermore, it may be distinguished from framework 102. In addition, user code may include one or more custom class / object definitions. In the Java programming language, these classes may be organized into a package called "beans". Program 106 instantiates a runtime object using the class definition in bean 108. That's good too.

[0015] As is common in many class definitions, the class in bean108 may include member variables, member functions, and other data. Constraint annotation 110 may be added to the class definition in bean108 at various locations. The scope of annotation 110 may vary based on the location of annotation 110 and / or the definition of the corresponding constraint annotation definition. As illustrated in the following example, annotation 110 may typically include a line of code that identifies the constraint and provide values ​​for the constraint, such as messages and / or other information that may be used when validating the constraint.

[0016] To verify constraints, a validator may be executed by program 106. In some cases, the framework 102 may include one or more built-in validators 104. A built-in validator may include code that validates a set of built-in constraint definitions. For example, some Java frameworks have built-in support for simple constraints. It may include constraints. The javax.validation.constraints package includes built-in constraints such as minimum / maximum values, null / non-null values, predefined regular expression patterns, and predetermined sizes. bean108 may utilize these built-in validators / constraints 104 by simply adding the corresponding annotation 110 to the bean108 code.

[0017] In addition to using the built-in validators / constraints 104, program 106 may also use custom validators / constraints 112. User-defined validator definitions and / or constraint definitions may be provided to program 106 for the use of custom validators and / or custom constraints. Each custom validator / constraint 112 may implement a predefined interface and / or abstract class provided by framework 102 so that the custom validators / constraints 112 can be executed by framework 102 in the same way that the built-in validators / constraints 104 are used at runtime.

[0018] Figure 2A shows an example of bean 108 using built-in constraint annotation 110 in several embodiments. This bean includes the definition of a public class that encapsulates a key-value data structure. Many modern data structures use this paradigm to store many different data types in a unified format. A general-purpose format may use a key-value structure in which data is stored as key-value pairs. The key portion of a pair may be used to describe the data type (or any other type of metadata) relating to the value portion of the pair. For example, the key portion of a pair may define a data type such as a phone number, address, or username. The corresponding value portion of the pair may include a specific phone number, a specific address, or the name of a specific user. This flexible system allows any type of data to be stored, as long as the key defines the data type and the value defines the data value. This KeyValue class may be used herein as an example of a bean that may use dynamic validation as described below. However, this class is used only as an example and is not meant to be limiting. Dynamic validation may be used with any data structure, including classes and other encapsulations of data.

[0019] bean108 may contain private member variables for both key and value. The example in Figure 2A includes constraint annotation 110, which may be used to validate the value of a string. Some built-in constraints in some Java frameworks may include the @NotBlank constraint, which indicates that the string value in the key variable should not be blank. Annotation 110 includes a parameter that sets the message associated with a constraint violation to a specified value, such as "key is blank". Instead of writing custom validation code, users can enforce predefined constraints that can be automatically validated by the framework's functionality without writing any additional code, simply by including constraint annotation 110.

[0020] In addition to using built-in constraints, programming language frameworks may also allow users to define their own custom constraint annotations and custom validators to validate those constraints. Figure 2B shows a definition of a custom validator / constraint 112. First, an example of a constraint definition 220 is provided that allows users to define their own constraint annotations. The constraint definition 220 may specify the targets (e.g., fields, methods, types, etc.) to which the constraint may apply. The constraint definition 220 may also include message, group, and / or payload fields. Other fields may be added to provide information or other settings that may enhance validation. For example, the message field may be used to create an error message that may be overridden by parameters, as shown in Figure 2A. The group field specifies the group to which the constraint belongs. A loop may be defined. The payload field may specify other data to which the constraint may be associated. For example, the payload may be used to associate severity with the constraint.

[0021] Along with the constraint definition 220, a validator definition 222 is also provided to specifically verify the constraints of the constraint annotation definition 220. In the context of the Java programming language, the validator definition 222 may implement the ConstraintValidator interface, and two public You may override the function. The initialize() function receives data from constraint annotations. It may also be used to initialize the validator. The isValid() function holds the code used to validate the corresponding constraint against the corresponding object. If an annotation to constraint definition 220 is used on a target object corresponding to the object type in validator definition 222, the constraint may be validated. In some cases, validator definition 222 may be defined inclusively such that the target class is of type Object. In this case, the framework calls user-defined validation code for all targets annotated with the constraint. For example, validator definition 222 may validate all target beans annotated with the @MyConstraint constraint that have a certain type MyObject. Validator definition 222 validates the runtime values ​​of attributes within the object. Please note that you cannot make a selection based on this.

[0022] Figure 3 shows a program 106 that validates constraints in bean 108 in several embodiments. First, program 106 instantiates a validator 302 of default type. Next, program 106 defines a validate() function 308 that performs validation on a specified list of objects in the parameter list. The main() function of Ram106 then takes the specified strings for the key and value attributes. A new KeyValue object is instantiated. This instantiated object is then passed to the validation function as parameter 306. The validation function 308 then runs the specified validator on the object and reports any constraint violations.

[0023] Users may define custom validators and constraints within existing programming language frameworks, but the embodiments described herein improve upon existing programming language frameworks to provide a mechanism for validating dependencies between attributes through the framework based on runtime values. These improvements make it easier to implement custom validators and constraints that provide deep validation where the value for one attribute may influence the type of constraint on which that value is validated. For example, if the value for a key in a KeyValue object contains the string value "phone", the user can define that... To ensure that a string is a properly formatted phone number, one might want to validate it in its value attribute. In another example, if the key is "date", the user might want to validate its value to ensure that the string is a properly formatted date. This cannot be done with static validation because only a single value of the target is validated. And while the user can validate relationships by defining their own constraints and providing validation code, the user would need to define a new combination of constraints and validators for each relationship in the target. This code is extremely difficult to maintain and extremely difficult to parse. The embodiments described herein describe extensions to a validation framework that solve this problem in a comprehensive manner, rather than requiring specific code for each relationship.

[0024] Figure 4 shows Figure 400 of framework extensions for dynamic validation by several embodiments. Figure 400 shows that framework 102 has several additional modules, namely dynamic validation annotations 402, dynamic validators 404, dynamic value annotations 406, and dynamic value validators. Figure 1 is similar to Figure 100, except that it has been extended to include data 408. Each of these modules is described in more detail below. In short, these modules enable the framework to handle the @DynamicValidation annotation and then dynamically validate different relationships between different data fields based on runtime values, such as the relationship between keys and values ​​in the KeyValue class described above. Note that these modules are part of the programming language framework and are not user-defined classes that the user is required to write. They are modules that may be deployed with framework 102 and may therefore be distinguished from code that the user may write to interact with framework 102.

[0025] In this example, bean416 may include dynamic annotations 410, such as the @DynamicValidation annotation, which will be described in detail below. When program 414 creates an instance of an object defined in bean416, the dynamic annotation 410 instructs framework 102 to perform dynamic validation using a custom dynamic value validator 412 defined by the user. As described below, the custom dynamic value validator 412 may extend an abstract base class that is made available in extensions to framework 102, thus minimizing the amount of code that the user may be required to write.

[0026] Figure 5 shows dynamic validation constraint annotations in several embodiments. The starting point for dynamic validation is the definition of a constraint annotation and its corresponding validator. Dynamic validation constraint definition 402 defines an annotation that may be added to a class to indicate to the framework that dynamic validation should be performed rather than conventional validation. Since dynamic validation may be used to evaluate relationships between different member variables of a class, constraint definition 402 sets the target value to TYPE, which allows access to all attributes within the object definition. The name given to this constraint definition 402 is DynamicValidation(@DynamicValidation annotation (corresponding). However, this name is used only as an example and is not intended to be limiting. Any other name may be used for dynamic validation constraint definition 402. In some embodiments, it is not necessary to define a default message 502 with the annotation. Any message defined within this annotation may be omitted and replaced during validation by the validator, as described below. It should also be noted that definition 502 specifies that this constraint may be validated by the DynamicValidator class, the name of which is merely illustrative, and its functionality is described in detail below.

[0027] Figure 6 shows an example of bean 416 using dynamic validation in several embodiments. Using the definition described above in Figure 5, the KeyValue class may be annotated with the @DynamicValidation constraint annotation. This allows the framework to invoke a validator that dynamically evaluates the relationship between the runtime values ​​of the key and value member attributes. Note that since the target value of the dynamic validation constraint definition 402 is TYPE, the dynamic annotation 410 may be applied at the class level rather than at the individual member variable level. This dynamic annotation 410 based on the dynamic validation constraint definition 402 may be added in a similar position to any bean that should invoke dynamic validation.

[0028] Figure 7 shows a new annotation added to the framework that defines relationships between dynamic values, in several embodiments. As will be described in detail below, this annotation may be used for a custom dynamic value validator to indicate runtime attribute values ​​that may cause the validator to invoke. Specifically, Figure 7 shows a dynamic value annotation definition 406 that defines relationships between values. This particular annotation has two methods, namely, attributeName and includes valuePattern. The attributeName method checks if the value is in the target bean. Returns the name of the attribute to be checked. The valuePattern method returns a regular expression for checking the value. This annotation is from DynamicValueValidator, which is explained in detail below. It may be used on an instance. This extension is a relational definition defined with @DynamicValue. This ensures that only beans that satisfy the condition need to be validated further. In addition, this annotation may be used multiple times on a target DynamicValueValidator instance to allow the user to define multiple relationships. For example, if there are more @DynamicValue annotations on a DynamicValueValidator, these relationships defined by the annotations can be further validated. Each of these can be further examined.

[0029] Figure 8 shows examples of abstract classes for DynamicValueValidator in several embodiments. This demonstrates that, first, it should be noted that the DynamicValueValidator class is an abstract class. This means that any custom dynamic value validator class defined by the user should extend DynamicValueValidator408, and that extension should be annotated with at least one of the aforementioned @DynamicValue annotations. This abstract class may be patterned after the javax.validation.ConstraintValidator abstract class in some Java frameworks, which is extended by regular user-defined validators.

[0030] Each validator that extends the DynamicValueValidator class has an isValid() method 802 An example of its implementation should be provided. This method checks the relationship defined with @DynamicValue. If the validated bean is satisfied, it may be called by the extended class. Specifically, the code to provide the actual validation may be provided in the isValid() function in the custom dynamic value validator, where this abstract function is overridden in the abstract base class.

[0031] Furthermore, DynamicValueValidator408 includes two protected methods, namely validateCustomConstraints()804 and useConstraint()806, which are used by - May be used to simplify the definition validator. validateCustomConstraints( Method 804 may be used in user-generated validators when it defines that its own object should be statically validated. One of the core concepts behind validation is that the validator defines its own inner class which has attributes annotated with constraints. These attributes are then populated with data from the bean being validated. An instance of the class is then passed to the validateCustomConstraints() method 804. If this method 804 identifies a constraint violation in the validated object, it takes a first message from that violation, passes it to ConstraintValidationContext, and returns false. Helper method useConstraint() 8 Function 06 may be used to provide a user-defined message when the user identifies a failed deep validation of a bean (for example, the user validates whether they can open a connection to a provided URL). Both of these functions may be called by custom dynamic value validators written by the user that extend this class. As part of a framework extension, these functions reduce the amount of code required to write custom dynamic value validators.

[0032] Figure 9A shows the definition for the DynamicValidator404 class in several embodiments. DynamicValidator implements the ConstraintValidator template already defined in the framework. Importantly, DynamicValidator404 performs dynamic validation. It serves as an entry point to framework extensions added by the embodiments described herein in order to be executed. This class first creates a validator for checking statically defined constraints, creates a list of dynamic validators to be loaded from a classpath scan, and creates a static instance of VALIDATOR. DynamicValidator is responsible Note that it can be used for any type of bean. ConstraintValidator Once an instance of it is created, it will extend the aforementioned DynamicValueValidator in a way that allows it to do so. Load the class. Constructor 902 is called DynamicVal according to the code in Figure 9A. An instance of the idator is created. Specifically, if any of the dynamic validators in the classpath have not yet been instantiated, they are loaded and instantiated synchronously. As shown in Figure 9A, the code filters out any abstract classes, classes without argumentless constructors, and classes that do not have at least one correct @DynamicValidation annotation. Each of these classes is then instantiated and cached. Some embodiments may use a full classpath scan, while others use Contexts and Dependency Injection. Using (CDI), a DynamicValueValidator with the @DynamicValidation annotation... All instances may be retrieved. If CDI is used, user-defined dynamic bean validators should define their scopes to be visible to CDI lookups. This approach may be preferred in Java EE environments.

[0033] Figure 9B shows the isValid() function 910 for DynamicValidator in several embodiments. As soon as the isValid() method 910 is called in DynamicValidator 404, it may perform validation of statically defined constraints within the bean (912). Dynamic validation may not be necessary if static constraints are violated, and therefore isValid() The method may return and terminate. Statically defined constraints may, in some embodiments, have a higher priority than dynamically defined constraints. Alternatively, if there are no constraint violations in the statically defined constraints, dynamic validation may be initiated. The list of dynamic validators populated in constructor 902 above is filtered to check for validators defined for this particular type of bean and satisfying the relationship defined in @DynamicValue. You may find the data (914). Note that if the attribute does not have type String, the toString() method may be called to get the string representation of the attribute. Then, lastly, any validators that satisfy these conditions may be passed to their respective isValid() methods (916).

[0034] Figure 9C shows, in several embodiments, how DynamicValidator performs static validation and matching between metadata defined in a DynamicValue annotation and the corresponding bean. The isStaticValid() function 920 may perform validation for all properties found in the current class and recursively in any parent class. This private function 920 is called in Figure 9B above to first determine whether any static validation has failed before performing any dynamic validation. The matchDynamicAnnotation() function 922 may perform matching between metadata defined in a DynamicValue annotation and the bean. This private member function is called in the annotation. The function may return true if the defined data matches the data found in the bean. This function 922 is called above in Figure 9B when filtering out dynamic validators that do not have the specified relational conditions.

[0035] Figures 7–9C illustrate implementations of various modules that may be included in a framework extension to perform dynamic verification, according to several embodiments. These exemplary modules may provide implementable disclosures using the Java programming language and specific Java constructs as examples. However, these examples are not intended to be limiting. The principles for extending the framework to provide dynamic verification may be applied to any programming language and may have different implementations other than those specifically used as examples in these figures.

[0036] Figure 10A shows examples of user-defined custom dynamic value validators 412 for dynamic validation in several embodiments. The custom dynamic value validator 412 may be the only code that needs to be written by the user to employ dynamic validation. First, the validator 412 should contain one or more instances of the @DynamicValue annotation 1002. Validator 412 also uses the DynamicValueValidator abstraction described in Figure 8 above. The class should be extended (1004). This extended class provides an implementation for the abstract isValid() function 1006 from the parent class. Some embodiments may also provide a private helper function to perform validation.

[0037] The dynamic @DynamicValue annotation 1002 specifies the variable that triggers this dynamic validation and the variable Specify a value. In this example, the target object contains a variable with the attribute name "key". Dynamic validation is triggered when the value of that attribute contains a string with the text “phone number” as shown in annotation 1002. Validator 412 extends the DynamicValueValidator abstract parent class, in particular for objects of the KeyValue type described above in Figures 2A and 6 (1004). isValid() takes a target KeyValue object and then validates the phone number using the private PhoneNumber class. At this point, the variable value in the KeyValue target object is expected to validate a valid phone number because the key variable dynamically indicates so. Note that if the value of the attribute in the KeyValue object does not match the value in the annotation of custom dynamic value validator 412, the validator will not run on the instance of that object.

[0038] Figure 10B shows an example of a custom dynamic value validator with multiple constraint annotations in several embodiments. The example in Figure 10A uses only a single @DynamicValue annotation, but others An example implementation may use multiple @DynamicValue annotations. For example, the KeyValue class mentioned above. This includes a single key in a single value. Another embodiment includes a TwoKeyValue class that includes two keys and a single value. The first key (key1) is still a phone number. The first key (key2) may be used to specify the country code. Since each country may have a different format for its phone number, both keys may be included separately in the @DynamicValue annotation 1010 for this particular custom dynamic value validator 412 to be invoked. The extension (1012) is done using the TwoKeyValue class instead of the KeyValue class. Except for the fact that it can behave the same as the validator in Figure 10A, it can also behave the same way. Similarly, the isValid() function 1014 accepts a TwoKeyValue object instead of a KeyValue object. You may take it.

[0039] Figure 11 shows an example of program 414 in which dynamic validation may be invoked, according to several embodiments. As mentioned above in relation to Figure 6, the KeyValue class is annotated with the @DynamicValidation constraint. When a new instance 1104 of the KeyValue class is created, string values ​​may be provided for the key and value attributes. In this example, the key is set to "phone", which is eligible for the custom dynamic value validator 412 in Figure 10. The `validate()` function is called to dynamically check the key value ("phone"), and a custom action is performed. You may call the value validator 412 to ensure that the telephone number given in the value attribute is in the correct format.

[0040] Figure 12 shows flowchart 1200 of a method for dynamically verifying variable dependencies at runtime in several embodiments. This method may include receiving an instance of an object in a programming language framework (1202). The instance of the object may be instantiated from an object definition. For example, a class object may be instantiated based on a class definition file. The class definition may be part of a bean or other software module. The definition of an object, such as a class definition, may be annotated with constraints. The constraints may indicate that the instance of the object should undergo dynamic verification rather than static verification or other forms of custom user-defined verification routines. Dynamic verification is performed on the object It may be implied that certain types of validation routines and constraints applied to an instance depend on mutable runtime values ​​in the object instance. For example, the @DynamicValidation constraint annotation may be used on a class definition as shown in Figure 6. An instance of an object (e.g., a KeyValue object) may be instantiated and passed to the framework as part of a validation function, as shown in Figure 3.

[0041] The method may also include receiving one or more validators that are annotated with annotations that identify attributes in the definition of an object and the values ​​of those attributes (1204). For example, the custom dynamic value validators in Figures 10A and 10B can be annotated using the @DynamicValue annotation from Figure 7. The annotation identifies attributes in the definition of an object. The attribute name that identifies the attribute may be included along with the corresponding value of that attribute. For example, the attribute may be identified by an attribute name such as "key", and the value may include a value string such as "phone number" as used in the example above. The validator is an abstraction of the framework. When extending the class, it may be received by the framework. The validator may also implement a Boolean function (e.g., the isValid() function) that returns an indication of whether the value passed the constraint. The validator may include user-defined code that implements constraints such as format, minimum, maximum, range, and / or any other variable constraints.

[0042] The method may also include identifying one or more validators whose attribute values ​​in an object instance match the attribute values ​​in an annotation (1206). For example, the DynamicValidator class in Figure 9A may identify all validators in the runtime path or otherwise associated with the program. The constructor for DynamicValidator may then iterate through each of the available validators and identify validators whose annotations (e.g., DynamicValue parameters) match the values ​​of the corresponding attributes in an object instance. In some embodiments, each validator may have more than one (i.e., multiple) DynamicValue annotations, each of which may be satisfied to execute the validator on an object instance.

[0043] This method may further include running validators using an instance of an object (1208). Identified validators may run on an instance of an object along with any other validators that meet the annotation criteria. For example, an attribute value may be validated against a constraint, which may be selected based on the value of another attribute, thus allowing attribute dependencies to influence which validators are run and the results of those validators.

[0044] It should be understood that the specific steps illustrated in Figure 12 provide a particular method for performing dynamic verification according to various embodiments. Other sequences of steps may also be performed according to alternative embodiments. For example, alternative embodiments may perform the steps outlined above in a different order. Furthermore, the individual steps shown in Figure 12 may include multiple substeps that may be performed in various sequences as needed for the individual steps. In addition, additional steps may be added or removed depending on the specific application.

[0045] Each of the methods described herein may be implemented by a computer system. Each step of these methods may be performed automatically by the computer system and / or inputs / outputs involving a user may be provided. For example, a user may provide inputs to each step of a certain method, each of which may respond to a specific output requesting such input, which is generated by the computer system. Each input may be received in response to the corresponding requesting output. Furthermore, inputs may be received from the user as a data stream from another computer system, retrieved from a memory location, retrieved over a network, etc. It may also be requested from a web service. Similarly, the output may be provided to the user as a data stream to another computer system, stored in a memory location, transmitted over a network, or provided to a web service. In short, each step of the methods described herein may be performed by a computer system and may include any number of inputs, outputs, and / or requests to and from the computer system, with or without user involvement. Steps without user involvement may be said to be performed automatically by the computer system without human intervention. Thus, in light of this disclosure, it will be understood that each step of each method described herein may be modified to include inputs to and outputs from the user, or may be performed automatically by the computer system without human intervention, if any decisions are made by the processor. Furthermore, some embodiments of each of the methods described herein may be implemented as a set of instructions stored on a tangible non-temporary storage medium to form a tangible software product.

[0046] Figure 13 shows a simplified diagram of a distributed system 1300 for realizing one embodiment. In the illustrated embodiment, the distributed system 1300 includes one or more client computing devices 1302, 1304, 1306, and 1308, which are configured to run and operate client applications such as web browsers and owned clients (e.g., Oracle Forms) over one or more networks 1310. A server 1312 may be coupled to communicate with the remote client computing devices 1302, 1304, 1306, and 1308 over the network 1310.

[0047] In various embodiments, the server 1312 may be adapted to run one or more services or software applications provided by one or more components of the system. In some embodiments, these services may be provided to users of client computing devices 1302, 1304, 1306, and / or 1308 as web-based services or cloud services, or under a software-as-a-service (SaaS) model. Users operating client computing devices 1302, 1304, 1306, and / or 1308 may then interact with the server 1312 using one or more client applications to use the services provided by these components.

[0048] In the configuration shown in the figure, software components 1318, 1320, and 1322 of system 1300 are shown as being implemented on server 1312. In other embodiments, one or more components of system 1300 and / or services provided by these components may be implemented by one or more client computing devices 1302, 1304, 1306, and / or 1308. Users operating the client computing devices may then use one or more client applications to access the services provided by these components. These components may be implemented in hardware, firmware, software, or a combination thereof. It should be understood that a variety of different system configurations are possible, which may differ from the distributed system 1300. The embodiment shown in the figure is therefore an example of a distributed system for implementing the system of the embodiment and is not intended to be limiting.

[0049] Client computing devices 1302, 1304, 1306 and / or 1308 are portable handheld devices (e.g., iPhone®, cellular phones, iPad®, computing tablets, personal digital assistants (PDAs)). ) or wearable devices (for example, Google Glass® head-mounted display), software such as Microsoft Windows Mobile®, and / or various operating systems such as iOS, Windows Phone, Android, BlackBerry 10, Palm OS It runs a mobile operating system and has enabled communication protocols such as the Internet, email, Short Message Service (SMS), Blackberry®, or other communication protocols. The client computing device can be a general-purpose personal computer, for example, running Microsoft Windows®, Apple Macintosh®, and / or Linux® operating systems. This includes personal computers and / or laptop computers running various versions. Client computing devices include various GNU / Linux® operating systems, such as Google® Chrome OS, for example. This may be a workstation computer running any of the various commercially available UNIX® or UNIX-like operating systems, but is not limited to these. Alternatively, or in addition, the client computing devices 1302, 1304, 1306, and 1308 may be any other electronic devices capable of communicating over the network 1310, such as thin client computers, internet-enabled gaming systems (e.g., Microsoft Xbox game consoles with or without Kinect® gesture input devices), and / or personal messaging devices.

[0050] The illustrated distributed system 1300 is shown with four client computing devices, but any number of client computing devices may be supported. Other devices, such as devices with sensors, may interact with the server 1312.

[0051] Network 1310 within distributed system 1300 includes, but is not limited to, TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (System Network Architecture), IPX (Internet Packet Switching), AppleTalk, and others. It may be any type of network that can support data communication using any of the various commercially available protocols. For example, network 1310 may be a local area network (LAN), such as one based on Ethernet®, Token Ring, etc. Network 1310 may be a wide area network or the Internet. It may also be a virtual private network (VPN), intranet, extranet, public switched telephone network (PSTN), infrared network, wireless network (e.g., IEEE 802.11 protocol suite, Bluetooth®, and / or any other wireless protocol). Virtual networks may include, but are not limited to, networks operating under either of these; and / or any combination of these and / or other networks.

[0052] Server 1312 may consist of one or more general-purpose computers, dedicated server computers (including, for example, PC (personal computer) servers, UNIX® servers, midrange servers, mainframe computers, rack-mount servers, etc.), server farms, server clusters, or any other suitable configuration and / or combination. In various embodiments, Server 1312 may be adapted to run one or more services or software applications as described in the foregoing disclosure. For example, Server 1312 may correspond to a server for performing the processing described above in accordance with a certain embodiment of this disclosure.

[0053] Server 1312 is an operating system including any of the above, and Server 1312 may run any market-available server operating system. Server 1312 may also run any of a variety of other server applications and / or middle-tier applications, including HTTP (Hypertext Transfer Protocol) servers, FTP (File Transfer Protocol) servers, CGI (Common Gateway Interface) servers, Java® servers, database servers, etc. Exemplary database servers include, but are not limited to, those available on the market from Oracle, Microsoft, Sybase, IBM® (International Business Machines), and others.

[0054] In some implementations, server 1312 may include one or more applications for analyzing and organizing data feeds and / or event updates received from users of client computing devices 1302, 1304, 1306, and 1308. For example, the data feeds and / or event updates may include real-time events related to sensor data applications, financial stock market boards, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automotive traffic monitoring, etc., received from one or more third-party sources and continuous data streams, such as Twitter®. The feed may include, but is not limited to, a feed, Facebook® updates, or real-time updates. Server 1312 may also include one or more applications for displaying the data feed and / or real-time events via one or more display devices of client computing devices 1302, 1304, 1306, and 1308.

[0055] The distributed system 1300 may also include one or more databases 1314 and 1316. Databases 1314 and 1316 may reside in various locations. For example, one or more of databases 1314 and 1316 may reside on a non-temporary storage medium local to (and / or resident of) server 1312. Alternatively, databases 1314 and 1316 may be remote from server 1312 and communicate with server 1312 via a network-based connection or a dedicated connection. In one embodiment, databases 1314 and 1316 may reside within a storage area network (SAN). Similarly, any necessary files for performing functions attributable to server 1312 may be stored locally on server 1312 and / or remotely, as appropriate. In one embodiment, databases 1314 and 1316 may include relational databases, such as Oracle databases, adapted to store, update, and retrieve data in response to SQL-formatted commands.

[0056] Figure 14 is a simplified block diagram of one or more components of a system environment 1400 that may provide services provided by one or more components of the system of the embodiment as cloud services, according to one embodiment of the present disclosure. In the illustrated embodiment, the system environment 1400 includes one or more client computing devices 1404, 1406, and 1408 that may be used by a user to interact with a cloud infrastructure system 1402 that provides cloud services. The client computing devices may be configured to run client applications such as a web browser, an intellectual property-owned client application (e.g., Oracle Forms), or any other application, which may be used by a user of the client computing device to interact with the cloud infrastructure system 1402 to use services provided by the cloud infrastructure system 1402.

[0057] It should be understood that the illustrated cloud infrastructure system 1402 may have components other than those shown. Furthermore, the embodiment shown in the figure is only one example of a cloud infrastructure system that may incorporate certain embodiments. In some other embodiments, the cloud infrastructure system 1402 may have more or fewer components than shown in the figure, may combine two or more components, or may have different configurations or arrangements of components.

[0058] Client computing devices 1404, 1406, and 1408 may be similar to those described above for 1302, 1304, 1306, and 1308.

[0059] An exemplary system environment 1400 is shown with three client computing devices, but any number of client computing devices may be supported. Other devices, such as devices with sensors, may interact with the cloud infrastructure system 1402.

[0060] Network 1410 may facilitate data communication and exchange between clients 1404, 1406, and 1408 and the cloud infrastructure system 1402. Each network may be any type of network that can support data communication using any of the various commercially available protocols, including those described above for network 1310.

[0061] The cloud infrastructure system 1402 may include one or more computers and / or servers, which may include the ones described above for server 1312.

[0062] In one embodiment, the services provided by the cloud infrastructure system may include hosting services that are made available on demand to users of the cloud infrastructure system, such as online data storage and backup solutions, web-based email services, hosted office suites and document collaboration services, database processing, and managed technical support services. The services provided by the cloud infrastructure system can be dynamically scaled to meet the needs of its users. A specific instance of a service provided by the cloud infrastructure system is referred to herein as a “service instance.” Generally, any service made available to users from a cloud service provider’s system via a communication network such as the Internet is referred to as a “cloud service.” Typically, in a public cloud environment, the servers and systems that make up the cloud service provider’s system are different from the customer’s own on-premises servers and systems. For example, the cloud service provider’s system may host applications, and users may order and use those applications on demand via a communication network such as the Internet.

[0063] In some examples, services within a computer network cloud infrastructure may include secure computer network access to storage, hosted databases, hosted web servers, software applications, or other services provided to users by the cloud vendor or known in the art. For example, a service may include password-protected access to remote storage on the cloud over the internet. Another example is a web service-based hosted relational database and networked It could include a scripting language middleware engine for private use by the developer. As another example, the service could include access to an email software application hosted on a cloud vendor's website.

[0064] In one embodiment, the cloud infrastructure system 1402 may include a set of application, middleware, and database service offerings that are self-service, subscription-based, flexibly scalable, reliable, highly available, and delivered to customers in a secure manner. An example of such a cloud infrastructure system is the Oracle Public Cloud offered by the Assignee.

[0065] In various embodiments, the cloud infrastructure system 1402 may be adapted to automatically provision, manage, and track customer subscriptions to services provided by the cloud infrastructure system 1402. The cloud infrastructure system 1402 may provide cloud services through different deployment models. For example, the services may be provided under a public cloud model, where the cloud infrastructure system 1402 is owned by an organization that sells cloud services (e.g., owned by Oracle), and the services are made available to the general public or different industry companies. As another example, the services may be provided under a private cloud model, where the cloud infrastructure system 1402 operates only for a single organization and provides services to one or more entities within that organization. The cloud services may also be provided under a community cloud model, where the cloud infrastructure system 1402 and the services provided by the cloud infrastructure system 1402 are shared by several organizations within a relevant community. The cloud services may also be provided under a hybrid cloud model, which is a combination of two or more different models.

[0066] In some embodiments, the services provided by the cloud infrastructure system 1402 may include one or more services provided under the categories of Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), or other categories of services including hybrid services. A customer may order one or more services provided by the cloud infrastructure system 1402 through a subscription order. The cloud infrastructure system 1402 then performs processing to provide the services in the customer's subscription order.

[0067] In some embodiments, the services provided by the cloud infrastructure system 1402 may include, but are not limited to, application services, platform services, and infrastructure services. In some examples, application services may be provided by the cloud infrastructure system via a SaaS platform. The SaaS platform may be configured to provide cloud services that fall under the SaaS category. For example, the SaaS platform may provide the ability to build and deliver a set of on-demand applications on an integrated development and deployment platform. The SaaS platform may manage and control the underlying software and infrastructure for providing the SaaS services. By using the services provided by the SaaS platform, customers can utilize applications that run on the cloud infrastructure system. Customers can obtain application services without having to purchase separate licenses and support. A variety of different SaaS services may be provided. Examples include sales performance management, enterprise Services that provide solutions for business integration and business flexibility for large organizations include, but are not limited to, business integration.

[0068] In some embodiments, platform services may be provided by a cloud infrastructure system via a PaaS platform. The PaaS platform may be configured to provide cloud services that fall under the PaaS category. Examples of platform services may include, but are not limited to, services that enable an organization (such as Oracle) to integrate existing applications on a shared common architecture, and the ability to build new applications that leverage the shared services provided by the platform. The SaaS platform may manage and control the underlying software and infrastructure for providing SaaS services. Customers can obtain PaaS services provided by the cloud infrastructure system without having to purchase separate licenses and support. Examples of platform services include, but are not limited to, Oracle Java Cloud Service (JCS) and Oracle Database Cloud Service (DBCS).

[0069] By utilizing the services provided by the PaaS platform, customers can adopt programming languages ​​and tools supported by the cloud infrastructure system and also control the deployed services. In some embodiments, the platform services provided by the cloud infrastructure system may include database cloud services, middleware cloud services (e.g., Oracle Fusion Middleware services), and Java cloud services. In one embodiment, the database cloud service may support a shared services deployment model that enables an organization to pool database resources and provide customers with databases as a service in the form of a database cloud. Middleware cloud services may provide a platform for customers to develop and deploy various business applications, and Java cloud services may provide a platform for customers to deploy Java applications on the cloud infrastructure system.

[0070] Various different infrastructure services may be provided by IaaS platforms within a cloud infrastructure system. Infrastructure services facilitate the management and control of underlying computing resources such as storage, networking, and other basic computing resources for customers using services provided by SaaS and PaaS platforms.

[0071] In one embodiment, the cloud infrastructure system 1402 may also include infrastructure resources 1430 for providing resources used to provide various services to customers of the cloud infrastructure system. In one embodiment, the infrastructure resources 1430 may include a pre-integrated and optimized combination of hardware such as servers, storage, and networking resources to run services provided by the PaaS platform and SaaS platform.

[0072] In some embodiments, resources in the cloud infrastructure system 1402 may be shared by multiple users and dynamically reallocated according to demand. In addition, resources may be allocated to users in different time zones. For example, the cloud infrastructure system 1430 may allow a first set of users in a first time zone to use the resources of the cloud infrastructure system for a specified number of hours. It may be possible to make the resource available and then reallocate the same resource to a different group of users in different time zones, thereby maximizing resource utilization.

[0073] In one embodiment, several internal shared services 1432 may be provided that are shared by different components or modules of the cloud infrastructure system 1402 and by the services provided by the cloud infrastructure system 1402. These internal shared services may include, but are not limited to, security and identity services, integration services, enterprise repository services, enterprise manager services, virus scanning and whitelisting services, high availability, backup and recovery services, services to enable cloud support, email services, notification services, and file transfer services.

[0074] In certain embodiments, the cloud infrastructure system 1402 may provide comprehensive management of cloud services (e.g., SaaS, PaaS, and IaaS services) within the cloud infrastructure system. In one embodiment, the cloud management functionality may include the ability to provision, manage, and track customer subscriptions received by the cloud infrastructure system 1402.

[0075] In one embodiment, as shown in the figure, the cloud management functionality may be provided by one or more modules, such as an order management module 1420, an order orchestration module 1422, an order provisioning module 1424, an order management and monitoring module 1426, and an identity management module 1428. These modules may include, or be provided using, one or more computers and / or servers, which may be general-purpose computers, dedicated server computers, server farms, server clusters, or any other suitable configuration and / or combination.

[0076] In exemplary operation 1434, a customer using a client device such as client device 1404, 1406, or 1408 may interact with the cloud infrastructure system 1402 by requesting one or more services provided by the cloud infrastructure system 1402 and placing an order for a subscription to one or more services provided by the cloud infrastructure system 1402. In one embodiment, the customer may access a cloud user interface (UI), cloud UI 1412, cloud UI 1414, and / or cloud UI 1416 and place a subscription order through these UIs. The order information received by the cloud infrastructure system 1402 in response to the customer placing an order may include information identifying the customer and one or more services provided by the cloud infrastructure system 1402 that the customer intends to subscribe to.

[0077] After an order is placed by the customer, the order information is received via the cloud UI 1412, 1414, and / or 1416.

[0078] In operation 1436, the order is stored in the order database 1418. The order database 1418 may be one of several databases operated by the cloud infrastructure system 1418 and operated in conjunction with other system elements.

[0079] In operation 1438, order information is transferred to the order management module 1420. In some examples, the order management module 1420 verifies the order and, once verified, records the order. It may be configured to perform billing and accounting functions related to orders, such as [example of configuration].

[0080] In operation 1440, information about the order is communicated to the order orchestration module 1422. The order orchestration module 1422 may use the order information to orchestrate the provisioning of services and resources for the order placed by the customer. In some examples, the order orchestration module 1422 may use the services of the order provisioning module 1424 to orchestrate the provisioning of resources to support the subscribed services.

[0081] In certain embodiments, the order orchestration module 1422 enables the management of business processes associated with each order and applies business logic to determine whether the order should proceed to provisioning. In operation 1442, upon receiving a new subscription order, the order orchestration module 1422 sends a request to the order provisioning module 1424 to allocate resources and configure the resources required to fulfill the subscription order. The order provisioning module 1424 enables the allocation of resources for the services ordered by the customer. The order provisioning module 1424 provides a level of abstraction between cloud services provided by the cloud infrastructure system 1400 and a physical implementation layer used to provision resources to provide the requested services. Thus, the order orchestration module 1422 may be isolated from implementation details, such as whether services and resources are actually provisioned on the fly or pre-provisioned and allocated / assigned only on demand.

[0082] In operation 1444, once the services and resources are provisioned, a notification of the provided services may be sent by the order provisioning module 1424 of the cloud infrastructure system 1402 to the customers on client devices 1404, 1406, and / or 1408.

[0083] In operation 1446, customer subscription orders may be managed and tracked by the order management and monitoring module 1426. In some cases, the order management and monitoring module 1426 may be configured to collect usage statistics about the services in the subscription order, such as the amount of storage used, the amount of data transferred, the number of users, and the amount of system uptime and system downtime.

[0084] In some embodiments, the cloud infrastructure system 1400 may include an identity management module 1428. The identity management module 1428 may be configured to provide identity services in the cloud infrastructure system 1400, such as access management and authorization services. In some embodiments, the identity management module 1428 may control information about customers who wish to use the services provided by the cloud infrastructure system 1402. Such information may include information that authenticates the identity of such customers and information that describes what actions those customers are permitted to perform on various system resources (e.g., files, directories, applications, communication ports, memory segments, etc.). The identity management module 1428 may also include managing descriptive information about each customer, as well as descriptive information about how and by whom that descriptive information can be accessed and modified.

[0085] Figure 15 shows an exemplary computer system 1500 in which various embodiments may be implemented. The system 1500 may be used to implement any of the computer systems described above. As shown in the figure, the computer system 1500 includes a processing unit 1504 that communicates with several peripheral subsystems via a bus subsystem 1502. These peripheral subsystems may include a processing acceleration unit 1506, an I / O subsystem 1508, a storage subsystem 1518, and a communication subsystem 1524. The storage subsystem 1518 includes a tangible computer-readable storage medium 1522 and system memory 1510.

[0086] The bus subsystem 1502 provides a mechanism for various components and subsystems of the computer system 1500 to communicate with each other as intended. Although the bus subsystem 1502 is schematically shown as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. The bus subsystem 1502 may be one of several types of bus structures, including a memory bus or memory controller, peripheral bus and local bus, using any of the various bus architectures. For example, such architectures may include the Industry Standard Architecture (ISA) bus, the Microchannel Architecture (MCA) bus, the Extended ISA (EISA) bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus, which can be implemented as a mezzanine bus manufactured according to the IEEE P1386.1 standard.

[0087] The processing unit 1504 can be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers) and controls the operation of the computer system 1500. One or more processors may be included in the processing unit 1504. These processors may include single-core processors or multi-core processors. In certain embodiments, the processing unit 1504 may be implemented as one or more independent processing units 1532 and / or 1534, each containing a single-core or multi-core processor. In other embodiments, the processing unit 1504 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors onto a single chip.

[0088] In various embodiments, the processing unit 1504 can execute various programs in response to program code and can maintain multiple programs or processes running simultaneously. At any given time, some or all of the program code to be executed can reside in the processor 1504 and / or the storage subsystem 1518. Through suitable programming, the processor 1504 can provide the various functionalities described above. The computer system 1500 may further include a processing acceleration unit 1506, which may include a digital signal processor (DSP), a special-purpose processor, and the like.

[0089] The I / O subsystem 1508 may include user interface input devices and user interface output devices. User interface input devices may include pointing devices such as keyboards, mice or trackballs, touchpads or touchscreens integrated into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, voice input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may also include motion sensing and / or gesture recognition devices such as Microsoft Kinect® motion sensors, which enable users to control and interact with input devices such as Microsoft Xbox® 360 game controllers through a natural user interface using gesture and speech commands. User interface input devices are It detects eye movements from the user (for example, blinking while taking a photo and / or selecting from a menu) and uses eye gestures to input devices (e.g., Google The user interface input device may also include eye gesture recognition devices such as the Google Glass® blink detector, which converts the input into Glass®. In addition, the user interface input device may include a voice recognition sensing device that enables the user to interact with a voice recognition system (e.g., Siri® Navigator) via voice commands.

[0090] User interface input devices may include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, gamepads and graphic tablets, as well as auditory / visual devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers, 3D scanners, 3D printers, laser rangefinders, and eye-tracking devices. In addition, user interface input devices may include, for example, medical imaging input devices such as computed tomography, magnetic resonance imaging, positron emission tomography, and medical ultrasound equipment. User interface input devices may also include, for example, audio input devices such as MIDI keyboards and digital musical instruments.

[0091] User interface output devices may include non-visual displays such as display subsystems, indicator lights, or audio output devices. Display subsystems may include flat panel devices such as those using cathode ray tubes (CRTs), liquid crystal displays (LCDs), or plasma displays, projection devices, touchscreens, etc. Generally, the use of the term “output device” is intended to include all conceivable types of devices and mechanisms for outputting information from the computer system 1500 to a user or another computer. For example, user interface output devices may include, but are not limited to, a variety of display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, audio output devices, and modems.

[0092] The computer system 1500 may also include a storage subsystem 1518 containing software elements, which are currently shown as being located in the system memory 1510. The system memory 1510 may store program instructions that can be loaded and executed on the processing unit 1504, as well as data generated during the execution of these programs.

[0093] Depending on the configuration and type of the computer system 1500, the system memory 1510 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). RAM typically includes data and / or program modules that are immediately accessible to the processing unit 1504 and / or currently being operated and executed by the processing unit 1504. In some implementations, the system memory 1510 may include several different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, a basic input / output system (BIOS) containing basic routines that help transfer information between elements within the computer system 1500, such as during startup, may typically be stored in ROM. As an example, but not an limitation, the system memory 1510 may also include application programs 1512, program data 1514, and an operating system 1516, which may include client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), etc. It also shows that, for example, operating system 1516 is compatible with various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux®. This may include trademark operating systems, various commercially available UNIX® or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome® OS, etc.), and / or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® 10 OS, and Palm® OS.

[0094] The storage subsystem 1518 may also provide a tangible, computer-readable storage medium for storing basic programming and data structures that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by the processor, provides the above-described functionality may be stored in the storage subsystem 1518. These software modules or instructions may be executed by the processing unit 1504. The storage subsystem 1518 may also provide a repository for storing data used according to some embodiments.

[0095] The storage subsystem 1500 may also include a computer-readable storage medium reader 1520 which may be further connected to the computer-readable storage medium 1522. Together with the system memory 1510, and optionally in combination with the system memory 1510, the computer-readable storage medium 1522 may comprehensively represent a combination of a storage medium and remote, local, fixed, and / or removable storage devices for temporarily and / or more permanently storing, storing, transmitting, and retrieving computer-readable information.

[0096] The computer-readable storage medium 1522 containing code or a portion of code may also include any suitable media, including storage and communication media, such as volatile and non-volatile, removable and non-removable media, implemented by any method or technique for storing and / or transmitting information. This may include tangible computer-readable storage media such as RAM, ROM, electronically erasable programmable ROM (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile disk (DVD) or other optical storage devices, magnetic cassettes, magnetic tapes, magnetic disk storage devices or other magnetic storage devices, or other tangible computer-readable media. This may also include intangible computer-readable media such as any other media that can be used to transmit data signals, data transmission or desired information and can be accessed by the computing system 1500.

[0097] For example, computer-readable storage media 1522 include hard disk drives that read and write to non-removable non-volatile magnetic media, magnetic disk drives that read and write to removable non-volatile magnetic disks, CD-ROMs, DVDs, and Blu-rays (registered trademarks). The computer-readable storage medium 1522 may include, but is not limited to, optical disc drives that read from and write to removable non-volatile optical discs such as disks, or other optical media. The computer-readable storage medium 1522 may also include, but is not limited to, Zip® drives, flash memory cards, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVD discs, digital videotapes, etc. The computer-readable storage medium 1522 also includes flash memory-based SSDs, enterprise flash drives, solid-state drives (SSDs) based on non-volatile memory such as solid-state ROM, SSDs based on volatile memory such as solid-state RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hi-bit drives that use a combination of DRAM and flash memory-based SSDs. This may also include a lid SSD. Disk drives and computer-readable media associated therewith may provide computer-readable instructions, data structures, program modules, and other data non-volatile storage to the computer system 1500.

[0098] The communication subsystem 1524 provides an interface to other computer systems and networks. The communication subsystem 1524 acts as an interface for sending and receiving data between other systems and the computer system 1500. For example, the communication subsystem 1524 may enable the computer system 1500 to connect to one or more devices via the Internet. In some embodiments, the communication subsystem 1524 may include radio frequency (RF) transceiver components for accessing wireless voice and / or data networks (e.g., cellular telephone technology, 3G, 4G, or EDGE (High Speed ​​Data Rate for Global Evolution)), Global Positioning System (GPS) receiver components, and / or other components. In some embodiments, the communication subsystem 1524 can provide wired network connectivity (e.g., Ethernet®) in addition to, or instead of, the wireless interface.

[0099] In some embodiments, the communication subsystem 1524 may also receive input communications in the form of structured and / or unstructured data feeds 1526, event streams 1528, event updates 1530, etc., on behalf of one or more users who may use a computer system 1500.

[0100] For example, the communication subsystem 1524 handles Twitter® feeds, Facebook ( (Registered Trademark) Updates, Web feeds such as Rich Site Summary (RSS) feeds, and It may also be configured to receive data feeds 1526 in real time from users of social networks and / or other communication services, such as real-time updates from one or more third-party sources.

[0101] In addition, the communication subsystem 1524 may also be configured to receive data in the form of a continuous data stream, which may include an event stream 1528 and / or event update 1530 of real-time events, which may be inherently continuous or infinite, without an explicit termination. Examples of applications that generate continuous data may include, for example, sensor data applications, financial stock market boards, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, and automotive traffic monitoring.

[0102] The communication subsystem 1524 may also be configured to output structured and / or unstructured data feeds 1526, event streams 1528, event updates 1530, etc., to one or more databases which may communicate with one or more streaming data source computers connected to the computer system 1500.

[0103] The computer system 1500 can be one of various types, including handheld portable devices (e.g., iPhone® mobile phones, iPad® computing tablets, PDAs), wearable devices (e.g., Google Glass® head-mounted displays), PCs, workstations, mainframes, kiosks, server racks, or any other data processing systems.

[0104] Due to the ever-changing nature of computers and networks, the computer shown in the diagram The description of System 1500 is intended merely as a specific example. Many other configurations are possible, having more or fewer components than the system depicted in the figure. For example, customized hardware may also be used, and / or certain elements may be implemented in hardware, firmware, software (including applets), or a combination thereof. Furthermore, connections to other computing devices, such as network input / output devices, may be employed. Other embodiments and / or methods may be used to implement various embodiments based on the disclosures and teachings provided herein.

[0105] In the preceding description, for illustrative purposes, numerous specific details were provided for a complete understanding of the various embodiments. However, it will be apparent that these embodiments may be carried out without some of these specific details. In other examples, well-known structures and devices are shown in block diagram form.

[0106] The foregoing description provides only exemplary embodiments and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the foregoing description of exemplary embodiments provides a practical description for carrying out at least one embodiment. It should be understood that various modifications can be made to the function and configuration of the elements without departing from the spirit and scope of any embodiment described in the claims.

[0107] The above description provides specific details to give a complete understanding of the embodiments. However, embodiments may be carried out without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in the form of block diagrams to avoid obscuring the embodiments with unnecessary details. In other cases, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary details to avoid obscuring the embodiments.

[0108] Furthermore, note that individual embodiments may be described as processes depicted as flowcharts, flow diagrams, data flow diagrams, structural diagrams, or block diagrams. While some flowcharts may describe operations as sequential processes, many operations may be performed in parallel or simultaneously. In addition, the order of operations may be rearranged. A process terminates when its operations are completed, but it may have additional steps not shown in the diagram. A process may correspond to a method, function, procedure, subroutine, subprogram, etc. If a process corresponds to a function, its termination may correspond to the function returning to a calling function or main function.

[0109] The term “computer-readable medium” includes, but is not limited to, portable or fixed storage devices, optical storage devices, wireless channels, and various other media that can store, contain, or carry instructions and / or data. A code segment or machine-executable instruction may represent a procedure, function, subprogram, program, routine, subroutine, module, software package, class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc., may be passed, transferred, or transmitted via any preferred means, including memory sharing, message passing, token passing, network transmission, etc.

[0110] Furthermore, the embodiments include hardware, software, firmware, middleware, It may be implemented by microcode, a hardware description language, or any combination thereof. When implemented in software, firmware, middleware, or microcode, the program code or code segment that performs the required task may be stored in a machine-readable medium. The required task may be performed by a processor.

[0111] While various aspects of the embodiments are described in the aforementioned specification with reference to specific embodiments, not all embodiments are limited thereto. The various features and aspects of the embodiments described above may be used individually or in combination. Furthermore, embodiments can be used in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of this specification. Accordingly, the specification and drawings should be considered illustrative rather than restrictive.

[0112] Furthermore, for illustrative purposes, the method has been described in a specific order. It should be understood that in alternative embodiments, the method may be performed in an order different from that described. It should also be understood that the above method may be performed by hardware components, or it may be embodied in a sequence of machine-executable instructions, which, when used, cause a machine such as a general-purpose or dedicated processor or logic circuit programmed with such instructions to perform the above method. These machine-executable instructions may be stored on one or more machine-readable media, such as a CD-ROM or other type of optical disk, a floppy diskette, ROM, RAM, EPROM, EEPROM, magnetic or optical card, flash memory, or other types of machine-readable media suitable for storing electronic instructions. Alternatively, the method may be performed by a combination of hardware and software.

Claims

1. A program that, when executed by one or more processors, includes instructions that cause one or more processors to perform an operation, wherein the operation is: In a programming language framework, this includes receiving an instance of an object at runtime, the definition of the object is annotated with constraints, and the operation further includes: The aforementioned programming language framework includes receiving one or more validators annotated with a certain annotation, wherein the annotation is The attributes of the aforementioned object in the aforementioned definition, The value of the attribute in the definition of the object is identified, and the operation further, A program in the aforementioned programming language framework that includes identifying one or more validators whose attribute value in the instance of the object at runtime matches the value of the attribute in the annotation, and changing the value of the attribute at runtime modifies the validator selected at runtime from the one or more validators.

2. The program according to claim 1, wherein the validator verifies the value of the second attribute in the definition of the object.

3. The program according to claim 1 or 2, wherein the one or more validators include a second validator, and the value of the attribute in the instance of the object does not match the value of the attribute in the annotation of the second validator.

4. The program according to any one of claims 1 to 3, wherein the constraints annotating the definition of the object cause the programming language framework to use dynamic verification rather than static verification.

5. The program according to claim 4, wherein the programming language framework includes definitions for constraints that annotate the definitions of the object, the definitions for constraints specifying that the constraints may be executed on an object type target.

6. The program according to any one of claims 1 to 5, wherein the programming language framework includes definitions for annotations that annotate one or more validators, and the definitions include attribute names and attribute value patterns.

7. The program according to any one of claims 1 to 6, wherein the programming language framework includes the definition of an abstract class from which each of the one or more validators inherits.

8. The program according to claim 7, wherein the abstract class includes an abstract function that determines whether a constraint is valid for an object.

9. The program according to claim 7, wherein the abstract class includes a protected function for validating an object against a custom constraint.

10. The program according to any one of claims 1 to 9, wherein the programming language framework includes a definition of a class that scans the classpath and identifies each of the one or more validators in the classpath.

11. The program according to claim 10, wherein the definition of the class includes a function for filtering out validators among the one or more validators whose value of the attribute in the instance of the object does not match the value of the attribute in the annotation.

12. The program according to claim 10, wherein the programming language framework, upon receiving the instance of the object, creates an instance of the class based on the definition of the class as an entry point for dynamic verification.

13. The definition of the class is the program according to claim 10, which first performs an arbitrary static verification and then performs an arbitrary dynamic verification.

14. The program according to any one of claims 1 to 13, wherein the instance of the object includes the attribute and a second attribute.

15. The program according to claim 14, wherein the attribute determines which of the one or more validators should be used to verify the value assigned to the second attribute.

16. The program according to claim 15, wherein the attribute includes a key, and the second attribute includes a value in a key-value pair.

17. The program according to claim 16, wherein the key indicates the data type of the value.

18. The validator is annotated with a second annotation that identifies a second attribute in the definition of the object and a second value for the second attribute, The program according to any one of claims 1 to 17, wherein the value of the second attribute in the instance of the object matches the second value of the second attribute in the second annotation of the validator.

19. It is a system, One or more processors, The system comprises one or more memory devices which, when executed by the one or more processors, include instructions that cause the one or more processors to perform an operation, and the operation is, In a programming language framework, this includes receiving an instance of an object at runtime, the definition of the object is annotated with constraints, and the operation further includes: The aforementioned programming language framework includes receiving one or more validators annotated with a certain annotation, wherein the annotation is The attributes of the aforementioned object in the aforementioned definition, The value of the attribute in the definition of the object is identified, and the operation further, The programming language framework includes identifying one or more validators whose attribute value in the instance of the object at runtime matches the value of the attribute in the annotation, and changing the value of the attribute at runtime means changing the validator selected at runtime from the one or more validators.

20. A method for performing dynamic verification in a programming language framework, One or more processors in a programming language framework receive instances of objects at runtime, the definition of the object is annotated with constraints, and the method further includes: The one or more processors described above include receiving one or more validators annotated with a certain annotation in the programming language framework, wherein the annotation is The attributes of the aforementioned object in the aforementioned definition, The method further identifies the value of the attribute in the definition of the object, and the method further A method in which the one or more processors, in the programming language framework, identify a validator among the one or more validators whose value of the attribute in the instance of the object at runtime matches the value of the attribute in the annotation, and changing the value of the attribute at runtime is to change the validator selected at runtime from the one or more validators.

Images