cetia4

The REST architecture has become increasingly popular in the creation of flexible web service applications and SOA-based systems. However, the lack of a java servlet-based framework has affected its adoption for java platform projects.

The Cetia4 REST Framework uses a simple but powerful abstraction that allows the easy creation of a Java Servlet-based application that can work as:

a web application that may be accessed by a typical web browser or any stateful web-enabled client, and/or
a REST web service application that may answer HTTP stateless requests.

The Cetia4 framework released here is usable, and its main features have been programmed. However, there are still a lot of things to do, so if you want to join actively the project, please let us know. We are particularly interested in exploring new usages and applications of the framework, as we believe a REST-based architecture can be very flexible and can lead to interesting implementations.

For more information on the framework please refer to this
link.

NUEVO!!! Tutoriales de Cetia4 en Español. La explicación de la aplicación de ejemplo
forum_injection ( disponible en el área de Documents &
files )
se explica en una serie de Tutoriales en Español. Entrar al sitio web de Acsinet, y seleccionar la sección de Tutoriales en Línea.

20/Jun/2007 - Version 1.1 of the framework is finally released !!! More examples in line will follow soon.

29/Mar/2007 - Version 1.1 features are almost finished, and now we will focus in providing good documentation before officially anouncing the next release.

We believe this version shows how easy and elegant an application can be built using REST principles. However, we know some important parts are still missing and that's what we will be covering with the next ( maybe 2.0 ) version. Much of these ideas are already in design stage and no longer floating in the air like before, so the future evolution of the framework is clearer now:

Until now the framework has been presented as a convenient way to build applications that work on both XML web service and traditional web environments using a same code base using REST principles. What we want next is to leverage the simplicity of such architecture and fully embrace the emerging wave towards a semantic web. One of the biggest refactorings already made in Cetia4 v.1.1 was internally implementing it as a hierarchy of resources, while maintaining its simplicity from the point of view of a regular programmer. Now we need these resources to be autodescriptive.
The first step in order to achieve this goal is that the data structures used to receive data and the XML documents returned from a call to a service must fall into a defined schema. But we also want to provide this without having the developer to define such schema manually for each and every possible call if he doesn't want to. We want to continue providing the option of fast development if that is what is wanted. And we want to also provide the option of manually defining the schemas if that is also what is wanted. We know, that a lot of efforts have been done elsewhere to provide easy ways to perform these types of service descriptions in an easy way. But we also know that the adoption of a RESTful architecture simplifies much of these concerns. In short, we believe it will be easy to provide such facility within the framework to allow description of the involved message formats, and at the same time such facility will allow a simple way to map objects from and to those formats. Some things will obviously change in the way data mapping in the framework works today, but we think it's worth the effort. We won't try to implement all types of mappings possible with the first release, but we will try to provide code usable enough for the most common needs.
Data may be provided on POST/PUT requests using both traditional parameters and multipart requests. The same schema facility described above will allow to transparently handle both types of requests.
In this scenario, any resource in the hierarchy may be queried directly, and will be capable of reporting it's methods, the types of requests that each may answer, the data formats that may be used with each one, and the resources that are related with any resource.
Relationships between resources may be reported as RDF or other similar format, so external agents will be able to use and work with these information. This will be the foundation for features that will allow to combine information, and present it in different ways depending on the needs of the client. A facility may be built that allows the dynamic registration of new relationships.
A convenient security mechanism will be built all around this.
Real testing of these features using all the emerging RIA libraries and standards will always be important.
JSR 311 support will also be important, if its features are flexible enough to fall into the direction that we will be giving to the framework from now on.

23/Feb/2007 - Changes planned for version 1.1 ( UPDATE: Estimated release date May 2007 ):

Everything here will be covered in the user manual and the JavaDocs.

Special _type parameter that forces a request type for cases where the
header-based approach is
not useful. _type=web for traditional web requests, _type=ws ( or
ws_stateless ) for stateless web service requests. New isWebRequest() and
isWebServiceRequest() methods in RenderContext and ActionContext.
DONE!
Special _clear parameter that if set to true cleans a session variable
before mapping it ( for traditional web requests ).
DONE!
Configuration parameters to make an application or component web service only,
or traditional web only.
DONE!
Support for Hibernate Annotation-Based Validator, and a plugin feature to add
other validation strategies if required. This plugin feature was designed to
be generic so typical extensions for the framework can be integrated here.
DONE!
Integration facilities with Spring Framework now allows to create
a model based on Spring Framework without having to necessarily
create a ServiceLocator sub-interface.
DONE!
Support for wiring model components ( declared in a Spring configuration file or
in a ServiceLocator sub-interface that may be used to communicate with any
desired implementetion ) to controller components ( servlets and nested modules ),
using simple setter methods annotated with the new ServiceReference annotation.
This will help to reduce the need to create a ServiceLocator sub-interface
for some cases.
DONE!
The ServiceInitializerBase functionality was split into two classes: one called
BasicServiceInitializer that has no Spring Framework dependencies, for applications
that will not use that framework; and another called SpringServiceInitializer. The
older class was deprecated in favor of the new ones.
DONE!
A new ResourceManager service was created to query about resources in a REST
hierarchy, and will be the base to provide extensive resource information in the
following release of the framework. Now it provides some limited ( but useful )
resource information ( methods supported by a resource, some information on
data types, etc. ), but the plan is to continuously enhance this part until
service metadata can be obtained in a convenient way.
DONE!
Some of the JPA annotations can be leveraged by the framework. Although in the
future this will not be the main source of information for resources, their
relationships and their associated data types, this can be practical in a number
of situations.
DONE!
More complete paging support - ordering and new related tags.
DONE!
The @Filter annotation was created so common filtering tasks when using Hibernate's
criteria can now be easily implemented. Other typical implementations may be
developed on top of this if desired.
DONE!
Default ping() methods to any resource via GET or POST/PUT/DELETE. They can be overriden.
DONE!
Generic classes useful for simple objects like catalogs or instances without
much business logic: GenericDAOServlet, GenericDAOModule, PagedDAOServlet, PagedDAOModule
( with or without custom filters ), FixedCatalogServlet, FixedCatalogModule,
AbstractCatalogServlet, AbstractCatalogModule.
DONE!
Ability to bind a class to a model interface, and to create default methods
based on annotations on the given interface. Coding for typical resources
can be substantially simplified with this approach. All default method
implementations can be overriden if necessary. Eight default method types can
be generated: list method, get object method, get catalog method, insert form
method, insert method, update form method, update method, and delete method.
DONE!
( Experimental ) Facilities to create a generic HTML or XML view of a
REST resource based on templates, resource information and some simple
annotations. We think this approach is very interesting, and it will be
explored until a powerful solution is reached.
IN PROGRESS! ALMOST DONE!
( Experimental ) Facilities for combining the
XML output of various resources - we eventually
want to turn this facility into a powerful resource query facility. This
facility is based on some annotations that specify relationships between
REST resources.
IN PROGRESS!
Handlers for resource hierarchies of variable depth; to model resources organized
in a tree-like fashion, like filesystem resources, directory service resources,
etc.
Restrict a method to answer just queries from a particular HTTP method; the current
default implementation treats POST/PUT/DELETE somewhat equal due to current web
infrastructure limitations, but this restriction may be useful to developers that
want a better alignment with REST original proposal.
Default mappings for nested properties.
DONE!
Tests, refactorings and bug fixes, of course.
More working examples with source code to show most of these features.