Dynamic object attribute validation

Abstract

Programming language frameworks can be extended to provide dynamic validation. Dynamic validation allows validators for any variable to be selected at runtime rather than being statically declared at programming time. Instead of annotating a variable with an annotation that points to a specific validator function or constraint type, a programmer can annotate the variable with an annotation that indicates that the validator function will be dynamically selected at runtime. When a runtime instance of the variable is created, the programming language framework may identify the dynamic validation annotation on the variable and then use the runtime value at the variable to determine which validator function should be used.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of and priority to U.S. patent application Ser. No. 16 / 809,025, entitled “DYNAMIC VALIDATION FRAMEWORK EXTENSION,” filed Mar. 4, 2020, which is incorporated by reference in its entirety. [Background technology]

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

[0003] For example, the Java programming language provides validation against constraints imposed on class modules or "beans". Bean validation is defined in the JSR380 standard, which allows for static validation of Java beans. In static validation, attributes (e.g. member variables) inside a bean meet some predefined criteria, such as not null, not empty, within a specified numeric range, etc. If these predefined criteria are not met, the framework reports a constraint violation. The validation framework also allows users to create user-defined constraints and user-defined validators. These allow users to customize various validation routines to fit their desired data format. Summary of the Invention

[0004] overview Modern programming language frameworks provide constructs that perform static validation 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 validator functions that ensure that the runtime values ​​conform to the predefined constraints. The predefined constraints may include numeric ranges, allowable string patterns, date ranges, specific formatting, and / or other requirements that may be enforced on the data values. To activate a constraint, a variable or member attribute may be annotated with a text string that points to a particular validator function. Thus, the validator function that should be used for a particular variable is set at programming time, not at runtime.

[0005] The embodiments described herein enhance programming language frameworks to provide dynamic validation. Dynamic validation allows validators for any variable to be selected at run time, rather than being statically declared at programming time. Instead of annotating a variable with an annotation that points to a particular validator function or constraint type, a programmer can annotate the variable with an annotation that indicates that a validator function will be dynamically selected at run time. When a run-time instance of the variable is created, the programming language framework may identify the dynamic validation annotation on the variable and then use the run-time value on the variable to determine which validator 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 undergo dynamic validation as described above. Another annotation definition may be used to annotate the user-defined dynamic value validator function itself. A second annotation may receive a name and / or value for an attribute that is to be dynamically validated. For example, a class definition may include two member attributes that act as key-value pairs (e.g., string key, string value). The second annotation may reference a "key" attribute and determine whether a value in the "key" attribute indicates that a phone number (e.g., key = "phone"; value = "571-555-1534") is to be stored in this key-value pair. An annotation used on the validator function may specify that the attribute named "key" should be used when it has a value of "phone", and code within the validator function may then validate the "value" attribute to determine whether it stores a properly formatted phone number. If the "key" value stores something different, such as a "date" or a "time", this validator will not run on this class instance. This decision is made at runtime by the framework.

[0007] When the programming language framework receives a variable annotated for dynamic validation at runtime, the framework may first perform any traditional static validation. If static validation fails, dynamic validation may not be required. After static validation is completed, 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. The framework may then cycle through the list of available dynamic value validator functions and identify any dynamic value validator functions where the runtime value of the annotated variable satisfies the annotated constraints on the dynamic value validator function. Continuing with the above example, the framework may identify a phone number value validator function in the classpath and compare the attributeName="key" and attributeValue="phone" constraints in the function annotation with the runtime value of the variable. Any identified validator functions may then 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 validation, which may be overridden in custom dynamic value validators written by the programmer.

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

[0009] BRIEF DESCRIPTION OF THE DRAWINGS A further understanding of the nature and advantages of the various embodiments may be realized by reference to the remaining portions of the specification and the drawings, in which like reference numerals are used to refer to like components throughout the several views. In some cases, a sub-label is associated with a reference numeral to indicate one of multiple similar components. When referring to a reference numeral without specifying an existing sub-label, the intention is to refer to all such multiple similar components. [Brief description of the drawings]

