Quick start to Service Oriented Architecture
SOA, an abbreviation that is frequent in text-books, but not so much in codebases.
Lets demystify SOA.
Lets say you want to build a Flight Ticket Booking website. Basically you get the users requirements and search from expedia and other service providers.
The monolithic way of doing this is
- You make an AJAX call to your HTTP server,
- HTTP server queries the API of expedia and other service providers
- Once the API responds, your HTTP servers sends the result back to the browers (via the AJAX call)
- Your HTTP server is highly coupled with the way your service provides.
- Response Time is high. The user is kept waiting throughout this process.
- Testing and maintenace becomes very difficult with such high coupling.
- Takes up a lot of server resources and scaling becomes a pain
The Services Way
- You make an AJAX call to your HTTP server, it take the request and passes it onto a Messaging Queue.
- Your HTTP server immediately responds to the user, asking him to wait. Your HTTP server is now free of that request.
- You implementing a Booking Service, which takes the request from the messaging queue and carry's out its responsibilty and puts its reponse back
- We listen for this response and pass the information to the browser via a socket connection or a comet server.
- Responsibilities are well seperated. Your HTTP service and Booking service are no more coupled. They talk via the messaging queue
- Testing and maintenance becomes a lot easier.
- Very Responsive.
- Server Resources are freed and its easier to scale.
Have you used SOA in your architecture. What Messaging Queue did you use?