What are the major types of Application Server Middleware?
RPC/RMI: basic approach for development and execution (location transparency)
TP Monitor: focuses on transaction processing (TRPC) and process management (single tier: mainframe). Key principle is large scale TP: robustness + scalability
Object Broker (CORBA): distributed object computing: some additions to RMI model.
Object Transaction Monitor: simple combination of TP monitor with object broker capabilities
Component transaction monitor: combines TP mon., object broker with server-side components. Further separation of application logic form infrastructure, automating many server-side tasks.
What are the main tasks of an Application Server?
- Overall: programming abstraction + infrastructure
- Distributed computing infrastructure (~RPC/RMI)
- Transaction processing (distributed infrastructure + programming interface: demarcation)
- Large-scale efficient processing (transactions)
- Unified access to heterogeneous systems
- Reliability, high availability, security
What are the major deficiencies of RMI as an application server middleware?
- No heterogeneity: java only, no standardization of format and protocol
- No transaction support, no security, and other important middleware tasks
- BUT: location transparency + platform-independence
What are the main capabilities provided by TP monitors in addition to RMI?
Main goal: support transactional distributed IS (transaction, process, application) management beyonde X/OPEN DTP
- Support high number of concurrent clients/terminals, accessing shared resources
- High availability, flexible load balancing
- Administrative functionality: install, manage, monitor, tune
- old form of middleware in mainframe environment, takes over many tasks of OS and database gateways
What are the key ingredients in TPMs to achieve Scalability and Performance?
Schedule clients to available server objects: pooling!
- Extended to connection (DB) pooling.
- Predefined static queries associated to server classes (re-entrant server code)
Load-balancing: dynamic management of server pools, priorities
Give an overview of the TP monitor architecture
- Interface component: handles interaction with client/terminals (presentation)
- Program flow: scheduler and management of procedures
- Router: logical-physical resource mapping (DBMS)
- Communication manager, for remote interactions
- Transaction manager
- Wrappers, TP Services
What are the goals and general architecture of CORBA?
CORBA: Platform independent RPC + Services
- Provide object-oriented middleware platform (portable) allows heterogeneous components to work together
- Specification for objects bus architecture (RMI)
- interface for application and object services (addition to RMI): persistence, query, transaction, lookup…
- Object adapter (TP monitor functionality): scheduling, load balancing, deployment, … Object implementation handling
What is the functionality of CORBA IOL and how is it used in the programming environment?
Defines interfaces of objects in a standard way. Language-specific binding and compilers are used to implement (Skeletons and stubs)
IDL features may be easier or hard to implement in some languages
Give an overview of the ORB and object adapter components of CORBA
ORB: ~RMI functionality: manages stubs on the client side and mappings to object adapters on the server side, as well as providing helper functions (conversion, cast, …)
Portable Object Adapter: (TP Monitor) generates objects references. Handles mapping of RMI to server objects + activate/register/deactivate server objects
- Request Broker = ORB + POA
What are the invocation approaches of CORBA?
Static invocation: traditional stub + skeleton approach (map IDL: prog. language)
Dynamic invocation: discoverability, selection of objects interfaces through repository (~ DB catalog)
- Comprable to embedded SQL vs Dynamic (JDBC)
- Generic operations to build and perform requests
- Flexible, but costly (no static checks, generic representations of request/data types)
Give an overview of the communication aspects in CORBA
Standardized data formats (encoding of data types) and responsabilities for conversion: common data representation (CDR)
Standardized communication protocol: between different ORBs. General inter-ORB protocol (GIOP). Implemented by, eg, TCP/IP in Internet IOP.
Give an overview of CORBA Object services, specifically the transaction Service
Goal: extend ORB with additional services, defined with IDL. Naming, transaction,uery, persistence…
Provides service objects with standard interface (eg. name service), implemented by CORBA system or by components/application (eg. transaction)
Transaction service: based on X/OPEN DTP
- Usually just flat transactions (nested = optional)
- transactions may go across ORBs + interoperable with other standard X/OPEN DTP TA-Managers
Explain the roles involved in CORBA transactions and relate them to X/OPEN DTP.
Transactional Client = X/OPEN application
- Demarcation of transaction using “current” interface by Trans. Service (OTS)
- Requests (TRPC) to transactional servers
Transactional Server = X/OPEN Server
- Does not manage resources, but propagates transaction context (implements (flat) transaction object).
- May use current to signalize errors and cause rollbacks (limited TA participation)
Recoverable Server = X/OPEN Resource Manager
- Manages recoverable resources
- MUST register (join) with OTS (no predef. list like in X/OPEN)
- Implements Transactional Object and Resource, uses Current and Coordinator (participates in 2PC)
Transaction Service (OTS) itself is the TA-Manager of X/OPEN.
What are the drawbacks of CORBA and how does a Server-side component model solve the problem in this approach?
Programming model is too complex (a lot of infrastructure code must be implemented)
No standard for programming server-side objects (proprietary infrastructure: loading/lifecycle, etc, pooling…). Object Adapter
Server side component model:
- Contracts between component and component server: load balancing, pooling, performance, lifecycle, persistence, …
- Developer focuses on application logic, above issues handled in deployment phase: components need to follow some restrictions
- Simple programming model + portable components
What are the main goals and concepts of EJB?
EJB as server-side component encapsulating business logic: separated from infrastructure code
EJB container as runtime environment providing services and execution context. Bean-container contract: callback methods optionally implemented by developer of bean (lifecycle)
EJB consists of class implementing business logic, remote interface (accessed by clients), home interface (additional life-cycle logic), primary key class (for persistence), and deployment descriptor: includes desired properties (persistence, transaction behavior) of beans, which can be implemented by deployer
Client interacts with home interface and EJB object (automatically generated at deployment): remote interface + business logic of bean + infrastrucuture code
What are the different types of beans and their semantics?
Entity beans: PERSISTED business objects (state managed by DB/RM -> primary key)
- Home interface methods handle creation (INSERT), delete (DELETE), find (SELECT): finder methods
- Multiple clients may use the same entity instance (concurrency, transactions): shared objects
- Persistence, relationships, queries, EJB-QL (next chapter)
Session beans: TRANSIENT objects for session-oriented activities (like in web concept)
- Client usually does not interact directly with entities, but with sessions (reduce communication)
- Also have lifecycle handle by home interface, but no persistence aspect is involved
- Stateless vs statefull (requires coupling session-client) session beans (trivial notion)
- Able to manage persisted data (DB, JDBC)
Give an overview of the deployment process in EJB
EJB objects are server independent: server-related/infrastructure aspects are defined on deployment.
Make classes and interface known, specify mapping to DB, configure transactional behavior, security, set environment/context variable: generates glue-code
All specified in descriptor
How does the demarcation of transactions work in EJB and what are the different approaches?
Transactional behavior of method of method can be:
- Requires code to be in TA, start if no TA context given (Required)
- Requires TA from caller, error if not present (Mandatory)
- pass on context if given, otherwise run without TA (Supports)
- Requires a new exclusive TA, suspending any existing (requiresNew)
- doe not handle transaction, ignores given context (Not Supported)
Explicit/Programmatic TA Management
- Use JTA api to explicit demark TA boundaries in application logic (begin, commit, suspend, resume, callback, …)
- Transact on context may be passed along implicitly or explicitly as method argument
- Only supported for session beans: specify transaction-type = bean managed.
- Stateless: BOT + EOT must be in the same method, stateful can keep TA active across invocations (Dangerous but necessary for Web)
Implicity/Declarative TA Management
- Associate behaviour properly to method (listed above)
- Container implements required property
- separated from business logic! Can be deferred to deployment phase
Give an overview of transaction support in JDBC (distributed)
Interaction with transaction manager: X/OPEN DTP, Java transaction service (JTS)
Demarcation must be done through JTA (user transaction object) and not with connection interface
Datasource interface provides transparency if distributed transactions
Implementing drivers must be implemented additional methods (XA*)
Similar to X/OPEN DTP capabilities
Give an overview of the connection pooling mechanism of JDBC
Connections to DB are expensive: pooling can improve performance and scalability
- Server side components can reuse connections (only few shared user IDs used, short duration of operations)
- Prefered approach to large-scale IS, app servers maintains cache of connections
- Instead of open, get connection from pool/ instead of close, return to pool
Transparent to application with DataSource interface, gives logical Connection to JDBC app.
Security aspect: give connections based on authentication.
Give an overview of large-scale resource management in EJB
TP monitor capabilities added to components (load balancing, pooling)
Instance pooling/swapping: bean objects can be reused across transaction boundaries (stateless session + entity)
Passivation / Activation: bean state stored separately from bean (passivation)
- Frees resources if bean not used for a while, reactivated when needed again
- Uses java serialization (also available for stateful session beans)
-
1 - Motivation4
-
2 - Distributed Information Systems Architecture15
-
3 - DB-Gateways13
-
4 - RPC and Distributed Transactions10
-
5 - Application Server Middleware21
-
6 - Object PErsistence, Relationships, and Queries23
-
8 - Web Services Foundations21
-
9 - WS Coordination and Transactions8
-
10 - Web-based Information Systems6
-
Exam50
