1 / 10

Distributed Software Architecture and Distributed Systems Middleware

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

emmanuel-garrett
Télécharger la présentation

Distributed Software Architecture and Distributed Systems Middleware

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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!

More Related