Hello all,
So I have been working on a rather involved refactoring of the client,
Photon, that I believe will make the code simpler and more reliable.
Here are the major things I did:
1) On Andrei's advice, I factored out the "model" of the application
into its own plugins, org.marketcetera.photon.core. This forces us to
be more rigorous about separating model and view.
2) I reworked the application to use a staged (SEDA-like) model for
dealing with asynchronous messages from various sources: jms, quote
feed. More on this below.
3) Rearranged the package hierarchy inside org.marketcetera.photon
The most invasive and interesting part of this refactoring is that we
are now using the "message driven POJO" construct for handling message
passing between threads inside of our application. There are
currently two sources of asynchronous message traffic inside the
application: the quote feed and the JMS connection. We have several
consumers of the message traffic: the scripting subsystem, the main
controller (which passes on data to the model, and ultimately the UI),
and possibly others. To tackle these rather complex data flows, we
are now using ActiveMQ internally in our application to marshal the
data through "VM protocol" queues and topics.
Rather than dealing with the queues and topics explicitly, however,
there are several classes in the SpringFramework that make
implementing SEDA-like stages much easier. First, the
MessageListenerAdapter class is able to convert JMS messages into an
object that is then passed into a user defined method on your business
object ( for example PhotonController). That allows us to write our
business logic without any knowledge of JMS. For the other end of the
equation, we use JmsTemplate to dispatch messages to the appropriate
internal or external queue, again without any knowledge of JMS.
As of right now, there are two "stages" or "message driven POJOs", the
PhotonController and the scripting subsystem. The assumption is that
code in these stages will be executed in threads as determined by the
framework. The PhotonController is responsible for marshalling any
calls to update the model into the UI thread. Then the UI elements
listen for changes on the model that will occur in the UI thread as
required by the SWT libraries.
That being said the quote feed and scripting APIs are still under
flux. And I wouldn't recommend running the build from the SVN HEAD
for anything useful until further notice, as we have some regression
issues to work out first.
Here is a list of some other changes I made:
* Moved some classes related to UI from the org.marketcetera.photon
package into org.marketcetera.photon.ui.
* Created an org.marketcetera.photon.ui.validation package to hold all
of the code used to do eclipse forms validation.
* Moved all the code from org.marketcetera.photon.scripting into the
main photon plugin, and eliminated the dependency.
If any of the terms I used above are confusing, I apologize, I've been
knee deep in this stuff for a few days. Here are a few links that I
found useful in figuring this all out.
http://www.springframework.org/docs/reference/jms.html#jms-asynchronousMessageReceptionhttp://www.springframework.org/docs/reference/index.htmlhttp://blog.interface21.com/main/2006/08/11/message-driven-pojos/The actual files we're using to configure the spring stuff are here
(though I'm still thinking there may be a way to do some of that in
code rather than spring configs):
http://svn.marketcetera.org/client/photon/trunk/plugins/org.marketcetera.photon/src/main/resources/(the three xml files)
More soon in a more comprehensive architecture overview.
graham
--
Marketcetera Trading Platform
download.run.trade.
www.marketcetera.org
_______________________________________________
m-etc-dev mailing list
[hidden email]
http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-dev