[0010] [Figure 1] 1 illustrates a diagram of a constraint validation framework for a programming language, according to some embodiments. [Figure 2A] 1 illustrates an example of a bean that uses built-in constraint annotations, according to some embodiments. [Figure 2B] Define a custom validator / constraint. [Diagram 3] 4 illustrates a program for validating constraints on a bean, according to some embodiments. [Figure 4] 1 illustrates a diagram of a framework extension for dynamic verification, according to some embodiments. [Diagram 5] FIG. 1 illustrates a dynamic validation constraint annotation according to some embodiments. [Figure 6] 1 illustrates an example of a bean that uses dynamic validation, according to some embodiments. [Figure 7] 13 illustrates new annotations added to the framework that define relationships between dynamic values, according to some embodiments. [Figure 8] 1 illustrates an example of an abstract class for a DynamicValueValidator, according to some embodiments. [Figure 9A] 1 illustrates a definition for a DynamicValidator class, according to some embodiments. [Figure 9B]1 illustrates an isValid( ) function for a DynamicValidator, according to some embodiments. [Figure 9C] 1 illustrates how a DynamicValidator, according to some embodiments, performs static validation and matching between metadata defined in a DynamicValue annotation and a corresponding bean. [Figure 10A] 1 illustrates an example of a user-defined custom dynamic value validator for dynamic validation, according to some embodiments. [Figure 10B] 1 illustrates an example of a custom dynamic value validator with multiple constraint annotations, according to some embodiments. [Figure 11] 4 illustrates an example of a program in which dynamic verification may be invoked, according to some embodiments. [Figure 12] 1 illustrates a flowchart of a method for dynamically validating variable dependencies at runtime, according to some embodiments. [Figure 13] 1 shows a simplified block diagram of a distributed system for implementing some of the embodiments. [Figure 14] FIG. 1 illustrates a simplified block diagram of components of a system environment in which services provided by components of an embodiment of the system may be provided as cloud services. [Figure 15] FIG. 1 illustrates an exemplary computer system upon which various embodiments may be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Detailed Description In the Java programming language, various standards (e.g., JSR380, JSR349, JSR303) describe frameworks that may be used for validation of attributes in Java beans. Bean validation is commonly used when data flows from the presentation layer to the persistence layer. Before this framework, users typically had to duplicate their validation code in each layer of their application. The validation framework allows users to perform validation using a single mechanism via metadata that is added to the domain or classes. The metadata may include constraints that are added via XML descriptors. For example, the default metadata source for a Java class may include Java annotations that are added to the target. The target data may then be validated against the constraints referenced by the annotations at runtime.

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

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

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

[0015] As is common in many class definitions, a class in bean 108 may include member variables, member functions, and other data. Constraint annotations 110 may be added to a class definition in bean 108 at various locations. The scope of the annotation 110 may vary based on the location of the annotation 110 and / or the definition of the corresponding constraint annotation definition. As described in the examples below, annotations 110 typically include lines of code that identify the constraint and may provide values ​​for the constraint, such as a message and / or other information that may be used when validating the constraint.

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

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

[0018] FIG. 2A illustrates an example of a bean 108 that uses built-in constraint annotations 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 a unified format. One universal format may use a key-value structure in which data is stored as a key-value pair. The key portion of the pair may be used to describe the data type (or any other type of metadata) for the value portion of the pair. For example, the key portion of the pair may define a data type such as a phone number, an address, a username, etc. The corresponding value portion of the pair may include a particular phone number, a particular address, the name of a particular 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 herein as an example of a bean that may use dynamic validation as described below. However, this class is used only as an example and is not meant to be limiting. Dynamic validation may be used with any data structure, including classes and other encapsulations of data.

[0019] The bean 108 may include private member variables for both the key and the value. The example of FIG. 2A includes a constraint annotation 110 that may be used to validate the value of a string. Some of the built-in constraints in some Java frameworks may include a @NotBlank constraint that indicates that the string value in the key variable should not be blank. The annotation 110 includes a parameter that sets the message accompanying the constraint violation to a specified value, such as "key is blank." Instead of writing custom validation code, a user can simply include the constraint annotation 110 to enforce a predefined constraint that can be automatically validated by features in the framework without writing additional code.

[0020] In addition to using built-in constraints, the programming language framework may also allow users to define their own custom constraint annotations and custom validators to validate 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 users to define their own constraint annotations. The constraint definition 220 may specify targets (e.g., fields, methods, types, etc.) to which the constraint may be applied. The constraint definition 220 may also include message, group, and / or payload fields. Other fields may be added to provide information or other settings that may enhance validation. For example, the message field may be used to create an error message that may be overridden by a parameter as shown in FIG. 2A. The group field may define the group to which the constraint belongs. The payload field may specify other data with 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 validate the constraints of the constraint annotation definition 220. The validator definition 222 in the context of the Java programming language may implement a ConstraintValidator interface and may override two public functions. The initialize( ) function may be used to receive data from the constraint annotation and initialize the validator. The isValid( ) function holds the code used to validate the corresponding constraint against the corresponding object. If the annotation for the constraint definition 220 is used on a target object that corresponds to the object type in the validator definition 222, the constraint may be validated. In some cases, the validator definition 222 may be defined generically such that the target class is of type Object. In this case, the framework invokes the user-defined validation code for all targets annotated with the constraint. For example, the validator definition 222 may validate all target beans annotated with the @MyConstraint constraint that have a type of MyObject. Note that the validator definition 222 cannot be selected based on the runtime value of an attribute in the object.

