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

[Vivek K Gupta <Vivek.K.Gupta@xxxxxxxxxx>]

Hi Mike ,

I think the problem is not of Path structuring
but of OSLC Media Types itself . We are using JPA to create entities and
the same entities are enhanced using OSLC annotations. These entities are
converted into xml , rdf , json representation through Wink Asset classes
automatically. 

Now after enhancing the entities with
OSLC annotation this entity can only be used to supply OSLC data as the
registered providers take those into account as well. One way to solve
the problem is that  we create duplicate entities(one oslc annotated
and other not) and then duplicate resource classes (one returning oslc
annotated asset ) with additional path at the root  which would be
very cumbersome to maintain . 

Instead the same problem can be solved
in case we have additional Media Type for OSLC like oslc-rdf-xml , oslc-xml
,oslc-json along with their providers . Calling the same resource with
the required media type would help a user decide on what data does he need.
This would just require addition of these media types on Asset classes
for the same entity and their provider should take care of adding the OSLC
data or not depending upon the media type invoked. ?

Or is there some other way we can solve
this issue. ? 


--------------------------------------------------------------------------
Regards 
Vivek Gupta 
Engineering Manager - India Software Lab - Gurgaon
Vivek.K.Gupta@xxxxxxxxxx | +919899806117
--------------------------------------------------------------------------



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

---

For a given registered Wink application class at a specific
web context, Wink will look for methods capable of providing (or accepting)
the requested media type.   In the case of OSLC4J, you would normally
register the OSLC4J providers for application/rdf+xml, application/xml
and application/json by registering them with OslcWinkApplication (extends
WinkApplication).

If you want to provide alternate representations for these
media types I would suggest simply putting the methods/services in a different
class at a different web context root (@Path, see the Wink documentation).
  Wink provides many ways for you to either use its default providers
for serialization/de-serialization or to register your own.   See
chapter 5.1 of the user guide:  http://incubator.apache.org/wink/1.1.2/Apache_Wink_User_Guide.pdf

This is a fairly common approach.   A tool might
provide OSLC representations at http://example.com/services/oslc/...
and perhaps native representations at http://example.com/services/native/.....

Regards,
Mike 



On Tue, Dec 11, 2012 at 7:28 AM, Vinod Kumar Choudhary
<vinodkc@xxxxxxxxxx>
wrote:
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


_______________________________________________
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