Object attribute dynamic validation

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, entitled "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 each data set, 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". Provides verification for approximate. Bean Validation is defined in the JSR380 specification that enables static verification of Java beans. In static verification, the internal attributes of the bean (e.g., member variables) satisfy several predefined criteria such as not being null, not being empty, within a specified numerical range, etc. If these predefined criteria are not met, the framework reports a constraint violation. The validation framework also enables users to create user-defined constraints and user-defined validators. These allow users to customize various validation routines to conform to the desired data format. Summary of the Invention

[0004] Summary Modern programming language frameworks provide a configuration for performing static verification on runtime values using predefined constraints. When a runtime instance is created, the runtime values stored in variables and / or member attributes may be provided to a validator function that ensures the runtime values conform to the predefined constraints. The predefined constraints may include numerical ranges, acceptable string patterns, date ranges, specific formatting, and / or other requirements that may be imposed on data values. To activate the constraints, a variable or member attribute may be annotated with a text string that refers to a specific validator function. Thus, the validator function to be used for a particular variable is set at programming time rather than at runtime.

[0005] The embodiments described in this specification enhance a programming language framework to provide dynamic verification. Dynamic verification allows validators for any variable to be selected at runtime rather than statically declared at programming time. Instead of annotating variables with annotations that refer to specific validator functions or constraint types, a programmer can annotate variables with an annotation indicating that the validator function is to be dynamically selected at runtime. When a runtime instance of a variable is created, the programming language framework identifies the dynamic verification annotation on the variable and then, using the runtime value in the variable, may determine which validation 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 variables that are to receive dynamic verification as described above. Another annotation definition may be used to annotate user-defined dynamic value validator functions themselves. The second annotation may receive names and / or values for attributes that are to be dynamically verified. For example, a class definition may include two member attributes that operate as key-value pairs (e.g., string key, string value). The second annotation may reference the "key" attribute and determine whether the value in the "key" attribute indicates that a phone number (e.g., key = "phone"; value = "571-555-1534") is stored in this key-value pair. The annotation used on the validator function can specify that it should be used when the attribute named "key" has the value "phone", and the code within the validator function can then verify the "value" attribute to determine whether it stores a properly formatted phone number. If the "key" value stores something different, such as "date" or "time" ", this validator will not be executed on this class instance. This determination is made at runtime by the framework.

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

[0008] These programming language framework improvements enable the programmer to encapsulate different dependencies between member attributes in different validator functions that are dynamically selected at runtime. If only static verification were used, validator functions would have been required to include branches of if / then statements that compare different possible values. These s The statement is difficult to maintain over time as the code evolves. However, when using dynamic verification, each variable dependency for verification can be handled separately and independently, and new dependencies can be easily added without limitation by annotating the added dependencies with new validator functions.

[0009] Brief Description of the Drawings A further understanding of the nature and advantages of the various embodiments can be realized by referring to the remainder of the specification and the drawings, wherein like reference numerals are used to refer to like components throughout the several drawings. In some cases, a lower label is associated with the reference numeral to indicate one of a plurality of like components. When referring to a reference numeral without specifying an existing lower label, it is intended to refer to all such plurality of like components.

Brief Description of the Drawings

[0010]

Figure 1

Figure 2A

Figure 2B

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9A

Figure 9B

Figure 9C

Figure 10A

Figure 10B

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Best Mode for Carrying Out the Invention

[0011] Detailed Description In the Java programming language, various specifications (such as JSR380, JSR349, JSR303, etc.) describe frameworks that may be used for the validation of attributes within Java beans. Bean validation is generally used when data flows from the presentation layer to the persistence layer. Before this framework, users usually had to duplicate their own validation code in each layer of their application. The validation framework enables users to perform validation using a single mechanism via metadata added to the domain or class. The metadata may include constraints added via an XML descriptor. For example, the default metadata source for a Java class may include Java annotations added to the target. The target data may then be validated against the constraints referenced by the annotations at runtime.

