Distributed Software Architecture and Distributed Systems Middleware

1
Distributed Software Architecture and
Distributed Systems Middleware

• Eric M. Dashofy
• Department of Information and Computer Science
• University of California, Irvine
• May 8, 2000
• WESAS 2000

2
Worlds Quickest ReviewSoftware Architecture

• Components
• Loci of computation
• Connectors
• Loci of communication
• Implicit/Explicit
• Configurations

3
Distributed Systems Middleware

• Facilitates communication between
• Processes
• Machines
• Languages
• Provides
• Marshaling/Unmarshaling
• Transparency (depends on middleware)
• Value-added services
• Fault-tolerance
• Component location
• Application Dynamism
• Examples
• CORBA, ILU, RMI, Polylith, COM/DCOM, HP E-Speak

4
Current Architecture-Middleware Relationship

• Middleware induces architecture
• CORBA/ILU (Distributed Objects)
• Components Objects
• Connectors RPC
• Configurations OOP Interfaces
• Polylith (Software Bus)
• Components Processes
• Connectors Single message bus
• Configurations Process-wide connection to bus,
  explicit send/receive

5
Current Architecture-Middleware Relationship

• This is a Bad Thing
• Inhibits architects from choosing most
  appropriate architecture
• Can rob architects of ability to use architecture
  tools, analyzability, components
• Programmers/architects need to be keenly aware of
  interactions
• Can change architecture of the system if
  implemented late

6
Thoughts...

• Invert the relationship
• Make architectural style the key abstraction
• Middleware becomes a lower layer -like it should
  be!
• Encapsulate middleware in connectors

7
Pictorially
Architectural Style
Architectural Style?
Comp
Comp
Comp
Comp
Comp
Comp
Comp
Comp
Comp
Comp
Connector
Connector
Connector
Middleware
Middleware 1
Middleware 2
OS Network
OS N
OS N
OS Network
OS Network
OS N
Process Boundaries
Process Boundaries

• After
• Architectural style defined by architect
• Architect leverages middleware(s) to create
  value-added connectors
• Abstract style rules intact

• Before
• Architectural style defined by middleware
• Components directly connected to/dependent on
  middleware

8
Future Research Areas

• How do we pull up middleware capabilities into
  software architecture?
• Middleware-based dynamism
• Add/replace/remove components / processes /
  machines at runtime
• Important ancillary middleware services
• Real-time, fault tolerance
• Transactions
• Legacy component interoperability
• Middleware-provided/based gauges?

9
Future Directions

• Problems to address
• Failure semantics
• What happens when a connection breaks or a
  message is lost?
• Architectural visibility
• Modifying distributed architecture via an
  Architecture Evolution Manager
• Middleware limitations
• What kind of connectors can/cant be built with
  middleware?
• Middleware quirks
• What can and cant be marshaled
• Name service

10
Conclusions

• Architecture and middleware a natural marriage
• Architecture should wear the pants in the family
• Add value, dynamism, flexibility to architecture
  through middleware
• Still a lot of work to be done!