[0022] 3 illustrates a program 106 that validates constraints on a bean 108, according to some embodiments. First, the program 106 instantiates a default type validator 302. The program 106 then defines a validate( ) function 308 that performs validation against 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 validation function. The validation function 308 then runs the specified validator against the object and reports any constraint violations.

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

[0024] FIG. 4 illustrates a diagram 400 of a framework extension for dynamic validation, according to some embodiments. This diagram 400 is similar to the diagram 100 of FIG. 1, except that the framework 102 has been extended to include several additional modules: dynamic validation 402 annotation, dynamic validator 404, dynamic value annotation 406, and dynamic value validator 408. Each of these modules is described in more detail below. In essence, these modules allow the framework to handle the @DynamicValidation annotation and then dynamically validate different relationships between different data fields based on the runtime values, such as the relationship between the key and value in the KeyValue class described above. Note that these modules are part of the programming language framework and are not user-defined classes that a user is required to write. These are modules that may be deployed with the framework 102 and may therefore be distinguished from code that a 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 more detail below. When program 414 creates an instance of an object defined in bean 416, dynamic annotation 410 instructs framework 102 to perform dynamic validation using a user-defined custom dynamic value validator 412. As described below, custom dynamic value validator 412 may extend abstract base classes made available in extensions to framework 102, thus minimizing the code that a user may be required to write.

[0026] FIG. 5 is a diagram illustrating a dynamic validation constraint annotation according to some embodiments. The starting point of dynamic validation is the definition of a constraint annotation and its corresponding validator. Dynamic validation constraint definition 402 defines an annotation that may be added to a class to indicate to the framework that dynamic validation should be performed instead of traditional validation. Since dynamic validation may be used to evaluate relationships between different member variables of a class, constraint definition 402 sets the target value to TYPE, which allows access to all of the attributes in 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 is not meant to be limiting. Any other name may be used for dynamic validation constraint definition 402. In some embodiments, it is not necessary to define a default message 502 with the annotation. As described below, any message defined in this annotation may be omitted and replaced during validation by a validator. Note that definition 502 also specifies that this constraint may be validated by a DynamicValidator class, the name of which is merely exemplary and the functionality of which is described in detail below.

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

[0028] FIG. 7 illustrates a new annotation added to the framework that defines relationships between dynamic values, according to some embodiments. As described in detail below, this annotation may be used for custom dynamic value validators to indicate 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 includes two methods: attributeName and valuePattern. The attributeName method returns the name of the attribute whose value will be checked in the target bean. The valuePattern method returns a regular expression for checking the value. This annotation may be used on an instance of DynamicValueValidator, which is described in detail below. This extension ensures that only beans that satisfy the relationship definition defined in @DynamicValue need to be further validated. In addition, this annotation may be used multiple times on a target DynamicValueValidator instance to allow a user to define multiple relationships. For example, if there are more @DynamicValue annotations for a DynamicValueValidator, each of these relationships defined by the annotations can be further validated.

[0029] 8 shows an example of an abstract class for a DynamicValueValidator, according to some embodiments. First, note that the DynamicValueValidator class is an abstract class, which means that any custom dynamic value validator class defined by a user should extend DynamicValueValidator 408, 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 of the isValid( ) method 802. This method may be called by the extended class if the relationship defined in @DynamicValue is satisfied for the bean being validated. Specifically, the code to provide the actual validation may be provided in a custom dynamic value validator in an isValid( ) function that overrides this abstract function in the abstract base class.

[0031] Additionally, DynamicValueValidator 408 includes two protected methods, validateCustomConstraints( ) 804 and useConstraint( ) 806, which may be used to facilitate user-defined validators. The validateCustomConstraints( ) method 804 may be used in a user-created validator when it defines its own objects to be statically validated. One of the core concepts behind validation is that a validator defines its own inner 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 takes the first message from the violation, passes it to the ConstraintValidationContext, and returns false. The helper method useConstraint( ) 806 may be used to provide a user-defined message if the user identifies a deep validation of a bean that has failed (e.g., verifying that the user can open a connection to the provided URL). Both of these functions may be called by custom dynamic value validators written by users that extend this class. As part of the framework extension, these functions reduce the amount of code required to write custom dynamic value validators.

