1. Basic Services: Architecture Options Vance Maverick ADAPT Bologna Feb. 13, 2003

2. Adaptability goals for BS Adaptability to failure –Fault tolerance –Transparent failover –Exactly-once semantics Adaptability to load –Load distribution oSupport for CS load adaptability

3. Overview J2EE –Replication based on group communication JBoss Replication strategies –Maximalist and minimalist examples –Commonalities Conclusion

4. J2EE Three layers: –web –business –database Designed for distribution, not replication HTTP request Entity Bean EJB Container Session Bean Database Layer Servlet Web Container

5. Containers and Components J2EE developers create “components” Web and EJB tiers are “containers” running components Component: class or group of related classes Container: “engine” or environment that instantiates and invokes the component

6. Component state EJB specifies serialization of bean state (for entity beans, only with CMP) For HttpSession, apply standard Java serialization to contents LayerComponentStateSerialization WebServletHttpSession– EJB Stateless SB Instance data N / A Stateful SBFields Entity BeanProperties

7. J2EE: Transactions Transaction manager: 2-phase coordinator Governs database transaction through JDBC driver One logical transaction associated with current thread Association propagated with remote calls

8. Transactional attributes EJB “deployment descriptor”: transactional attributes per method “Required”: if not present, EJB container must create one “Mandatory”: association must be present in client (i.e. servlet)

9. JBoss Mature open-source implementation of J2EE Replication since v3.0 –Passive –Component state transmitted in GC messages HttpSession SFSB instance data ?Entity bean data –Transaction manager unaware of replication

10. “Maximalist” proposal Every request and response “logged” by multicast to all replicas Not only HTTP req/resp but also any other component –Database component (above JDBC) Periodic state updates On failure, new replica replays from last state point Transactions? Must be replicated

11. “Minimalist” proposal Use GC sparingly All processing for a request in one transaction, on one replica Multicast all state changes in a single message to all replicas –For exactly-once, includes request ID, full HTTP response On failure, let client retry

12. “Minimalist”: commit J2EE transaction not replicated Custom TX participant on local node sends message First committer wins –Loser aborts transaction –Database-level locking useful but not required

13. Common framework? Intervenes in all request/response pairs, at both ends –including HTTP and database Listens to transactions Invokes “replication manager” embodying the replication policy RM performs group communication, invokes components, sets sate Dummy implementation: standard non- replicated behavior

14. Conclusion Research opportunities –Replication + transactions –Group communication support –Database (separate Madrid project) Open questions –Choose replication strategy now, or explicitly allow for alternatives Discussion