Increasingly JSON is being used as a transport medium for data and with the rise of NoSQL solutions, having a selector language for JSON makes a lot of sense when dealing with JSON documents whose structure isn’t deterministic.

JSONSelect provides a good implementation of just such a JSON selector language but after working with it on a project I found myself needing to do more than it allowed me to do. Namely, I wanted 1. to be able to perform a selection and receive matching paths instead of the data contained in those paths and I wanted 2. to be able to modify data specified at a path location in-place.

jsonselect.match(sel, obj, asPath); // Added the asPath flag to return a path instead of the values
jsonselect.forEach(sel, obj, fun, asPath); // Added the same flag to forEach, I use this to
jsonselect.get(path,obj); // For getting the value using a path
jsonselect.set(path, value, obj); // For setting the value of a path
jsonselect.del(path,root); // For deleting a path

Here is my modified version of jsonselect in case anyone needs help solving the same problems I mentioned above.

Share/Save

• The project is now thread-safe. I’ve removed request and response as global objects and, instead, made sure they get passed along the request chain.
• This means the events for request and response have been taken out (which, I’ve been informed, I didn’t make a big enough deal about last time). The only event that you will get now is the init complete event which will provide your application a copy of the servlet configuration.
• You can still access the request object (and, subsequently, the session object) by accepting a single HashMap parameter in your method.
• A new annotation has been added, @Jpoxy(enabled = false), which allows you to tell the framework not to expose a method if it is public. This means you can mark all your internal event listener code so they aren’t exposed to the public.
• You can now expose methods which accept a complex Java object. This means you can expose a method which accepts, say, a User object and the framework will use Jackson to marshal the parameters you provide into that object.

We also now have a Google group! So if you have any questions or comments we would love to hear from you.

Share/Save

Here is an example query that is now possible:

http://localhost:8080/hbasebridge/rpc?debug=true&data={"method":"lookup","params":{"table":"hbasetable","filter":"searchstring"}}

Share/Save

For more information (and for future updates), visit the new project page here.

If you are interested in using, contributing to, or reporting bugs for this project, contact us!

Share/Save

Explanation of standard formats and protocols:

• JSON (JavaScript Object Notation) is a lightweight¹ data-interchange format with language bindings for C, C++, C#, Java, JavaScript, Perl, TCL and many others.
• JSON-RPC is a simple remote procedure call protocol similar to XML-RPC although it uses the lightweight JSON format instead of XML.

What is it?

I love the simplicity of JSON-RPC when it comes to rapidly devloping cutting-edge web applications.

I recently decided to start writing more server-side code in Java servlets in order to take advantage of cloud-based infrastructures such as the Google App Engine. Until now I have written my web applications using PHP as the server-side language. Specifically using frameworks such as Symfony or Kohana, which makes writing simple JSON-RPC services relatively trivial.

So I started looking for a simple JSON-RPC system I could use in Java to abstract my business logic classes from the mundane tasks associated with handling web requests. I found several packages which all claimed to implement the JSON-RPC protocol via Java servlets, however they seemed to require far more by way of setup than I wanted and they all seemed to require the developer to write applications to their specific implementation’s standards.²

So I decided to write yet another Java implementation of the JSON-RPC specification myself with the following goals in mind:

• Easy to implement. Setup for this package should be kept at a minimum. This includes both development as well as production setup.
• Easy to code in. Application developers using this class should not need to know much about JSON-RPC beyond exposing methods in their code that can be called remotely from other applications via the web.
• Non-invasive. Developers using this implementation should be able to reuse plain old Java object (POJO) classes as much as possible, making the transport layer of JSON-RPC as transparent as possible.

With these goals in mind I set off to develop the package com.werxltd.jsonrpc to be a simple wrapper designed to be used inside of a standard .war project.

Setting it up

You can either download the .jar file here to include in your project manually or (and this is my preferred method) you can import the com.werxltd.jsonrpc package as a dependency in your Maven-managed project by specifying the following in your project’s pom.xml configuration file:

<repositories>
    <repository>
        <id>werxltd</id>
        <url>http://maven.werxltd.com </url>
        <snapshots>
            <enabled>true</enabled>
        </snapshots>
        <releases>
           <enabled>true</enabled>
       </releases>
    </repository>
</repositories>

<dependencies>
    <dependency>
        <groupId>com.werxltd</groupId>
        <artifactId>jsonrpc</artifactId>
        <version>0.9</version>
    </dependency>
</dependencies>

Next, you’ll need to specify endpoints in your .war file’s web.xml configuration file. Here’s an example:

