1 / 23

CSC407: Software Architecture Winter 2007 Middleware

CSC407: Software Architecture Winter 2007 Middleware. Greg Wilson BA 4234 gvwilson@cs.utoronto.ca. Overview. The term “middleware” refers to the plumbing that holds applications together Provides proven ways to connect software components so they can exchange information relatively easily

jovan
Télécharger la présentation

CSC407: Software Architecture Winter 2007 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. CSC407: Software ArchitectureWinter 2007Middleware Greg Wilson BA 4234 gvwilson@cs.utoronto.ca

  2. Overview • The term “middleware” refers to the plumbing that holds applications together • Provides proven ways to connect software components so they can exchange information relatively easily • Completely hidden from end users • At least, until something goes wrong

  3. Roadmap Business Process Orchestrators ActiveBPEL SonicMQ Message Brokers J2EE, .NET Application Servers Message-Oriented Middleware, Distributed Object Systems Transport

  4. The Layers • Transport layer moves messages around • Appliaction servers provide transactions, security, and directory services • Message brokers define how to exchange, manipulate, and route messages between application components • BPOs support workflow-style applications • E.g., keep track of outstanding purchase orders

  5. Distributed Object Systems • Object-oriented programming across multiple machines • Best-known example is CORBA • Common Object Request Broker Architecture Server Client Servant reply Object Reference request client ORB server ORB Network

  6. Implementation • Object are represented remotely by proxies • For X:A to call a method of Y:B • A’s ORB looks up (or creates) a proxy for Y:B • X:A calls the proxy’s method • Request is routed to Y’s ORB, which delivers it to B • X:A is blocked until Y:B’s response is returned • So it looks like a local, synchronous call

  7. The Details • Usually specify object interfaces with IDL • Interface Definition Language • Compile it to create the proxy class • Also create the interface (or abstract base class) from which the implementation class is derived interface IFred module Fred { interface MyObject { string isAlive(); } } class FredProxy class FredImpl

  8. A Closer Look • Requests to remote servers are millions of times slower than local requests • “Build it local, then distribute” turns out to be a bad design strategy • Cannot pass by reference • How deeply to copy lists of lists of lists? • Have to cope with partial failure • We’ll return to this later…

  9. Message-Oriented Middleware • MOM doesn’t even try to hide the distinction between local and remote objects • Inherently asynchronous • Basic element is a message queue • Any message a sender enqueues will eventually be dequeued and delivered, in order • Can be implemented point-to-point, or by using a central server

  10. Advantages • Sender doesn’t have to wait for a reply • “Send and forget” • E.g., logging systems • Sender decides when to wait for a reply • I.e., when to try to dequeue a reply message • Is this another way of saying “Every programmer has to figure it out herself”? • Handles intermittent connections more robustly

  11. Message Delivery • Message delivery must be reliable • If MOM loses a credit card transaction, the customer may be happy, but the store will not • But reliability costs performance • Quality of Service options: • Best effort (time out and discard) • Persistent (costs 30-80% of performance) • Transactional (persistent, with grouping)

  12. Publish-Subscribe • One-to-one messaging is tedious and inefficient • Tedious: have to send the same message many times • Inefficient: have to copy/send it many times • Publish-subscribe extends MOM to support 1:N, N:N, and N:1 messaging • Every message is associated with one or more topics • Subscribers listen for messages on interesting topics • Yes, it’s observer/observable

  13. …Publish-Subscribe • Decouples senders and receivers • Many processes can create messages on a topic, while many are consuming • New ones can appear and disappear at arbitrary times • May organize topics hierarchically • Newer systems use something like tagging • Messages may be published with a “time to live” • Stock quotes are only interesting for so long…

  14. Tuple Space • Appeared in Linda in the early 1980s • System consists of: • Zero or more running processes • A shared collection of tuples f(a, b) h("red") (1,2) … (3,"blue") g(123)

  15. …Tuple Space • out(val,...) creates a tuple • E.g., out(1, 3) adds (1, 3) to tuple space • in(val,...) blocks until a matching tuple can be found, then removes it • If x and y are variables, in(?x,?y) blocks until a tuple with matching types exists, copies values into x and y, then removes the tuple • Can mix values and variables at will • rd() is like in(), but doesn't remove the tuple

  16. …Tuple Space • eval(f,val,...) creates a process • Executes function f on given parameters • Turns into a tuple when execution terminates • And that's it

  17. Task Farm Example for i in num_jobs: eval(worker_func, job_data[i]) results = [] for i in num_jobs: in(?r) results.append(r)

  18. Distributed Queue void put(str name, type val): int i; in(name, "tail", ?i); i += 1; out(name, "tail", i); out(name, i, val); type get(str name): int i; in(name, "head", ?i); i += 1; out(name, "head", i); type val; in(name, i, val); return val; ("job", "tail", 9); ("job", "head", 7); ("job", 7, …data…); ("job", 8, …data…);

  19. JavaSpaces • JavaSpaces is Sun's Java implementation of TS • Adds the notion of a lease • A process requesting access to resource must specify how long it wants to use it • Resource owner grants access for no longer than that time • Lease holder can renew or cancel leases • When a lease expires, the grantor reclaims the resources and signals the lease holder

  20. Service-Oriented Architecture • SOA assembles an “application” from loosely-coupled software services Application Front end Contract Business Logic Service Implementation Data SOA Service Repository Interface Service Bus

  21. WSDL • Web Services Description Language <message name="getTermRequest"> <part name="term" type="xs:string"/> </message> <message name="getTermResponse"> <part name="value" type="xs:string"/> </message> <portType name="glossaryTerms"> <operation name="getTerm"> <input message="getTermRequest"/> <output message="getTermResponse"/> </operation></portType>

  22. UDDI • Universal Description Discovery and Integration • Original idea was a “yellow pages” for web services, but in practice: • Trust was an issue • And so was lack of semantics • In practice: • Used on intranets • Most of the possible metadata is ignored

  23. Twin Challenges • How to test and debug? • Model delays and partial failures when testing • Few debuggers know how to track events across process boundaries (much less machines) • How to tune? • Gathering performance data is hard enough on one machine • Gathering it on many distorts the system being measured

More Related