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

[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

From: Vivek K Gupta <Vivek.K.Gupta@xxxxxxxxxx>
Date: Wed, 19 Dec 2012 11:04:53 +0530
Delivered-to: lyo-dev@xxxxxxxxxxx
List-archive: <http://dev.eclipse.org/mailman/private/lyo-dev>
List-help: <mailto:lyo-dev-request@eclipse.org?subject=help>
List-subscribe: <http://dev.eclipse.org/mailman/listinfo/lyo-dev>, <mailto:lyo-dev-request@eclipse.org?subject=subscribe>
List-unsubscribe: <http://dev.eclipse.org/mailman/options/lyo-dev>, <mailto:lyo-dev-request@eclipse.org?subject=unsubscribe>

Thanks mike . I have filed a defect . We are ok with the timing of fix in sometime in jan too.

--------------------------------------------------------------------------
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: 18-12-12 08:30 PM
Subject: Re: [lyo-dev] Using OSLC SDK to build new OSLC compliant REST application
Sent by: lyo-dev-bounces@xxxxxxxxxxx

> seems to indicate that OSLC json representation in not in sync with their standards .

The W3C JSON-LD specs are approaching their final versions and the intent is for OSLC Core V3 to align with JSON-LD.

> Anyway's for us the question is - How to restrict the OSL4J-jena provider to limit its output for application/rdf+xml media type only ?

It looks like this would require a code change to the OSLC4J Jena providers to allow the consumer to optionally not use OSLC4J as a producer for application/xml. Please open a Bugzilla enhancement request. Given the time of year, it is unlikely to get immediate attention unless someone wants to jump in and propose a solution.

Regards,
Mike

On Tue, Dec 18, 2012 at 4:42 AM, Vivek K Gupta <Vivek.K.Gupta@xxxxxxxxxx> wrote:
Hi Uri ,

OSLC suggests enhancements of existing entities with OSLC tags to make them OSLC compliant.. These tags are understood by the providers supplied by the SDK . To clarify again , we do as follows :

Without OSLC

1) Create a JPA entity for the Underlying table . Add JAXB annotation to it (basically the root element and access Type)
2) Create a Wink Asset class which wraps the jpa entity and this User Asset is returned by the GET . Wink looks up at the requested Media Type and invokes the required providers(json provider here) to translate the same entity to either xml or json . So we are able to get either xml or json by changing the media type .

Now with OSLC

After step 1 above , we add OSLC annotation to the same JPA entity and register the jean provider in the application class . This is what we see :

a) For application/rdf+xml : RDF representation of JPA along with the OSLC tags - which is correct
b) For application/xml : Same as above
c) For application/json : Json format of RDF representation .

When the jena providers are removed without removing the OSLC tags from the entity , we get the same data as without OSLC meaning that OSLC tags are not taken into account by wink json provider which is correct .

Now seems like this is a bug in the OSLC4J-jena provider implementation. When OSLC4J-json4j-provider is not registered with application , then why OSLC - rdf representation is translated to json overriding the basic one . Same for application/xml .

Ideally the RDF representation should be given only in case if media type requested is applicaiton/rdf+xml ?

May be a different media type is not needed for OSLC depending upon the application requirement , since the same can be achieved through registration of the required providers. In case json representation of rdf is needed then OSLC-json4j-provider can be used else use the one provided by wink .

I had a look at W3C on rdf/json and (http://www.w3.org/2011/rdf-wg/wiki/TF-JSON) and they talk about "application/ld+json" media type for having json translation of rdf data. Looking at their json specs seems to indicate that OSLC json representation in not in sync with their standards . Not sure which is the right one here.

Anyway's for us the question is - How to restrict the OSL4J-jena provider to limit its output for application/rdf+xml media type only ?

Also jena provider required to be explicitly registered in Application class where are all the wink providers get automatically registered upon dropping in the lib folder . Is there any specific reason for this ?

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

From: Uri Shani <SHANI@xxxxxxxxxx>
To: Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Date: 18-12-12 01:34 PM
Subject: Re: [lyo-dev] Using OSLC SDK to build new OSLC compliant REST application
Sent by: lyo-dev-bounces@xxxxxxxxxxx

Hi,
My understanding for 2 cents into this discussion is that Vivek wants to be able to respond in the same path and media type different contents. So, the resource being returned in JSON for a certain RESTful GET may have different structure, fields, field names, field formats, etc. One would be OSLC compliant, the other is his "old" way of handling that resource.
I think that this is not possible to differentiate and specify with only the path and media-type specifications in the GET request. Additional parameters will be needed which the resource may be written to be sensitive to.
Vivek, am i correct?

Regards,

Uri Shani, IBM

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

Not sure what you are proposing here. A change to the OSLC specifications to add alternate media types? The point of using application/rdf+xml, application/json, etc is exactly that they are standard types. A core principle of OSLC is to use existing established standards and web patterns instead of trying to invent new ones which consumers will not understand.

>From what I understand of your scenario, having a separate service/context for OSLC representations would be the way to go. The OSLC and non-OSLC services could use the same base or lower level services to retrieve the data.

If you would like to propose a code change to OSLC4J, you can open a Bugzilla request for it. Code contributions for enhancements to Lyo are welcome.

Regards,
Mike

On Sun, Dec 16, 2012 at 11:54 PM, Vivek K Gupta <Vivek.K.Gupta@xxxxxxxxxx> wrote:
Team ,

Can you help us solve this issue ?

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

From: Vivek K Gupta/India/IBM
To: Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>
Cc: Lyo project developer discussions <lyo-dev@xxxxxxxxxxx>, lyo-dev-bounces@xxxxxxxxxxx
Date: 12-12-12 11:28 AM
Subject: Re: [lyo-dev] Using OSLC SDK to build new OSLC compliant REST application

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

_______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/lyo-dev_______________________________________________ lyo-dev mailing listlyo-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/lyo-dev_______________________________________________ lyo-dev mailing listlyo-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@xxxxxxxxxxxhttp://dev.eclipse.org/mailman/listinfo/lyo-dev

References:
- [lyo-dev] Using OSLC SDK to build new OSLC compliant REST application
  - From: Vinod Kumar Choudhary
- Re: [lyo-dev] Using OSLC SDK to build new OSLC compliant REST application
  - From: Michael Fiedler
- Re: [lyo-dev] Using OSLC SDK to build new OSLC compliant REST application
  - From: Vinod Kumar Choudhary
- Re: [lyo-dev] Using OSLC SDK to build new OSLC compliant REST application
  - From: Michael Fiedler
- Re: [lyo-dev] Using OSLC SDK to build new OSLC compliant REST application
  - From: Vivek K Gupta
- Re: [lyo-dev] Using OSLC SDK to build new OSLC compliant REST application
  - From: Michael Fiedler
- Re: [lyo-dev] Using OSLC SDK to build new OSLC compliant REST application
  - From: Uri Shani
- Re: [lyo-dev] Using OSLC SDK to build new OSLC compliant REST application
  - From: Vivek K Gupta
- Re: [lyo-dev] Using OSLC SDK to build new OSLC compliant REST application
  - From: Michael Fiedler

Prev by Date: Re: [lyo-dev] Using OSLC SDK to build new OSLC compliant REST application
Next by Date: [lyo-dev] Summary page for Perl contributions
Previous by thread: Re: [lyo-dev] Using OSLC SDK to build new OSLC compliant REST application
Next by thread: [lyo-dev] More Gerrit/SSH config tips, especially for Windows users
Index(es):
- Date
- Thread

Breadcrumbs