System Design

After the proposed technology was accepted, the technical proposal document and the requirements analysis document were sent to the lead designer in the team for detailed system design.

A high-level design diagram depicting the general dataflow in the system was created:

Whenever a customer raises a case, an ID is generated and the case details are wrapped in a JMS message and sent to the message broker's request queue. This message will be delivered to the data repository object RequestPool in the case management system, which will be listening asynchronously for messages. On message delivery, the information in the message will be used to create a case request and added into the request pool. An acknowledgement message will be sent back to the message broker's response queue with the case status set to "open". This message will be delivered to a data repository object ResponsePool in the case logging system, which will be also be listening asynchronously for messages. On message delivery, the information in the message will be used to create a case response and added into the response pool.

The helpdesk assistants can view the list of cases available in the request pool and expand individual tickets to view case details. They can also add comments and change the status of the cases. All these updates will be sent to the response queue as JMS messages and the message broker will deliver these messages to the response pool. The information in the messages will be used to create case response objects that will be stored in the pool against individual case IDs. When the status is changed to "closed", the case request will be removed from the request pool. The end users can query case history by specifying the case ID and the information will be retrieved from the response pool.

System Interaction Design

It was decided to engineer the system using a JSP presentation tier. The user actions at the browser would be routed to JSP files within the web application. The JSPs were designed with embedded custom tags that implemented the business logic and populated the HTTP Request object with JavaBeans required for rendering the data on the user's browser.

It was decided to identify the sequence of internal system interactions that were triggered by the various use cases and tie them to relevant JSPs, custom tags, and presentation wrapper JavaBeans. Subsequently the lead designer came up with a matrix depicting these relations.

Case Logging System

User/System Action	Description	JSP (.jsp)	Custom Tag	Bean	Scope
Logon	Authenticates the user	logon index	None	ResponsePool	application
Create Case	Creates a case	createcase	createCase	None	N/A
View History	Views case history	case history	viewCase	CaseResponse	request
On Message	Receives response messages from the case mgmt. system	None	N/A	N/A	N/A

Case Management System

User/System Action	Description	JSP (.jsp)	Custom Tag	Bean	Scope
Logon	Authenticates the user	logon index	None	RequestPool	application
List case	Lists all open and pending cases	listcase	listCase	CaseRequest	request
View case	Views case detail	viewcase	viewCase	CaseRequest	request
Update case	Updates case status	updatecase	updateCase	None	N/A
On Message	Receives request messages from the case logging system	None	N/A	N/A	N/A

A series of sequence diagrams were created to illustrate the various internal system interactions triggered by the use cases. The following sections explain those sequence diagrams.

The Case Logging System

This section explains the internal system interactions associated with the case logging system.

Logon

Note 

The user authentication for the case logging system was implemented using standard J2EE formbased authentication.

In the configuration file, web.xml, access to the application is restricted to users belonging to the group user. Groups and users were configured within the WebLogic application server (as will be demonstrated later). The user logon action generates the following sequence of events:

• The user is presented with the logon form defined in logon.jsp

• On successful authentication the user is presented with index.jsp

• In index.jsp a ResponsePool object is stored as an application scope bean with name responsePool

• The responsePool is initialized by passing in the ServletContext

• In the initialization method, responsePool retrieves the JMS configuration information stored in the web.xml file from the servlet context, and initializes an instance of JMSManager named responseManager

• The responseManager is used as a message consumer for the case responses sent to the response queue by the case management system

The instance responsePool implements javax.jms.MessageListener to register itself as a message listener with responseManager and on message delivery it creates instances of CaseResponse class and stores them internally.

Create Case

The following sequence of events occurs when the customer raises a case:

• The request is routed to casecreate.jsp

• In casecreate.jsp an instance of CaseCreateTag is created

• The doStartTag() method of the custom tag is called

• Instances of the servlet context and HTTP request are retrieved from the implicit variable pageContext

• The JMS configuration information stored in the web.xml file is retrieved from the servlet context

• This information is used to create and initialize an instance of JMSManager named requestManager, which will act as a message producer to the request queue

• The case details are retrieved from the HTTP request object and the IDGenerator helper class is used to get the next available case ID

• The requestManager is used to create a MapMessage and all the case details are stored in the MapMessage

• The message is the sent to the request queue using requestManager

• The case ID is stored back in the pageContext to be introduced as a scripting variable to the enclosingJSP, and sent to the user through the output of createcase.jsp for further reference

On Message

This event occurs when a case status is updated at the case management system. This sends a case response message to the response queue, which is delivered asynchronously to the application scope bean responsePool of the case logging system. This message remains in the JMS queue if the case logging system is not running and will be delivered to the system as soon as it is up and running.

The sequence of events is:

• The case response details are retrieved from the JMS message

• A CaseResponse object is created and the attributes are set

• The responsePool stores responses to a case as an array for that case ID

If the case ID for the response is already there in the pool, the response is added to the end of the list. Otherwise a new map is created for the case ID, and a new list containing the newly arrived response.

View Case History

This event occurs when the users enter a case ID and search the case update status. As already mentioned in the previous sections, whenever helpdesk assistants change the status of cases or add comments to cases using the case management system, JMS messages holding the case update information are sent to the response queue. These messages are asynchronously delivered to the application scope bean responsePool. These responses are stored by responsePool in an internal data structure as a map of case IDs to a list of responses for the case. Whenever users query case statuses by specifying case IDs, this data structure is interrogated and the result is sent back to the user.

The sequence of events is:

• The view history request is sent to casehistory.jsp.

• An instance of tag handler class custom tag caseHistory, which implements BodyTag, is created within the JSP.

• In the doStartTag() method of the custom tag, instances of servlet context and HTTP request are retrieved from the implicit variable pageContext.

