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

[Dave]

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.
* 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.?


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.

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.
* 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


--
OSLC Spec Lead
IBM Rational Software