Investigation of Clamp Common Parameter Handling and Validation.

Page for general findings around the investigation of the current clamp common parameter handling and validation and its possible implementation with the Spring boot framework. This investigation also addresses the possible benefits to using Spring boot validation and also the java x Bean validation API.

Current Clamp Common.

At present the common parameter handling and validation comprises of multiple classes and interfaces and perform cross field validation. The current implementation of bean validation is quite flexible as it has its own annotation interface declarations that allow for custom constraints logic as illustrated in the image below.

Although Spring validation and java x validation offer their own annotations and error handling, it is believed that the validation checking that these constraint annotations enforce does not at times provide the same level of validation that the current common provides which, may have a work around that will involve utilizing self-defined annotation and validation classes like the one shown in the figure above along with the API defined annotations.

Validation design.

1. Custom defined annotations that can be used across all packages to provide common constraints.
2. Custom validation rules through multiple validation classes and result storing with result implementations based on the validation results.
3. Logic implemented in the validation classes is custom changeable to requirements and easy to implement for cross field validation.
4. Shares similar structure and implementation to spring MVC validation of custom constraints which, could be considered a positive when formulating a work through for the policy common to be constructed using the Spring boot framework.
5. Multiple validation classes allow for cross field validation providing a real common parameter library.

Spring boot validator or Java x validation.

When converting to spring boot there are options available when validating but, at times the differentials between these validation API’s can be difficult to make. The question of whether there is a difference between these API’s is not made evident as the Spring boot validation API and Java x validation API have the potential to be used at any given time .If one did not wish to perform bean validation and simply validate objects or data types at the class level then that can be achieved by standard Spring validation. An example can be seen in the image below.

Spring validation allows for annotation constraint validation and creation for data types and objects at class level. To use validation the spring boot starter validation dependency must be specified but this also gives access to the java x validation API which from what can be gathered from documentation online can be added as a dependency on its own using the java x dependency or the hibernate validator which will be further explained.

Java x validation (Bean Validation API) .

Incorporating the javax bean validation API aka JSR-380 or JSR-303 into the current common in my opinion can be achieved for the most part. Spring boot validation along with custom annotations would be required in order to ensure that the correct level of constraint has been achieved, if replicating current validation is necessary.  Specific constraints and validation rules can be crafted for handling common parameters using the java validation API if required or one can do class level two step authentication as seen below.

This level of validation uses the validated annotation from the spring validation library and provides pre validation on parameters being sent to the class or application. The second level of validation is provided by the java x valid annotation. This will ensure that the object on which it is called satisfy the constraint, whether that be its data type, content, length and so on. Utilization of the libraries like this is suitable for restructuring at class level for components like participants or runtime parameter handling but do not provide a common parameter handling solution. To achieve this I believe that, depending on the needs of the project or design decisions it can be achieved using the following methods.

• Decide on what library is best suited for the job, in my opinion the spring boot starter validator or hibernate validator will work but I do not know the memory implications that come with each at initial run.

• The next step will be to create the annotation interfaces that will define the class that will validate the constraint whenever the annotation is used.

• Next, validation logic must be created for the annotation and this will be a custom constraint that can be reused throughout the project.

• Once we have enough custom validators we need to focus on bean validation which can prove to be tricky to accomplish seeing as a validation class cannot be created to validate every bean when desired. Instead a validator factory can be created and the value extractor functionality if required to cycle through the resulting list from the violator. However, this does include writing an extraction method for the desired class or object that implements the value extractor.

• Alternatively, and perhaps preferably a validator factory can be created manually and a set of violations can be created to hold the results of the validation. It is simply a case then of passing the required bean to the validate method and iterating through the set using the get message method to return any violations that may have occurred specified by the annotations in the bean that is being validated.

Benefits of Spring Validation and Spring Boot.

• Speed

  • Spring boot allows for rapid assembly and deployment of applications and may show optimization in the parameter handling if performed efficiently. It also provides conflict free versioning through dependency management in the POM's.

• Testing

  • Testing will always be an important factor in the project and I believe that the Spring Boot framework will ease this process as it has its own testing library and annotations to allow for easy creation of tests and inversion of control. Spring boot also brings with it the benefits of mocking beans in our testing easing up on the amount of testing code written.

• Properties Configuration

  • No XML based configurations at all. Very much simplified properties. The beans are initialized, configured and wired automatically.

• Community Support.

  • Put simply, Spring Boot is a popular framework used in development and therefore has a big community of developers behind it. This gives rise to beliefs that support on bugs and security issues may be addressed and documented by developers in the community and fixes made as soon as documented. This provides a layer of support and security that for lack of words a homebrew parameter handler can offer. The spring home page has a lot of documentation and forums that can provide aid for developers and tutorials on design patterns and so on. 

• Code Readability.

  • A minor but still notable benefit of the Spring boot framework for the policy common is readability. This could be personal preference but the class level annotation constraints and properties configuration of a Spring boot application can be easier to maintain and follow for developers but as stated this can be preference. 

Current known implications of operating in the spring boot framework.

I can state that implementing the current common using the Spring Boot framework is possible and can offer benefits to the project going forward there are some blockades that must be addressed and decided upon before proceeding with the implementation of the parameter handling in Spring and they are as follows.

• Code Restructure.

  • Restructuring the current parameter handling to meet the standard of the current common can be done but not without resources and time. There is also the fact that restructure in the common parameters may effect other packages and there functionality in the process. Do the benefits out weigh the resources required.

• Custom Constraints to meet validation requirements that Spring Boot cannot.

  • Other investigations have shown that the current annotations and validation method have a greater flexibility and validation processing than the level that can be achieved with the standard java x validation API. In order to counteract this fact, custom constraints and validation rules will have to be written when converting to Spring Boot to ensure that no integrity is lost in comparison to the original methodology.

• Bean Validation.

  • This issue is discussed in the java x validation paragraph of this paper along with my thoughts on a solution.

• Security.

  • Security issues arise with spring boot mainly due to bad practice or not preparing for a possible attack in database creation primarily. Injection attacks are always a possibility if not accounted for.

• Parameter Structure.

  • Spring boot uses a properties or YAML file to define the configuration of the application.
  • These configuration files are beneficial as they allow for handling of data types such as lists, maps, scalars and so on in the spring boot application.
  • The majority of participants communicate and receive messages from other sources such as Dmapp. These messages are in Json format which cannot be handled due to the configuration being defined as a properties or YAML file and will require translation before being able to be validated.

• Deployment Size.

  • Spring boot has the potential to add to the deployment binary size if there are any unused dependencies in the project.