New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Srini Penchikala on Mar 02, 2010
So far in the Java Enterprise Edition (JEE) Version 6 series, we've looked at the Java API for RESTful Web Services (JAX-RS), Contexts and Dependency Injection (CDI), the Web Tier (Servlet 3, JSF 2), and EJB 3.1. In this concluding part we look at Bean Validation (JSR 303), one of the core features of JavaEE 6 release. It defines a metadata model and an API for entity validation. The default metadata source for validations is annotations, but the developers can extend the meta-data through the use of XML descriptors. The Validation API is not tied to a specific application tier or programming model so the same set of validations can be shared by all the layers of an application. It also provides a mechanism to add custom validation constraints by extending the Validation API as well as a way to query the constraint metadata repository.
Prior to Bean Validation feature in JEE6, developers had to write their validation rules in the presentation framework, then in the business layer, and also in the persistent layer and keep all of them synchronized which is time consuming and error-prone. The bean validation model is supported by constraints in the form of annotations placed on a field, method, or class of a JavaBeans component such as a backing bean. Constraints can be built-in annotations (available in the javax.validation.constraints package) or they can be user-defined. Some of the commonly used built-in annotations are listed below:
Here is an example described in Java EE 6 article, that declares some constraints through Bean Validation annotations:
public class Address {
@NotNull @Size(max=30)
private String addressline1;
@Size(max=30)
private String addressline2;
public String getAddressline1() {
return addressline1;
}
public void setAddressline1(String addressline1) {
this.addressline1 = addressline1;
}
}
The @NotNull annotation specifies that the annotated element, addressline1, must not be null. The @Size annotation specifies that the annotated elements, addressline1 and addressline2, must not be longer than the specified maximum, 30 characters.
When an Address object is validated, the addressline1 value is passed to a validator class that is defined for the @NotNull constraint as well as to a validator class defined for the @Size constraint. The addressline2 value is also passed to the validator class for the @Size constraint. The pertinent validator classes perform the validations.
Below is an example of a custom constraint named ZipCode:
@Size(min=5, max=5)
@ConstraintValidator(ZipcodeValidator.class)
@Documented
@Target({ANNOTATION_TYPE, METHOD, FIELD})
@Retention(RUNTIME)
public @interface ZipCode {
String message() default "Wrong zipcode";
String[] groups() default {};
}
You can specify the @ZipCode constraint on a class, field, or property just like any other constraint.
public class Address {
@ZipCode
private String zipCode;
public String getZipCode() {
return zipCode;
}
public void setZipCode(String zipCode) {
this.zipCode = zipCode;
}
}
Validation API describes how to programmatically validate a JavaBean. The default package for the Bean Validation API is javax.validation. Some of the classes in this API library are listed below:
ConstraintValidator: This is the interface implemented by a constraint validation implementation. It defines the logic to validate a given constraint for a given object type.
Validator: The Validator interface holds contracts to validate object graphs. The implementations of this interface must be thread-safe.
ConstraintViolation: The constraint failure on a given bean is described using ConstraintViolation interface which exposes the constraint violation context as well as the message describing the violation.
ValidationException: If some unrecoverable failure happens during validation, a ValidationException is raised. This exception can be specialized in some situations (invalid group definition, invalid constraint definition, invalid constraint declaration).
The Bean Validation specification provides a way to query the constraint repository. This API is expected to be used for tooling support as well as integration with other frameworks, libraries and JSRs. The Bean Validation specification aims to provide both a validation engine and a metadata repository for object constraints. Frameworks (Java EE or Java SE) in need for constraint definition, validation and metadata will be able to rely on the Bean Validation specification for these services avoiding any unnecessary duplication work from an application and infrastructure point of view.
The Bean Validation is integrated with JSF 2.0 and JPA 2.0 versions. In JSF, you bind form inputs to properties of your domain model. JSF 2 and Bean Validation figure out which property you are binding to and execute the constraints associated to it to expose constraint violations to the user.
Hibernate Validator 4 is the reference implementation framework of Bean Validation specification. Hibernate Validator's latest version adds some new features like validation grouping, native integration with JPA2 and JSF2, and an extended annotation set.
Srini Penchikala currently works as Security Architect and has 17 yrs of experience in software product management.
Getting Started with Stratos - an Open Source Cloud Platform
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
18 agile and lean practices for effective software development governance
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
Hi,
Just to let people know that GraniteDS 2.2 comes with an ActionScript3/Flex implementation of the JSR-303 specification. Furthermore, its code generation tools may be configured to automatically replicate Java bean constraint annotation into the generated AS3 model. Entity validation may therefore be performed in the Flex client application the same way it will be perform on server side before persistence.
See documentation here: www.graniteds.org/confluence/display/DOC22/3.+V....
FW.
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
1 comment
Watch Thread Reply