539D 25/1/07 AspectJ tutorial, exercise 4 Three types of Middleware Project proposal Paper...
-
date post
20-Dec-2015 -
Category
Documents
-
view
235 -
download
0
Transcript of 539D 25/1/07 AspectJ tutorial, exercise 4 Three types of Middleware Project proposal Paper...
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
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…