CSC407: Software Architecture Winter 2007 Middleware

CSC407: Software ArchitectureWinter 2007Middleware 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 • Completely hidden from end users • At least, until something goes wrong

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

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

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

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

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

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…

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

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

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)

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

…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…

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)

…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

…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

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)

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…);

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

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

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>

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

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

CSC407: Software Architecture Winter 2007 Middleware