- Use of Service-Oriented Design in the Wild
- Service-Oriented Design Versus Service-Oriented Architecture Versus RESTful-Oriented Architecture
- Making the Case for Service-Oriented Design
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
Service-Oriented Design Versus Service-Oriented Architecture Versus RESTful-Oriented Architecture
There are many approaches to designing a service-oriented application. This book takes an approach slightly different than those espoused in Java books on service-oriented architecture (SOA) or even other books that focus on REST. Within the community of professionals building service-based systems there is a bit of debate about the proper use of terminology and what qualifies as best practices.
SOA has become a loaded term. To many people, it implies the use of tools such as SOAP, WSDL, WS-*, or XML-RPC. This implication is why the title of this book uses the word design as opposed to architecture. Even so, this book does focus on architecture. The real goal of service-oriented design is to create simple and agile services layers that can be consumed without the use of generators or strict schemas. In this regard, the style in this book is more in line with REST-based web services than with SOA.
In the book RESTful Web Services,2 Leonard Richardson and Sam Ruby discuss the details for a concept they call resource-oriented architecture (ROA). ROA represents their approach for HTTP-based RESTful design and architecture. Richardson and Ruby lay out the concepts of resources, URIs, representations, and links. They also state that ROA has properties of addressability, statelessness, and connectedness, as well as a uniform interface. When it comes to the design of specific services, this book follows Richardson and Ruby's guidelines. (The appendix, "RESTful Primer," provides an overview of REST.)
The real difference between the focus of this book and that of RESTful Web Services lies in the interaction points—that is, how services interact with each other to create a complete working application. The focus of this book is on internal services instead of external ones. While some of an application's services can be exposed to external consumers, their real purpose is to serve other developers working within a single organization. In this regard, this book has more similarity to what one would commonly refer to as SOA. This book also includes a more specific focus on deploying and developing with Rails, Sinatra, and other Ruby libraries and tools.
Of course, SOA, ROA, and RESTful are all meant as guidelines. In the real world, it makes sense to flex a design with the needs of the application rather than adhere to the dogma of a prescribed approach such as REST or SOA. This book takes a pragmatist's view and focuses on what these things mean for a Ruby environment that uses services as part of the core infrastructure for delivering an application or a web page to a user.