[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, a 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 work together to perform runtime validation of the constraints against program data.

[0013] FIG. 1 shows a diagram 100 of a constraint verification framework 102 for a programming language, according to some embodiments. In computer programming, a software framework is an abstraction in which software providing general functionality can be extended by user code. The 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, the framework 102 may include support programs, compilers, code libraries, tool sets, 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 verification. As used herein, the framework 102 itself may be distinguished from user code or custom, user-defined validators and constraint annotations.

[0014] The user program 106 may include user code that is compiled, assembled, interpreted, and / or executed as a software application. For example, the program 106 may include a main( ) function that instantiates class objects, executes functions, stores variables, and / or otherwise implements various aspects of a software application. The program 106 may be considered user code and distinguished from the framework 102. Additionally, the user code may include one or more custom class / object definitions. In the Java programming language, these classes may be organized into packages called "beans". The program 106 may use the class definitions in the bean 108 to instantiate runtime objects and may do so.

[0015] As is common in many class definitions, the classes within bean108 may contain member variables, member functions, and other data. Constraint annotations 110 may be added to the class definitions 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 explained in the following example, annotation 110 typically includes lines of code that identify the constraints and may provide values for the constraints, such as messages and / or other information that may be used when validating the constraints.

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

[0017] In addition to using the built-in validators / constraints 104, program 106 may also use custom validators / constraints 112. To use custom validators and / or custom constraints, user-defined validator definitions and / or constraint definitions may be provided to program 106. Each of the custom validators / constraints 112 may implement a predefined interface and / or abstract class provided by framework 102 such 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 a bean 108 using the built-in constraint annotation 110 according to some embodiments. This bean includes a 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 an integrated format. A general-purpose format may use a key-value structure where data is stored as key-value pairs. The key part of the pair may be used to describe the data type (or any other type of metadata) for the value part of the pair. For example, the key part of the pair may define data types such as phone numbers, addresses, usernames, etc. The corresponding value part of the pair may include a specific phone number, a specific address, the name of a specific user, etc. 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 in this specification as an example of a bean that may use dynamic verification as described below. However, this class is used only as an example and is not meant to be limiting. Dynamic verification may be used with any data structure, including other encapsulations of classes and data.

[0019] The bean 108 may include private member variables for both the key and the value. The example in Figure 2A includes a constraint annotation 110 that may be used to verify a string value. Some of the built-in constraints in some Java frameworks may include a @NotBlank constraint indicating that the string value in the key variable should not be blank. The 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 verification code, the user can enforce pre-defined constraints that can be automatically verified by the functionality in the framework simply by including the constraint annotation 110 without writing additional code.

[0020] In addition to using built-in constraints, a programming language framework may also allow a user to define their own custom constraint annotations and custom validators to verify those constraints. FIG. 2B shows the definition of a custom validator / constraint 112. First, an example of a constraint definition 220 is provided that allows a user to define their own constraint annotations. The constraint definition 220 may specify a target (e.g., a field, method, type, etc.) to which the constraint may apply. The constraint definition 220 may also include a message, a group, and / or a payload field. Other fields may be added to provide information or other settings that may enhance the verification. For example, a message field may be used to create an error message that may be overwritten by a parameter as shown in FIG. 2A. The group field may define a group to which the constraint belongs. The payload field may specify other data to which the constraint may be associated. For example, the payload may be used to associate a 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. The validator definition 222 in the context of the Java programming language may implement the ConstraintValidator interface and may override two public functions. The initialize( ) function receives data from the constraint annotation It may also be used to initialize the validator. The isValid( ) function holds the code used to verify the corresponding constraints against the corresponding object. When an annotation for a constraint definition 220 is used on a target object corresponding to the object type in the validator definition 222, the constraint may be verified. In some cases, the validator definition 222 may be defined comprehensively such that the target class is of Object type. In this case, the framework calls the user-defined verification code for all targets annotated with the constraint. For example, the validator definition 222 may verify all target beans annotated with the @MyConstraint constraint having a certain type of MyObject. It should be noted that the validator definition 222 cannot be selected based on the runtime values of the attributes within the object in mind.

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

[0023] The user may define custom validators and constraints in an existing programming language framework, but the embodiments described herein improve the existing programming language framework to provide a mechanism for validating dependencies between attributes through the framework based on runtime values. These improvements enable easy implementation to provide deep validation where custom validators and constraints can affect the type of constraints in which the value for one attribute is verified on another attribute. For example, if the value for a key in a KeyValue object contains the string value "phone", the user may wish to verify it in a value attribute to ensure that the string is a properly formatted phone number. In another example, if the key is "date", the user may wish to verify the value to ensure that the string is a properly formatted date. This cannot be done with static validation as only a single value of the target is verified. And while the user can define their own constraints and provide validation code to verify the relationships, the user would need to define a new combination of constraints and validators for each relationship in the target. This code is very difficult to maintain and very difficult to analyze. The embodiments described herein instead describe an extension to a validation framework that solves this problem in a comprehensive manner without requiring specific code for each relationship. The user may wish to verify it in a value attribute to ensure that the string is a properly formatted phone number. In another example, if the key is "date", the user may wish to verify the value to ensure that the string is a properly formatted date. This cannot be done with static validation as only a single value of the target is verified. And while the user can define their own constraints and provide validation code to verify the relationships, the user would need to define a new combination of constraints and validators for each relationship in the target. This code is very difficult to maintain and very difficult to analyze. The embodiments described herein instead describe an extension to a validation framework that solves this problem in a comprehensive manner without requiring specific code for each relationship.

[0024] Figure 4 shows a framework extension 400 for dynamic validation according to some embodiments. This figure 400 shows that the framework 102 has several additional modules, namely, dynamic validation 402 annotations, dynamic validators 404, dynamic value annotations 406, and dynamic value vali It is the same as FIG. 100 in FIG. 1, except that it is extended to include data 408. Each of these modules will be described in more detail below. Briefly, 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. These modules are part of the programming language framework and it should be noted that they are not user-defined classes that the user is required to write. These are modules that may be deployed with the framework 102 and can thus be distinguished from the code that the user may write to interact with the framework 102.

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

[0026] Figure 5 is a diagram showing dynamic verification constraint annotations according to some embodiments. The starting point of dynamic verification is the definition of the constraint annotation and its corresponding validator. The dynamic verification constraint definition 402 defines an annotation that may be added to a class to indicate to the framework that dynamic verification, rather than conventional verification, should be performed. Since dynamic verification may be used to evaluate the relationships between different member variables of a class, the constraint definition 402 sets the target value to TYPE, which enables access to all of the attributes within the object definition. The name given to this constraint definition 402 is DynamicValidation (corresponding to the @DynamicValidation annotation) However, this name is used only as an example and does not imply limitation. Any other name may be used for the dynamic verification constraint definition 402. In some embodiments, it is not necessary to define a default message 502 along with the annotation. As will be explained below, any message defined within this annotation may be omitted and replaced during validation by the validator. Also note that the definition 502 specifies that this constraint may be verified by the DynamicValidator class, and its name is merely illustrative, and its functionality will be described in detail below.

[0027] Figure 6 shows an example of a bean 416 using dynamic verification according to some embodiments. Using the definition described above in Figure 5, the KeyValue class may be annotated with the @DynamicValidation constraint annotation. This enables the framework to call 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 verification 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 verification constraint definition 402 may be added at a similar position for any bean for which dynamic verification should be called.

[0028] 7 illustrates a new annotation added to the framework that defines relationships between dynamic values, according to some embodiments. As described in more detail below, this annotation may be used for custom dynamic value validators to indicate the runtime attribute values ​​that may cause the validator to be invoked. Specifically, FIG. 7 illustrates a dynamic value annotation definition 406 that defines relationships between values. This particular annotation defines two methods: attributeName and and valuePattern. The attributeName method checks whether the value is Returns the name of the attribute that will be checked. The valuePattern method returns a regular expression to check the value against. This annotation is implemented using the DynamicValueValidator, which is explained in more detail below. This extension is used on the relationship definition defined by @DynamicValue. needs to be further validated. Additionally, 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 for a DynamicValueValidator, then all of these relationships defined by the annotations Each of these can be further verified.

[0029] FIG. 8 is an example of an abstract class for a DynamicValueValidator, according to some embodiments. First, note 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 above-mentioned @DynamicValue. This abstract class may be patterned after the javax.validation.ConstraintValidator abstract class in some Java frameworks, which is extended by normal user-defined validators.

[0030] Each validator that extends the DynamicValueValidator class should provide an implementation example of the isValid( ) method 802 This method may be called by the extended class if the relationship defined by @DynamicValue is satisfied for the bean being validated. Specifically, the code for providing the actual validation may be provided in the isValid( ) function that overrides this abstract function in the custom dynamic value validator and in the abstract base class. Furthermore, DynamicValueValidator408 includes two protected methods, namely, validateCustomConstraints( ) 804 and useConstraint( ) 806, which may be used to facilitate user-defined validators. validateCustomConstraints(

[0031] ​​)Method 804 may be used in user-generated validators when it is defined such that its own object is statically verified. One of the core concepts behind validation is that the validator defines its own internal class with 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 extracts the first message from that violation, passes it to the ConstraintValidationContext, and returns false. Helper method useConstraint( )8 06 may be used to give a user-defined message when the user has identified a deep validation failure of the bean (e.g., the user validates whether they can open a connection to the provided URL). Both of these functions may be called by a custom dynamic value validator written by a user who extends this class. As part of the framework extension, these features reduce the amount of code required to write a custom dynamic value validator.

[0032] Figure 9A shows the definition for the DynamicValidator404 class according to some embodiments. DynamicValidator implements the ConstraintValidator template already defined in the framework. Importantly, DynamicValidator404 serves as an entry point for framework extensions added by the embodiments described herein for performing dynamic validation. This class first creates a validator for checking statically defined constraints, creates a list of dynamic validators loaded from a classpath scan, and creates a static instance of VALIDATOR. DynamicValidator is tasked with executing the dynamic validators in the list. The dynamic validators are loaded by scanning the classpath for classes that implement the DynamicValidator interface. Note that it may be used for any type of bean. When an instance of ConstraintValidator is created, it loads all classes that extend the above-mentioned DynamicValueValidator. Constructor 902 creates an instance of DynamicVal idator according to the code in Figure 9A. 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 a no-argument constructor, and classes that do not have at least one correct @DynamicValidation annotation. Next, each of these classes is instantiated and cached. Some embodiments may use a full classpath scan, and other embodiments may use Contexts and Dependency Injection )(CDI) to obtain all instances of DynamicValueValidator with the @DynamicValidation annotation. If CDI is used, user-defined dynamic bean validators should define their scope to be visible for CDI lookups. This approach may be preferred in a Java EE environment. )(CDI) to obtain all instances of DynamicValueValidator with the @DynamicValidation annotation. If CDI is used, user-defined dynamic bean validators should define their scope to be visible for CDI lookups. This approach may be preferred in a Java EE environment. All instances of DynamicValueValidator with the @DynamicValidation annotation. If CDI is used, user-defined dynamic bean validators should define their scope to be visible for CDI lookups. This approach may be preferred in a Java EE environment.