• The case ID entered by the user is retrieved from the HTTP request.

• The application scope bean responsePool is retrieved from the servlet context.

• The instance responsePool is queried by passing the case ID to get a list of responses for the case ID.

• If the returned list is empty doStartTag() returns SKIP_BODY, which prevents the body of the tag from being evaluated, otherwise the first element in the list, which is of type CaseResponse, is stored in the HTTP request and EVAL_BODY_TAG is returned.

• In the doAfterBody() method of the tag handler the contents of body content is written to the enclosing writer. If there are more elements in the list retrieved in doStartTag the next element is retrieved and stored in the HTTP request and EVAL_BODY_TAG is returned. Otherwise SKIP_BODY is returned.

• The JSP declares a request scope bean of type CaseResponse, which is populated by the doStartTag() and doAfterBody() methods of the tag handler. The JSP uses the standard getProperty tags of useBean to render the data stored in the bean.

The Case Management System

This section explains the internal system interactions associated with the case management system.

Logon

Note 

The user authentication for the case management system was implemented using the standard J2EE form-based authentication.

In the configuration file for the web application, web.xml, access to the application is restricted to users belonging to the group system. Groups and users are defined within the WebLogic application server. The user logon action generates the following sequence of events:

• The user is presented with the logon form defined in logon.jsp

• On successful authentication the user is presented with index.jsp

• In index.jsp an instance of RequestPool is stored as an application scope bean named requestPool

• The instance requestPool is initialized by passing in the ServletContext

• In the initialization method, requestPool retrieves the JMS configuration information stored in the web.xml file and initializes two instances of JMSManager, responseManager and requestManager

• The instance requestManager will be used as a message consumer for the case requests sent to the request queue by the case logging system

• The instance responseManager is used for sending the initial response with status as "open" to the response queue when a case request arrives afresh

The instance requestPool implements javax.jms.MessageListener too so that it can be registered as a message listener with responseManager. On message delivery it creates instances of CaseRequest class and stores them internally.

On Message

This event occurs when a case request is raised at the case logging system. That will send a case request message to the request queue, which is asynchronously delivered to the application scope bean requestPool at the case management system.

The sequence of events is:

• The case request details are retrieved from the JMS message

• An instance of CaseRequest is created and the attributes are set

• The instance requestPool stores a map of case IDs and case requests, which can later be interrogated to get a list of pending cases or the case details for the specified case ID

• When a case request is delivered asynchronously a response message is created using the instance responseManager with status set to "open" and sent to the response pool

Case List

This event occurs when the helpdesk assistant instigates the action to list all pending cases. The case requests are stored in the application scope bean responsePool in an internal data structure as a map of case IDs to case requests. Whenever helpdesk assistants query the list of cases, this data structure is interrogated and the result is sent back to the user.

The sequence of events is:

• The list cases request is sent to listcase.jsp.

• An instance of tag handler class listCase, which implements BodyTag, is created within the JSP.

• In the doStartTag() method of the custom tag, instances of servlet context and HTTP request are retrieved from pageContext.

• The application scope bean requestPool is retrieved from the servlet context.

• The instance responsePool is queried for the list of pending cases.

• If the returned list is empty doStartTag() returns SKIP_BODY, which prevents the body of the tag from being evaluated. Otherwise the first element in the list, which is of type CaseRequest, is stored in the HTTP request and EVAL_BODY_TAG is returned.

• In the doAfterBody() method of the tag handler the body content is written to the enclosing writer. If there are more elements in the list retrieved in doStartTag() the next element is retrieved and stored in the HTTP request and EVAL_BODY_TAG is returned. Otherwise SKIP_BODY is returned.

• The JSP declares a request scope bean of type CaseRequest, which is populated by the doStartTag() and doAfterBody() methods of the tag handler. The JSP uses the standard getProperty tags of useBean to render the data stored in the bean to the user's browser.

View Case Details

These events occur when the helpdesk assistant opens the case request list to view the details of individual cases.

The sequence of events is:

• The view case detail request is sent to viewcase.jsp.

• An instance of tag handler class viewCase, which implements BodyTag, is created within the JSP.

• In the doStartTag() method of the custom tag, instances of servlet context and HTTP request are retrieved from the implicit variable pageContext.

• The application scope bean requestPool is retrieved from the servlet context.

• The instance responsePool is queried for case details for the specified case ID.

• If the requested case is not found, doStartTag() returns SKIP_BODY, which prevents the body of the tag from being evaluated. Otherwise the returned object of type CaseRequest is stored in the HTTP request and EVAL_BODY_TAG is returned.

• In the doAfterBody() method of the tag handler the body content is written to the enclosing writer. The enclosing writer for the body content is the instance of JspWriter used by the JSP enclosing the tag.

• The JSP declares a request scope bean of type CaseRequest, which is populated by the doStartTag() and doAfterBody() methods of the tag handler. The JSP uses the standard getProperty tags of useBean to render the data stored in the bean.

Update Case Status

The following sequence of events occurs when the helpdesk assistant updates a case status:

• The request is routed to updatecase.jsp

• In updatecase.jsp an instance of UpdateCaseTag is created

• This class implements the standard JSP Tag interface

• The doStartTag() method of the custom tag is called. Instances of servlet context and HTTP request are retrieved from the implicit variable pageContext

• The JMS configuration information stored in the web.xml file is retrieved from the servlet context

• This information is used to create and initialize an instance of JMSManager named responseManager, which will act as a message producer to the response queue

• The case update details are retrieved from the HTTP request

• The instance responseManager is used to create a map message and all the case update details are stored into the map message

• The map message is the sent to the response queue using responseManager

• If the case status is set to "closed", the case request is removed from the requestPool