Fork me on GitHub

n. Slang a rough lawless young Kuali developer.
[perhaps variant of Houlihan, Irish surname]
kualiganism n

Blog of an rSmart Java Developer. Full of code examples, solutions, best practices, et al.

Tuesday, November 18, 2014

Ducktyping Web Services Published on Rice


An article about how to one can use ducktyping with web services in Kuali applications. I have been wanting to write a piece on this for awhile now, but just have not had the time available.


Developing web services in general is commonplace in the web application arena. There are many different types of web services, different protocols, and even different consumers/producers available. Whenever transferring objects serialized ambiguously over something as generic as HTTP with a strictly typed language, there is a common issue that is encountered. That is sharing the class/schema between client/server API's. For example, suppose I have a class that looks like the following:

Notice that the getOrganization() method returns an object of type Organization. Unfortunately, the client probably has no idea about the implementation of Organization. One common way around this is to use a Data Transfer Object pattern. In that case, there would be a common library with a Organization interface that is implemented by an OrganizationDto class that is used. This is great. The trouble is that for each new class we create, we need two classes. The interface and the Data Transfer Object. What if there isn't a DTO? What if there isn't even the Organization interface? Do we create a DTO? Do we create the interface?

Instead, we can use something called ducktyping. It's called this because if it walks like a duck and talks like a duck, then it must be a duck. The concept is born in loosely-typed languages. It means that if a class looks and behaves like a certain class, it accepts it as that class. This kind of thing can be done in Java in cases like the one I have described.

Ducktyping Example

I've created an example to illustrate how to use ducktyping with Kuali Rice. Allow me to break down the fundamental pieces of how I solved the problem.

Proxy Class and Invocation Handler

This is where the magic actually happens. The Proxy creates an instance of the Organization instance with the DucktypeInvocationHandler.

The DucktypeInvocationHandler allows us to specify a generic implementation allowing us to ducktype any interface (including Organization).

This is of course a really simplified ducktyping implementation. It assumes that the ReST service is going to return some object as a Map. It should look something like this:
{"id":"1","name":"Human Resources"}

The invocation handler basically converts any query or assignment to method calls against the Map. Since all objects that come from the ReST service can be expected to be JSON Maps, we can reasonably use this to ducktype against all objects that return from ReST services.

The DucktypeInvocationHandler can be reused for other interfaces. This way, we do not need to create a new DTO for each interface. We can just rely on a generic invocation handler that works on everything.

That's ducktyping

No comments:

Post a Comment