Well, the task is simple enough:
- build secured web service for mostly getting and sometimes posting data;
- REST interface is required
- but SOAP could be added later (I think that if you build SOAP web service you should wait that you'll need to provide REST API for this web service too and vise versa).
As web service is build with REST philosophy, than we need to support processing of GET, POST (well, for me it's enough) requests and return data as XML or JSON. Spring MVC as well others REST web service frameworks and API help with this too. So, what's next?
As application is build with Spring 2.5, it was the best to have some framework for building REST web service easily and easily to integrate it with Spring. Not a secret, that Spring MVC integrates with Spring better that any other web framework or REST web service framework (hm, maybe it's because it is build on Spring). Well, this is cons for using Spring MVC and it is good, but truly - this not enough yet.
Yet one requirement: SOAP web service could be added later. And if it could be added than (in most cases) it will be added. This is important, very important, because we want to build easy-to-extend software. And in case of SOAP WS I prefer to use Spring WS, that is well integrated with Spring MVC. Need also to take into consideration that some REST web service frameworks hardly integrates with Spring MVC or wanted to process all requests. That is a great pros for using Spring MVC.
You may understand what I'm implying. Yes, Spring MVC will be used to build RESTful web service.
Architecture
The main goals of architecture are:
- be scalable (not to much, but enough to process thousands of requests per hour)
- be extendable (SOAP must be easy to add)
- do what is required and nothing more
Next decisions were made:
- request should be stateless
- each request should be processed as quick as possible
- there will be 2 levels of caching: one cache for entities and queries (used by web service backend service), and another cache for rendered XML response (used by web service endpoint).
- everything that could be changed is configured through simple XML configuration (i.e. cache configuration, security configuration, business logic configuration etc.)
The main result of made decisions & rules is request processing lifecycle, that consists of next few phases:
- Authentification & Authorization (security filter)
- Getting request parameters. Web service endpoint (in our case it is SpringMVC controller) parses request parameters and validates them.
- If everything is okay than it tries to get XML response from cache and sends it as response to the client. This step is optional and is processed only if cache is enabled and client does not specify request as such that ignores cache.
- Endpoint determines the appropriate WebService backend service and run it and get results.
- Endpoint converts results into XML, prepare response and stores it at cache (if cache is enabled). After the XML response is send back to client.
So, if the request response is cached in 2nd or 1st cache levels, than response will be generated without hitting database. In my development environment caching helps to increase performance up to 1500%. In production this number is less - just 300-500%. Still these is very well.
This lifecycle helps to build a scheme of responsibilities and modules. Later each responsibility could be processed by own server or a set of servers.
Simple implemenation
Spring 2.5 gave us possibility to use annotations as for declaring services as for declaring SpringMVC controllers. Spring's annotations
Controller, RequestMapping, RequestParam and flexible politic on request handle method parameters gives us brilliant instrument for building web service endpoint.Ofcourse, hardcoding of URLs in annotations looks as not the best way for building flexible and configurable application. But, this is quite pardonable, because we will use UrlRewriteFilter. UrlRewriteFilter is very useful tool, as it will helps to rewrite URLs, get parameters from URL and do other interesting things. But for our the most important are next 2 features:
- flexibility while mapping external URLs (used by users) to internal URLS (processed by endpoint controllers)
- possibility to catch parameters from URL, e.g. http://example.com/book/edit/12 ->
http://exampl.com/book/edit?boodId=12 etc.
Lets look how we could use this features:
Let we have RESTful web service that returns XML with information with specified by id book. Web service clients could get this information by requesting url
http://ourservice.com/ws/rest/book/{bookId} (e.g. http://ourservice.com/ws/rest/book/12). Our application should handle this call and the information about book wit specified id.
Here is our web service controller:
@Controller
public class WebServiceEndpoint {
@Autowired
private BookService bookService;
@RequestMapping(value = "webservice/book", methods = RequestMethod.GET)
public ModelAndView getBook(@RequestParam(name="bookID", required=true)int bookId, Map<String, Object> model) {
model.put("book", bookService.getBookById(bookId));
return new ModelAndView("template/ws/bookInfo", model);
}
}
Code is very simple, but it's good as for sample.
So, we have controller that processes all GET requests for
'webservice/book' resource, that should have request parameter of type integer with name 'bookID'. Endpoint just call backend service, gets information about book, put it to model map and return the ModelAndView instance with simple template that will be rendered and returned to client. This endpoint controller can't be default process web service request. To redirect web service client request to our endpoint we will use UrlRewriteFilter
<rule>
<from>^/ws/rest/book/[0-9]+$</from>
<to>/webservice/book?bookID=$1</to>
</rule>
so request for resource
http://ourservice.com/ws/rest/book/12 will be rewrited by filter to http://ourservice.com/webservice/book?bookID=12.That's about all for now. The story looks to long. Most of us do not have enough time to read long articles :)
