[oslc] Ways to think about OSLC SDK "reference implementations"

[Olivier Berger]

Hi.

Le lundi 27 juin 2011 à 10:02 -0400, Dave a écrit :
> There are a couple of different ways to think about the OSLC reference
> implementations and some conflicting goals, depending on how you
> think. I think it's useful to consider the different ways to think
> about the SDK's provider implementation(s), so here are three:
> 
> 
> 1) Reference Implementation: Think of RIO as a reference
> implementation, design to support the needs of workgroups developing
> specs and experimenting with new features, protocols, etc.
> * Goals
>   - Support spec development process
>   - Provide complete and correct implementation of OSLC specs
>   - Experimental "prototype" for proposed spec features
>   - Provide example code for developers implementing providers
>   - Make it very easy for workgroups to build implementations
>     e.g. data-driven implementation, use of RDF triple store, etc.

I'd add that it comes together with a (high-level) test suite that can
be used to test other provider implementations. It it's a correct
implementation and such tests fail on other providers, chances are that
these are buggy ;)

> * Non-goals
>   - Useful as an ALM tool
>   - Production ready and high performance
> * Issues
>   - Easy for OSLC workgroups is different from easy for product
> developers, and product developer care a lot about being production
> ready and high-performance, so this approach won't help product
> developers looking for example code and re-usable components.
> 
> 
> 2) Provider Framework: Think of RIO as a framework for building OSLC
> providers, design to support the needs of product development teams
> who are adding OSLC support to existing products.
> * Goals
>   - Provide framework for building Provider Implementations
>   - Suitable for creating complete and correct implementation of OSLC specs
>   - Suitable for creating production ready implementation of OSLC specs
>   - Make it easy for product teams to add OSLC support to existing products
> * Non-goals
>   - Useful as an ALM tool
> * Issues
>   - Developers already use a lot of different web development
> frameworks. Do we really want to introduce a new framework for
> REST/Linked Data services? Won't this cause problems for those already
> using other web/REST frameworks such as Spring, JSF, Seam, Wicket,
> Struts, Play, JAX-RS, etc.?

We may expect more existing (or new) Open Source ALM tools developing
OSLC-compliant modules. If they share their code as Open Source, there's
no need for such a framework, then.
Reusing non-reference, but existing code is the way to go for
implementers.
But then, there's again the need for reference tests to be passed by
tools in order to be able to assess their compatibility before reuse.
Still, in such a schema, one has to initiate the process or publising
Open Source OSLC compliant ALMs, for each popular language/technology.
So, for instance, if it is considered strategic for some actors to
develop, say, JAX-RS based adapter for webservices, then let have them
do it and rejoice ;)... still, I don't think this would qualify for a RI
(even if this can be great).
FWIW, our current codebase in PHP (Zend Framework) initially developped
for MantisBT, then ported to FusionForge, somehow fits this kind.

> 
> 
> 3) Pluggable Adapter Implementation: Think of RIO as an Adapter Server
> that can be used to create an OSLC provider by "plugging in" a backend
> system. This is very similar to the "Shindig" reference implementation
> for OpenSocial.
> * Goals
>   - Complete OSLC adapter that allows back-end to be plugged in
>   - Suitable for creating complete and correct implementation of OSLC specs
>   - Suitable for creating production ready implementation of OSLC specs
>   - Make it easy for product teams to add OSLC support to existing products
> * Non-goals
>   - Useful as an ALM tool
> * Issues
>   - There are some significant problems with the adapter approach,
> e.g. introduction of redundant URLs for resources, new server to be
> maintained, etc.
> 
> 
> Personally, I think we want #1 and #3 above.

Definitely #1 and test suite ;)

> 
> Regardless of how we think of RIO, I think the OSLC SDK should include
> a Provider Library, a set of components, utilities and helper classes
> for building OSLC provider implementations.

iterated for every popular language ?

> * Goals
>   - Provide specific components useful for building OSLC providers
>   - e.g. Query Syntax parser, OSLC JSON parser/generator
>   - Suitable for creating complete and correct implementation of OSLC specs
>   - Suitable for creating production ready implementation of OSLC specs
>   - Make it easy for product teams to add OSLC support to existing products
>   - Works equally well with any web development framework
> 
> 
> Other thoughts? What type of provider implementation(s) would you like
> to see in the OSLC SDK?
> 
> Thanks,
> Dave

My 2 cents,

-- 
Olivier BERGER <olivier.berger at it-sudparis.eu>
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)