Your class project is the delivery of an executable software system that makes use of:
1. At
least FOUR design patterns; and
2. At
least SIX EIP patterns (you may not count the
EIPs in RED in the list below in
your count of six, as you will all be using these EIPs of
necessity by simply using ActiveMQ messaging).
To refresh your memory, here are the patterns we have (or will) cover during class or which are assigned as reading (with the lecture in which they are assigned):
Design Pattern/Architectural
Pattern |
Lecture Reading Assigned |
Enterprise Integration Pattern |
Lecture Covered |
Singleton |
1 |
Message Broker |
6 |
Template Method |
2 |
Message |
6 |
Composite |
2 |
Message Endpoint |
6 |
Strategy |
2 |
Request-Reply |
6 |
Iterator |
2 |
Message Channel |
6 |
Class Adapter |
3 |
Point-to-Point Channel |
6 |
Object Adapter |
3 |
Publish-Subscribe Channel |
6 |
Mediator |
3 |
Polling Consumer |
7 |
Observer |
3 |
Event-Driven Consumer |
7 |
State |
4 |
Splitter |
7 |
Prototype |
4 |
Aggregator |
7 |
Proxy |
4 |
Message Router |
7 |
Facade |
5 |
Content-Based Router |
8 |
Layers |
5 |
Message Translator |
8 |
Builder |
5 |
Message Filter |
8 |
Abstract Factory |
6 |
Invalid Message Channel |
8 |
Factory Method |
6 |
Datatype Channel |
8 |
Chain of Responsibility |
6 |
Channel Adapter |
9 |
Command |
7 |
Messaging Gateway |
9 |
Interpreter |
7 |
Competing Consumer |
9 |
Bridge |
7 |
Selective Consumer |
9 |
Visitor |
8 |
Dynamic Router |
9 |
Decorator |
8 |
Correlation Identifier |
9 |
Flyweight |
8 |
Dead Letter Channel |
9 |
Memento |
8 |
Message Dispatcher |
9 |
Pipes & Filters |
3 |
NOTE you are NOT limited to the EIPs listed above right.
You may choose any of the EIP patterns listed in the link below
(with the exception of the Message Broker, Message Endpoint,
Message, Pipes & Filters, and Channel noted above):
The
65 Enterprise Integration Patterns Listing
NOTE likewise,, you are NOT limited to the Design Patterns listed above left. You may choose any of the Design Patterns listed here:
The 23 Gang of
Four Design Patterns
You should
produce a project proposal for review by me by 11:00 pm, April 29th, 2024.
You are welcome to propose your project earlier than that
date. The project proposal will specify a particular business or scientific problem
that you are solving, and will list the patterns involved in
your proposed solution to the problem, with a brief discussion
of how these patterns participate in an intelligent solution to
the original problem. You are free to change your
mind, and use other patterns as you
get into your coding of the project, as this is the normal
course of software development. Allowing me to
review your project concept will give you the go-ahead for
proceeding. You should come up with a legitimate problem
concept that will benefit from your selection of patterns (see
examples below). That is to say, your
pattern selection should all fit together to solve some
legitimate business or scientific need. In short, come up
with an interesting problem, and solve it using the available
design, architectural, and enterprise integration
patterns. (You may additionally select from any of the
patterns in Gamma et. al. for design patterns and any of the
patterns in Hohpe & Woolf).
You may leverage Camel's implementations of any of the EIP
patterns in your delivery. You may leverage pattern
implementations in Java (that is you may use Java Iterators, etc..., you do not have to write your
own Iterators as you had to do in the labs). You must
use both ActiveMQ and Camel in your
final deliverable.
Some example project ideas:
1. One might design an auction site that takes in bids
from various sources and produces a best bid output, announcing
a "winner" after a certain time. Multiple "auctions" would
need to be run concurrently. Possible EIP patterns include
Splitter, Aggregator, Message Channel (Queue or Topic), Message
Router, Message Endpoint (from/to), Invalid Message Channel,
Content-Based Router, Point-to-Point Channel, Publish-Subscribe
Channel, etc. Possible Design Patterns include Singleton,
Template Method (for calculating the winning bid), Iterator to
iterate through lists of auctions or lists of items being
auctioned, Strategy (for pricing), etc. You might want to
see the example in Hoppe and Woolf pp. 276ff. for more on an
auction example.
2. Or, one might design a portfolio management system that
allows multiple/disparate instruments to be valued and displayed
to particular/appropriate customers. Possible EIP patterns
include Splitter, Aggregator, Message Channel (Queue or Topic),
Message Router, Message Endpoint (from/to), Invalid Message
Channel, Content-Based Router, Point-to-Point Channel,
Publish-Subscribe Channel, etc. Possible Design Patterns
include Singleton, Composite (for portfolios), Template Method
(for calculating the winning bid), Iterator to iterate through
the Composite, Strategy (for pricing strategies, stats
calculations, etc.), etc.
3. Or, one might design a typical integration problem
where different data formats are shared by different "systems"
(these systems can be very very
simple), and leverage a Canonical Data Model to pass messages
back and forth between the various "systems". So for example, all systems pass a trade
around, but in one case, the trade is in XML format, in another
case, a binary Java object, and in another case, a text
file. The "core" information (price, quantity, buy/sell,
etc.) is contained within each system but is provided by the
system in different formats. Possible EIP patterns include
Splitter, Aggregator, Message Translator, Message Filter,
Message Channel (Queue or Topic), Message Router, Message
Endpoint (from/to), Invalid Message Channel, Content-Based
Router, Point-to-Point Channel, Publish-Subscribe Channel,
etc. Possible Design Patterns include Singleton, Template
Method (for calculating the winning bid), Iterator to iterate
through lists of auctions or lists of items being auctioned,
Strategy (for pricing), etc.
4. Or, one might design an RSS Aggregator that reads in
multiple RSS feeds and acts on that (big) data. The
strategies that might be applied to the data may range from a fairly simple of aggregation of multiple
feeds to one or more channels (like a "Yahoo Business" channel,
a "CNN Headlines" channel, etc.), or something more complicated
and challenging that implements big data analytic strategies
that may predictive analytics, crowdsourcing, clustering and
distance measurement, association mapping, etc. and puts
calculation results onto various channels. Note you may
certainly leverage hadoop and map
reduce but you need also to leverage the pattern requirements.
Other (previous) project proposals for the class (which may help
you with models for your own proposals) may be found here.
Default Course Project:
If you're having trouble coming up with your own example, you
may, if you so choose, use and implement this project
idea as your own.
GRADING:
You can "extend" or "reuse" the patterns (and thus your code)
used in a lab assignment in your final project, but the reused
parts CANNOT be the primary focus of the project--that is to
say, you should not simply "string together" the lab assignments
you've already written. Instead, they can be used as a
starting point for developing something new. The reused work
should be an order of magnitude less significant than the final
project itself. If you choose to reuse lab work, you give
us the license to take off some amount of points if we feel the
final project was not significantly different from the
previously-submitted work.
In short, you can "reuse" any pattern(s) that you've used in a
given lab, including some of the code.
Also, we need a detailed proposal of about 200 - 600 words (note
that these general comments in this web page are about 1200
words) detailing the following (those who have already been
approved do not need to resubmit):
1. The General Topic (1 paragraph)
2. A Description of the Problem to be Solved (1-2
paragraphs)
3. A Listing of the EIP Patterns (6 or more) to be
leveraged. HOW and WHY and WHERE?
4. A Listing of the Design Patterns (4 or more) to be
leveraged. HOW and WHY and WHERE?
5. A Summary of the anticipated deliverable: About
how many classes in the system? About how many source
files?
6. A drawing (UML preferred) of your solution
A final project
deliverable that is complex enough to make the graders happy
should be somewhere between 1000 lines of code or more.
Your mileage may vary.
A final note. The focus of the grading of the final
project will be on (a) the depth of the problem engaged (b) the quality of your pattern
implementations in your coded solution to that problem more than
on the sheer number of lines of code submitted. The above
is more of a guideline. No one will be counting your lines
of code. This guideline is for YOU to use as a yardstick
to conclude that a submission of 110 lines of Java that has an "AddEmUp" function at its core is
probably not going to make anyone happy, most of all yourself.