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, May 9th,
2022. 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.