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

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

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

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

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

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

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

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)

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

“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

“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

“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

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

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