539D 25/1/07

• AspectJ tutorial, exercise 4 • Three types of Middleware• Project proposal• Paper discussions

Exercise 4a

aspect Answer4a { Rectangle around(): execution(Rectangle Group.getBounds()) {

return FigureElement.MAX_BOUNDS;}

}

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; }}

Exercise 4c

aspect Answer4c { …

before(Group g): call(void move(int, int)) && target(g) { g.cache = null; }

…}

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; } }}

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; } }}

Middleware

• RPC and Object Middleware– CORBA

• Message-Oriented Middleware– JMS

• Web services– WSDL/SOAP

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

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

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

IDL Approach

PL6

PL2

PL5

PL1

PL4

PL3 PL6

PL2

PL5

PL1

PL4

PL3IDL

Text and Graphics from Prof. Wolfgang Emmerich, University College, London

RPC Approach

• IDL is compiled into generated stubs

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

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?

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

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

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

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

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

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]

Event Routers

Can make intelligent use of subscription information

CanadaRouter

EnglandRouter

PublisherSubscriber

Subscriber

IBM && AMD

IBM

IBM

Event Routers

Can make intelligent use of subscription information

CanadaRouter

EnglandRouter

PublisherSubscriber

Subscriber

IBM && AMD

AMD

IBM

Point-to-Point Middleware

• Messages are sent to a unique receiver• Provides temporal decoupling of sending

and receiving messages

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

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

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

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

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

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

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

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)

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

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

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!

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…

Questions

1. What is the problem addressed by this paper?2. What is the approach to solve this problem?3. How do the authors validate

(prove/show/argue) that their approach solves the problem?

4. What is one part of the approach or validation that you think can be improved or extended?