539D 25/1/07

1. 539D 25/1/07 • AspectJ tutorial, exercise 4 • Three types of Middleware • Project proposal • Paper discussions

2. Exercise 4a aspect Answer4a { Rectangle around(): execution(Rectangle Group.getBounds()) { return FigureElement.MAX_BOUNDS; } }

3. Exercise 4b aspect Answer4b { private Rectangle Group.cache = null; Rectangle around(Group g): execution(Rectangle Group.getBounds()) && this(g) { if (g.cache == null) { g.cache = proceed(g); } return g.cache; } }

4. Exercise 4c aspect Answer4c { … before(Group g): call(void move(int, int)) && target(g) { g.cache = null; } … }

5. Exercise 4d aspect Answer4d { private Rectangle Group.cache = null; private Group Point.enclosingGroup = null; before(Point p, Group g): execution(void add(FigureElement)) && args(p) && target(g) { p.enclosingGroup = g; } Rectangle around(Group g): … before(Point p): set(* Point.*) && target(p) { if (p.enclosingGroup != null) { p.enclosingGroup.cache = null; } } }

6. Exercise 4e aspect Answer4e { private Rectangle Group.cache = null; private Group FigureElement.enclosingGroup = null; before(FigureElement p, Group g): execution(void add(FigureElement)) && args(p) && target(g) { p.enclosingGroup = g; } Rectangle around(Group g): … before(Point p): set(* Point.*) && target(p) { FigureElement fe = p; while (fe.enclosingGroup != null) { fe.enclosingGroup.cache = null; fe = fe.enclosingGroup; } } }

7. Middleware • RPC and Object Middleware • CORBA • Message-Oriented Middleware • JMS • Web services • WSDL/SOAP

8. Managing Dependencies between Components • Coupling: To join together two units • Tight coupling “considered harmful” • Loose coupling is the “holy-grail” of SOA • Basic strategy for loose-coupling: Add another layer of indirection • Sounds easy, but tradeoffs are hard to measure • Some coupling is necessary and can be useful • Take advantage of invariants that will not change often

9. Two kinds of coupling + Interfaces • Referential coupling • Need to know the “name” of recipient • Reduce by using content-based routing • Temporal coupling • Need to synchronize with recipient • Reduce by using message persistence • Interfaces add coupling also but since they are mostly necessary we usually don’t apply that term

10. Remote Procedure Call (RPC) • Masks remote function calls as being local • Client/server model • Request/reply paradigm usually implemented with message passing • Marshalling of function parameters and return value • Marshalling code is generated from IDL

11. IDL Approach PL PL PL PL 1 2 1 2 PL PL PL IDL PL 6 3 6 3 PL PL PL PL 5 4 5 4 Text and Graphics from Prof. Wolfgang Emmerich, University College, London

12. RPC Approach • IDL is compiled into generated stubs

13. CORBA • Adds interfaces to RPC • Collection of methods implemented by a class • Adds instances to RPC • Easier to correlate state • Easier to migrate state • Adds object groups to RPC • Replication • Load balancing

14. CORBA • Referential coupling • CORBA objects usually refer to each other by a name given as a string • Names are converted into network address by centralized Naming Server • Optionally a Trading Service can be used • Works like a Yellow Pages • Lookup objects by their interface instead of their name • Big Problem: Distributed garbage collection does not scale • How should the server know when the client is done using an object?

15. CORBA • Temporal Coupling • RPC is synchronous • Failures are passed back to client as exceptions • CORBA also adds asynchronous “void” methods • “Fire-and-forget” • Client infrastructure will keep trying for a certain period but application will not be notified • CORBA also adds deferred synchronous • Application can poll infrastructure to find out when a procedure call has completed

16. CORBA Interfaces • Server objects implement IDL interface • IDL has tight match to major OO languages: • Java, C++, Python, etc.. • Easy to translate Java interface to IDL • IDL has awkward mapping to other languages: • Most notably C

17. Message-Oriented Middleware • Asynchronous Messaging in Distributed Systems • Loosely coupled architectures • Components come and go as they please • Two major kinds: • Publish-Subscribe • Point-to-Point

18. Publish-Subscribe • Multiple applications need to receive the same message (broadcast) • Publishers and Subscriber and loosely coupled • Delivery is based on event subscriptions • Content-Based Routing • Event topics (types) organized hierarchically • Components: • Publisher/Subscriber • Connector: • Event Router

19. Topic Hierarchy Stocks { NASDAQ { AMD { int price; int change; }; IBM int price; int change; }; }; NYSE { … }; } • Organized in a tree • Similar to XML • Contains main topics and topic values

