Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Lyo/Oslc4Js"

< Lyo
(Motivation)
(Motivation)
 
Line 14: Line 14:
 
The MEAN Stack, and JavaScript have some interesting characteristics that provide real advantages over Java and OSLC4J:
 
The MEAN Stack, and JavaScript have some interesting characteristics that provide real advantages over Java and OSLC4J:
  
# JavaScript is a scripting language that supports agile development. Along with Node.js, the entry cost may be somewhat lower compared to Java and OSLC4J.
+
# JavaScript is a scripting language that supports agile development. Along with Node.js, the entry cost may be somewhat lower compared to Java and OSLC4J.<br />
#
+
# JavaScript is a dynamic language which can help bridge the gap between the open-world assumptions of RDF (upon which OSLC is based) and the closed-world assumptions of Java classes. JavaScript objects are dynamic, they contain the properties that are discovered at runtime rather than the properties the developer designed into static, structure-based classes. This is a much better fit for integration development because it increases developer flexibility, fits better with the dynamic, asynchronous, reflective and discovery-based approach of OSLC, and reduces coupling between clients and servers.<br />
# JavaScript is a dynamic language which can help bridge the gap between the open-world assumptions of RDF (upon which OSLC is based) and the closed-world assumptions of Java classes. JavaScript objects are dynamic, they contain the properties that are discovered at runtime rather than the properties the developer designed into static, structure-based classes. This is a much better fit for integration development because it increases developer flexibility, fits better with the dynamic, asynchronous, reflective and discovery-based approach of OSLC, and reduces coupling between clients and servers.
+
# JavaScript is a single-threaded language - there are no threads or thread synchronization issues. Rather JavaScript and Node.js are event-based programming models that are inherently asynchronous, reflecting the needs of modern, Web application development.<br />
#
+
# JavaScript is a single-threaded language - there are no threads or thread synchronization issues. Rather JavaScript and Node.js are event-based programming models that are inherently asynchronous, reflecting the needs of modern, Web application development.
+
#
+
 
The OSLC team is already getting requests to provide a simpler, more programmer friendly, and JavaScript interface to OSLC domains. OSLC4JS is an experimental initiative to investigate building Node.js modules for OSLC core and the OSLC domains.  
 
The OSLC team is already getting requests to provide a simpler, more programmer friendly, and JavaScript interface to OSLC domains. OSLC4JS is an experimental initiative to investigate building Node.js modules for OSLC core and the OSLC domains.  
  
 
Things to consider are:
 
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.
+
# 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.<br />
#
+
# Bluemix may be a useful deployment platform for development and testing<br />
# 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.<br />
#
+
# 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.<br />
# 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.
+
#
+
 
# Consider developing the OSLC v3 reference implementations on LDP.js in JavaScript, using the new OSLC.js modules. This would provide testing of the specifications, OSLC REST services, OSLC.js modules and common OSLC use cases in the same test cases.
 
# Consider developing the OSLC v3 reference implementations on LDP.js in JavaScript, using the new OSLC.js modules. This would provide testing of the specifications, OSLC REST services, OSLC.js modules and common OSLC use cases in the same test cases.
  

Latest revision as of 14:27, 9 October 2015

OSLC4JS: A JavaScript Node.js Module for OSLC

OSLC4JS is a Lyo sub-project to develop a JavaScript Node.js module supporting OSLC client and server development. The client API exposes the OSLC core and domain capabilities through a simple JavaScript API on the OSLC REST services. The same API also represents an abstract implementation of a server supporting OSLC core capabilities and domains. Express.js can be used to implement the REST services that delegate to this API which can then be adapted to existing data sources, services and OSLC domains.

OSLC4JS exploits the dynamic and asynchronous capabilities of JavaScript and Node.js to build and API that can easily adapt to any OSLC domain, extensions to domains, and/or integrations between domains.

Motivation

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.

Modern Web application development currently focused on the MEAN Stack (Mongo, Express, Angular, Node). There is currently no JavaScript support for OSLC core or any of the domains. The OSLC team did develop LDP.js - an LDP server written in JavaScript and deployed on Bluemix. But this server does not support any OSLC Core or any OSLC domains. OSLC should be accessible to programmers in the development environments they are most likely to use. In the near term, that is the MEAN stack, as well as Java and JAX-RS.

The MEAN Stack, and JavaScript have some interesting characteristics that provide real advantages over Java and OSLC4J:

  1. JavaScript is a scripting language that supports agile development. Along with Node.js, the entry cost may be somewhat lower compared to Java and OSLC4J.
  2. JavaScript is a dynamic language which can help bridge the gap between the open-world assumptions of RDF (upon which OSLC is based) and the closed-world assumptions of Java classes. JavaScript objects are dynamic, they contain the properties that are discovered at runtime rather than the properties the developer designed into static, structure-based classes. This is a much better fit for integration development because it increases developer flexibility, fits better with the dynamic, asynchronous, reflective and discovery-based approach of OSLC, and reduces coupling between clients and servers.
  3. JavaScript is a single-threaded language - there are no threads or thread synchronization issues. Rather JavaScript and Node.js are event-based programming models that are inherently asynchronous, reflecting the needs of modern, Web application development.

The OSLC team is already getting requests to provide a simpler, more programmer friendly, and JavaScript interface to OSLC domains. OSLC4JS is an experimental initiative to investigate building Node.js modules for OSLC core and the OSLC domains.

Things to consider are:

  1. 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.
  2. Bluemix may be a useful deployment platform for development and testing
  3. The effort should include a Swagger implementation of OSLC 3.0 domain REST services.
  4. 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.
  5. Consider developing the OSLC v3 reference implementations on LDP.js in JavaScript, using the new OSLC.js modules. This would provide testing of the specifications, OSLC REST services, OSLC.js modules and common OSLC use cases in the same test 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.

Developing oslc.js

Jazz Authentication in JavaScript

Using RDF in JavaScript and Node.js

Using JSON-LD instead of RDF Directly

Developing oslc.js

Sample OSLC Change Management Client App

Back to the top