[0032] FIG. 9A illustrates a definition for the DynamicValidator 404 class, according to some embodiments. DynamicValidator implements the ConstraintValidator template already defined in the framework. Importantly, DynamicValidator 404 serves as an entry point for framework extensions added by the embodiments described herein to perform dynamic validation. This class first creates a validator to check statically defined constraints, creates a list of dynamic validators to be loaded from the classpath scan, and creates a static instance of VALIDATOR. Note that DynamicValidator may be used for any type of bean. When an instance of ConstraintValidator is created, it loads all classes that extend DynamicValueValidator as described above. Constructor 902 creates an instance of DynamicValidator according to the code in FIG. 9A. Specifically, if any of the dynamic validators in the classpath are not yet 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. Each of these classes is then instantiated and cached. Some embodiments may use a full classpath scan, while other embodiments may use Contexts and Dependency Injection (CDI) to obtain all instances of DynamicValueValidator that have the @DynamicValidation annotation. If CDI is used, user-defined dynamic bean validators should define their scope to be visible to CDI lookup. This approach may be preferred in a Java EE environment.

[0033] FIG. 9B illustrates an isValid( ) 910 function for a DynamicValidator, according to some embodiments. Once the isValid( ) method 910 is called in the DynamicValidator 404, it may perform validation of statically defined constraints in the bean (912). If the static constraints are violated, dynamic validation may not be necessary, and thus the isValid( ) method may return and terminate. Statically defined constraints may have a higher priority than dynamically defined constraints in some embodiments. Alternatively, dynamic validation may begin if there are no constraint violations in the statically defined constraints. The list of dynamic validators populated above in the constructor 902 may be filtered to find validators defined for this particular type of bean and for which the relationship defined in @DynamicValue is satisfied (914). Note that if the attribute does not have type String, the toString( ) method may be called to retrieve a string representation of the attribute. Finally, any validators that meet these conditions may then be passed 916 to their respective isValid( ) methods.

[0034] FIG. 9C illustrates how a DynamicValidator performs static validation and matching between metadata defined in a DynamicValue annotation and a corresponding bean, according to some embodiments. The isStaticValid( ) function 920 may perform validation on all properties found in the current class and recursively on any parent classes. This private function 920 is called above in FIG. 9B to first determine if any static validations have failed before performing any dynamic validations. The matchDynamicAnnotation( ) function 922 may perform matching between metadata defined in a DynamicValue annotation and a 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 in FIG. 9B when filtering dynamic validators that do not have a specified relationship condition.

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

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

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

[0038] FIG. 10B illustrates 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 includes a single key with a single value. Other embodiments include a TwoKeyValue class that includes 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 a country code. Because each country may have a different format for its phone numbers, both keys may be included separately in the @DynamicValue annotation 1010 for this particular custom dynamic value validator 412 to be invoked. This validator 412 may operate similarly to the validator of FIG. 10A, except that the class extension (1012) may be done using the TwoKeyValue class instead of the KeyValue class. Similarly, the isValid( ) function 1014 may receive a TwoKeyValue object instead of a KeyValue object.

[0039] Figure 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 Figure 6, the KeyValue class is annotated with the @DynamicValidation constraint. When a new instance 1104 of the KeyValue class is created, string values ​​may be provided for the key and value attributes. In this example, the key is set to "phone", which qualifies for the custom dynamic value validator 412 of Figure 10. The validate() function may then be called to dynamically check the value of the key ("phone") and invoke the custom dynamic value validator 412 to ensure that the phone number provided in the value attribute is of the proper format.

[0040] FIG. 12 illustrates 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 in a programming language framework (1202). The instance of the object may be instantiated from an object definition. For example, a class object may be instantiated based on a class definition file. The class definition may be part of a bean or other software module. The definition of the object, such as a class definition, may be annotated with constraints. The constraints may indicate that an instance of the object should be subject to dynamic validation rather than static validation or other forms of custom user-defined validation routines. Dynamic validation may imply that certain types of validation routines and constraints applied to an instance of the object depend on variable runtime values ​​in the object instance. For example, the @DynamicValidation constraint annotation may be used on a class definition as shown in FIG. 6. An instance of the 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 annotations that identify attributes in the object's definition and values ​​for those attributes (1204). For example, the custom dynamic value validator of FIG. 10A and FIG. 10B may be annotated with the @DynamicValue annotation from FIG. 7. The annotation may include an attribute name that identifies an attribute in the object's definition along with the corresponding value for 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 validators may be received by the framework when the framework extends the abstract base class. The validators may also implement a Boolean function (e.g., an isValid( ) function) that returns an indication of whether the value passes the constraints. The validators may include user-defined code that implements constraints such as format, minimum, maximum, range, and / or any other variable constraints.

[0042] The method may additionally include identifying one or more validators whose values ​​of the attributes in the instance of the object match the values ​​of the attributes in the annotations (1206). For example, the DynamicValidator class of FIG. 9A may identify all of the validators in the runtime path or otherwise associated with the program. A constructor for the DynamicValidator may then cycle through each of the available validators and identify a validator whose annotation (e.g., 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., multiple) DynamicValue annotations, each of which may be satisfied to run the validator on the object instance.

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

