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. World’s Quickest Review:Software 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. After Architectural style defined by architect Architect leverages middleware(s) to create value-added connectors Abstract style rules intact 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 • 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/can’t be built with middleware? • Middleware quirks • What can and can’t 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!