IBM Support

Registry Services on the Glass - Part 1: Registration

Technical Blog Post


Registry Services on the Glass - Part 1: Registration


The Hitchhiker’s Guide to interfacing with Registry Services two-part series introduced everything you needed to know about Registry Services’ concepts in order to write a client application. If you are already familiar with RESTful interfaces and RDF models, you probably can skip a good part of it.

The Java language is certainly very popular and well-covered in the Registry Services samples, but it will not be of much help if your code runs inside a web-browser and you are not keen on suffering through the time-tested pain of mixing applets with real code.

For those wanting a pure Javascript solution, there is an extensive collection of frameworks out there. I particularly suggest that you skim through the excellent summary under “Strategies for Building Semantic Web Applications”. I chose the RDFQuery plugin for jQuery for the comprehensive RDF support, and for jQuery’s small footprint and wide adoption in the developer community. Still on my list is trying to figure out a direct connection between RDF resources and Dojo data stores, the other 800lb gorilla of Javascript frameworks.

Before you start, if you are like me, you probably would prefer to have the complete source code on hand while reading through the explanations, so I uploaded the entire example to GitHub.

You need an RDF resource for your Service Provider record first…

Assuming you have read through the OSLC Core specification for a Service Provider, you know a Service Provider should have at least one Service, which would lead you to an RDF model like the one below, using Notation 3/N-Triples/Turtle representation. Pause to note that this type of notation is not yet supported in Registry Services, but it is more compact for usage in a blog entry and also easier to map to a triple-based RDF programming framework like RDFQuery.

    @prefix rr: <>.
    @prefix dcterms: <>.
    @prefix oslc: <>.
    @prefix rdf: <>.

        a oslc:ServiceProvider.
        dcterms:title "Example service provider"^^rdf:XMLLiteral; 
	dcterms:description "Example provider created with Javascript"^^rdf:XMLLiteral;
        oslc:service _:servicePerf; 
    _:servicePerf oslc:domain <>;
	a oslc:Service.

In the interest of clarity (?) , here is the representation of that same RDF resource in the RDF/XML abbreviated format that Registry Services will actually receive from the code snippet.

    <?xml version="1.0" encoding="utf-8"?>
    <rdf:RDF xmlns:dcterms=""
        xmlns:rr="" >
      <oslc:ServiceProvider rdf:about="">
        <dcterms:title rdf:parseType="Literal">Example service provider</dcterms:title>
        <dcterms:description rdf:parseType="Literal">Example provider created with Javascript
            <oslc:domain rdf:resource="" />


…then map it to RDF statements


Here is the Javascript snippet that would create the RDFQuery databank (‘databank’ is RDFQuery-speak for an in-memory RDF model) :

    var spSourceUrl = "";
    var sp = $.rdf
     .prefix("dcterms", "")
     .prefix("oslc", "")
     .prefix("rdf", "")
     .prefix("rr", "")
     .add("<" + spSourceUrl + "> rdf:type <> .")
     .add("<" + spSourceUrl + "> dcterms:title \"Example service provider\" .")
     .add("<" + spSourceUrl + "> dcterms:description \"Example provider created with Javascript\" .")
     .add("<" + spSourceUrl + "> oslc:service _:servicePerf .")
     .add("_:servicePerf oslc:domain <> ."); 



The next step is to convert that databank to a payload that can be understood by Registry Services, such as abbreviated RDF/XML:



      var spDump = sp.dump({ 
         format : "application/rdf+xml" 



With the HTTP POST request payload in hands, it is time to let jQuery send the request to the Registry Services application:



        type : "POST",
        contentType : "application/rdf+xml; charset=UTF-8",
        url : "/oslc/pr/collection",
        processData : false,
        data : spDump,
        success : function(response, textStatus, jqXHR) {
          var spUrl = jqXHR.getResponseHeader("Location");


Note that the URL parameter assumes the web-application containing the Javascript is running on the same server running Registry Services. Cross-site domain restrictions and workarounds apply.


RDF model for a Registration Record…

With the location of the service provider in hands, it is not possible to proceed with creating a registration record for that service provider.

Here is the RDF model, again in Notation 3/N-Triples/Turtle representation:


    @prefix crtv: <>. 
    @prefix dcterms: <>. 
    @prefix oslc: <>.
    @prefix rdf: <>. 
    @prefix rr: <>.
    @prefix vm: <>.
    <> rr:recordType crtv:monitoring;
        a rr:RegistrationRecord, 
	oslc:serviceProvider <provider_url>;
        crtv:model "2007CAO"; 
	crtv:manufacturer "IBM";
	crtv:serialNumber "LG3G4";
	crtv:systemBoardUUID "avc-d1b27283-013c-8f36-4dbc-74bd38ca7e3f-z1";
	crtv:virtual "false";
	vm:state "up";









…and its mapping to Javascript

Once again, you can use the now familiar sequence of Javascript code to create the RDFQuery databank and post it to the Registry Services application:

    var regRecordUrl = "";
    var registrationRecord = $.rdf
       .prefix("oslc", "")
       .prefix("rdf", "")
       .prefix("rr", "")
       .prefix("crtv", "")
       .prefix("vm", "")
       .add("<" + regRecordUrl + "> rdf:type <> .")
       .add("<" + regRecordUrl + "> rdf:type <> .")
       .add("<" + regRecordUrl + "> oslc:serviceProvider <" + spUrl + "> .")
       .add("<" + regRecordUrl + "> rr:recordType <> .")
       .add("<" + regRecordUrl + "> crtv:manufacturer \"IBM\" .")
       .add("<" + regRecordUrl + "> crtv:model \"2007CAO\" .")
       .add("<" + regRecordUrl + "> crtv:serialNumber \"LG3G4\" .")
       .add("<" + regRecordUrl + "> crtv:systemBoardUUID \"avc-d1b27283-013c-8f36-4dbc-74bd38ca7e3f-z1\" .")
       .add("<" + regRecordUrl + "> crtv:virtual \"false\" .")
       .add("<" + regRecordUrl + "> vm:state \"up\" .");

    var regRecordDump = registrationRecord.dump({
      format : "application/rdf+xml"

        type : "POST",
        contentType : "application/rdf+xml; charset=UTF-8",
        url : "/oslc/rr/registration/collection",
        processData : false,
        data : regRecordDump,
        success : function(response, textStatus, rrjqXHR) {
            var rrUrl = rrjqXHR.getResponseHeader("Location");


And that is it!


Once the two script sequences are executed, you should have both a Service Provider and a corresponding Registration Record inside Registry Services. If you are running the sample in the GitHub repository, you should see the resulting URLs for the two records nicely displayed on a table. If you do give it a try, I am interested in your overall experience following the series.

In the next entry I will go over an example of how to query data from Registry Services.

[{"Business Unit":{"code":"BU050","label":"BU NOT IDENTIFIED"},"Product":{"code":"SSHPN2","label":"Tivoli"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"","Edition":"","Line of Business":{"code":"","label":""}}]