[0044] It should be understood that the specific steps illustrated in FIG. 12 provide a particular method of performing dynamic verification, according to various embodiments. Other sequences of steps may also be performed in accordance with alternative embodiments. For example, alternative embodiments may perform the steps outlined above in a different order. Additionally, individual steps illustrated in FIG. 12 may include multiple sub-steps that may be performed in various sequences depending on the needs of the 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 of the steps of these methods may be performed automatically by the computer system and / or may be provided with input / output involving a user. For example, a user may provide inputs for each step of a method, and each of these inputs may be responsive to a particular output that requests such input, which is generated by the computer system. Each input may be received in response to a corresponding requested output. Furthermore, an input may be received from a user as a data stream from another computer system, retrieved from a memory location, retrieved over a network, or requested from a web service. Similarly, an output may be provided to a user as a data stream to another computer system, stored in a memory location, transmitted over a network, or provided to a web service. In short, each of the steps of the methods described herein may be performed by a computer system and may include any number of inputs, outputs, and / or requests to and from the computer system, which may or may not involve a user. Steps that do not involve a user may be said to be performed automatically by the computer system without human intervention. Thus, in light of this disclosure, it will be understood that each step of each method described herein may be modified to include inputs to and outputs from a user, or may be performed automatically by a computer system without human intervention, where any decisions are made by a processor. Additionally, 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] 13 shows a simplified diagram of a distributed system 1300 for implementing one embodiment. In the illustrated embodiment, the distributed system 1300 includes one or more client computing devices 1302, 1304, 1306, and 1308 configured to execute and operate client applications, such as web browsers, proprietary clients (e.g., Oracle Forms), etc., over one or more networks 1310. A server 1312 may be communicatively coupled to the remote client computing devices 1302, 1304, 1306, and 1308 over the network 1310.

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

[0048] In the illustrated configuration, 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 a variety of different system configurations are possible that may differ from the distributed system 1300. The illustrated embodiment is thus an example of a distributed system for implementing the system of the embodiments 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, cellular phone, iPad, computing tablet, personal digital assistant (PDA)) or wearable devices (e.g., Google Glass head mounted display) running software such as Microsoft Windows Mobile and / or various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 10, Palm OS, and Internet, email, short message service (SMS), Blackberry, or other enabled communication protocols. The client computing devices may be general purpose personal computers, including, by way of example, personal computers and / or laptop computers running various versions of Microsoft Windows, Apple Macintosh, and / or Linux operating systems. The client computing devices may be workstation computers running any of the various commercially available UNIX or UNIX-like operating systems, including, by way of example, various GNU / Linux operating systems such as Google Chrome OS. Alternatively, or in addition, client computing devices 1302, 1304, 1306, and 1308 may be any other electronic device, such as a thin-client computer, an Internet-enabled gaming system (e.g., a Microsoft Xbox game console with or without a Kinect® gesture input device), and / or a personal messaging device, capable of communicating over network 1310.

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

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

