I have recently been involved in a project where an RDF ontology + instance set needs to be exposed through a web UI. Being a Java man myself I was immediately set to start fiddling about with JSP/JSF, Spring MVC and (obviously) a Sesame 2 store.
However, in this project my coworkers are .Net developers, so we were left with either me doing all the work myself or somehow figuring out a way of using a Sesame store in a .Net environment. Given that I only have one brain and two arms, and the project has a deadline that falls within the first half of this century, we decided to go for the second option. The web frontent will be in ASP/.Net, the server backend will run Sesame in Java. So, how to get them to talk?
Our first attempt involved using Spring-WS to write a Web Services wrapper (SOAP messaging, WSDL description, the works) around the Sesame store. However, this wrapper was application-specific (talking in terms of business objects from the application domain rather than being a generic sesame wrapper), and really rather large, clumsy and difficult to maintain, so we decided to try something else.
Enter IKVM.net. This is a Java implementation for Mono and .Net that can also be used to do a static porting of Java classes to .Net bytecode (or CIL as they call it in .Net-land). Using a handy little tool called ikvmc I managed (in about half an hour time, mostly spent on trying to figure out which of Sesame 2's impressive collection of jar files to in- and exclude from the process) to create a DLL and he presto! A Sesame 2-compatible HTTP Repository proxy API for .Net Is Born!
Using this DLL we can now access, in C#, a remote Sesame server in exactly the same fashion as we would from a Java environment: by simply using Sesame's own Repository API.
Perhaps not the most elegant and robust solution - and not nearly as much fun as spending several man-months on painstakingly building a .Net client library from scratch, including the creation of parsers and writers for N3, Turtle, RDFXML, Trig, TriX, SPARQL XML result format, SPARQL, SeRQL, and Sesame 2's transaction serialization format - but in a pinch and on a tight budget quite a satisfactory little workaround.
