Hi, Dave,<br><br>Thanks for the time you put into the response.  I&#39;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...<br>
<br>I&#39;ll start by working up my exact list of tasks and maybe objects I expect.  Maybe things will become more obvious.  <br><br><div class="gmail_quote">On Tue, Jun 2, 2009 at 11:03 AM, Dave Viner <span dir="ltr">&lt;<a href="mailto:daveviner@pobox.com">daveviner@pobox.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Jay,<br>
<br>
JSON is a transport mechanism.  Your web service returns some<br>
information.  Traditionally, it would be something like XML.  JSON is<br>
just easier when the code invoking the web service is Javascript.<br>
That&#39;s all.<br>
<br>
The more challenging part is figuring out what web services you really<br>
need.  Usually, you start with either REST or SOAP as the primary<br>
definition of your architecture.  Personally, I always start with REST<br>
because it&#39;s more in tune with the general architecture of the web as<br>
a whole.  (This is a bit of a philosophical debate, but you can read<br>
more about that elsewhere.)  You can develop a REST-afarian system by<br>
thinking through the &quot;objects&quot; or &quot;resources&quot; of your system.  To use<br>
a language metaphor, in a REST architecture, the resources are the<br>
nouns - the things on which you act.  The verbs are limited to GET,<br>
PUT, POST, and DELETE.  GET returns the &quot;representation of the<br>
resource&quot;.  DELETE removes the resource.  PUT (usually) creates the<br>
resource, and POST updates an existing resource.<br>
<br>
You can get a decent grounding in REST architecture design by reading<br>
just a few articles:<br>
&quot;How to create a REST Protocol&quot; -<br>
<a href="http://www.xml.com/pub/a/2004/12/01/restful-web.html" target="_blank">http://www.xml.com/pub/a/2004/12/01/restful-web.html</a> - this is one of<br>
the first solid walkthroughs of how to make your own protocol.  (Note<br>
that for the purposes of this discussion, &quot;protocol&quot; and &quot;web service&quot;<br>
are roughly synonymous.)  Read this 3 page article first.<br>
<br>
&quot;PUT or POST&quot; -<br>
<a href="http://jcalcote.wordpress.com/2008/10/16/put-or-post-the-rest-of-the-story/" target="_blank">http://jcalcote.wordpress.com/2008/10/16/put-or-post-the-rest-of-the-story/</a><br>
- this article focuses on the distinction between PUT and POST.  Both<br>
create or modify existing resources, so people frequently get confused<br>
as to why and when to use each.<br>
<br>
<br>
Those should give you a pretty solid understanding of how to get going<br>
in the REST world.<br>
<br>
Here are some thoughts on your specific questions:<br>
<div class="im">&quot;do you typically build really atomic pieces of code and communicate<br>
via JSON, even between processes on the same host?&quot;<br>
</div>- yes.  You define what your resources are.  Then you define what each<br>
REST verb means for each resource.  The response from your server will<br>
be in JSON.  Location of the host doesn&#39;t matter.  All communication<br>
between components is HTTP.  This has the rather spectacular benefit<br>
of allowing you to scale - when it&#39;s architected correctly.<br>
<div class="im"><br>
&quot;Where do the API of individual components end where you pass data in<br>
native format, and the JSON begin?&quot;<br>
</div>- This is hard to answer without knowing more of your process.  I&#39;d<br>
suggest starting with the definition of your resources, then the<br>
verbs.  That should help you define what the services are, and what<br>
actions you &quot;take&quot; or &quot;effect&quot; on them.  JSON is just the way to send<br>
information in response to the service request.  You could substitute<br>
XML for JSON and the resulting system would be identical.  Or you<br>
could use plain text of specified formats (e.g., csv, tsv, or simple<br>
new-line delimited keywords) and it&#39;s still the same.<br>
<br>
HTH<br>
<font color="#888888">Dave Viner<br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
On Tue, Jun 2, 2009 at 7:47 AM, Jay Strauss &lt;<a href="mailto:me@heyjay.com">me@heyjay.com</a>&gt; wrote:<br>
&gt; I like the idea of a java script (AJAX) client, although I don&#39;t know<br>
&gt; javascript, which just means more learning curve.<br>
&gt;<br>
&gt; You say use JSON.  I&#39;ve never used it (reading about it now), do you<br>
&gt; typically build really atomic pieces of code and communicate via JSON,<br>
&gt; even between processes on the same host?<br>
&gt;<br>
&gt; Where do the API of individual components end where you pass data in<br>
&gt; native format, and the JSON begin?<br>
&gt;<br>
&gt; Thanks<br>
&gt; Jay<br>
&gt;<br>
&gt; On Mon, Jun 1, 2009 at 2:27 PM, Dave Viner &lt;<a href="mailto:daveviner@pobox.com">daveviner@pobox.com</a>&gt; wrote:<br>
&gt;&gt; I would tend to agree with Jason.  Personally, I don&#39;t like most<br>
&gt;&gt; desktop apps.  I like to use my browser.  So, AJAX is perfect.  Just<br>
&gt;&gt; architect your web services to respond in JSON, and use jQuery to<br>
&gt;&gt; handle the communication.  This setup allows you to grow - if you and<br>
&gt;&gt; your brother hire other people, or want to license the software - and<br>
&gt;&gt; it allows you to make changes to the appropriate component (front-end<br>
&gt;&gt; versus service layer vs database).  (Note that many system would allow<br>
&gt;&gt; for similar levels of encapsulation.  I&#39;m just pointing out that a<br>
&gt;&gt; well-designed AJAX system allows the same flexibility as a<br>
&gt;&gt; well-designed desktop app or flash app or whatever else.)<br>
&gt;&gt;<br>
&gt;&gt; Another alternative to consider is AIR.  You can make a pretty simple<br>
&gt;&gt; desktop app using just HTML and JS.  Depending on your comfort with<br>
&gt;&gt; using Adobe as the main execution platform, it&#39;s an interesting<br>
&gt;&gt; approach that also buys you cross-platform compatibility.  Seesmic<br>
&gt;&gt; Desktop is a full AIR app which has some pretty cool features.<br>
&gt;&gt;<br>
&gt;&gt; HTH<br>
&gt;&gt; Dave Viner<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Mon, Jun 1, 2009 at 11:54 AM, Jason Rexilius &lt;<a href="mailto:jason@hostedlabs.com">jason@hostedlabs.com</a>&gt; wrote:<br>
&gt;&gt;&gt; Sorry to chime in here late in the conversation.  I was an architect at JP<br>
&gt;&gt;&gt; morgan for FX and fixed income web-based trading apps and some desktop apps<br>
&gt;&gt;&gt; so have a bit of experience in related fields.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; For fat client, I would suggest C++ if your desktop app needs good<br>
&gt;&gt;&gt; performance and Qt if your app needs good cross platform capability.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; If you do not need that level of performance I would jump all the way to the<br>
&gt;&gt;&gt; other end of the spectrum and look at Flex/Flash for fat-client-like<br>
&gt;&gt;&gt; capability or really well engineered AJAX interactivity (I built web-based<br>
&gt;&gt;&gt; FX trading apps using java, perl and javascript/HTML back in the day that<br>
&gt;&gt;&gt; moved very, very fast).<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Swing sux big time and you can get pretty close to its performance with well<br>
&gt;&gt;&gt; engineered flash client, particularly if the server component is local<br>
&gt;&gt;&gt; network.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; For server side, java is one choice, I think perl is still a strong<br>
&gt;&gt;&gt; candidate depending on _how_ you code.  Python is also a strong candidate.<br>
&gt;&gt;&gt;  If you are really looking to rock it hard, the best might be Erlang. But<br>
&gt;&gt;&gt; really it comes down to what language you are comfortable with.  A good perl<br>
&gt;&gt;&gt; coder can build a faster app than a bad Java coder..<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Me personally, unless you were doing heavy real-time trading based on market<br>
&gt;&gt;&gt; timing, I would build client in HTML/JS and server side with LAMP stack<br>
&gt;&gt;&gt; (perl, python or PHP) with shared mem or other high performance IPC<br>
&gt;&gt;&gt; mechanism to whatever your trading data feed provider is (reuters,<br>
&gt;&gt;&gt; bloomberg, etc.).  If you needed to do transforms or manips on data feed I&#39;d<br>
&gt;&gt;&gt; right that in C/C++ or erlang.  If youre just talking to a DB, then the<br>
&gt;&gt;&gt; basic principles of a good handler that wraps all access to DBs and good<br>
&gt;&gt;&gt; schema design should really be enough. ORMs are often more baggage than help<br>
&gt;&gt;&gt; but maybe use a simple code generator to do light ORM class building or<br>
&gt;&gt;&gt; something..<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Jay Strauss wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I don&#39;t think we&#39;ve set upon Java or not.  But I don&#39;t feel there is a<br>
&gt;&gt;&gt;&gt; good Perl rich GUI alternative (I know about wxperl, and am not in<br>
&gt;&gt;&gt;&gt; love)<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On Mon, Jun 1, 2009 at 12:35 PM, Michael Potter &lt;<a href="mailto:michael@potter.name">michael@potter.name</a>&gt;<br>
&gt;&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Jay,<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Here is my 2 cents:  If you are intending to replace Perl with Java then<br>
&gt;&gt;&gt;&gt;&gt; consider Groovy instead of Java.  Groovy has a lot of the benefits of<br>
&gt;&gt;&gt;&gt;&gt; Perl<br>
&gt;&gt;&gt;&gt;&gt; (Dynamic Language), but runs on the JVM and can interface with class<br>
&gt;&gt;&gt;&gt;&gt; files<br>
&gt;&gt;&gt;&gt;&gt; that were created with javac.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Let us know what you decide.<br>
&gt;&gt;&gt;&gt;&gt; --<br>
&gt;&gt;&gt;&gt;&gt; Michael Potter<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; On Mon, Jun 1, 2009 at 12:14 PM, Jay Strauss &lt;<a href="mailto:me@heyjay.com">me@heyjay.com</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; Hi all, need some advice.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; I want to build a new system.  My bro and I have a small<br>
&gt;&gt;&gt;&gt;&gt;&gt; equity/options trading application.  We cobbled it together in Perl<br>
&gt;&gt;&gt;&gt;&gt;&gt; and Oracle years ago.  Things have broken, some of the stuff we want<br>
&gt;&gt;&gt;&gt;&gt;&gt; to change.  Ultimately we want to start over.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; I&#39;m just trying to decide on what architecture to use going forward.<br>
&gt;&gt;&gt;&gt;&gt;&gt; I know this is a pretty wide question.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; Most (all) of the processes will run on a single box.  I don&#39;t really<br>
&gt;&gt;&gt;&gt;&gt;&gt; have an idea of which presentation route we&#39;ll go (full rich client<br>
&gt;&gt;&gt;&gt;&gt;&gt; maybe using Java/Swing, maybe a Java Script client using GWT, maybe<br>
&gt;&gt;&gt;&gt;&gt;&gt; plain HTML).  The client will probably request functionality from the<br>
&gt;&gt;&gt;&gt;&gt;&gt; server.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; I was thinking we&#39;d do the whole API for asking for quotes, requesting<br>
&gt;&gt;&gt;&gt;&gt;&gt; analytics, inserting transactins...  via HTTP (SOAP).<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; Can anyone give me their thoughts on their lessons learned, maybe<br>
&gt;&gt;&gt;&gt;&gt;&gt; routes to try, stuff I should be thinking of...<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; (again I know this is pretty open ended, but I&#39;m interested in what<br>
&gt;&gt;&gt;&gt;&gt;&gt; others have done with success)<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; Thanks<br>
&gt;&gt;&gt;&gt;&gt;&gt; Jay<br>
&gt;&gt;&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt;&gt;&gt; Chicago-talk mailing list<br>
&gt;&gt;&gt;&gt;&gt;&gt; <a href="mailto:Chicago-talk@pm.org">Chicago-talk@pm.org</a><br>
&gt;&gt;&gt;&gt;&gt;&gt; <a href="http://mail.pm.org/mailman/listinfo/chicago-talk" target="_blank">http://mail.pm.org/mailman/listinfo/chicago-talk</a><br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt;&gt; Chicago-talk mailing list<br>
&gt;&gt;&gt;&gt;&gt; <a href="mailto:Chicago-talk@pm.org">Chicago-talk@pm.org</a><br>
&gt;&gt;&gt;&gt;&gt; <a href="http://mail.pm.org/mailman/listinfo/chicago-talk" target="_blank">http://mail.pm.org/mailman/listinfo/chicago-talk</a><br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt; Chicago-talk mailing list<br>
&gt;&gt;&gt;&gt; <a href="mailto:Chicago-talk@pm.org">Chicago-talk@pm.org</a><br>
&gt;&gt;&gt;&gt; <a href="http://mail.pm.org/mailman/listinfo/chicago-talk" target="_blank">http://mail.pm.org/mailman/listinfo/chicago-talk</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; Chicago-talk mailing list<br>
&gt;&gt;&gt; <a href="mailto:Chicago-talk@pm.org">Chicago-talk@pm.org</a><br>
&gt;&gt;&gt; <a href="http://mail.pm.org/mailman/listinfo/chicago-talk" target="_blank">http://mail.pm.org/mailman/listinfo/chicago-talk</a><br>
&gt;&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; Chicago-talk mailing list<br>
&gt;&gt; <a href="mailto:Chicago-talk@pm.org">Chicago-talk@pm.org</a><br>
&gt;&gt; <a href="http://mail.pm.org/mailman/listinfo/chicago-talk" target="_blank">http://mail.pm.org/mailman/listinfo/chicago-talk</a><br>
&gt;&gt;<br>
&gt; _______________________________________________<br>
&gt; Chicago-talk mailing list<br>
&gt; <a href="mailto:Chicago-talk@pm.org">Chicago-talk@pm.org</a><br>
&gt; <a href="http://mail.pm.org/mailman/listinfo/chicago-talk" target="_blank">http://mail.pm.org/mailman/listinfo/chicago-talk</a><br>
&gt;<br>
_______________________________________________<br>
Chicago-talk mailing list<br>
<a href="mailto:Chicago-talk@pm.org">Chicago-talk@pm.org</a><br>
<a href="http://mail.pm.org/mailman/listinfo/chicago-talk" target="_blank">http://mail.pm.org/mailman/listinfo/chicago-talk</a><br>
</div></div></blockquote></div><br>