[0033] Figure 9B shows the isValid( ) 910 function for DynamicValidator according to some embodiments. As soon as the isValid( ) method 910 is called in DynamicValidator 404, it may execute the verification of statically defined constraints within the bean (912). If there is a violation of the static constraints, dynamic verification may not be necessary, and thus, isValid( )The method may return and terminate. Static constraints may have a higher priority than dynamically defined constraints in some embodiments. Alternatively, dynamic verification may be started if there is no violation of the static constraints. Filter the list of dynamic validators populated in constructor 902 above to find the validators defined for this particular type of bean and for which the relationships defined in @DynamicValue are satisfied. Data may be found (914). Note that if the attribute does not have type String, the toString() method may be called to obtain the string representation of the attribute. Finally, any validator that meets these conditions may be passed to their respective isValid() methods (916).

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

[0035] Figures 7 to 9C show implementation examples of various modules that may be included in a framework extension to perform dynamic verification according to some embodiments. These exemplary modules may provide an enabling disclosure using the Java programming language and specific Java constructs as examples. However, these examples are not meant to be limiting. The principles for extending a framework to provide dynamic verification may be applicable to any programming language and may have different implementation examples other than those specifically used as examples in these figures.

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

[0037] The dynamic @DynamicValue annotation 1002 specifies the variable that triggers this dynamic verification and the value of that variable. In this example, the target object includes a variable with the attribute name "key" When, in the case where the value of that attribute includes a string having the "phone number" text shown in annotation 1002, dynamic verification will be triggered. The validator 412 extends the DynamicValueValidator abstract parent class, specifically, for the KeyValue type objects described above in FIGS. 2A and 6 (1004). isValid( ) takes the target KeyValue object and then uses the private PhoneNumber class to verify the phone number. At this point, the variable value in the KeyValue target object is expected to be a valid phone number verified, 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 the custom dynamic value validator 412, the validator will not be executed on the instance of that object.

[0038] FIG. 10B shows an example of a custom dynamic value validator with multiple constraint annotations according to some embodiments. The example of FIG. 10A uses only a single @DynamicValue annotation, but other implementations may use multiple @DynamicValue annotations. For example, the KeyValue class described above contains a single key in a single value. Other embodiments include a TwoKeyValue class that contains two keys and a single value. The first key (key1) may still be used to specify that the value is a phone number, and the second 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 individually included in the @DynamicValue annotation 1010 for this particular custom dynamic value validator 412 to be called. This validator 412 is an extension of the class performed using the TwoKeyValue class instead of the KeyValue class (1012). Except for [[ID=]], it may operate in the same manner as the validator of FIG. 10A. Similarly, the isValid( ) function 1014 may receive a TwoKeyValue object instead of a KeyValue object. It may be received.

