I discussed on my previous article about REST and how to leverage RESTful web services on Grails platform. We will further discuss Grails on SOA & REST and try to visualize architecture in details.
REST and SOA are different architecture pattern with lots of commonality to make application highly interoperable.
As per Thomas Erl SOA is “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.”
Both SOA and REST architecture considerations are independent of technologies and represents how data communicate between and what guideline need to follow during data transfer between distributed systems to make them more interoperable.
RESTful web services with conjunction with SOAP can bring REST’s simplicity, flexibility, and low overhead without compromising the power or manageability of service-oriented solutions and architectures.
Without debating on RESTful and SOAP I would like discuss further that how we realize both using Grails application framework
Below diagram depicts realization of SOA and REST using grails:
Components: A components Is an encapsulated, independent part of systems build based on Object – Orients software principles. It will be accessed by Service layer by well-defined interfaces. Service components could be POJO based Grails Domain or Grails’ plug-ins or plain Groovy or Java components.
Composites Services: A services uses individually developed components and wired them to bring high reusable, flexible and extensible business services which could be exposed and consumed by distributed systems. This is one level above than Components layer and could be Groovy, JAVA or Grails defined services. Spring’s Dependency Injection pattern will be leveraged to access components.
Service Resources: This layer contains all the business services use by resource services in the form of GET, POST, PUT and DELETE. Service Resources Resource Services are light weight, stateless and independent services communicate with consumer via HTTP(s) protocols over various data format such as XML, JSON, MIME, Byte etc. Service resources access business process or composite service and expose into outer world on HTTP(s) protocols.
Business Process: A process is considered to be an abstract specification of business aligned IT functions and used by resource services or distributed system. Business processes orchestrate/ choreograph business composite services to perform well-defined business functionality. These processes depend on the services layer to provide the building blocks for necessary functionality. Grails provide automated dependency injection powered spring core DI for Groovy and Java and Grail Services.
Integration (ESB): This layer provides a mechanism to expose the services. The resource services expose using RESTful web services and business processes and services exposes using SOAP based web services. It may also provide message transformation, routing decisions, and protocol conversion capabilities.
Quality of Services: This layer provides services to enable infrastructure services for the solution and ease runtime environment management and monitoring.
Conclusion: SOA and REST both are architectural style can be used together to deliver scalable, interoperable solution in enterprise environments.
References:
- http://www.soapatterns.org/
- Service-Oriented Architecture (SOA): Concepts, Technology, and Design by Thomas Erl
- http://www.ibm.com/developerworks/webservices/library/ws-soa-ref-arch/
