Re: [lyo-dev] Using OSLC SDK to build new OSLC compliant REST applicatio

[Vinod Kumar Choudhary <vinodkc@xxxxxxxxxx>]

Thanks for the reply and helping me understand the general approach.

My specific question is that for a new REST implementation I need to have
different data models for OSLC compliant implementation and the non-OSLC
compliant one.

For example for a user resource I can have the following representations
1. xml representation of RDF model
<rdf:Description rdf:about="
http://localhost:8080/TeamReview/services/users/701";>
	<dcterms:created>2012-11-15T17:00:29.156+05:30</dcterms:created>
	<dcterms:name rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral";>SDWB test1
user</dcterms:name>
	<tr:isArchived>n</tr:isArchived>
	<tr:emailAddress rdf:datatype="
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral
">sdwtest2@xxxxxxxxxx</tr:emailAddress>
	<dcterms:identifier>701</dcterms:identifier>
	<oslc:serviceProvider rdf:resource="
http://localhost:8080/TeamReview/services/serviceProviders/user"/>
	<rdf:type rdf:resource="http://sdwb.ibm.com/ns/team_review#User"/>
</rdf:Description>

2. Similarly will can have the JSON representation of RDF model

These representations are consumable by OSLC Clients and may not make sense
to non-OSLC REST Clients which accepts the simple resource represented in
XML or JSON format (say retrieved from DB), something like

3. In XML

<User>
	<id>701</id>
	<name>SDWB test1 user</name>
	<isArchived>n</isArchived>
	<emailAddress>sdwtest2@xxxxxxxxxx</emailAddress>
</User>


4. In JSON

  "User": {
    "id": "701",
    "name": "SDWB test1 user",
    "isArchived": "n",
    "emailAddress": "sdwtest2@xxxxxxxxxx"
  }
}

Now I want to support all the above 4 representations in my implementation.
So will it require separate implementation for RDF and non-RDF models?

We are using apache wink to develop our application . When we try getting a
JSON for the OSLC annotated resource (using OSLC SDK) then we get the OSLC
annotated data in JSON format and not the basic enity . Seems like the OSLC
rdf adaptor is mandating the OSLC resource enhancement even for non-rdf
media types . Is it ok or the OSLC adaptor should only enhance the
resources for RDF media types?

Regards,
Vinod



From:	Michael Fiedler <fiedler.mf@xxxxxxxxx>
To:	Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Date:	12/10/2012 11:30 PM
Subject:	Re: [lyo-dev] Using OSLC SDK to build new OSLC compliant REST
            application
Sent by:	lyo-dev-bounces@xxxxxxxxxxx



I don't know of any written guidelines around this.   Some things you
should be considering are:

 - What OSLC domain specification or resources will your tools artifacts be
exposed as
 - What APIs/data access mechanisms does the tool provide today?
 - What scenarios or use cases are you solving (programmatic access to the
data, delegated UIs., etc)?

An approach used successfully by others is an "adapter" approach.   The
OSLC enabling code runs remotely from the existing tool (or perhaps as a
plugin - depends on the tool architecture) and "translates" OSLC requests
into the tool's native API.   OSLC4J is well suited to this.   If you can
model the existing tool's data which you want to expose as Java objects
(POJOs), you can annotate these objects with OSLC attributes and then write
some JAX-RS REST services to GET, POST, PUT, DELETE these resources.

The OSLC4JBugzilla adapter in the git://
git.eclipse.org/gitroot/lyo/org.eclipse.lyo.docs.git repository does this.
It translates OSLC requests to the Bugzilla API - it accepts HTTP requests
for RDF/XML or JSON and returns/creates/updates the resources.

Take a look at http://wiki.eclipse.org/Lyo/BuildOSLC4JBugzilla to get
started.

Regards,
Mike


On Sun, Dec 9, 2012 at 1:50 PM, Vinod Kumar Choudhary <vinodkc@xxxxxxxxxx>
wrote:

  As the purpose of OSLC specifications is to enable integration between
  the
  products and these specifications sets out the common features that OSLC
  compliant applications are expected to support.
  So when we make an existing tool OSLC compliant so that it can integrate
  with another OSLC compliant tool, its resources representation need to be
  consitent with RDF data model in addition to the
  existing non-OSLC implementation (though the resource representation
  format
  can be RDF, JSON etc).
  Now the OSLC services are consumable by OSLC Clients and OSLC SDK help in
  implementation of OSLC providers and consumers.
  So this means (my understanding) OSLC SDK facilitate the implementation
  of
  OSLC compliant REST services for existing application where we have to
  provide additional implementation which is OSLC compliant
  and the services are now consumable by OSLC compliant as well as
  noncompliant clients.
  Now the question is: Are there any guidelines to build a REST application
  from scratch using OSLC SDK which supports OSLC compliant as well as
  noncompliant clients?
  Do we need to have separate implementations to cater these two scenarios
  or
  we can have a common implementation which can serve both types of above
  mentioned clients.

  Regards,
  Vinod
  India Software Lab, IBM Software Group

  _______________________________________________
  lyo-dev mailing list
  lyo-dev@xxxxxxxxxxx
  http://dev.eclipse.org/mailman/listinfo/lyo-dev
_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/lyo-dev