<web-app>
    <servlet>
        <servlet-name>example</servlet-name>
        <servlet-class>com.werxltd.jsonrpc.RPC</servlet-class>
        <init-param>
            <param-name>rpcclasses</param-name>
            <param-value>YourClass</param-value>
        </init-param>
    </servlet>

    <servlet-mapping>
        <servlet-name>example</servlet-name>
        <url-pattern>/example</url-pattern>
    </servlet-mapping>
</web-app>

That’s it! Now your project is configured to filter all requests sent to /example through the JSON-RPC class which examines the class name you passed in (in this case, YourClass) for public methods it can expose. An instance of your class is created internally if your class is not static and it will remain in memory throughout the life of the servlet. Any exceptions your class generates are gracefully wrapped inside a JSON-RPC error message for proper handling upstream.

Using it

While the setup is pretty much straightforward, due to the loose typing found in JavaScript (and, as a result, JSON) there are some caveats in how methods are called. Specifically in how arguments are passed to those methods.

Scanned methods are stored internally with a signature consisting of the method name and how many arguements that method accepts. When a JSON-RPC request is made, the servlet determines how many parameters were included and attempts to match the method requested with a corresponding internal method which has the same number of parameters/arguements.

Because parameters are passed in via the web, only Java primitive data types along with three others, JSONObject, JSONArray and java.lang.String are accepted as valid parameter data types.

If a match of method name and number of parameters is found, an attempt is made to parse the passed-in data into the method’s required type. Any methods which accept as their first parameter a parameter of the JSONObject type, this method automatically takes prescience over all other parameters.

To use the JSON-RPC interface from another application, you must pass a valid JSON-RPC object to your final servlet as a parameter named “json” via either GET or POST. Here is an example of the valid JSON-RPC object you need to pass:

{
    "method":"add",
    "params":[1 2 3]
}

This JSON-RPC implementation accepts either named parameters or positional parameters like the ones shown above. Here is a named parameters example:

{
    "method":"echo",
    "params":{
        "text":"testing"
    }
}

The road ahead

Future development of this class will include more formalized access between the JSON-RPC layer and the underlying classes.

I’m also planning to post the Javadocs and the source to an example project that utilizes the JSON-RPC transport package.

Hope this helps someone else. I’m looking forward to using this class as a central component in many rich web projects I have planned.

1. Lightweight in both size and resources required to process data encoded in JSON vs. XML.
2. I did find this project after finishing the first revision of my class. It looks great and like it would do much of what I wanted, however the code is proprietary. After I finish documenting my classes I plan on releasing them under an OSI-approved licence. If you are interested in helping me with this project, feel free to let me know!

Share/Save

If you find this useful or a have a suggestion, feel free to let me know!

private function getStripped($obj) {
		$objVars = get_object_vars($obj);

		if(count($objVars) > 0) {
			foreach($objVars as $propName => $propVal) {
				if(gettype($propVal) == "object") {
					$cObj = $this->getStripped($propVal);
					if($cObj == null) {
						unset($obj->$propName);
					} else {
						$obj->$propName = $cObj;
					}
				} else {
					if(empty($propVal)) {
						unset($obj->$propName);
					}
				}
			}
		} else {
			return null;
		}
		return $obj;
	}

Share/Save

slow.

While SOAP has been widely adopted and used in web-based applications, and while XML has become the predominant information exchange medium, we’re finding out that they just aren’t as efficient as they could be. The main problem stems mostly from bloat inherit in the XML specification. In a nutshell, XML requires a root node and well-formed tags in order to make it “valid”. So the way you would send a simple name/value pair in XML would be:

     value

While this may not be too bad for console-based applications¹ this is extremely inefficient for web-based applications because of it’s size and the processing that is required to parse or “walk” the XML nodes in order to get the data you want.

Because of these (and other) issues, JSON was developed as a lightweight, cross-browser, alternative. JSON is essentially shorthand JavaScript Object Notation that allows us to pass name/value pairs in the format

{
     "name":"value"
}

which, as you can see compared to the XML above, saves a considerable amount of space and processing time on the client since JavaScript merely has to eval() the JSON string in order to parse it into a usable data object.

The problem we have now is that SOAP is only designed to use XML, not JSON, and the other communication alternatives like JSON-RPC are generally too lightweight and require extra code to handle errors not to mention the non-uniformity of the data that is often returned.

Enter SOAPjr, a lightweight alternative to SOAP and JSON-RPC that uses JSON schemas for data validation.

While SOAPjr doesn’t have very many tools and libraries at the moment, it is a very promising answer to the need for a lightweight and yet robust communications protocol. I plan on helping out with the development by helping to create tools in my favorite languages and frameworks like PHP, ExtJS, Java, GXT, Symfony, etc.

If you want to help out, get in touch with the SOAPjr team by emailing them at tools [at] SOAPjr.org.

1. And I would argue that even there processing time is being misused processing the data.

Share/Save