The Internet is the most essential networking environment in the world. Consequently, various designs including Web 2.0, Community 2.0, peer-to-peer architecture, Internet-scale operating system and etc are proposed to improve businesses and consumers. Based on the above, we propose a concise connectivity approach capable of increasing the serviceableness of web in wireless citywide environments and make the World Wide Web State full like desktop applications and most important accessibility. And also how can we perform a better searching in RIAs.
Traditional web applications centered all activity around a client-server architecture with a thin client. Under this system all processing is done on the server, and the client is only used to display static (in this case HTML) content. The biggest drawback with this system is that all interaction with the application must pass through the server, which requires data to be sent to the server, the server to respond, and the page to be reloaded on the client with the response. By using a client side technology which can execute instructions on the client’s computer, RIAs circumvent this slow loop. This difference is somewhat analoguous to the difference between “terminal and mainframe” and Client-server/Fat client approaches. It should be noted that Internet standards have evolved slowly and continually over time to accommodate these techniques, so it is hard to draw a strict line between what constitutes an RIA and what does not. Usually what can be done in an RIA is limited by the capabilities of the system used on the client.
Rich Internet Applications (RIA) are web applications that have the features and functionality of traditional desktop applications. RIA’s typically transfer the processing necessary for the user interface to the web client but keep the bulk of the data (i.e maintaining the state of the program, the data etc) back on the application server. RIA’s typically run locally in a secure environment called a sandbox.
Because RIAs take advantage of the client’s CPU, they offer real-time user-interface options that are not possible with the standard HTML widgets available to browser-based Web applications. This richer functionality may include anything that can be implemented in the system being used on the client side, including “drag and drop,” using a slider to change data, calculations that happen on the client (e.g., an insurance rate calculator) and do not need to be sent back to the server, etc. High interactivity of RIA applications (when compared to standard web applications) may approach that of fat clients.
The current status of RIA development and adoption
RIAs are still in the early stages of development and user adoption. There are a number of restrictions and requirements that remain:
- Browser adoption
- Web standards
- Development tools
- Accessibility concerns
- User adoption
The advent of RIA technologies has introduced considerable additional complexity into Web applications. Traditional Web applications built using only standard HTML, having a relatively simple software architecture and being constructed using a limited set of development options, are relatively easy to design and manage. For the person or organization using RIA technologies to deliver a Web application, their additional complexity makes them harder to design, test, measure, and support.
Use of RIA technology poses several new Service Level Management (“SLM”) challenges, not all of which are completely solved today. SLM concerns are not always the focus of application developers, and are rarely if ever perceived by application users, but they are vital to the successful delivery of an online application. Aspects of the RIA architecture that complicate management processes are:
- Greater complexity makes development harder.
- RIA architecture breaks the Web page paradigm.
- Asynchronous communication makes it harder to isolate performance problems.
- The client engine makes it harder to measure response time.