[Chicago-talk] New system architecture

Jay Strauss me at heyjay.com
Tue Jun 2 07:28:38 PDT 2009


Hi, the client side of things isn't very complex.  My client is really
just display of our indicators and trade suggestions.  We are not
doing high frequency trades or trades that require lighting fast
execution.  HTML is probably fine.

I'm more concerned with the server side of things.  It seems like
there are some many different architectures these days I don't know
where to begin.  I could do everything in Perl, just having modules
talk to each other or I could go all the way to the other end like
some sort of spring/struts or SOAP kinda thing.

Furthermore, while I'm much more comfortable in Perl, It seems like
Java is the direction to go if I ever want to put my app on a web host
or some other app server.

I'm just sort of overwhelmed these days.


On Mon, Jun 1, 2009 at 1:54 PM, Jason Rexilius <jason at hostedlabs.com> wrote:
> Sorry to chime in here late in the conversation.  I was an architect at JP
> morgan for FX and fixed income web-based trading apps and some desktop apps
> so have a bit of experience in related fields.
>
>
> For fat client, I would suggest C++ if your desktop app needs good
> performance and Qt if your app needs good cross platform capability.
>
> If you do not need that level of performance I would jump all the way to the
> other end of the spectrum and look at Flex/Flash for fat-client-like
> capability or really well engineered AJAX interactivity (I built web-based
> FX trading apps using java, perl and javascript/HTML back in the day that
> moved very, very fast).
>
> Swing sux big time and you can get pretty close to its performance with well
> engineered flash client, particularly if the server component is local
> network.
>
>
> For server side, java is one choice, I think perl is still a strong
> candidate depending on _how_ you code.  Python is also a strong candidate.
>  If you are really looking to rock it hard, the best might be Erlang. But
> really it comes down to what language you are comfortable with.  A good perl
> coder can build a faster app than a bad Java coder..
>
> Me personally, unless you were doing heavy real-time trading based on market
> timing, I would build client in HTML/JS and server side with LAMP stack
> (perl, python or PHP) with shared mem or other high performance IPC
> mechanism to whatever your trading data feed provider is (reuters,
> bloomberg, etc.).  If you needed to do transforms or manips on data feed I'd
> right that in C/C++ or erlang.  If youre just talking to a DB, then the
> basic principles of a good handler that wraps all access to DBs and good
> schema design should really be enough. ORMs are often more baggage than help
> but maybe use a simple code generator to do light ORM class building or
> something..
>
>
>
>
> Jay Strauss wrote:
>>
>> I don't think we've set upon Java or not.  But I don't feel there is a
>> good Perl rich GUI alternative (I know about wxperl, and am not in
>> love)
>>
>> On Mon, Jun 1, 2009 at 12:35 PM, Michael Potter <michael at potter.name>
>> wrote:
>>>
>>> Jay,
>>>
>>> Here is my 2 cents:  If you are intending to replace Perl with Java then
>>> consider Groovy instead of Java.  Groovy has a lot of the benefits of
>>> Perl
>>> (Dynamic Language), but runs on the JVM and can interface with class
>>> files
>>> that were created with javac.
>>>
>>> Let us know what you decide.
>>> --
>>> Michael Potter
>>>
>>> On Mon, Jun 1, 2009 at 12:14 PM, Jay Strauss <me at heyjay.com> wrote:
>>>>
>>>> Hi all, need some advice.
>>>>
>>>> I want to build a new system.  My bro and I have a small
>>>> equity/options trading application.  We cobbled it together in Perl
>>>> and Oracle years ago.  Things have broken, some of the stuff we want
>>>> to change.  Ultimately we want to start over.
>>>>
>>>> I'm just trying to decide on what architecture to use going forward.
>>>> I know this is a pretty wide question.
>>>>
>>>> Most (all) of the processes will run on a single box.  I don't really
>>>> have an idea of which presentation route we'll go (full rich client
>>>> maybe using Java/Swing, maybe a Java Script client using GWT, maybe
>>>> plain HTML).  The client will probably request functionality from the
>>>> server.
>>>>
>>>> I was thinking we'd do the whole API for asking for quotes, requesting
>>>> analytics, inserting transactins...  via HTTP (SOAP).
>>>>
>>>> Can anyone give me their thoughts on their lessons learned, maybe
>>>> routes to try, stuff I should be thinking of...
>>>>
>>>> (again I know this is pretty open ended, but I'm interested in what
>>>> others have done with success)
>>>>
>>>> Thanks
>>>> Jay
>>>> _______________________________________________
>>>> Chicago-talk mailing list
>>>> Chicago-talk at pm.org
>>>> http://mail.pm.org/mailman/listinfo/chicago-talk
>>>
>>> _______________________________________________
>>> Chicago-talk mailing list
>>> Chicago-talk at pm.org
>>> http://mail.pm.org/mailman/listinfo/chicago-talk
>>>
>> _______________________________________________
>> Chicago-talk mailing list
>> Chicago-talk at pm.org
>> http://mail.pm.org/mailman/listinfo/chicago-talk
>
> _______________________________________________
> Chicago-talk mailing list
> Chicago-talk at pm.org
> http://mail.pm.org/mailman/listinfo/chicago-talk
>


More information about the Chicago-talk mailing list