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

[Michael Fiedler <fiedler.mf@xxxxxxxxx>]

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