[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [lyo-dev] Using OSLC SDK to build new OSLC compliant REST application
|
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