[0052] The servers 1312 may be comprised of one or more general purpose computers, dedicated server computers (including, by way of example, PC (personal computer) servers, UNIX servers, mid-range servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or any other suitable configurations and / or combinations. In various embodiments, the servers 1312 may be adapted to execute one or more services or software applications described in the preceding disclosure. For example, the servers 1312 may correspond to servers for executing the processes described above in accordance with certain embodiments of the present disclosure.

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

[0054] In some implementations, 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. By way of example, the data feeds and / or event updates may include, but are not limited to, Twitter® feeds, Facebook® updates, or real-time updates received from one or more third party sources and continuous data streams that may include real-time events related to sensor data applications, financial stock ticker boards, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc. Server 1312 may also include one or more applications for displaying the 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 reside in a variety of 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 or dedicated connection. In one set of embodiments, the databases 1314 and 1316 may reside within a storage area network (SAN). Similarly, any necessary files to perform the functions ascribed to the server 1312 may be stored locally on the server 1312 and / or remotely, as appropriate. In one set of embodiments, the databases 1314 and 1316 may include relational databases, such as those provided by Oracle, adapted to store, update, and retrieve data in response to SQL-formatted commands.

[0056] 14 is a simplified block diagram of one or more components of a system environment 1400 that may provide services provided by one or more components of an embodiment system as cloud services, according to one embodiment of the disclosure. In the illustrated embodiment, the system environment 1400 includes one or more client computing devices 1404, 1406, and 1408 that may be used by a user to interact with a cloud infrastructure system 1402 that provides cloud services. The client computing devices may be configured to run a client application, such as a web browser, a proprietary client application (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 other components than those shown. Additionally, the illustrated embodiment is only one example of a cloud infrastructure system that may incorporate an embodiment. In some other embodiments, cloud infrastructure system 1402 may have more or fewer components than shown, may combine two or more components, or may have a different configuration or arrangement of components.

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

[0059] Although the exemplary system environment 1400 is shown with three client computing devices, 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 communication and exchange of data between clients 1404, 1406, and 1408 and cloud infrastructure system 1402. Each network may be any type of network capable of supporting data communications using any of a variety of commercially available protocols, including those described above for network 1310.

[0061] Cloud infrastructure system 1402 may include one or more computers and / or servers, which may include those described above for server 1312.

[0062] In an embodiment, the services provided by a cloud infrastructure system may include a host of services made available to users of the cloud infrastructure system on demand, 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, etc. The services provided by the cloud infrastructure system may be dynamically scaled to meet the needs of its users. A particular instantiation of a service provided by the cloud infrastructure system is referred to herein as a "service instance." In general, any service made available to users from a cloud service provider's system over a communications network such as the Internet is referred to as a "cloud service." Typically, in a public cloud environment, the servers and systems that make up the cloud service provider's system are distinct from the customer's own on-premise servers and systems. For example, the cloud service provider's system may host an application, and a user may order and use that application on demand over a communications network such as the Internet.

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

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

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

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

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

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

[0069] By utilizing the services offered by the PaaS platform, customers can adopt programming languages ​​and tools supported by the cloud infrastructure system and also control the deployed services. In some embodiments, the platform services offered 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 services may support a shared services deployment model that allows organizations to pool database resources and provide database-as-a-service to customers in the form of a database cloud. The middleware cloud services may provide a platform for customers to develop and deploy various business applications, and the Java cloud services may provide a platform for customers to deploy Java applications in the cloud infrastructure system.

[0070] A variety of different infrastructure services may be provided by the IaaS platform in a cloud infrastructure system that facilitates management and control of underlying computing resources, such as storage, network, and other fundamental computing resources, for customers that use the services provided by the SaaS and PaaS platforms.

[0071] In an embodiment, 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, infrastructure resources 1430 may include a pre-integrated and optimized combination of hardware, such as servers, storage, and networking resources to run the services offered by the PaaS and SaaS platforms.

[0072] In some embodiments, resources in the cloud infrastructure system 1402 may be shared by multiple users and dynamically reallocated per demand. In addition, resources may be allocated to users in different time periods. For example, the cloud infrastructure system 1430 may allow a first set of users in a first time period to utilize resources in the cloud infrastructure system for a specified number of hours, and then reallocate the same resources to another set of users in a different time period, thereby maximizing utilization of the resources.

[0073] In an embodiment, several internal shared services 1432 may be provided that are shared by different components or modules of cloud infrastructure system 1402 and by services provided by 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 whitelist services, high availability, backup and recovery services, services to enable cloud support, email services, notification services, file transfer services, etc.

[0074] In particular embodiments, 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, cloud management functions may include capabilities for provisioning, managing, tracking customer subscriptions received by cloud infrastructure system 1402, and the like.

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

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

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

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

[0079] At operation 1438, the order information is forwarded 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 validating the order and booking the order once verified.

[0080] At operation 1440, information regarding the order is communicated to the order orchestration module 1422. The order orchestration module 1422 may utilize 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 management of business processes associated with each order and applies business logic to determine whether the order should proceed to provisioning. At operation 1442, upon receiving a new subscription order, the order orchestration module 1422 sends a request to the order provisioning module 1424 to allocate resources and configure resources needed to fulfill the subscription order. The order provisioning module 1424 enables allocation of resources for services ordered by a customer. The order provisioning module 1424 provides a level of abstraction between the cloud services offered by the cloud infrastructure system 1400 and the physical implementation layer used to provision resources to provide the requested services. Thus, the order orchestration module 1422 may be insulated from implementation details, such as whether services and resources are actually provisioned on the fly or pre-provisioned and allocated / allocated only on demand.

[0082] At operation 1444 , once the services and resources have been provisioned, a notification of the rendered services may be sent by the order provisioning module 1424 of the cloud infrastructure system 1402 to the customer on the client device 1404 , 1406 and / or 1408 .

[0083] At 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 and down time.

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

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

[0086] Bus subsystem 1502 provides a mechanism for allowing the various components and subsystems of computer system 1500 to communicate with each other as intended. Although bus subsystem 1502 is shown diagrammatically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. 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 MicroChannel Architecture (MCA) bus, an Enhanced 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 may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers) and controls the operation of the computer system 1500. One or more processors may be included in the processing unit 1504. These processors may include single-core processors or multi-core processors. In particular embodiments, the processing unit 1504 may be implemented as one or more independent processing units 1532 and / or 1534, with a single-core processor or a multi-core processor included in each processing unit. In other embodiments, the processing unit 1504 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

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

[0089] The I / O subsystem 1508 may include user interface input devices and user interface output devices. User interface input devices may include a keyboard, a pointing device such as a mouse or trackball, a touchpad or touch screen integrated into 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. User interface input devices may include motion sensing and / or gesture recognition devices such as a Microsoft Kinect® motion sensor that allows a user to control and interact with an input device such as a Microsoft Xbox® 360 game controller through a natural user interface using gestures and spoken commands. User interface input devices may also include eye gesture recognition devices such as a Google Glass® blink detector that detects eye movements from a user (e.g., "blinking" while taking a picture and / or making a menu selection) and translates the eye gestures as input to an input device (e.g., Google Glass®). Additionally, the user interface input devices may include a voice recognition sensing device that allows a user to interact with a voice recognition system (e.g., the Siri® navigator) via voice commands.

[0090] User interface input devices may also include, but are 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. In addition, user interface input devices may include medical imaging input devices, such as, for example, computed tomography, magnetic resonance imaging, positron emission tomography, medical ultrasound machines, etc. User interface input devices may also include audio input devices, such as, for example, MIDI keyboards, digital musical instruments, etc.

[0091] User interface output devices may include non-visual displays such as a display subsystem, indicator lights, or audio output devices. The display subsystem may be a flat panel device such as one using a cathode ray tube (CRT), liquid crystal display (LCD) or plasma display, a projection device, a touch screen, etc. In general, use of the term "output device" is intended to include all conceivable types of devices and mechanisms for outputting information from computer system 1500 to a user or to another computer. For example, user interface output devices may include, but are not limited to, various display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, automobile navigation systems, plotters, audio output devices, and modems.

[0092] Computer system 1500 may also include a storage subsystem 1518 that includes software elements currently shown as located in system memory 1510. System memory 1510 may store program instructions loadable and executable on processing unit 1504, as well as data generated during the execution of these programs.

[0093] Depending on the configuration and type of 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 and / or currently being operated on and executed by the processing unit 1504. In some implementations, the system memory 1510 may include a number of different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, a basic input / output system (BIOS), containing the basic routines that help to transfer information between elements within the computer system 1500, such as during start-up, may typically be stored in ROM. By way of example and not limitation, the system memory 1510 also illustrates application programs 1512, program data 1514, and an operating system 1516, which may include client applications, a web browser, a mid-tier application, a relational database management system (RDBMS), and the like. By way of example, operating system 1516 may include various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux® operating systems, various commercially available UNIX® or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome® OS, etc.), and / or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® 10 OS, and Palm® OS operating systems.

