JSON-RPC is the answer to the argument that XML RPC is too verbose and bloated and convoluted.  JSON is just about as simple as you can get in data formats and it is becoming a great baseplane standard and is a tool that spans many platforms.

“Does distributed computing have to be any harder than this? I don’t think so.”

Can it be even simpler ?

JSON-RPC is lightweight remote procedure call protocol similar to XML-RPC. It’s designed to be simple!

• specification
• python package implementing JSON-RPC
• more implementations
• services
• about JSON-RPC

JavaScript

• There is a JSON-RPC implementations as part of JavaScript O Lait jsolait.
  You can also find some live examples
• The Open Source TelePort Library supports JSON-RPC as well as other RPC protocols.
  Live demos and documentation can be found here.
• JSON-RPC to Java bridge includes a JavaScript client.
• Dojo Toolkit 0.3 implements JSON RPC.
• JSON/XML-RPC Client Implementation which abstracts-away the differences between JSON-RPC and XML-RPC and permits cross-site requests.

C

• JSON-RPC C Bridge. There is also support for GoAhead WebServers.

C#

• .NET and ASP.NET

Erlang

• YAWS JSON-RPC module (HTTP client/server)

Java

• JSON-RPC to Java bridge
• JRP

Lisp

• Common Lisp

Lua

• Lua

Perl

• Catalyst using the JSONRPC plugin
• JSON module

Php

• JSON-PHP
• php-json
• PHP-O-Lait
• Phpxmlrpc (in the ‘extras’ package)
• SCA_SDO Pecl Package
• JSON_RPC_Server, a JSON-RPC implementation in PHP
• JSON/XML-RPC Server Implementation which abstracts-away the differences between JSON-RPC and XML-RPC.

Python

• A python package which implements the JSON-RPC specs. It includes an mod_python handler, a CGIHandler, a TCP server and (soon) a ServiceProxies implementation.
• CherryPy (python)
• Zope 2
• Zope 3
• Twisted JSON-RPC - Web, Web2, and TCP

Ruby

• Ruby

Frameworks

• Catalyst (Perl) using the JSONRPC plugin
• CherryPy (python)
• JRP
• .NET and ASP.NET
• Zope 2
• Zope 3

XML is railed against plenty these days for being too verbose and leads to massive config invasions in your codez. But it deserves due respect for what it did.

What did it do you say?

Well, there was a time when data services rarely existed, connecting to trading partners or business partners was almost impossible. Connecting with partners directly to their RDBMS which is poor coupling and is not as message based as services.

Before XML was accepted it was a pipe-delimited, tab delimited, column delimited, ini file, proprietary binary serialization, locked down, non sharing, no service type world. It was the dark ages of data sharing. Hate on XML all you want, XML opened the doors.

Then comes XML, the executives and CTO magazines flooded with the term XML and large budgets signed on the word alone. But was it all hype or did it do something amazing? XML Amazing you say? With XML it was so simple it gave people no excuse not to open up information. A flawless victory on data nazi attitude. Is it the best, no, but it did what was necessary. We would not have the service based systems we have now of even JSON or other more micro formats at all if it weren’t for XML. Both HTML and XHTML and XML are all responsible (javascript as well and MIME) for delivering the simplistic base platform which all programmers can write to to instantly make their apps standard, the web and services that live on them.

After XML… Yes, XML did the amazing… It freed data into services. The web was also instrumental in this effort itself but when systems started working so closely together the exchange and mapping of data quickly became troublesome. Before web services emerged, client/server, remoting, RPC or other more closely coupled communication connections ruled the day. XML with web services helped to push the service model in addition to other technologies such as SOAP bloated but XMLRPC, REST, JSON, have emerged in stronger force or late because they are better iterations and less enterprise-y and simpler and more compact but I still believe that XML was in large part a tool that made data so simple to share that the capabilities and costs came down when people wanted to expose this data.

XML deserves to be a baseplane technology and is used where appropriate in baseplane tools and toolkits.

XML is recently 10 years old, seems like the average for standards to truly take hold and influence. Same with CSS, XHTML, the DHTML that later became AJAX and javascript kits of today. They are all stepping platforms.

Markets of many things have a period of innovation and experimentation through normal human trial and error, record response, adjust feedback loops. Over time, certain market standards emerge.

For social networks these market standards are profiles, friends, messages, blogs, pictures, and other custom handlers. OpenSocial has emerged late 2007 and is a great example of where after a period of time, a standard baseplane platform emerges and makes it another stepping stone to a further period of innovation and experimentation through normal human trial and error, record response, adjust feedback loops by combining and allowing a protocol to expose and consume data for OpenSocial. This could help many smaller or quickly developed communities get setup quickly, and it will also create social network giants that own the data. OpenSocial from Google was released after Microsoft signed with Facebook. Google came back with OpenSocial that got lots of attention and respec, also a move for Google to own the information and data standard. Then Facebook got forced to open up the apis to provide almost the same functionality, but no OpenSocial. Sometimes you need toolkits that will help to talk to both systems or many more pluggable ROM generation kits that allow you to integrate into these services such as blogging has the metaweblog apis and do most communication in a RESTful or XMLRPC based standard communication. It has allowed many blogging tools to integrate and help proliferate the platform and the companies involved in constructing it such as Wordpress (Automattic), MoveableType (SixApart), etc. There is great value to having open standards and market standards that allow the platform to flourish.

The baseplane code generation BOM (baseplane object mapper) has a ROM (rapid object mapper) both in development that can map your objects or existing applications to share along the OpenSocial standards (roadmaps and tests coming soon). We have many more ROMs that allow layers to be added to your code generation and custom manipulation of that work that have been built after 12+ years of experience in enterprise development. The great thing is the ROMs are custom, meaning that they follow your coding style and how you want things. None of this dictator like ORM systems, this is the reverse to that. They can integrate with existing code and they are not THE platform, they help you shape one though. More on this as the BOM is dropped.

The good news is more platforms are emerging, the bad news is there is much to learn and become an expert on.