The OSLC 2.0 specifications have been finalized on open-services.net, and are implemented a significant number of successful client and server products. This certainly proves the utility and value proposition of OSLC. OASIS OSLC Core and CCM Technical Committees are currently developing the OASIS OSLC 3.0 specifications that define additional OSLC capabilities built on the W3C Linked-Data Platform. The eclipse Lyo (OSLC4J) project provides a reference implementation of the OSLC 2.0 domains, and provides Java APIs for developing client and server implementations and adapters. There is also an excellent tutorial on open-services.net that describes how to use OSLC4J to develop a Bugzilla OSLC CM provider, and the NinaCRM consumer/client that access that provider.
However, the cost of OSLC adoption is still somewhat higher then we had hopped. The OSLC4J tutorial is somewhat complex and requires users to understand a large number of Java-based technologies (eclipse, Maven, Git, Java annotations, Java EE, JAX-RS, eclipse Lyo/OSLC4J, Apache Wink, Apache CSF, etc.). These technologies are fine, but don't necessarily represent the most current approach to Web application development.
Things to consider are:
- The Node modules should be developed in eclipse Lyo in order to leverage the eclipse infrastructure and governance processes, as well as to expand the existing eclipse Lyo community.
- Bluemix may be a useful deployment platform for development and testing
- The effort should include a Swagger implementation of OSLC 3.0 domain REST services.
- Build the OSLC.js modules in layers starting with the REST layer, then building up to more logical APIs that more directly support common OSLC interaction use cases.
The goal is to minimize the cost of developing the OSLC 3.0 specifications, reference implementation and test suites. The OASIS OSLC 3.0 would also benefit from a reference implementation in another language.