Building an application the SOA way

After the great talk from Ole Michaelis on Service Oriented Architecture (SOA) I was inspired to come up with a better way of building a website for myself using SOA ideas.

The idea is to make use of an api service that can be called by the frontend service and by the client’s browser. This allows the frontend service to cache responses from the api and display them as static HTML, with dynamic content being loaded directly from the api service.

SOA Application Structure
Overall SOA Application Structure

 

This approach allows for a disconnection of the individual parts of the application with communication between api service and dependants via HTTP. This is important, as changes in programming languages and standards may require that your api, written in PHP, be rewritten in Javascript (Node.js). This detachment of concerns and common communication protocol allows for replacement of services with minimum disruption.

Request Lifecycle

To take you through the application structure I will use the example of a visitor arriving on a blog page.

  • The browser sends a request to the server for the page http://onmylemon.co.uk/blog, the reverse proxy then handles the request by passing it to the frontend service.
  • The frontend service (written in PHP for example) then gets a list of blog posts from the api service and stores it in local cache (this could be implemented in OPCache or any other cache service)
  • The list of blog posts supplied by the api is also cached by the api service
  • As the user scrolls down the page more posts are then required
  • The additional posts are loaded by the client’s browser using direct calls to http://api.onmylemon.co.uk/blog?count=10&page=3
  • Another client browser accesses the page http://onmylemon.co.uk/blog, again the reverse proxy passes the request to the frontend service
  • The frontend service has a cached copy of this page so it just serves this (as long as the cache has not expired)
  • As the client scrolls down the page, the next set of posts
  • The api service then responds with a cached version of the information
e
Request Lifecycle

 

As the reverse proxy does not support any caching at this stage any responses it sends would technically be uncached responses. This could however be provided using something along the lines of this ReverseProxyCachingExample. Each of the services can reside on multiple virtual or physical servers using load balancers to share requests between services.

Conclusions

Using a service oriented architecture has the following advantages:

  • Quickly exchangeable services
  • Ease of management
  • Reduction in database queries
  • Reduction in initial page load times
  • Improvements in load times for api requests

As all the services communicate with each other using a common protocol, they can be rewritten without any major headaches.

This post has been viewed 2729 times.

Leave a Reply

Your email address will not be published. Required fields are marked *