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.

SOA is a useful architectural pattern that makes highly interoperable applications. According to Thomas Erl, “SOA is a term that represents a model in which automation logic is decomposed into smaller, distinct units of logic. Collectively, these units comprise a larger piece of business automation logic. Individually these units can be distributes.”

SOA and RESTfu1 are architectural considerations that exist independently from the specific technologies you use, like Java or SQL vs. NoSQL databases. It represents how data communicates between application components, and it determines the guidelines that need to be followed during data transfers betweendistributed systems. This allows a high level of interoperability if the SOA is built properly.

RESTful web services in conjunction with SOAP can add REST’s simplicity, flexibility, and low overhead without compromising the power or manageability of service-oriented solutions and architectures.

Without debating whether REST or SOAP is better, I would like discuss how we harness both using the Grails application framework

The diagram below depicts an example of SOA and REST using Grails:

Components: A components is an encapsulated, independent part of the system’s build based on OO software principles. It will be accessed by the service layer using well-defined interfaces. Service components could be POJO-based Grails Domain, Grails plug-ins or plain Groovy or Java components.

Composites Services: A composite service uses individually developed components and wires them together to create highly reusable, flexible and extensible business services that can be exposed and consumed by distributed systems. This is one level above the Components layer and can be made from Groovy, Java or Grails-defined services. Spring’s dependency injection pattern will be leveraged to access these components.

Service Resources: This layer contains all the business services used by resource services in the form of GET, POST, PUT and DELETE. Service Resource Services are lightweight, stateless and independent services that communicate with a consumer via HTTP(S) protocols over various data formats such as XML, JSON, MIME, Byte etc. Service resources access business processes or composite services and expose them with HTTP(S) protocols.

Business Processes: A business process is an abstract specification of business-aligned IT functions and used by resource services or a distributed system. Business processes orchestrate business composite services that perform well-defined business functions. These processes depend on the services layer to provide the building blocks for necessary functionality. Grails provides automated dependency injection through Spring core DI for Groovy, Java and Grails Services.

Integration (Enterprise Service Bus): The ESB layer provides a mechanism to expose the SOA’s services. The resource services are exposed using RESTful or SOAP-based web services and business processes. It may also provide message transformation, routing decisions, and protocol conversion capabilities.

Quality of Services: This layer provides services that enable infrastructure services for the solution and ease runtime environment management and monitoring.

Grails does an excellent job of helping developers use SOA and REST to deliver scalable, interoperable solutions in enterprise environments.

References: