10 - Web-based Information Systems Flashcards
How does the architecture of a Web-IS look like?
Web scenario introduces separation of presentation layer
- client-side (browser), server side (web server, HTML filter)
- on top of application server middleware
Give an overview of Java Applets as a client-side approach presentation technology
Specific and dynamic clients integrated in the browser: loaded at runtime, communicate with app. server or DB, management of state
Java applets: stored in server, downloaded on client and executed in clients JVM (browser plugin)
- Security restrictions: no access to local resources, communication only with original server
- May be digitally signed
- DB access with JDBC/SQLJ (Types 3 + 4 comm. server (better but slower)) or with CORBA/Java APIs
What are the advantages and disadvantages of Applets?
Advantages
- Enhance UI, with all JAva capabilities
- Takes care of state alone
- May connect directly to DB server, comm. server (Driver type 3), app. server
- Connection preserved across iterations: long, multi-step, distributed transactions
Disadvantages
- loading time (solution keep local copy persisted, use interfaces and depay download of impl)
- security: only connection to origin allowed: DB must be in same machine (solution: signed applets)
- Transactions cannot involve client + server (passing TA-context not possible with HTTP)
- requires opening DB/app server ports to whole internet (ok in intranet)
Give an overview of server-side approaches?
Web server executes processing, communicating with DB or app. server
- Required resource (response) generated dynamically
Approaches
- CGI: separate process to process requests (not scalable)
Server API: improves CGI (no process) by providing server app. functions (SAF) on web server
Java Servlets: java version of servlet API (adr: portable, dynamic class load -> binding)
SSI: directives inside HTML, dynamically evaluated by web server
JSP: Java’s SSI: scripting elements (Java code), directives, actions (more powerful than SSL)
What are the different alternatives for managing session state?
Problem: HTTP stateless, context of client must be manged across interactions (session_ID + user_ID)
Approaches
- Form variables: (universal browser support, but force (also not persistent) dynamic HTML for inserting values)
- URL encoding: session_ID given in URL (IDs. separated from HTML, but complex realization (translation of URL) and unfriendly URLs)
- HTTP cookies: stored on client, indep. of web page (disadvantage: may be disable)
- HTTP authentication: user registration and login (automatically supported by browser + server, but reg. mandatory)
- problem with all techniques: choosing time-out
- ideal solution: middleware
Give an overview of REST
REpresentation State Transfer (architectural style for building large-scale IS)
- resources identified by URI
- uniform (HTTP) interface: GET, PUT, POST, DELETE (on resources)
- Self-descriptive messages (resources decoupled fro representation)
- Steteful interactions with state contained in messages (Self-contained): no need to keep state on server
Basis for scalability on web: caching, clustering, load balancing
RESTful Web Services: based on REST APIs, no SOAP/WSDL
- lightweight service, simple, combine with Ajax nicely
- Server-side processing
Drawnbacks: to simple (only RPC-style with HTTP, no reliability, transactions)
- SQL/HTML integration