Three patterns for integrating .NET apps with Oracle Spatial & Graph Semantic Database

Just a quick blog post on how to integrate your .NET application with an Oracle Semantic RDF backend.

The key thing to understand is that, much like other database vendors, Oracle’s implementation of SPARQL/RDF requires a plugin. The out-of-the-box plugin supplied with all of the latest versions of Oracle database is an Oracle-specific implementation of the Apache JENA adapter**. The purpose of the JENA adapter is to convert SPARQL queries into native SQL. As such, if you wish to integrate using traditional coding patterns, Oracle assumes you will be running Java.

But that doesn’t mean that it is impossible to do a relatively clean integration using .NET. Au contraire. SPARQL by its very nature was designed to with HTML get and puts in mind. As such, the obvious integration between .NET and Oracle would be to leverage that feature of the WC3 specification.

We herein present three patterns for doing such an integration. There are obviously other patterns (not the least of which would be to write a custom .NET adapter), but these three appear to be the most likely to be implemented quickly and easily. Please be aware that Visual Studio already has native SQL integrations with Oracle database, therefore certain bits of the .NET to Oracle RDF integration are already in place (specifically, the ability to directly query the datastore in SQL for maintenance, logging, testing, and analytics).

Note: the primary assumption we are making in this post is that the Oracle database will be provisioned on Oracle Cloud Infrastructure (a.k.a. OCI).

#1. Pure OCI solution

This pattern should be obvious: host everything on OCI. You would start with provisioning an Oracle Database instance (either on compute, or DBaaS, or Autonomous), provision a compute instance for hosting TomCat and installing the JENA plugin there, and then finally provisioning another compute for one of the various the Windows Server images.  

#2. Cross-cloud solution

This pattern would be considered by those clients who have a big investment in Azure but want their Oracle database to perform at its best. First, you would start with provisioning an Oracle Database instance (either on compute, or DBaaS, or Autonomous), provision a compute instance for hosting TomCat and installing the JENA plugin there, and then finally connect your Azure ExpressRoute circuit to a corresponding Oracle FastConnect circuit. It goes without saying that both data centers will need to be in the same region.   

#3. Hybrid on-prem/cloud solution

This pattern would be considered by those clients who have requirements for maintaining their on-prem architecture but want their Oracle database to perform at its best. It is similar to #2 mentioned above except that Azure is not involved. First, you would start with provisioning an Oracle Database instance (either on compute, or DBaaS, or Autonomous), provision a compute instance for hosting TomCat and installing the JENA plugin there, and then finally connect your customer-premises equipment to a corresponding Oracle FastConnect circuit.  

** the A-Team will soon open-source an Oracle-specific version of the Eclipse RDF4J adapter which should allow legacy applications with a SAIL/Sesame dependency to finally be able to integrate with Oracle’s enterprise-level implementation of RDF. 

Links:

• Eclipse RDF4J specification: https://rdf4j.org
• Apache JENA specification: https://jena.apache.org
• WC3 SPARQL specification: https://www.w3.org/TR/sparql11-query/