Re: [lyo-dev] Design / implementation questions

[Michael Fiedler <fiedler.mf@xxxxxxxxx>]

Hi Lars, great comments.  I think some of the issues you highlight
stem from the client library originating from some samples meant to
show how to connect to  OSLC and Jazz implementations.  In some
respects they were done in the reverse order you might expect.   I
think there is an opportunity now to take a look at how they are
structured and do some of the refactoring you suggest.

Anyone interested in this is welcome to contribute as you have (either
on the list with ideas, through Bugzilla bug/enhancement requests or
with code contributions).

See below for some additional comments.

Regards,
Mike

On Mon, Sep 17, 2012 at 4:38 AM,  <Lars.Ohlen@xxxxxxxxx> wrote:
> Hi Lyo Dev,
>
>
>
> I have been playing around with the OSLC client for a week or so, and now I
> have some design / implementation questions.
>
>
>
> I fully understand that Lyo is targeting generic OSLC and not some specific
> tool, but I will relate to Jazz tools because these are the OSLC tools that
> we are working with.
>
>
>
>
>
> Q1 – Configuration vs Design decisions
>
>
>
> Some of the usage of inheritance (e.g. by extending  a subclass) implicit
> requires the Lyo OSLC library users to take design decisions.
>
> A good example is that the JazzFormAuthClient extends the OslcClient – a
> construction that does not work well if you have form based authentication
> but
>
> want to use OAuth during future API calls (and therefor would need a variant
> of JazzFormAuthClient that extends OslcOAuthClient)
>
>
>
> In a real life scenario we as developers of solutions really would like to
> be able to configure the client behavior during execution time, since our
> customers set-up of their OSLC enabled server is not always known at design
> time. Example of configuration parameters:
>
> -       Form based login vs Basic Authentication
>
> -       OAuth vs Session based access
>
> The combination of these 4 options would requires several specialized
> classes.
>
>
>
> Have I misunderstood something about the underlying principles here?
>
>
>
> Even if my question is Jazz related is quite easy to image that other tool
> providers will provide the similar capabilities and thus require similar
> solutions.
>
> A solution could be that the OslcClient instead uses features provided by
> the OslcOAuthClient class (e.g. uses instead of inheritance) and that a (not
> yet existing abstract class) JazzClient class uses services provided by a
> JazzFormAuthClient.
>
>
>

Yes, good comment.  An artifact of the order things were done
originally.  Splitting the authentication/session details from the
OSLC functionality is required.

>
>
>
>
> Q2 – Adding new resources
>
>
>
> RQM is providing both OSLC and an proprietary REST based API. As the QM
> specs evolve one can suspect that the proprietary API will disappear, but
> with the current solution there is a need to mix both OSLC calls and RQM
> REST API calls to create a real-life application.
>
>
>
> It is possible to mix an OSLC call with a RQM REST based called sharing the
> same HttpClient (thus implicit sharing cookies, session etc). So therefore
> we have the need  to add some RQM REST API resource types (XML) capabilities
> to the existing OSLC QM resource types .
>
>

Yes, this is possible.  The session can be shared.


>
> The constructor of the OslcClient class internally creates the Wink
> application (and registers a hardwired list of providers) so I cannot
> clearly see how this could be done. As a remedy solution the
> OslcOAuthClient::getResource method seems to create a new Wink application
> for each resource request to manipulate the registered providers.
>
>
>
> So my question is simply how can I add RQM REST specific resources to the
> same client implementation that also knows how to handle OSCL resources?
>
> (would like to avoid the recreation of the Wink app for each request)
>
>

The current RDF/XML, XML and JSON providers for Wink in OSLC4J just
deal with OSLC resources.   Instead of using the OSLC4J providers, you
could use getResource to retrieve the raw XML from RQM and JAXB to
marshall it into POJOs.

>
>
>
> Q3 – Exception/Error handling strategy
>
>
>
> At a first glance the method OslcClient::getResource(final String url, final
> String mediaType) throws IOException, OAuthException, URISyntaxException
>
> seems to be able to throw 3 different exception types.  But after some
> examination it turns out that the code statements in the method is throwing
> 0 exceptions.
>
> (the throws clause is required because the overlaid method in the sub class
> OslcOAuthClient requires them – related to Q1)
>
>
>
> The Apache Wink library seems to be implemented using a  “exception less”
> principle and instead rely on HTTP status codes and HTTP messages.
>
> Is this strategy also intended for the Lyo client implementation?
>
>
>
>
>
> Q4 – Resources definition in client
>
>
>
> In the client project there are core, cm and qm resources defined (in the
> package org.eclipse.lyo.client.oslc.resources)
>
> Should they not be contained in an separate library (e.g. jar) so that the
> same definition can be use both client and server side?
>
>

Yes, this definitely needs to be done.   Another artifact from
evolving from a sample.

>
>
>
>
>
>
>
>
> Lars Ohlén
> Tieto
>
>
>
>
>
>
> _______________________________________________
> lyo-dev mailing list
> lyo-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/lyo-dev
>