110 likes | 268 Views
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
E N D
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
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
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!