[Chicago-talk] New system architecture

Dave Viner daveviner at pobox.com
Tue Jun 2 10:23:00 PDT 2009


No problem.  If you need help, feel free to ping me off-list or
contact me via my consulting group http://www.vinertech.com.

Good luck!
Dave Viner

On Tue, Jun 2, 2009 at 9:52 AM, Jay Strauss <me at heyjay.com> wrote:
> 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
>
>
> _______________________________________________
> 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