> 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 <[email protected]> To: [email protected], [email protected] Date: 06/27/2011 10:03 AM Subject: [oslc] Ways to think about OSLC SDK "reference implementations" Sent by: [email protected] 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 [email protected] http://open-services.net/mailman/listinfo/community_open-services.net
