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

World’s Quickest Review: Software Architecture Components –Loci of computation Connectors –Loci of communication –Implicit/Explicit Configurations

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

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

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

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

Pictorially Comp Middleware OS + NetworkOS + N Middleware 1 OS + Network OS + N Connector Middleware 2 Connector Comp Connector Process Boundaries Architectural Style? Architectural Style 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

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?

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/can’t be built with middleware? –Middleware quirks What can and can’t be marshaled Name service

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!