[0094] The storage subsystem 1518 may also provide a tangible computer-readable storage medium for storing the basic programming and data constructs that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by a processor, provide the functionality described above 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] 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. Along with, and optionally in combination with, the system memory 1510, computer readable storage medium 1522 may collectively represent remote, local, fixed, and / or removable storage devices plus storage media for containing, storing, transmitting, and retrieving computer readable information on a temporary and / or more permanent basis.

[0096] The computer readable storage medium 1522 containing the code or portions of code may 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 manner or technology for the storage and / or transmission of information. This may 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, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage, or other tangible computer readable medium. This may also include non-tangible computer readable media, such as a data signal, data transmission, or any other medium that can be used to transmit the desired information and that can be accessed by the computing system 1500.

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

[0098] The communications subsystem 1524 provides an interface to other computer systems and networks. The communications subsystem 1524 serves as an interface for sending and receiving data between other systems and the computer system 1500. For example, the communications subsystem 1524 may enable the computer system 1500 to connect to one or more devices via the Internet. In some embodiments, the communications subsystem 1524 may include a radio frequency (RF) transceiver component for accessing wireless voice and / or data networks (e.g., using cellular telephone technology, advanced data network technologies such as 3G, 4G, or EDGE (Enhanced Data Rates for Global Evolution), WiFi (IEEE 802.11 family of standards, or other mobile communications technologies, or any combination thereof), a global positioning system (GPS) receiver component, and / or other components. In some embodiments, the communications subsystem 1524 may provide wired network connectivity (e.g., Ethernet) in addition to or instead of a wireless interface.

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

[0100] As an example, the communications subsystem 1524 may be configured to receive data feeds 1526 in real time from users of social networks and / or other communications services, such as web feeds such as Twitter® feeds, Facebook® updates, Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third party sources.

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

[0102] The communications 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 may be in communication with one or more streaming data source computers coupled to the computer system 1500.

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

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

[0105] In the preceding description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the various embodiments. It will be apparent, however, 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 exemplary embodiments provides an enabling description for implementing at least one embodiment. It should be understood that various changes can be made in the function and arrangement of elements without departing from the spirit and scope of an embodiment as set forth in the claims.

[0107] In the above description, specific details are given to provide a thorough 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 in order to avoid obscuring the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

[0108] It should also be noted that particular embodiments may be described as a process that is 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 may be performed in parallel or simultaneously. In addition, the order of operations may be rearranged. A process is terminated when the operations are completed, but may have additional steps not included in the diagram. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. Where a process corresponds to a function, its termination may correspond to a return of the function to the calling function or to 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 capable of storing, containing, or carrying instructions and / or data. A code segment or machine-executable instructions 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, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.

[0110] Furthermore, the embodiments may be implemented in hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine-readable medium. The necessary tasks may be executed by a processor.

[0111] In the foregoing specification, aspects of various embodiments are described with reference to specific embodiments thereof, but all embodiments are not limited thereto. Various features and aspects of the above-described embodiments may be used individually or together. Moreover, 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 the specification. Thus, the specification and drawings should be regarded as illustrative rather than restrictive.

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

Claims

1. 1. A program comprising instructions that, when executed by one or more processors, cause the one or more processors to perform operations, the operations comprising: In a programming language framework, the method includes receiving an instance of an object, the definition of the object being annotated with constraints, the operation further comprising: receiving, in the programming language framework, one or more validators annotated with an annotation, the annotation comprising: an attribute in said definition of said object; and a value for the attribute, the programming language framework including a definition of an abstract class from which each of the one or more validators is inherited, the abstract class including a protected function that validates an object against a custom constraint, and the operation further comprising: identifying, in the programming language framework, one of 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.

2. The program of claim 1 , wherein the validator validates values ​​of additional attributes in the definition of the object.

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

4. The program of claim 1, wherein the constraints annotating the definition of the object cause the programming language framework to use dynamic validation rather than static validation.

5. The program of claim 4 , wherein the programming language framework includes a definition for the constraint that annotates the definition of the object, the definition for the constraint specifying that the constraint may be executed on an object type target.

6. The program of claim 1 , wherein the programming language framework includes definitions for the annotations that annotate the one or more validators, the definitions including attribute names and attribute value patterns.

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

8. The program of any one of claims 1 to 7, wherein the programming language framework includes definitions of classes for scanning a classpath and identifying each of the one or more validators in the classpath.

9. 9. The program of claim 8, wherein the definition of the class includes a function that filters out those of the one or more validators where the value of the attribute in the instance of the object does not match the value of the attribute in the annotation.

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

11. 9. The program of claim 8, wherein the definition of the class is first subjected to any static verification and then any dynamic verification.

12. The program of claim 1 , wherein the instance of the object includes the attribute and an additional attribute.

13. The program of claim 12 , wherein the attribute determines which of the one or more validators should be used to validate a value assigned to the additional attribute.

14. 14. The program of claim 13, wherein the attribute comprises a key and the additional attribute comprises a value in a key-value pair.

15. The program of claim 14 , wherein the key indicates a data type of the value.

16. the validator is annotated with additional annotations that identify additional attributes in the definition of the object and additional values ​​for the additional attributes; The program of claim 1 , wherein a value of an additional attribute in the instance of the object matches the additional value of the additional attribute in the additional annotation of the validator.

17. 1. A system comprising: one or more processors; and one or more memory devices containing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations, the operations including: In a programming language framework, the method includes receiving an instance of an object, the definition of the object being annotated with constraints, the operation further comprising: receiving, in the programming language framework, one or more validators annotated with an annotation, the annotation comprising: an attribute in said definition of said object; and a value for the attribute, the programming language framework including a definition of an abstract class from which each of the one or more validators is inherited, the abstract class including a protected function that validates an object against a custom constraint, and the operation further comprising: identifying, in the programming language framework, one of 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.

18. 1. A method for performing dynamic verification in a programming language framework, comprising: The method includes one or more processors receiving, in a programming language framework, an instance of an object, a definition of the object being annotated with constraints, the method further comprising: The one or more processors receive, in the programming language framework, one or more validators annotated with an annotation, the annotation comprising: an attribute in said definition of said object; and a value for the attribute, the programming language framework including a definition of an abstract class from which each of the one or more validators is inherited, the abstract class including a protected function that validates an object against a custom constraint, the method further comprising: the one or more processors identifying, in the programming language framework, one of the one or more validators, a validator in which a value of the attribute in the instance of the object matches the value of the attribute in the annotation; and wherein the one or more processors execute the validator using the instance of the object.

Images