In the most abstract view what a servlet does is transformation of a request into a response. The rest of framework is needed to properly dispatch incoming request to the concrete method call and then send the response to the right client. This functionality is identical whatsoever technology you take. Be it servlet container, or EJB container, or RMI, or WCF, etc the flow is always the same -
1) pick a remote request from the transport layer,
2) transform it into a message in memory,
3) identify the target bean and the method within it by analyzing some well-known fields of the message,
4) maybe unmarshall the parameters, and invoke the target method,
5) capture a return object (which can be void) and/or an exception, and transform it into a response,
6) identify the correct remote end-point,
7) send the response to it.
All of these operations are typically associated to each other by means of a single context that carries certain processing attributes. This context is usually called Session. Multi-threaded processing, pooling of the target bean instances, configurable dispatching rules, etc are just details that vary from one implementation to another but are usually present in some form in every framework.
So, back to servlets, what do we have there? I assume the only distinctive feature of Servlet API are Filter and Filter Chains. My understanding of a filter is that it is just another name for a request pre-processor. Originally a configurable filter chain probably was a very flexible approach. It allowed to dynamically apply a number of pre-processors to any incoming request before passing it to the target method. However, with the most recent innovations in the technology stack it now seems to be slightly outdated. Indeed, authentication, logging, auditing, compression, virtually any other application concern that would be implemented as yet another filter some time ago, now can be embedded using aspect-oriented approach, for example. In the simplest form, even if I am not using AOP, I can simply mark up the target method with the proper annotations and still be able to tell the container what pre-processing I want for this particular invocation. The major point here is that I keep mapping of incoming requests to particular methods very close to the latter ones. I don't need to maintain separate configuration files that must be kept in sync with the code.
Further on, if my service container is entirely message-driven then an entry point for every request can be defined by annotating every target method with a combination of a queue/topic and a message selector (similarly to EJB 3.0 @MessageDriven). That also gives an option to vary the pre-processing chain by creating multiple entry points for the same queue with different selectors. Lets imaging we are using JMS as the base technology. HttpServletRequest/HttpServletResponse can be transformed into JMS Message by creating JMS service provider that would expose all incoming HTTP requests as JMS Messages, and send JMS Messages back as HTTP responses. It seems that nothing prevents a URL from being presented as Message. For example, taken this URL
http://myhost.mydomain.com/mywebapp/myservlet.do?userID=1234&group=pest
the corresponding message Msg might have been structured like this (simplified):
Msg.destination = Queue(queueName="mywebapp/myservlet.do");
Msg.intProperty["userID"]=1234;Msg.stringProperty["group"]="pest";
That gives me even more than ServletRequest does where the only parameter type is String.
The major point of messaging is that it is independent of the actual transport layer. Today it is HTTP, tomorrow it is ActiveMQ or Tibco - all are handled the same way, and the server code remains the same in all cases. Even EJB and RMI internally do messaging although it is hidden from the end-user and exposed in a very simplified form. I am curious how could a typical servlet-based application look when completely migrated to a messaging platform. And there is the question - is it at all possible? If it is, then maybe it makes sense to thin out the technology forest.
No comments:
Post a Comment