Grails – GORM Tutorial

Grails is known as domain driven language that means we can build application using bottom to top approach which is more nearer to object oriented programming. GORM (Grail Object Relational Mapping) uses intern Hibernate to map the domain with table which gives life to Domain modeling. If we combined everything just only based on domain we could build the whole web application. Scaffolding can bring domain design directly to visible state to business users with extra involvement Continue reading “Grails – GORM Tutorial” →

SOA and REST with Grails

In my previous articles I’ve introduced REST and how to leverage RESTful web services on the Grails platform. We will further discuss Grails in a service-oriented architecture using RESTful services, and we will try to visualize the architecture in detail. Continue reading “SOA and REST with Grails” →

Grails a Spring MVC Framework

Grails is based on the Model-View-Controller (MVC) architectural pattern and favors convention over configuration Grails framework build on top of Spring MVC. It uses URL to identify the action & view and process CRUD using domain. Business logic constitute in Grails services which could be wired with controller using Spring DI (Dependency Injection) mechanism. Continue reading “Grails a Spring MVC Framework” →

Grails – RESTful Webservice using JAX-RS plugin

I discussed about RESTful architecture consideration and how to build RESTful web services using Jersey JAX-RS [JSR 311]  in JAVA. Today I am going to discuss how to build the RESTful web services using Grails framework.

GRAILs framework is the platform which provides end to end solution to build web application from scratch to advance intuitive RIA web application. Grails potentially be a one-stop shop for all your enterprise application development. Grails is modular, allowing you to pick and choose which modules are applicable for your application Continue reading “Grails – RESTful Webservice using JAX-RS plugin” →

REST – Representational State Transfer

REST comes from Roy Fielding’s PhD paper, published in 2000, and it stands for Representational state Transfer. REST is set of architectural constrains which can apply on application design to make application more scalable, flexible, reusable, loose couple and align to business agile. Fielding’s REST guideline defines the specific role for data, component, operation, communication protocols, data consumer and producer.

REST is generic constraints for distributed technologies with no limits of technologies or stack.

Following are the constraints that define a RESTful system.

  • Should be for distributed system
  • Data communication should be stateless
  • Request should be independent and reusable
  • It has to support caching.
  • System should be access uniformly accessible
  • Desperate representation of  response
  • Standardize operations

These are independent of technology and represents how data communicate between and what’s guideline need to follow during data transfer between distributed systems.

e.g. Static web is RESTful as it follows fielding’s key guideline on REST. For instance, the existing static web  provide caching, stateless connection, the unique link to resources (HTML). On the other hand, traditional dynamic web applications haven’t always been RESTful, because they typically break some of the outlined constraints. For instance most dynamic application is not stateless.

But we can use abstraction on dynamic system that makes a RESTful system using HTTP protocols, URIs, representation and resources.