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

Paul McMahan pmcmahan at us.ibm.com
Mon Jun 27 10:42:40 EDT 2011


>  1) Reference Implementation
> ...
>  * Goals
>   - Support spec development process
>   - Provide complete and correct implementation of OSLC specs

A reference implementation could be seen as a supplement to the
specification in terms of defining what is normative.


Best wishes,
Paul McMahan
Rational Quality Manager




From:	Dave <snoopdave at gmail.com>
To:	oslc-tools-devel at lists.sourceforge.net,
            community at open-services.net
Date:	06/27/2011 10:03 AM
Subject:	[oslc] Ways to think about OSLC SDK "reference implementations"
Sent by:	community-bounces at open-services.net



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

_______________________________________________
Community mailing list
Community at open-services.net
http://open-services.net/mailman/listinfo/community_open-services.net





More information about the Community mailing list