What is JSON, JSON-RPC and JSON-RPC-Java? 317
Michael Clark writes "Seen those funky remote scripting techniques employed by Orkut, Gmail and Google Suggests that avoid that oh so 80's page reloading (think IBM 3270 only slower). A fledgling standard is developing to allow this new breed of fast and highly dynamic web applications to flourish.
JSON (JavaScript Object Notation) is a lightweight data-interchange format with language bindings for C, C++, C#, Java, JavaScript, Perl, TCL and others. It is derived from JavaScript and it has similar expresive capabilities to XML. Perfect for the web as doesn't suffer from XML's bloat and is custom made for our defacto browser language.
JSON-RPC is a simple remote procedure call protocol similar to XML-RPC although it uses the lightweight JSON format instead of XML (so it is much faster).
The XMLHttpRequest object (or MSXML ActiveX in the case of Internet Explorer) is used in the browser to call remote methods on the server without the need for reloading the page.
JSON-RPC-Java is a Java implementation of the JSON-RPC protocol.
JSON-RPC-Java combines these all together to create an amazingly and simple way of developing these highly interactive type of enterprise java applications with JavaScript DHTML web front-ends.
" Click below to read more about it.
"Now is the turning point. Forget that horid wait while 100K of HTML downloads when the application just wanted to update one field on the page.
The XMLHttpRequest object has made it's way into all the main browsers with it's recent introduction into Opera and Konqueror (sans the Konqueror bug).
This new form of web development now works on Internet Explorer 5, 5.5, 6, Mozilla, Firefox, Safari 1.2, Opera 8 Beta and Konqueror 3.3 (with a much needed patch).
Appeal to Konqueror users - please log into the KDE bugzilla and vote on this bug
so you to can experience this wonderful thing.
More details here: http://oss.metaparadigm.com/jsonrpc/ "
Re:O...k..... (Score:4, Informative)
repopulate your product page for a new product WITHOUT reloading the whole page.
Put a timer in, and have rotating feature products WITHOUT reloading the whole page on a timer.
Update your totals in your chckout / shopping cart WITHOUT reloading the whole page.
Write an RSS news ticker in html rather than flash...
Basically anything that you might have used flash or an IFrame for, you could do with this, javascript and a DIV tag... Pretty important news (if you write commercial websites)
Re:Pros and cons? (Score:4, Informative)
A2. Yes, security is an interesting topic. The Java implementation refered to works on a deny all by default - allow specific objects to specific clients. It does require the programmer to think about what methods they are exposing. I have been using it over HTTPS with selective objects exported to authorized clients (using the existing JAAS Java authorization and Authentication framework), so I believe it can be used in a very secure way.
Re:Pros and cons? (Score:5, Informative)
Well, JSON is a subset of JavaScript object notation, so people who know JavaScript already know this. It's basically a way of transfering structured data between browser and server that is less verbose than XML, and can be eval()ed straight into javacript itself.
Of course, any server receiving this stuff via POST should do the same validity checks it does on anything else it gets from the wire. On the client, IIRC you can only use XMLHttpRequest with the server the document originated from, and neither should you be able to execute script across domains, even within iframes, so the existing browser security model should be sufficient to prevent additional security problems, bugs and exploits notwithstanding...
Re:Perfect for the web? I don't think so (Score:5, Informative)
Also, the JSON takes one line of code to parse and access natively in our defacto web browser language 'JavaScript'.
The second requires a bloated JavaScript XML parser (as this is not built in to many browsers) and CPU intensive processing and a cumbersome API to get the data out. Also try doing 100 RPC calls a second with SOAP in a browser (this can be done with JSON-RPC on a local network - 10ms round trip on simple methods).
ICBW but: Re:Perfect for the web? I don't think so (Score:3, Informative)
Re:Perfect for the web? I don't think so (Score:3, Informative)
Pushlets (Score:4, Informative)
This is a server side push framework based on the same idea. It preceded GMail et alia.
Or instead... (Score:3, Informative)
All JSON does is make it easier to have your JavaScript call in to your application and parse the results. If you're just interested in presentation, just have your JS call up, get some HTML, and replace the affected HTML. This decreases the amount of JS and increases your re-use (since you don't need to build your UI twice: once is (PHP|Java|.Net|Ruby|.*), and once in JS). You just call your (\1) code on the server from the JS and have it generate the HTML.
I understand that sometimes there are advantages to the programmatic approach that JSON (and XML-RPC, which the browsers support) extoll, but I don't think many developers even realize the UI-based alternative.
3270s (Score:3, Informative)
Hey, 3270s were coax-connected to a channel-attached controller with a 4.5MB/sec path to the CPU. You could do video on them (if you didn't mind the fact that your pixels were the size of a tic-tac.
A.
(who lusts for the feel of a 3270 keyboard under his fingers)
Re:XML-RPC did this *years* ago (Score:2, Informative)
Back to the future: Web = CICS? (Score:3, Informative)
However, your memory of 3270's is a lot different than mine. How about when that nifty wifty 3270 cluster controller went south, as it did at our shop multiple times per day? And maybe you could pump bits at it pretty fast, but under TSO your Q1 response time was 10 to 20 seconds during peak times, so it didn't really matter how high-speed the intrinsic channel was.
3270's were designed for forms entry with CICS apps, basically. It's a record-oriented device (like all IBM devices) which just doesn't add up to a very good user experience. You need character interrupts, and you need fast service for those interrupts. The mainframe secret is to let the CPU compute uninterrupted by batching up terminal I/O, screw the user.
Which is exactly the Web experience today. Fill in a form, press a button, wait. Back to the future! In the limit, it doesn't matter whether you're connecting back to get a whole new page, or whether you're doing some socket hackery under the covers to return a response to some jscript code. Either way, you're waiting for a server that's servicing a bazillion other people, so conceptually you might as well be running CICS thirty years ago.
Yeah, yeah, the screens are prettier now, you can download jscript and java applets, yadda yadda. You could program the 3270, too, with sufficient pain. Wake me up when this jscript shit actually works reasonably well. Just coming up for air after writing a few pages of it, and boy am I pissed. Standards all over the place. IE style.backgroundColor is "#ffffff", FF's is "rgb(255, 255, 255)". There are religious wars over "document.all", with some w3c fanatics claiming the world should have to write hideous tree-walkers to iterate over the DOM (so prove me wrong, post a code frag to show how easy it is). It never ends.
(that 3270 keyboard was GREAT. Nothing like it today. Typing on spongebob squarekeys at the moment).
Re:Pros and cons? (Score:3, Informative)
You're right, the expected client is JavaScript, inside a browser. The frontend UI is typically in HTML (or SVG), but the client-side logic is written in JavaScript. In this case, the request/response happens within a web-page, between the browser and the web server.
HTML forms are one mechanism for client-server data transfer in a browser, but posting them necessitates reloading the entire web-page, or an iframe, which is not seamless for interfaces like Google Suggest, and may be overkill if you're only making small changes. In addition, a pure POST of form parameters can't transfer the same level of structural detail as XML or JSON without writing your own custom parser/serializer in JavaScript. Since JSON /is/ JavaScript to all intents and purposes, no extra parser is needed.
Advantages to hidden iframe (Score:3, Informative)
You could use the JSON as message format with hidden iframes, too.
Re:O...k..... (Score:1, Informative)
I'm basing this on my understanding that the XmlHttpRequest object first appeared in Internet Explorer, and was later copied by the Mozilla folks.
That is correct. Since then, the DOM 3 Load and Save specification has been published by the W3C and implemented in Mozilla, Opera and Konqueror.