[0039] FIG. 11 shows an example of a program 414 in which dynamic validation may be invoked according to some embodiments. As described above in connection with FIG. 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 of FIG. 10. Then , the validate( ) function is called to dynamically check the value of the key ("phone") and call the custom dynamic value validator 412 to ensure that the phone number provided in the value attribute is in the appropriate format.

[0040] FIG. 12 shows a flowchart 1200 of a method for dynamically validating variable dependencies at runtime according to some embodiments. The method may include receiving an instance of an object (1202) in a programming language framework. 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 validation rather than static validation or other forms of custom user-defined validation routines. The dynamic validation is of the object Certain types of validation routines and constraints applied to an instance may imply a dependence on variable runtime values in an object instance. For example, the @DynamicValidation constraint annotation may be used on a class definition as shown in FIG. 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 FIG. 3.

[0041] The method may also include receiving one or more validators annotated with an annotation that identifies an attribute in the object's definition and the value of that attribute (1204). For example, the custom dynamic value validators of FIGS. 10A and 10B can be annotated using the @DynamicValue annotation from FIG. 7. The annotation may include the attribute name that identifies the attribute in the object's definition, 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 above example. The validator may be received by the framework when the framework extends the abstract base class. The validator may also implement a boolean function (e.g., an 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. The validator may be received by the framework when the framework extends the abstract base class. The validator may also implement a boolean function (e.g., an 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 further include identifying, among one or more validators, a validator in which the value of an attribute in an instance of an object matches the value of the attribute in the annotation (1206). For example, the DynamicValidator class of FIG. 9A may identify all validators in the runtime path or otherwise associated with the program. Next, a constructor for the DynamicValidator may iterate through each of the available validators and identify a validator in which an annotation (e.g., the DynamicValue parameter) matches the value of the corresponding attribute in the object instance. In some embodiments, each validator may have more than one (i.e., a plurality of) DynamicValue annotations, each of which may be satisfied to execute the validator on the object instance.

[0043] The method may further include executing a validator using an instance of an object (1208). The identified validator may be executed on the instance of the object along with any other validator that meets the annotation criteria. For example, an attribute value may be verified against a constraint, which may be selected based on the value of another attribute, thus enabling an attribute dependency to affect which validators are executed and the results of those validators.

[0044] It should be understood that the specific steps illustrated in FIG. 12 provide a particular way of performing dynamic verification according to various embodiments. Other sequences of steps may also be performed according to alternative embodiments. For example, an alternative embodiment may perform the steps outlined above in a different order. Further, each individual step shown in FIG. 12 may include a plurality of sub-steps that may be performed in various sequences depending on the need for each individual step. Additionally, additional steps may be added or removed depending on the particular application.

[0045] Each of the methods described herein may be implemented by a computer system. Each step of these methods may be automatically executed by the computer system and / or input / output involving the user may be provided. For example, the user may provide input for each step of a method, and each of these inputs may be in response to a specific output that requires such input, and that output may be generated by the computer system. Each input may be received in response to the corresponding required output. Further, the input may be received from the user, as a data stream from another computer system, retrieved from a memory location, retrieved via a network, or 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 via a network, or provided to a web service. In short, each step of the methods described herein may be performed by a computer system, with or without user involvement, and may include any number of inputs, outputs, and / or requests to and from the computer system. Steps without user involvement may be said to be automatically executed by the computer system without human intervention. Thus, in light of the present disclosure, it will be understood that each step of each method described herein may be modified to include input from and output to the user, or may be automatically performed by the computer system without human intervention if any decisions are made by the processor. Further, some embodiments of each of the methods described herein may be implemented as a set of instructions stored on a tangible non-transitory storage medium to form a tangible software product.

[0046] FIG. 13 shows a schematic diagram of a distributed system 1300 for implementing one of the embodiments. In the illustrated embodiment, the distributed system 1300 includes one or more client computing devices 1302, 1304, 1306, and 1308, which are configured to execute and operate client applications such as web browsers, proprietary clients (e.g., Oracle Forms), etc. via one or more networks 1310. The server 1312 may be communicatively coupled to the remote client computing devices 1302, 1304, 1306, and 1308 via the network 1310.

[0047] In various embodiments, the server 1312 may be adapted to execute one or more services or software applications provided by one or more of the components of the system. In some embodiments, these services may be provided to the users of the 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. The users operating the client computing devices 1302, 1304, 1306, and / or 1308 may then interact with the server 1312 using one or more client applications to utilize the services provided by these components.

[0048] In the configuration shown in the figure, the software components 1318, 1320, and 1322 of the system 1300 are shown as being implemented on the server 1312. In other embodiments, one or more of the components of the system 1300 and / or the services provided by these components may be implemented by one or more of the client computing devices 1302, 1304, 1306, and / or 1308. A user operating a client computing device may then utilize one or more client applications to use the services provided by these components. These components may be implemented in hardware, firmware, software, or a combination thereof. It should be understood that various different system configurations may be possible that 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] The client computing devices 1302, 1304, 1306, and / or 1308 may be portable handheld devices (e.g., iPhone (registered trademark), cellular phone, iPad (registered trademark), computing tablet, personal digital assistant (PDA) ) or wearable devices (e.g., Google Glass (registered trademark) head-mounted display), software such as Microsoft Windows Mobile (registered trademark), and / or various It runs a mobile operating system and is an effective communication protocol such as the Internet, email, Short Message Service (SMS), Blackberry (registered trademark), or others. The client computing device can be a general-purpose personal computer, for example, a personal computer running various versions of Microsoft Windows (registered trademark), Apple Macintosh (registered trademark), and / or Linux (registered trademark) operating systems and / or a laptop computer. It includes personal computers and / or laptop computers running various versions of them. The client computing device includes various GNU / Linux (registered trademark) operating systems such as Google (registered trademark) Chrome OS, but It is not limited to this and can be a workstation computer running any of various commercially available UNIX (registered trademark) or UNIX-like operating systems. Alternatively, or in addition, the client computing devices 1302, 1304, 1306, and 1308 can be any other electronic devices such as a thin client computer, an Internet-enabled game system (for example, a Microsoft Xbox game console with or without a Kinect (registered trademark) gesture input device), and / or a personal messaging device that can communicate via the network 1310.

[0050] The exemplary 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 also interact with the server 1312.

[0051] The network 1310 within the distributed system 1300 can include, but is not limited to, TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (System Network Architecture), IPX (Internetwork Packet Exchange), AppleTalk, etc. It can be any type of network that supports data communication using any of a variety of commercially available protocols. By way of example only, the network 1310 may be a local area network (LAN) such as one based on Ethernet (registered trademark), Token Ring, etc. The network 1310 may be a wide area network and the Internet. It can include virtual private networks (VPNs), intranets, extranets, public switched telephone networks (PSTNs), infrared networks, wireless networks (e.g., those operating under any of the Institute of Electrical and Electronics Engineers (IEEE) 802.11 protocol suite, Bluetooth (registered trademark), and / or any other wireless protocol ), including but not limited to virtual networks; and / or any combination of these and / or other networks.

[0052] The server 1312 may be composed of one or more general-purpose computers, dedicated server computers (including, by way of example, PC (Personal Computer) servers, UNIX (registered trademark) servers, midrange servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or any other suitable configuration and / or combination. In various embodiments, the server 1312 may be adapted to execute one or more of the services or software applications described in the foregoing disclosure. For example, the server 1312 may correspond to a server for executing the processes described above in accordance with an embodiment of the present disclosure.

[0053] The server 1312 includes an operating system including any of the foregoing, and any It may execute a server operating system available in the intended market. Server 1312 may also execute any of a variety of other server applications and / or middle-tier applications, including an HTTP (Hypertext Transfer Protocol) server, an FTP (File Transfer Protocol) server, a CGI (Common Gateway Interface) server, a JAVA (registered trademark) server, a database server, etc. Exemplary database servers include, but are not limited to, those available in the market from Oracle, Microsoft, Sybase, IBM (registered trademark) (International Business Machines), etc.

[0054] In some examples, Server 1312 may include one or more applications for analyzing and consolidating data feeds and / or event updates received from users of client computing devices 1302, 1304, 1306, and 1308. As an example, the data feeds and / or event updates may include real-time events related to sensor data applications, financial stock market dashboards, 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 information sources and continuous data streams, including Twitter (registered trademark) feeds, Facebook (registered trademark) updates or real-time updates, but are not limited thereto. Server 1312 may also include one or more applications for displaying data feeds 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. The databases 1314 and 1316 may be located in various locations. By way of example, one or more of the databases 1314 and 1316 may reside on a non-transitory storage medium local to (and / or resident on) the server 1312. Alternatively, the databases 1314 and 1316 may be remote from the server 1312 and communicate with the server 1312 via a network-based connection or a dedicated connection. In a set of embodiments, the databases 1314 and 1316 may reside within a storage area network (SAN). Similarly, any necessary files for performing functions attributable to the server 1312 may be stored locally on the server 1312 and / or remotely, as appropriate. In a set of embodiments, the databases 1314 and 1316 may include a relational database, such as a database provided by Oracle, that is adapted to store, update, and retrieve data in response to SQL-formatted commands.

[0056] FIG. 14 is a simplified block diagram of one or more components of a system environment 1400 that may provide, as cloud services, services provided by one or more components of an embodiment system according to an 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 operate a client application, such as a web browser, a client application under intellectual property rights (e.g., Oracle Forms), or some other application, that may be used by a user of the client computing device to interact with the cloud infrastructure system 1402 to use the 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 illustrated. Further, the embodiment shown in the figures is only an 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 figures, may combine two or more components, or may have a different configuration or arrangement of components.

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

[0059] The 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 the communication and exchange of data 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 a variety of 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 that may include those described above for server 1312.

[0062] In one embodiment, the services provided by a 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, managed technical support services, and the like. The services provided by the cloud infrastructure system can scale dynamically to meet the needs of its users. A particular instantiation of a service provided by the cloud infrastructure system is herein referred to as a "service instance". In general, any service made available to a user via a communication network such as the Internet from a cloud service provider's system 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 an application, and the user may order and use the application on demand via a communication network such as the Internet.

[0063] In some examples, services within a computer network cloud infrastructure may include protected computer network access to storage, a hosted database, a hosted web server, a software application, or other services provided to a user by a cloud vendor or otherwise known in the art. For example, a service can include password-protected access to remote storage on the cloud via the Internet. As another example, a service can include a web service-based hosted relational database and networked It can include a script language middleware engine for private use by the developer. As another example, the service can include access to an email software application hosted on the web site of a cloud vendor.

[0064] In one embodiment, the cloud infrastructure system 1402 can be self-service, subscription-based, elastically scalable, reliable, highly available, and security-protected, and can include a set of application, middleware, and database service offerings delivered to customers. An example of such a cloud infrastructure system is the Oracle Public Cloud provided 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 via different deployment models. For example, the services may be provided under a public cloud model where the cloud infrastructure system 1402 sells cloud services (e.g., owned by Oracle) by an organization and the services are made available to the general public or different industry enterprises. As another example, the services may be provided under a private cloud model where the cloud infrastructure system 1402 operates for only 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 the relevant community. The cloud services may also be provided under a hybrid cloud model that 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 a service as software (SaaS) category, a platform as a service (PaaS) category, an infrastructure as a service (IaaS) category, or other categories of services including hybrid services. A customer may order one or more services provided by the cloud infrastructure system 1402 via a subscription order. The cloud infrastructure system 1402 then executes processes 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, the application services may be provided by the cloud infrastructure system via a SaaS platform. The SaaS platform may be configured to provide cloud services falling within the SaaS category. For example, the SaaS platform may provide the ability to build and deliver a suite 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 utilizing the services provided by the SaaS platform, customers can utilize applications running on the cloud infrastructure system. Customers can obtain application services without the need to purchase separate licenses and support. A variety of different SaaS services may be provided. Examples include, but are not limited to, services that provide solutions for sales performance management, enterprise integration, and business agility for large organizations.

[0068] In some embodiments, the platform service may be provided by a cloud infrastructure system via a PaaS platform. The PaaS platform may be configured to provide cloud services corresponding to 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 utilize 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 the need to separately purchase licenses and support. Examples of platform services include, but are not limited to, Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS), etc.

[0069] By using the services provided by the PaaS platform, customers can adopt programming languages and tools supported by the cloud infrastructure system and can 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 service deployment model that enables an organization to pool database resources and provide a database as a service to customers in the form of a database cloud. The middleware cloud service may provide a platform for customers to develop and deploy various business applications, and the Java cloud service may provide a platform for customers to deploy Java applications in the cloud infrastructure system.

[0070] Various different infrastructure services may be provided by the IaaS platform in the cloud infrastructure system. The infrastructure services facilitate the management and control of underlying computing resources such as storage, network, and other basic computing resources for customers who utilize the services provided by the SaaS platform and the PaaS platform.

[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 server, storage, and networking resources to execute services provided by the PaaS platform and the SaaS platform.

[0072] In some embodiments, the resources in the cloud infrastructure system 1402 may be shared by multiple users and dynamically reallocated as needed. Additionally, the resources may be allocated to users at different times. For example, the cloud infrastructure system 1430 enables a first set of users in a first time period to utilize the resources of the cloud infrastructure system for a specified number of hours and then enables the same resources to be reallocated to another set of users in a different time period, thereby maximizing the utilization of the resources.

[0073] In one embodiment, some 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, file transfer services, and the like.

[0074] In certain embodiments, the cloud infrastructure system 1402 may provide comprehensive management of cloud services (e.g., SaaS, PaaS, and IaaS services) in 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, among other things.

[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 that may be a general-purpose computer, a dedicated server computer, a server farm, a server cluster, or any other suitable configuration and / or combination.

[0076] In an exemplary operation 1434, a customer using a client device such as client devices 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 certain embodiments, 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. Order information received by the cloud infrastructure system 1402 in response to the customer placing an order may include information identifying the customer and the one or more services provided by the cloud infrastructure system 1402 that the customer wishes to subscribe to.

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

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

[0079] In operation 1438, the order information is transferred to the order management module 1420. In some examples, the order management module 1420 may be configured to perform billing and accounting functions related to the order, such as verifying the order and posting the order if it is verified.

[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 the business processes associated with each order, and applies business logic to determine whether an order should proceed to provisioning. In operation 1442, upon receiving an order for a new subscription, the order orchestration module 1422 allocates resources and sends a request to the order provisioning module 1424 to 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 the cloud services provided by the cloud infrastructure system 1400, and the physical implementation layer used to provision the resources for providing the requested services. Thus, the order orchestration module 1422 may be isolated from the implementation details, such as whether the services and resources are actually provisioned on-the-fly or pre-provisioned and only allocated / assigned upon request.

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

[0083] In operation 1446, the customer's subscription order 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 for 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 up-time and system down-time.

[0084] In one embodiment, the cloud infrastructure system 1400 may include an identity management module 1428. The identity management module 1428 may be configured to provide identity services such as access management and authorization services in the cloud infrastructure system 1400. In some embodiments, the identity management module 1428 may control information about customers who desire to utilize the services provided by the cloud infrastructure system 1402. Such information may include information for authenticating the nature of such customers, and information describing which actions they 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 descriptive information about each customer, as well as management of the descriptive information about how and by whom that descriptive information can be accessed and modified.

[0085] Figure 15 illustrates an exemplary computer system 1500 in which various embodiments may be implemented as shown. 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 a system memory 1510.

[0086] The bus subsystem 1502 provides a mechanism for the 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 any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus, using any of a variety of bus architectures. For example, such architectures may include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Extended ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus, which may be implemented as a mezzanine bus manufactured in accordance with the IEEE P1386.1 standard.

[0087] The processing unit 1504 can be implemented as one or more integrated circuits (e.g., a conventional microprocessor or microcontroller) 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 of which includes a single-core processor 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 on 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 that are executed 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 that can 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. The user interface input devices may include a keyboard, a mouse or a pointing device such as a trackball, a touchpad or a touch screen incorporated in a display, a scroll wheel, a click wheel, a dial, a button, a switch, a keypad, a voice input device with a voice command recognition system, a microphone, and other types of input devices. The user interface input devices may include, for example, a motion sensing and / or gesture recognition device such as a Microsoft Kinect (registered trademark) that enables a user to control and interact with an input device such as a Microsoft Xbox (registered trademark) 360 game controller through a natural user interface using gestures and spoken commands. The user interface input devices may detect a user's eye movement (e.g., a "blink" while taking a photo and / or while making a menu selection) and input an eye gesture to a device (e.g., Google Gesture recognition devices such as a Google Glass (registered trademark) blink detector that converts as input to Glass (registered trademark) may also be included. Additionally, the user interface input device may include an audio recognition sensing device that enables the user to interact with an audio recognition system (such as a Siri (registered trademark) navigator) via voice commands.

[0090] The user interface input device may include, but is not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, game pads, and graphic tablets, as well as audio / visual devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers, 3D scanners, 3D printers, laser range finders, and eye-tracking devices. Additionally, the user interface input device may include, for example, medical imaging input devices such as computed tomography, magnetic resonance imaging, positron emission tomography, and medical ultrasound examination devices. The user interface input device may also include, for example, audio input devices such as MIDI keyboards and digital musical instruments.

[0091] The user interface output device may include a non-visual display such as a display subsystem, an indicator light, or an audio output device. The display subsystem may be a flat panel device such as one using a cathode ray tube (CRT), a liquid crystal display (LCD), or a plasma display, a projection device, a touch screen, etc. Generally, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computer system 1500 to the user or another computer. For example, the user interface output device may include, but is not limited to, various display devices that visually convey text, graphics, and audio / video information, such as a monitor, a printer, a speaker, headphones, an automotive navigation system, a plotter, an audio output device, and a modem.

[0092] The computer system 1500 may include a storage subsystem 1518 that includes software elements shown as being currently located within the system memory 1510. The system memory 1510 may store program instructions loadable and executable 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 contains data and / or program modules that are immediately accessible to the processing unit 1504 and / or are currently being operated on and executed by the processing unit 1504. In some implementations, the system memory 1510 may include multiple 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) that includes basic routines useful for transferring information between elements within the computer system 1500, such as during startup, may typically be stored in the ROM. By way of non-limiting example, the system memory 1510 may also include application programs 1512, program data 1514, and an operating system 1516 that may include, for example, client applications, web browsers, middleware applications, relational database management systems (RDBMS), etc. is also shown. By way of example, the operating system 1516 may include various versions of Microsoft Windows (registered trademark), Apple Macintosh (registered trademark), and / or Linux (registered trademark) operating systems, various commercially available UNIX (registered trademark) or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome (registered trademark) OS, etc.), and / or mobile operating systems such as iOS, Windows (registered trademark) Phone, Android (registered trademark) OS, BlackBerry (registered trademark) 10 OS, and Palm (registered trademark) OS.

[0094] The memory subsystem 1518 may also provide a tangible computer-readable storage medium for storing the basic programming and data structures that provide the functionality of some embodiments. Software (programs, code modules, instructions) that provides the above-described functionality when executed by a processor 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 in accordance with certain embodiments.

[0095] The storage subsystem 1500 may also include a computer-readable storage medium reader 1520 that may be further connected to a 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 storage medium added to remote, local, fixed, and / or removable storage devices for temporarily and / or more permanently accommodating, storing, transmitting, and retrieving computer-readable information.

[0096] A computer-readable storage medium 1522 that includes code or a portion of code can also include any suitable medium including, but not limited to, storage media and communication media such as volatile and non-volatile, removable and non-removable media implemented in any method or technology for information storage and / or transmission. This can include tangible computer-readable storage media such as RAM, ROM, electronically erasable programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD), or other optical storage device, magnetic cassette, magnetic tape, magnetic disk storage device or other magnetic storage device, or other tangible computer-readable media. This can also include non-tangible computer-readable media such as any other medium that can be used to transmit a data signal, data transmission, or desired information and can be accessed by computing system 1500.

[0097] By way of example, computer-readable storage medium 1522 can be a hard disk drive that reads from and writes to a non-removable non-volatile magnetic medium, a magnetic disk drive that reads from and writes to a removable non-volatile magnetic disk, a CD ROM, a DVD, and a Blu-Ray (registered trademark )An optical disc drive that reads and writes to a removable non-volatile optical disc such as a disk, or may include other optical media. The computer-readable storage medium 1522 may include, but is not limited to, a Zip (registered trademark) drive, a flash memory card, a Universal Serial Bus (USB) flash drive, a Secure Digital (SD) card, a DVD disc, a digital video tape, etc. The computer-readable storage medium 1522 may also be a solid-state drive (SSD) based on non-volatile memory such as a flash memory-based SSD, an enterprise flash drive, a solid-state ROM, an SSD based on volatile memory such as solid-state RAM, dynamic RAM, static RAM, a DRAM-based SSD, a magnetoresistive RAM (MRAM) SSD, and a hybrid that uses a combination of DRAM and a flash memory-based SSD A hybrid SSD may also be included. The disk drives and the computer-readable media associated therewith may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data to the computer system 1500.

[0098] The communication subsystem 1524 provides an interface to other computer systems and networks. The communication subsystem 1524 serves as an interface for the transmission and reception of 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, global positioning system (GPS) receiver components, and / or other components for accessing wireless voice and / or data networks (e.g., using cellular phone technology, advanced data network technologies such as 3G, 4G or EDGE (Enhanced Data rates for GSM Evolution), WiFi (IEEE802.11 family of standards, or other mobile communication technologies, or any combination thereof)). In some embodiments, the communication subsystem 1524 can provide wired network connectivity (e.g., Ethernet (registered trademark)) in addition to, or instead of, a wireless interface.

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

[0100] As an example, the communication subsystem 1524 may be configured to receive data feeds 1526 in real time from users of social networks and / or other communication services, such as Twitter (registered trademark) feeds, Facebook( (registered trademark) updates, web feeds such as Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third-party information 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 updates 1530 of real-time events that are essentially continuous or infinite without an explicit end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial stock market dashboards, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automotive traffic monitoring, and the like.

[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 that communicate with one or more streaming data source computers coupled to the computer system 1500.

[0103] The computer system 1500 can be one of various types, including a handheld portable device (e.g., an iPhone (registered trademark) mobile phone, an iPad (registered trademark) computing tablet, a PDA), a wearable device (e.g., a Google Glass (registered trademark) head-mounted display), a PC, a workstation, a mainframe, a kiosk, a server rack, or any other data processing system.

[0104] Due to the constantly changing nature of computers and networks, the computers shown in the figure The description of the TASI system 1500 is merely intended as a specific example. Many other configurations are possible that have more or fewer components than the systems depicted in the figures. For example, customized hardware may also be used and / or certain elements may be implemented in hardware, firmware, software (including applets), or a combination. Further, connections to other computing devices such as network input / output devices may be employed. Based on the disclosure and teachings provided herein, other aspects and / or methods may be used to implement various embodiments.

[0105] In the foregoing description, for purposes of explanation, numerous specific details were set forth in order to provide a thorough understanding of the various embodiments. However, it will be apparent that these embodiments may be practiced without some of these specific details. In other instances, 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 the exemplary embodiments provides an enabling description for implementing at least one embodiment. It should be understood that various changes may be made to the functions and configurations of the elements without departing from the spirit and scope of an embodiment recited in the claims.

[0107] In the above description, specific details were given to provide a complete understanding of the embodiments. However, the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form so as not to obscure the embodiments in unnecessary detail. In other cases, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail so as to avoid obscuring the embodiments.

[0108] Note also that individual embodiments may be described as a process depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be rearranged. A process terminates when its operations are completed, but may have additional steps not included in the figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to the function returning to the calling function or the 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, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a 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 suitable means including memory sharing, message passing, token passing, network transmission, etc.

[0110] Furthermore, embodiments may 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 segments that perform the necessary tasks may be stored on a machine-readable medium. The necessary tasks may be executed by a processor.

[0111] In the foregoing specification, aspects of various embodiments have been described with reference to specific embodiments, but not all embodiments are limited thereto. The various features and aspects of the above embodiments may be used individually or together. Further, the embodiments can be utilized 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 are to be regarded as illustrative rather than restrictive.

[0112] Furthermore, for purposes of illustration, a method has been described in a particular order. It should be understood that in alternative embodiments, the method may be performed in an order different from that described. Also, the above method may be performed by hardware components or may be embodied as a sequence of machine-executable instructions that, when used, cause a machine such as a general-purpose or special-purpose 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 disk, ROM, RAM, EPROM, EEPROM, magnetic or optical card, flash memory, or any other type of medium suitable for storing electronic instructions. Alternatively, the method may be performed by a combination of hardware and software.

Claims

**Claim 1** A non - transitory computer - readable medium including instructions that, when executed by one or more processors, cause the one or more processors to perform an operation, the operation including receiving an instance of an object in a programming language framework, wherein the definition of the object is annotated with constraints, and the operation further including receiving one or more validators annotated with an annotation, the annotation identifying an attribute in the definition of the object and a value of the attribute, and the operation further including identifying, among the one or more validators, a validator for which a value of the attribute in the instance of the object matches the value of the attribute in the annotation, and executing the validator using the instance of the object. **Claim 2** The non - transitory computer - readable medium according to claim 1, wherein the validator validates a value of a second attribute in the definition of the object. **Claim 3** The non - transitory computer - readable medium according to claim 1, 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. **Claim 4** The non - transitory computer - readable medium according to claim 1, wherein the constraints annotating the definition of the object cause the programming language framework to use dynamic verification rather than static verification. **Claim 5** The non - transitory computer - readable medium according to claim 4, wherein the programming language framework includes a definition for the constraints annotating the definition of the object, and the definition for the constraints specifies that the constraints may be executed on an object type target. **Claim 6** The non - transitory computer - readable medium according to claim 1, wherein the programming language framework includes a definition for the annotation annotating the one or more validators, and the definition includes an attribute name and an attribute value pattern. **Claim 7** The non - transitory computer - readable medium according to claim 1, wherein the programming language framework includes a definition of an abstract class from which each of the one or more validators is inherited. **Claim 8** The non-transitory computer-readable medium according to claim 7, wherein the abstract class includes an abstract function for determining whether a constraint is valid for an object.

9. The non-transitory computer-readable medium according to claim 7, wherein the abstract class includes a protected function for verifying an object against a custom constraint.

10. The non-transitory computer-readable medium according to claim 1, wherein the programming language framework includes a class definition that scans a classpath and identifies each of the one or more validators in the classpath.

11. The non-transitory computer-readable medium according to claim 10, wherein the definition of the class includes a function for filtering out validators among the one or more validators for which a value of the attribute in the instance of the object does not match a value of the attribute in the annotation. medium.

12. The non-transitory computer-readable medium according to claim 10, wherein the programming language framework creates an instance based on the definition of the class as an entry point for dynamic verification when receiving the instance of the object.

13. The non-transitory computer-readable medium according to claim 10, wherein the definition of the class first performs any static verification and then performs any dynamic verification.

14. The non-transitory computer-readable medium according to claim 1, wherein the instance of the object includes the attribute and a second attribute.

15. The non-transitory computer-readable medium according to claim 14, wherein the attribute determines which of the one or more validators should be used to verify a value assigned to the second attribute.

16. The non-transitory computer-readable medium according to claim 15, wherein the attribute includes a key and the second attribute includes a value in a key-value pair.

17. The non-transitory computer-readable medium according to claim 16, wherein the key indicates a 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 non - transitory computer - readable medium according to claim 1, 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. A system comprising: one or more processors; and one or more memory devices including instructions that, when executed by the one or more processors, cause the one or more processors to perform operations, the operations including: receiving an instance of an object in a programming language framework, wherein the definition of the object is annotated with constraints, and the operations further include: receiving one or more validators annotated with an annotation, the annotation identifying: an attribute in the definition of the object; and a value of the attribute, and the operations further include: identifying, among the one or more validators, a validator for which the value of the attribute in the instance of the object matches the value of the attribute in the annotation; and executing the validator using the instance of the object.

20. A method for performing dynamic verification in a programming language framework, the method including: receiving an instance of an object in a programming language framework, wherein the definition of the object is annotated with constraints, and the method further includes: receiving one or more validators annotated with an annotation, the annotation identifying: an attribute in the definition of the object; and a value of the attribute, and the method further includes: identifying, among the one or more validators, a validator for which the value of the attribute in the instance of the object matches the value of the attribute in the annotation; and executing the validator using the instance of the object.

Images