Chapter 14. SOA Considerations
A service-oriented architecture (SOA) prescribes very little about service implementation. The only thing that can be inferred from a design being SOA is that different concerns are handled by different applications, and those applications pass messages back and forth. What language a particular application is written in, what messaging transport applications use to communicate, how the messages are structured, and even what is in the messages is up to the software architect.
That said, you don’t need to start from scratch determining a byte order for your transport layer each time you write a service. There are a handful of industry-standard approaches for service-to-service communication that you can take advantage of to get rolling right away. The two most popular have been XML-RPC and SOAP, and more recently, REST.
In this chapter, we’ll examine the pros and cons of each approach. However, before comparing and contrasting REST, XML-RPC, and SOAP—an endeavor that generally pleases no one and disgruntles everyone—we’ll first go over two sets of properties for a good service design. In the first set are properties that ensure your service is maintainable and interoperable with current and future clients. The second set is guidelines for keeping a service lean and fast.
Service Considerations
As has been mentioned, a service is accessible only through its API. The service, via this contract, is the gatekeeper of any data it manages. This leads naturally ...
Get Enterprise Rails now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
