Browse Prior Art Database

Tooling system for dynamic enforcement of business conventions in J2EE development environment Disclosure Number: IPCOM000171723D
Original Publication Date: 2008-Jun-17
Included in the Prior Art Database: 2008-Jun-17
Document File: 5 page(s) / 44K

Publishing Venue



Many elements of Java EE applications can be defined through Deployment descriptors, Java annotations or both. Due to such distribution of application defining meta-data, it is hard to enforce governance conventions applicable to Java EE artifacts, such as naming conventions, security conventions, etc. The brute force approach to ensure the compliance with business/governance conventions is to review each annotated Java class and deployment descriptor, however this approach is not only error prone (reviewer might miss some files, not to notice that some information is overridden, etc) but also is not feasible in development environment that contains large number of Java EE artifacts. Another possible approach is to use some text pattern recognition based tool (like grep) that can be run on all the Java/deployment descriptor files trying to find all the occurrences of specific text pattern. However this solution has no notion of the domain specific rules applicable to certain annotations. For example @Stateless() annotation (note: no arguments specified) defined on the Java type level, defines the stateless session EJB which name is implied to be the same as the name of the type. Therefore such approach is error prone and is likely not to cover all the EJB development scenarios. The main goal of this article is to describe the extensible rule-based tooling system for detection of business convention violations in Java EE development environment. The tooling system will enable businesses with ability to quickly detect and address any non-compliances with business defined development rules. What is particularly important that such detection will occur at development time, before the code is even committed to code repository, thereby removing costs associated with post-development compliance verification. This system can also serve as a valuable learning tool for new developers to pick up knowledge about Java EE development conventions established in the given company.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 33% of the total text.

Page 1 of 5

Tooling system for dynamic enforcement of business conventions in J 2EE development environment

Tooling system is implemented as a set of plugable components that can be plugged into the existing JavaEE development environment. For the purposes of examples bellow we assume that development environment is Eclipse based, however the general concept can be applied to any other development environment as well.

Major components of the tooling system are shown in the diagram bellow

Business conventions validator (BCV)

This is the main component of the tooling system. When validation is started, BCV obtains Merged Model (Model that gives merged view of Java EE information based on information from Deployment Descriptors and Java annotations) from the development environment, OR if such model is not available, constructs this model based on the information contained in the deployment descriptors AND annotated Java files.

    When Merged model is available, BCV loads registered Rules and corresponding Rule interpreters and invokes "validate" functionality on loaded rule interpreters. In the Eclipse development environment, rules and corresponding rule handlers are registered through the extension points.

When all the rules have been processed, the results are passed to the


[This page contains 1 picture or other non-text object]

Page 2 of 5

Verification results visualizer for further processing. Verification results visualizer itself is registered with BCV through the use of extension point.

BCV implements the following interface





If the merged model representation is already available in the tooling environment, the validateModel(EObject mergedModel) method will be called. If such representation is not available, other two methods can be used and BCV will construct corresponding model underneath the covers.


As part of the system a default XML schema file (ruleDefinitionSchema.xsd ) can be provided to define the way to specify business rules in XML format. Regular expression based rule can be specified using this schema to enforce naming conventions, security checking, etc. Although the default format is provided, we realize that different companies might already have existing notations for expressing the business rules. To handle this case, the tooling system is able to handle any rule definition format as long as corresponding rule interpreter for such format is provided.

Specific files containing rule definitions are registered with tooling system through the use of extension points.

Example of using extension point for rule registration

<extension point= "" >


path= "/samples/rule.xml" >

As we can see, we specify the id that corresponds to the given rule file and the location o...