[Chicago-talk] New system architecture

Tue Jun 2 09:52:08 PDT 2009

Hi, Dave,

Thanks for the time you put into the response.  I'm going to need to read
some more on this stuff.  Its seems there are so many different / competing
ideas and frameworks, its sort of impossible to know which way to go.
Struts / Springs / JSP / some templating engine...

I'll start by working up my exact list of tasks and maybe objects I expect.
Maybe things will become more obvious.

On Tue, Jun 2, 2009 at 11:03 AM, Dave Viner <daveviner at pobox.com> wrote:

> Hi Jay,
>
> JSON is a transport mechanism.  Your web service returns some
> information.  Traditionally, it would be something like XML.  JSON is
> just easier when the code invoking the web service is Javascript.
> That's all.
>
> The more challenging part is figuring out what web services you really
> need.  Usually, you start with either REST or SOAP as the primary
> definition of your architecture.  Personally, I always start with REST
> because it's more in tune with the general architecture of the web as
> a whole.  (This is a bit of a philosophical debate, but you can read
> more about that elsewhere.)  You can develop a REST-afarian system by
> thinking through the "objects" or "resources" of your system.  To use
> a language metaphor, in a REST architecture, the resources are the
> nouns - the things on which you act.  The verbs are limited to GET,
> PUT, POST, and DELETE.  GET returns the "representation of the
> resource".  DELETE removes the resource.  PUT (usually) creates the
> resource, and POST updates an existing resource.
>
> You can get a decent grounding in REST architecture design by reading
> just a few articles:
> "How to create a REST Protocol" -
> http://www.xml.com/pub/a/2004/12/01/restful-web.html - this is one of
> the first solid walkthroughs of how to make your own protocol.  (Note
> that for the purposes of this discussion, "protocol" and "web service"
> are roughly synonymous.)  Read this 3 page article first.
>
> "PUT or POST" -
> http://jcalcote.wordpress.com/2008/10/16/put-or-post-the-rest-of-the-story/
> - this article focuses on the distinction between PUT and POST.  Both
> create or modify existing resources, so people frequently get confused
> as to why and when to use each.
>
>
> Those should give you a pretty solid understanding of how to get going
> in the REST world.
>
> Here are some thoughts on your specific questions:
> "do you typically build really atomic pieces of code and communicate
> via JSON, even between processes on the same host?"
> - yes.  You define what your resources are.  Then you define what each
> REST verb means for each resource.  The response from your server will
> be in JSON.  Location of the host doesn't matter.  All communication
> between components is HTTP.  This has the rather spectacular benefit
> of allowing you to scale - when it's architected correctly.
>
> "Where do the API of individual components end where you pass data in
> native format, and the JSON begin?"
> - This is hard to answer without knowing more of your process.  I'd
> suggest starting with the definition of your resources, then the
> verbs.  That should help you define what the services are, and what
> actions you "take" or "effect" on them.  JSON is just the way to send
> information in response to the service request.  You could substitute
> XML for JSON and the resulting system would be identical.  Or you
> could use plain text of specified formats (e.g., csv, tsv, or simple
> new-line delimited keywords) and it's still the same.
>
> HTH
> Dave Viner
>
>
>
> On Tue, Jun 2, 2009 at 7:47 AM, Jay Strauss <me at heyjay.com> wrote:
> > I like the idea of a java script (AJAX) client, although I don't know
> > javascript, which just means more learning curve.
> >
> > You say use JSON.  I've never used it (reading about it now), do you
> > typically build really atomic pieces of code and communicate via JSON,
> > even between processes on the same host?
> >
> > Where do the API of individual components end where you pass data in
> > native format, and the JSON begin?
> >
> > Thanks
> > Jay
> >
> > On Mon, Jun 1, 2009 at 2:27 PM, Dave Viner <daveviner at pobox.com> wrote:
> >> I would tend to agree with Jason.  Personally, I don't like most
> >> desktop apps.  I like to use my browser.  So, AJAX is perfect.  Just
> >> architect your web services to respond in JSON, and use jQuery to
> >> handle the communication.  This setup allows you to grow - if you and
> >> your brother hire other people, or want to license the software - and
> >> it allows you to make changes to the appropriate component (front-end
> >> versus service layer vs database).  (Note that many system would allow
> >> for similar levels of encapsulation.  I'm just pointing out that a
> >> well-designed AJAX system allows the same flexibility as a
> >> well-designed desktop app or flash app or whatever else.)
> >>
> >> Another alternative to consider is AIR.  You can make a pretty simple
> >> desktop app using just HTML and JS.  Depending on your comfort with
> >> using Adobe as the main execution platform, it's an interesting
> >> approach that also buys you cross-platform compatibility.  Seesmic
> >> Desktop is a full AIR app which has some pretty cool features.
> >>
> >> HTH
> >> Dave Viner
> >>
> >>
> >> On Mon, Jun 1, 2009 at 11:54 AM, 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
> >>>
> >> _______________________________________________
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/chicago-talk/attachments/20090602/79d95669/attachment.html>