Exam Flashcards
What is the conceptual layers in Information Systems?
There are 3 layers:
- Presentation layer: accepts request (input) and present information to user (output). UI, reports, etc.
- Application logic: implementation of services supported by the system (retrieve/modify data)
- Resource management: source of data. DB, files, “external” providers (other IS encapsulated).
What are distributed information systems?
Distributed Information Systems are composed by subsystems working together in a coordinated fashion. It may involve multiple resource managers.
We go distributed to reduce costs (vs mainframe), to have organizational separation, provide integration of existing components, increase performance and scalability.
Four variants of distribution?
We have four alternatives:
ALTERNATIVE 1: unity of distribution = transaction
ALTERNATIVE 2: unit of distribution = application component (program) (class or library)
ALTERNATIVE 3: unit of distribution = DB operation
ALTERNATIVE 4: distribution handled entirely by DB/RM
What are tiers?
Layers define a logical separation of functionality. Tiers correspond to the actual implementation architecture.
Adding tiers improve flexibility, functionality, distribution and scalability. However, decreases performance and add complex management.
Evolution from 1-tier to 2-tiers forced the definition of application logic APIs. Evolution from 2-tiers to 3-tiers forced the creation of resource management APIs (ODBC/JDBC). Evolution to N-tiers try to link different systems adding connectivity through the Internet.
Pros and cons of distribution alternative 2 (client/server) versus alternative 3 (DB operation)?
DB operation adds more flexibility, but has a bigger communication overhead.
Approaches of Web-based Information systems?
Web scenario introduces the separation of presentation layer:
Client-side: browser.
Server-side: web server, HTML filter.
How to maintain session state in Web-based IS?
The problem is: HTTP is stateless. Context of client must be managed across interactions (session ID + user ID). Approaches:
Form variables: universal browser support, but forces dynamic HTML for inserting values (also not persistent).
URL encoding: session ID given in URL. IDs separate from HTML, but complex realization (translation of URL/ unfriendly URL).
HTTP cookies: stored on client, independent of web page (disadvantage: may be disabled).
HTTP authentication: user registration and login (automatically supported by browser + server, but registration mandatory).
In all approaches, choosing a timeout is a problem.
What is the purpose of DB gateways?
Uniform data access to heterogeneous data sources (encapsulate/hide vendor specific aspects).
Access multiple DBs through separate (simultaneous) heterogeneous DB connections (driver manager). Access the same or different DBs, within the same distributed transaction.
What options are there to a DB speak with a programming language?
There are two main options:
Embedded: queries are embedded and integrated into standard programming language (but vendor specific). Two possibilities:
- Static: can perform early compilation (checks and optimization)
- Dynamic: char sequences interpreted as queries
Call Level Interface (CLI): standard library functions used through an API (dynamic approach).
- Portable and vendor independent
- But late compilation (no optimization, no error checking) and not so direct integrated into programming language.
CLI requires:
- Uniform database access (SQL, metadata, API), portability (application binaries), dynamic and late binding to DB (flexibility X performance, but queries can be prepared and just executed later).
What is X/OPEN DTP?
Specification for distributed transaction processing (DTP). Describes the interface between the global TA manager and the local resource manager.
Goal: allow multiple resources (DBs, app servers, message queue, etc. to be accessed within the same TA, thereby preserving the ACID properties across applications.
Uses 2-Phase Commit (2PC) protocol to ensure that all resource either commit or roll any particular TA consistently.
ACID transactions are a key feature in DB, but typically databases only provide the ACID guarantees for activities that happen inside a single database.
XA coordination allows many resources (again, often DBs) to participate in a single, coordinated, atomic update operation.
X/OPEN standard in local scenario
1 - APP > TM: begin
2 - TM > RM: start
3 - APP > RM: request (SQL)
4 - APP > TM: commit (or rollback)
EOT. TM will interact with RMs to complete the transaction using 2PC (TM = coordinator; RMs = agent).
X/OPEN standard - distributed extension
Just like local X/OPEN until a remote request (TRPC) is issued by AP. Adds communication manager to the picture.
1 - APP > CM: TRPC 2 - CM > TM: outgoing TA 3 - CM > CM': request 4 - CM' > TM': incoming 5 - CM' > Server: TRPC 6 - Server > RM: request
When commit happens (APP > TM: EOT): because previous outgoing message from CM to TM, TM knows it must perform Hierarchical-2PC.
In DB-gateways, how transactions work?
Transactional-oriented methods for local TAs (begin is implicit): commit( ), rollback( ).
Scope of transaction is a SINGLE connection.
Support for distributed transactions requires additional extensions, interactions with a TM-manager.
Explain SQLJ programming model
SQL code embedded in Java, generates JDBC with preprocessor:
Translator (profile) + Customizer (Vendor DB) > binary portability.
Context object is referred in SQL code (contains conn)
Input and results are placed in Java variables
Static authorization
Combines advantages of embedded with CLI
Types of persistence?
Orthogonal: all objects can be persisted independent of type.
Transient: whole tree of referenced objects is automatically persisted. Choose ROOT and objects referenced will be persisted.
Transparent: code that handle persisted and transient objects is almost the same.
- Client side: automatic/implicit interactions performed by infrastructure with data stored
- Server side: no special code to implement persistence.
What is EJB?
Enterprise Java Beans. Server-side components encapsulating business logic.
Provide standard way to implement the back-end business code typically found in enterprise applications.
Handle persistence, transactions, security, cache, load balancing, pooling, authorization.
EJB container as runtime environment providing services and execution context. Separated from infrastructure code.
What EJB container consists of?
Class implementing business logic
Remote interface (accessed by clients)
Home interface (additional life-cycle logic)
Primary-key class (for persistence)
Deployment descriptors: includes desired properties of beans, which can be implemented by the developer.
What varieties of beans exist in EJB?
Session beans
- handle session with client.
- Statefull: maintain state of a conversation with client (shopping cart)
- Stateless: do not maintain any state, thus can be reused for different clients.
Entity beans
- Live beyond a session with a client
- Multiple clients may use the same entity instance (concurrency, transactions) -> shared objects.
- Have state (stored in a DB or persisted - by itself (SQL) or automatically (object handled by container)).
Message-driven beans
- Asynchronous interaction with clients
- Act as clients to a JMS message bus.
Persistence in EJB
All and only entity beans are persisted (tight to the concept of entity). On the client side, the persistence is transparent: operation are hidden from client.
The persistence logic is separated from business logic, even if automatically generated.
Persistence in EJB - Container Managed Persistence (CMP)
EJB container handles all database storage and retrieval calls. Container manages the relationships between the entity beans.
You don’t have to code the database access calls in the entity bean. Instead, you specify settings in the bean’s deployment descriptor.
Not only does this approach save you time, but also it makes the bean portable across various database servers.
Persistence related code is generated automatically.
Fields manipulated through setter and getters - more flexibility, but lazy loading of attributes.
Server-side:
1 - defines abstract persistent schema. WHAT
2 - mapping to specific DB in deployment phase. HOW
Object state handled by container