20. Subscriptions • Subscribers select which events they are interested in • Register subscriptions with local event router • Make use of: • Logical operators: and, or, not • Arithmetic operators: >, <, == • Wildcard (*) matches any event type or data • Ex: All US stock that have fallen more than two dollars • /Stocks/NASDAQ/*[*, > 2] || /Stocks/NYSE/*[*, >2]

21. Event Routers • Can make intelligent use of subscription information IBM && AMD Subscriber Canada Router England Router IBM IBM Subscriber Publisher

22. Event Routers • Can make intelligent use of subscription information IBM && AMD Subscriber Canada Router England Router IBM AMD Subscriber Publisher

23. Point-to-Point Middleware • Messages are sent to a unique receiver • Provides temporal decoupling of sending and receiving messages

24. Message-Oriented Middleware • Referential Coupling • Managed by event router infrastructure • Subscribers don’t know the identity of Publishers • Publishers don’t know the identity of Subscribers • Content-based routing using subscription languages • Publishers/Subscribers need only attach to an event-routing network

25. Message-Oriented Middleware • Temporal Coupling • Traditional Pub/Sub drops messages once they are delivered to all active subscribers • Point-to-Point saves messages for pickup by receivers • Same behavior as e-mail • Pub/Sub + Persistent Subscriptions • Event routers act also as message queues for subscribers

26. Message-Oriented Middleware • Interfaces • Publishers must make topic structure known to subscribers • Changes to topic structure can cause subscribers to break • Topic languages mitigate problems to some extent • Same motivation as other query languages such as AspectJ pointcut language

27. Web Services • Get some of the benefits of CORBA but take advantage of existing WWW infrastructure • XML message format instead of binary encoding • Tradeoff: Give up performance for ease of programming and maintainance • Hijack HTTP • Let existing web servers do the grunt work • Naming, location, connection and buffer handling • XML Schema interface (WSDL) instead of IDL • More powerful than IDL

28. XML Schema • SimpleType: primitives such as int, string, date • ComplexType: defines a regular expression of Element sequences • Element is either: • <label>SimpleType</label> • <label>ComplexType</label> • Notice the recursion between ComplexType and Element • Allows us to define patterns of trees instead of patterns of strings

29. Where are Web Services? • C2B (Customer to Business) • Provide clients access to large-scale data resources through programmable interface • Browser-based • Use JavaScript APIs to compose services • “Mash-ups” • Dependent on JavaScript • Google Maps • SOAP/WSDL • eBay • Amazon

30. Where are Web Services? • B2B (Business to Business) • Manage another business’ data on their behalf • Supply Chain Management • Manage product ordering, inventory, shipping, tracking etc.. • Customer Relations Management • “Analysis of customer behavior to aid product and service decision making (e.g. pricing, new product development, etc)” • Saleforce.com

31. Web Services: Referential Coupling • Makes use of URLs • Take advantage of DNS • No centralized Naming Server is required • “Trading Service” realized as UDDI • Not used in practice • Hard to find two services that implement the same interface • Can’t trust services unless you know the company that implements them, then you don’t need the Trading Service anyway • Can Artificial Intelligence help? • Work on Semantic Web is growing (slowly)

32. Web Services • Temporal Coupling • Similar to CORBA • Some work on integrating Web services and Pub/Sub • Nothing mainstream yet • Interfaces • Provided by WSDL • “More powerful” than OO type systems • Harder to translate between Java interface to WSDL or vice versa

33. Conclusion • CORBA (Distributed Objects) • Tight coupling provides powerful platform and services • Useful for embedded systems, LAN, and fixed architectures • Message-Oriented Middleware • Content-based routing provides loose coupling but requires complex infrastructure • Web Services • Cuts out features of CORBA that do not scale • Integrates naturally with WWW infrastructure and XML databases

34. Course Project • 2 page (single column) proposal due in two week • 4 page (two-column) paper due one week before end of term • You may choose to do a large implementation project rather than a traditional research project • Refactor an open-source application using AspectJ • Logging, Monitoring, or anything like Logging does not count! • Build a complete, useable, Web application by composing two or more Web services • Don’t just throw up some pins on Google Maps!

35. Class Discussions • Remember discussion is worth 10% of your mark • Be prepared each class to address the four questions I have listed • For the first few discussions, we will start by asking for volunteer answers to each question…

36. Questions • What is the problem addressed by this paper? • What is the approach to solve this problem? • How do the authors validate (prove/show/argue) that their approach solves the problem? • What is one part of the approach or validation that you think can be improved or extended?