Fault Tolerant CORBA Extensions for JINI Pattern Language

1
Fault Tolerant CORBA Extensions for JINI Pattern
Language
Aniruddha Gokhale agokhale_at_lucent.com Bell Labs
Research, Lucent Technologies Murray Hill, NJ, USA
2
Ad hoc Networking

• Spontaneous network creation i.e., without
  infrastructure.
• No additional resources required beyond the
  participating wireless terminals.
• Automatic configuration and re-configuration.
• No specific technical skills needed for network
  creations and dissolution.
• Terminals can join and leave the network at
  anytime.
• Departure of one terminal does not disrupt
  communications between other terminals.

3
Trends in Distributed Systems

• Distributed applications are becoming more
  complex mission-critical
• Increasing demand for COTS-based
  multi-dimensional quality-of-service (QoS)
  support
• e.g., simultaneous requirements for efficiency,
  predictability, scalability, security,
  dependability
• Key open challenge is dependable middleware for
  ad hoc network applications

4
Promising Solution Fault Tolerant (FT)
Distributed Object Computing Middleware

• Challenges
• Limitations of non-OO FT strategies that focus on
  application processes
• Techniques based on process-based failure
  detection recovery are not applicable to
  distributed object computing applications due to
• Overly coarse granularity
• Inability to restore complex object relationships
• Restrictions on process checkpointing recovery

5
Solution Fault Tolerant CORBA

• Overview
• Provides a standard set of CORBA interfaces,
  policies, services
• Entity Redundancy of objects is used for fault
  tolerance via
• Replication
• Fault detection
• Recovery from failure
• Features
• Inter-Operable Group References (IOGR)
• Replication Manager
• Fault Detector Notifier
• Message Logging for recovery
• Fault tolerance Domains

6
Interoperable Object Group References

• Composite enhanced Interoperable Object
  Reference (IOR) for referencing server object
  groups
• Comprises one or more TAG_INTERNET_IOP profiles,
  which in turn must contain a TAG_FT_GROUP and
  zero or more TAG_IIOP_ALTERNATE_ADDRESS
  components
• TAG_PRIMARY component in at most one
  TAG_INTERNET_IOP profile
• Client ORBS operate on IOGRs in the same way as
  with IORs

7
FT-CORBA Component Interaction
1.External object asks RM to set properties for
replica group and create it
2.RM delegates replica creation to local factories
3.The local factories create CORBA objects
4.The local factories send the replica IORs to
the RM for it to create the IOGR
5.The RM registers the IOGR with a CORBA Naming
Service (NS)
6.The RM asks fault detectors to initiate fault
monitoring of replicas
7.Clients contact the NS for IOGR
8.Client sends requests to the primary
8
FT CORBA Spec Requirements

• Preserving the CORBA Object Model with
  enhancements
• No single point of failure
• Transparent failover
• Transparent client redirection reinvocation
• FT CORBA cannot handle commision faults or
  correlated faults

Key Challenge Support for JINI Pattern Language
9
Introducing Lease as a FT Property

• Provide a lease for replica group as a FT
  Property that can be set as default or at runtime
• Fault Monitoring and Recovery activated only
  while lease is valid
• Failures after lease expiry will throw
  LeaseExpired exception to the client
• Better resource management for RM, FD and NS

10
Adding fallback RM Profile

• RMs profile added to the IOGR

• Client ORB will consult RM profile as a last
  resort

• RM will attempt service discovery using service
  properties

• Returns new IOGR via LocationForward comprising a
  new RM profile if found, else throws
  ObjectNotFound

11
Concluding Remarks

• Current State of the Art
• COTS-based middleware with multi-dimensional QoS
  support used to implement dependable distributed
  systems
• Key challenges
• Supporting dependable services in Ad hoc
  networks
• Promising Solution
• FT-CORBA extensions to enhance JINI pattern
  language
• Use the Lease pattern in FT-CORBA to manage
  resources
• Provide fallback mechanisms that use the Lookup
  Pattern to rediscover services and provide
  transparent failover to clients