- All Implemented Interfaces:
- java.io.Serializable, javax.servlet.Servlet, javax.servlet.ServletConfig
public class QServlet
extends MessageServlet
QServlet is a servlet as an HTTP gateway of QFlow. It hosts a QFlow
instance running inside the servlet container as a web application. As a
web application, QFlow can receive JMS messages directly from web clients
and sends messages back on HTTP via the servlet. Therefore, QServlet is
the frontend and one of the reveiver of QFlow. It is responsible for
transformation between the HTTP requests/responses and JMS messages.
QServlet has 6 rulesets referenced by the URL path. The first one is /jms
for receiving event postables as the JMS TextEvents. The second is
/collectible for receiving event postables from the client and transforming
them to the collectible JMS TextEvents. The next is /event for receiving
event postables as the non-JMS events. The pre-configured RestURI is to
convert simple REST requests to JMS TextEvents. In this ruleset, the path
of /json or /xml is for posted JSON or XML data from a client. The path of
/stream is for downloading binary content from JDBC datasources, The rest
of paths are for ad hoc HTML form requests. When a web request hits one of
the URLs, the corresponding ruleset will be invoked to process the incoming
request. QServlet supports POST, GET and PUT methods. For POST or PUT, those
headers matched with HeaderRegex will be copied into the message. One of
examples with HeaderRegex is "^[Xx]-.+$" that matches all HTTP headers of
starting with "X-". In case of POST, it also supports file upload or raw
content such as xml or json.
A collectible TextEvent is a TextEvent with its message body set to the
collectible format of the original message. It is supposed to be forwarded
to remote destinations in the format of text. In order to get content of
the original message, the consumer will have to parse the message body with
the EventParser.
For ad hoc form requests, QServlet treats them in two different ways.
If the attribute of view is defined in the request and it is not empty, the
request will be converted into a TextEvent. Otherwise, if the attribute of
name is defined and it is not empty, the request will be converted to an
Event. If neither view nor name is defined, the ad hoc request will be
dropped as a bad request. Further more, if the attribute of URI is defined
and it is not empty, the request Event will be packed into collectible.
Once the incoming requests is transformed into messages, they will be
routed to the default receiver XQueue of the QFlow. After they are
processed, the messages will be retrieved as the response. Those
messages will have the requested data. Next, QServlet loads
the messages into the original request and forwards to the presentation
JSP. The presentation JSP is either defined in the incoming request or
reset in the returned message. It is used to retrieve data from the
request and render the web page for the client. If there is no
presentation JSP defined, QServlet will just set the content type
according to the type attribute of the message and write the content
of the message body to the output stream. The attribute of type can
be defined in the incoming request. It also can be overwritten by
the workflow. This is useful if the content is already a valid
web page and you do not want to modify it.
- Author:
- yannanlu@yahoo.com
- See Also:
- Serialized Form