140 likes | 158 Views
Explore adaptability goals for Basic Services architecture like fault tolerance, load distribution, and more. Learn about J2EE components, transaction management, and replication strategies in systems like JBoss. Discover "Maximalist" and "Minimalist" proposals for efficient replication approaches.
E N D
Basic Services:Architecture Options Vance MaverickADAPT BolognaFeb. 13, 2003
Adaptability goals for BS • Adaptability to failure • Fault tolerance • Transparent failover • Exactly-once semantics • Adaptability to load • Load distribution • Support for CS load adaptability
Overview • J2EE • Replication based on group communication • JBoss • Replication strategies • Maximalist and minimalist examples • Commonalities • Conclusion
HTTPrequest SessionBean EntityBean EJBContainer WebContainer Servlet DatabaseLayer J2EE • Three layers: • web • business • database • Designed for distribution, not replication
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
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