The aim of obligate is to provide a simple way of adding contracts to services.
Currently projects like Hibernate have started using annotations to define data constraints on objects, this is great to ensure data quality but doesn't help with Services which require more functional oriented, and often more complex forms of validation. Services invocations add another challenge which is that they need to have both pre-conditions, those that are evaluated before hand, and post-conditions, those that are evaluated afterwards. Another form of condition, the invariant, is the element that mustn't change between the pre and the post condition.
The aim is to enable something like the following
@precondition ("fred > barney")
@postcondition ("returnValue != null")
public String doFlintstones(int fred, int barney);
The obligate project rises out of previous experience of using approaches like Dresden OCL and other more formal approaches. The problem we found with these is that they worked great for the minority of uber-devs, but were too complex for the majority of people. The aim of obligate therefore is to provide a simple to use mechanism for the definition and evaluation of these rules. The aim of obligate is to make the addition of contracts to any form of service simple.
25th February 2006: RC1 (version 0.9.0) is now available for download and use. Its DIY at the moment as we may move to Sourceforge as it has Subversion support.
Obligate uses Java annotations, from Java SE 5 and above, to define the contracts, it operates using a ServiceLocator pattern which acts as the switch between enforcement and non-enforcement and provides the execution of the rules as required. The aim of obligate is to enable formal definition of specification via the interface, independently of the implementation. This will enable Obligate to be applied to POJO implementations as well as elements such as EJB.
One option with Obligate was to use Spring and have the conditions as aspects. This was certainly considered as an approach and might be done in future, the driver for the individuals working on the project however was applicability to a J2EE environment so it is that which will be addressed first.
Documentation is currently pretty light and just covers examples of how it works, as well as the Javadoc API