JAWAP Architecture

JAWAP provides the developer with a three-class model on which to build a service:

 

Ø       The Servlet Class

Ø       The Server Class

Ø       The Session Class

The Servlet Class

The first class is the service itself, which is essentially an HTTP servlet extended to provide Remote Method Invocation (RMI) support. This allows the actual service logic to be implemented on a separate machine from the web server that hosts the service, thus providing the basis for load sharing. Again, this suits the 'budget' service developer, who may not be sure that scalability is required at the onset of service deployment.

 

This development approach allows easy migration to a load sharing solution, and is therefore scalable if the future need arises. As the scalability requirements become more apparent, it is possible to take advantage of the separation of service logic and servlet. It is also possible to have instances of the service logic on more than one server. To use this effectively, it is necessary to put some load distribution logic in the servlet. At the simplest level, this could be a "round robin" technique whereby sessions are activated in servers in circular order. A more complicated mechanism would be to determine which server has the highest spare capacity. This has the advantage of allowing servers to be taken out of service for maintenance without loss of service.

 

JAWAP has been designed such that if the servlet cannot reach a server over RMI, it generates a default error card. The application designer can override the information in the error card if necessary.

The Server Class

The next class of the design model is the server. This is always active during the deployment of the service, and communicates with the servlet class via RMI. Because it's always active, it is useful for things such as feed handling. An example could be a news headline service, where the headlines are fetched at ten-minute intervals and stored in the server to reduce delay and load. The server also keeps track of the active sessions of the particular service that are present at any one time.

The Session Class

The third part of the model is the session class. This provides support for sustained interactivity over HTTP to a particular session, and can significantly reduce the time and complexity of services for WAP development. Part of the session handling is a set of library methods for writing WML decks. Methods include such things as beginDeck(), setCardBreak(), and setFont().

 

A particularly useful feature of the session class is its facility for button handling. Button handling in JAWAP has characteristics that are recognizable to applet designers, and the Java applet was obviously the inspiration. It allows links to be defined as buttons, and buttons to be defined as links. When using the button functionality as a button, or a link as a button, a "button listener" method is applied; this is all handled transparently to the developer, thus assisting smooth and intuitive service creation. For examples and screenshots of how this is implemented, refer to section 9.5 of the Developers Guide.

 

Here are all the JAWAP elements and methods that a programmer can use in an application. These methods are used to generate WML decks, and roughly speaking, each method generates a section of WML.

 

Elements	Associated Class	Related Methods
User Interface	Wapplication	setParagraphStyle()
		addAnyWML()
		addWMLFile()
		setFont()
Deck	-	beginDeck()
		beginParagraph()
		beginTextStyle()
		addNewLine()
		endTextStyle()
		endParagraph()
		setCardBreak()
		endDeck()
Button	Button	add()
select + option	ExitList	add()
	Font
Img	Image	add()
Anchor	Link	link.SetFont()
		add()
select + option	List	list.add()
		add()
input	TextField	add()
	TextArea	TextArea.append()
		TextArea.setFont
		add()
timer	WAPTimer	add()
table	-	add()
		BeginTable()
		SetTableLocation()
		EndTable()

 

The session is kicked off with the abstract initialize() method being called by the server, which must be overridden. This method includes any parameters passed in the URL.