Hi, Dave,<br><br>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...<br>
<br>I'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"><<a href="mailto:daveviner@pobox.com">daveviner@pobox.com</a>></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'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'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 "objects" or "resources" 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 "representation of the<br>
resource". 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>
"How to create a REST Protocol" -<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, "protocol" and "web service"<br>
are roughly synonymous.) Read this 3 page article first.<br>
<br>
"PUT or POST" -<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">"do you typically build really atomic pieces of code and communicate<br>
via JSON, even between processes on the same host?"<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't matter. All communication<br>
between components is HTTP. This has the rather spectacular benefit<br>
of allowing you to scale - when it's architected correctly.<br>
<div class="im"><br>
"Where do the API of individual components end where you pass data in<br>
native format, and the JSON begin?"<br>
</div>- This is hard to answer without knowing more of your process. I'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 "take" or "effect" 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'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 <<a href="mailto:me@heyjay.com">me@heyjay.com</a>> wrote:<br>
> I like the idea of a java script (AJAX) client, although I don't know<br>
> javascript, which just means more learning curve.<br>
><br>
> You say use JSON. I've never used it (reading about it now), do you<br>
> typically build really atomic pieces of code and communicate via JSON,<br>
> even between processes on the same host?<br>
><br>
> Where do the API of individual components end where you pass data in<br>
> native format, and the JSON begin?<br>
><br>
> Thanks<br>
> Jay<br>
><br>
> On Mon, Jun 1, 2009 at 2:27 PM, Dave Viner <<a href="mailto:daveviner@pobox.com">daveviner@pobox.com</a>> wrote:<br>
>> I would tend to agree with Jason. Personally, I don't like most<br>
>> desktop apps. I like to use my browser. So, AJAX is perfect. Just<br>
>> architect your web services to respond in JSON, and use jQuery to<br>
>> handle the communication. This setup allows you to grow - if you and<br>
>> your brother hire other people, or want to license the software - and<br>
>> it allows you to make changes to the appropriate component (front-end<br>
>> versus service layer vs database). (Note that many system would allow<br>
>> for similar levels of encapsulation. I'm just pointing out that a<br>
>> well-designed AJAX system allows the same flexibility as a<br>
>> well-designed desktop app or flash app or whatever else.)<br>
>><br>
>> Another alternative to consider is AIR. You can make a pretty simple<br>
>> desktop app using just HTML and JS. Depending on your comfort with<br>
>> using Adobe as the main execution platform, it's an interesting<br>
>> approach that also buys you cross-platform compatibility. Seesmic<br>
>> Desktop is a full AIR app which has some pretty cool features.<br>
>><br>
>> HTH<br>
>> Dave Viner<br>
>><br>
>><br>
>> On Mon, Jun 1, 2009 at 11:54 AM, Jason Rexilius <<a href="mailto:jason@hostedlabs.com">jason@hostedlabs.com</a>> wrote:<br>
>>> Sorry to chime in here late in the conversation. I was an architect at JP<br>
>>> morgan for FX and fixed income web-based trading apps and some desktop apps<br>
>>> so have a bit of experience in related fields.<br>
>>><br>
>>><br>
>>> For fat client, I would suggest C++ if your desktop app needs good<br>
>>> performance and Qt if your app needs good cross platform capability.<br>
>>><br>
>>> If you do not need that level of performance I would jump all the way to the<br>
>>> other end of the spectrum and look at Flex/Flash for fat-client-like<br>
>>> capability or really well engineered AJAX interactivity (I built web-based<br>
>>> FX trading apps using java, perl and javascript/HTML back in the day that<br>
>>> moved very, very fast).<br>
>>><br>
>>> Swing sux big time and you can get pretty close to its performance with well<br>
>>> engineered flash client, particularly if the server component is local<br>
>>> network.<br>
>>><br>
>>><br>
>>> For server side, java is one choice, I think perl is still a strong<br>
>>> candidate depending on _how_ you code. Python is also a strong candidate.<br>
>>> If you are really looking to rock it hard, the best might be Erlang. But<br>
>>> really it comes down to what language you are comfortable with. A good perl<br>
>>> coder can build a faster app than a bad Java coder..<br>
>>><br>
>>> Me personally, unless you were doing heavy real-time trading based on market<br>
>>> timing, I would build client in HTML/JS and server side with LAMP stack<br>
>>> (perl, python or PHP) with shared mem or other high performance IPC<br>
>>> mechanism to whatever your trading data feed provider is (reuters,<br>
>>> bloomberg, etc.). If you needed to do transforms or manips on data feed I'd<br>
>>> right that in C/C++ or erlang. If youre just talking to a DB, then the<br>
>>> basic principles of a good handler that wraps all access to DBs and good<br>
>>> schema design should really be enough. ORMs are often more baggage than help<br>
>>> but maybe use a simple code generator to do light ORM class building or<br>
>>> something..<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> Jay Strauss wrote:<br>
>>>><br>
>>>> I don't think we've set upon Java or not. But I don't feel there is a<br>
>>>> good Perl rich GUI alternative (I know about wxperl, and am not in<br>
>>>> love)<br>
>>>><br>
>>>> On Mon, Jun 1, 2009 at 12:35 PM, Michael Potter <<a href="mailto:michael@potter.name">michael@potter.name</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> Jay,<br>
>>>>><br>
>>>>> Here is my 2 cents: If you are intending to replace Perl with Java then<br>
>>>>> consider Groovy instead of Java. Groovy has a lot of the benefits of<br>
>>>>> Perl<br>
>>>>> (Dynamic Language), but runs on the JVM and can interface with class<br>
>>>>> files<br>
>>>>> that were created with javac.<br>
>>>>><br>
>>>>> Let us know what you decide.<br>
>>>>> --<br>
>>>>> Michael Potter<br>
>>>>><br>
>>>>> On Mon, Jun 1, 2009 at 12:14 PM, Jay Strauss <<a href="mailto:me@heyjay.com">me@heyjay.com</a>> wrote:<br>
>>>>>><br>
>>>>>> Hi all, need some advice.<br>
>>>>>><br>
>>>>>> I want to build a new system. My bro and I have a small<br>
>>>>>> equity/options trading application. We cobbled it together in Perl<br>
>>>>>> and Oracle years ago. Things have broken, some of the stuff we want<br>
>>>>>> to change. Ultimately we want to start over.<br>
>>>>>><br>
>>>>>> I'm just trying to decide on what architecture to use going forward.<br>
>>>>>> I know this is a pretty wide question.<br>
>>>>>><br>
>>>>>> Most (all) of the processes will run on a single box. I don't really<br>
>>>>>> have an idea of which presentation route we'll go (full rich client<br>
>>>>>> maybe using Java/Swing, maybe a Java Script client using GWT, maybe<br>
>>>>>> plain HTML). The client will probably request functionality from the<br>
>>>>>> server.<br>
>>>>>><br>
>>>>>> I was thinking we'd do the whole API for asking for quotes, requesting<br>
>>>>>> analytics, inserting transactins... via HTTP (SOAP).<br>
>>>>>><br>
>>>>>> Can anyone give me their thoughts on their lessons learned, maybe<br>
>>>>>> routes to try, stuff I should be thinking of...<br>
>>>>>><br>
>>>>>> (again I know this is pretty open ended, but I'm interested in what<br>
>>>>>> others have done with success)<br>
>>>>>><br>
>>>>>> Thanks<br>
>>>>>> Jay<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>
>>>>><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>
>>>>><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>
>>><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>
>>><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>
>><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>
><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>