Pervasive Web Application Architecture

PERVASIVE WEB APPLICATION ARCHITECTURE:

Requirements of computational infrastructure:

Failure management.  

Security.  

Performance.  

Dependability.

The architecture for pervasive computing applications that support multiple devices, such as PCs, WAP phones, PDA and voice-only phones enabled to access Web servers through voice gate-ways. The architecture addresses the special problems associated with pervasive computing, including diversity of devices, markup language and authentication methods shows how pervasive computing applications based on this architecture can be secured. Users have many different devices that look and behave in very different ways. Examples of several kinds of pervasive computing devices include WAP phones, PDAs, and voice-recognition devices. These devices proving different user interfaces, use different markup languages, use different communication protocols, and have different ways of authenticating themselves to servers.

Scalability and Availability are the two important issues because pervasive architecture should as scalable to meet the large amount of user who are subscribing for applications. According to scalability, when a user accessing the application and if it is not available then the user will assume that it does not works and the user will switch on to next service. Thus the service should be available whenever needed.

A scalable topology for pervasive computing is shown in the Fig. This shows several gateways used for accessing the server.

WAP gateway which executes WTLS protocol in the direction of clients and SSL in the direction of servers.  

Voice  gateways  use  voice  recognition  engine  which  consumes  more

power.  

PDA gateway for the PDAs.  

     Network Dispatcher which routes incoming request to the approporiate server. Support handling of HTTP request from a particular client is

always sent to the same server to avoid repeated SSL handshakes.  

Two dispatchers available to increase availability.  

Two firewalls are placed to perform secure connection.

Authentication proxy is placed which checks all incoming request according to security policy defined and use the credentials given by the client in order to secure transactions. Authentication proxy consumes significant computing power.  

Cluster of application servers are arranged in order to add additional machines if load increases

Development of Pervasive Computing Web Application

     Business Logic Designers, User Interface Designers, Application Programmers and experts for existing database system are the roles

assigned to implement web application.  

Application flow is designed by Business Logic Designers.  

Look and feel of the system is given by User Interface Designers.  

Programmers are concerned with technologies such as HTML and JSP and implementing the application logic.  

Those experts who monitor the gateways are responsible in knowing the technologies such as WML, Voice XML.

Pervasive Application Architecture:

The model-view-controller (MVC) pattern is a good choice when implementing Web applications.

Standard mapping of the pattern to servlets, JSPs, and EJBs, where controller is implemented as a servlet, the model implemented as a secure EJBs, and the views as JSPs..

 As devices are very different from each other, we can assume that one controller will fit all device classes. In the MVC pattern the controller encapsulates the dialog flow of an application.

 This flow will be different for different classes of devices, such as WAP phone, voice-only phones, PCs, or PDAs.

 Thus, we need different controller for different classes of devices.

 To support multiple controllers, we replace the servlet's role to that of a simple dispatcher that invokes the appropriate controller depending on the type of device being used.

Securing Pervasive Computing Application

 Web applications have to be secured by appropriate encryption, authentication, using authorization mechanisms.

 The secure pervasive access architecture is designed to process client requests on the application server in a secure and efficient way. 

 It addresses user identification, authentication, and authorization of invocation of application depending on configurable security policies.

All incoming requests originate from the device connectivity infrastructure. This infrastructure may include different kinds of gateways that convert device specific requests to a canonical form, i.e. HTTP request that may carry information about the device type, the desired language and the desired reply content type, e.g. HTML, WML, or Voice XML. Examples of gateways in the device connectivity layer are voice gateways with remote Voice XML browsers, WAP gateways, and gateways for con-necting PDAs.An important function that the device connectivity layer must provide is support of session cookies to allow the application server to associate a session with the device.The secure access component is the only system component allowed to invoke application functions. It checks all incoming requests and calls application functions according to security policies stored in a database or directory.A particular security state - part of the session state – is reached by authentication of the client using user-ID and password, public-key client authentication, or authentication with a smart card, for example. If the requirements for permissions defined in the security policy are met by the current security state of a request's session, then the secure access layer invokes the requested application function, e.g. a function that accesses a database and returns a bean. Otherwise, the secure access component can redirect the user to the appropriate authentication page.Typically, the secure access component will be implemented as an authentication proxy within a demilitarized zone as shown earlier.Finally, the output generated by the application logic is delivered back to the user in a form appropriate for the device him or her issuing. In the Figure, the information to be displayed is prepared by the application logic and passed to the content-delivery module encapsulated in beans.The content-delivery module then extracts the relevant part of the information from the bean and renders it into content that depends on the device type and desired reply content type, for example by calling appropriate JSPs.The content-delivery module delivers the content generated in the previous step via the device connectivity infrastructure that converts canonical responses (HTTP responses) to device-specific responses, using-appropriate gateways.For example, if a user accesses the system via a telephone, the voice gateway receives the HTTP response with Voice XML content and leads an appropriate 'conversation' with the user, finally resulting in a new request being sent to the server.