Creating a client for OSLC services

OSLC implementations
1

Creating a client for OSLC services prompts me to seek guidance on best practices. Here are the options I’m considering:

Write the client completely by hand and use an RDF parser:
Pros:
Full control over the implementation.
Customization according to specific requirements.
Cons:
Time-consuming and error-prone.
May require extensive knowledge of the OSLC specifications.

Model the toolchain with Eclipse Lyo and generate the client with Lyo:
Pros:
Code generation reduces manual effort.
Compliance with OSLC standards.
Cons:
Learning curve associated with Eclipse Lyo.
Limited flexibility compared to hand-coding.

Generate the client from the OpenAPI.yaml file:
Pros:
Standardized approach using OpenAPI.
Code generation reduces manual effort.
Cons:
OpenAPI support for OSLC might be limited.
OpenAPI may not cover all OSLC-specific features.

Crawl URIs starting from the catalog and generate the client:
Pros:
Dynamic approach adaptable to changes.
Full customization of the generated client.
Cons:
Complex to implement, especially handling various service scenarios.
May result in higher maintenance efforts.

Future plans involve developing clients for multiple services, potentially including an OSLC service.

The chosen programming language is Java, preferably within the Vert.x framework.

Any insights or recommendations would be greatly appreciated.

2

Hallo Michael,

Welcome to the forum. I recommend a middle ground approach:

  • use Lyo Designer, but only to model your domain and generate annotated POJOs. This way, you take advantage of Jena and Lyo’ object-graph-mapper.
  • At the samw time, write the client yourself. Either from the ground up using Lyo’s JenaModelHelper, or based on Lyo Client.

See an example of this approach in refimpl/src/client-toolchain/src/main/kotlin/co/oslc/refimpl/client at master · oslc-op/refimpl · GitHub for the client and lyo/domains at master · eclipse/lyo · GitHub for Lyo Designer. I used Kotlin coroutines for better concurrency, which is similar to Vert.x goals.

Cheers,
Andrew

3

Agree with your suggestion Andrew.

Here’s also a link to clarify how to use LyoDesigner for domain modelling. The instructions are a bit out of date, but the main flow is still the same. (maybe the figures just don’t match latest versions).
https://oslc.github.io/developing-oslc-applications/eclipse_lyo/domain-specification-modelling-workshop.html

4

Thank you both for your good advice. I have attempted to implement the client as per your suggestions.

However, I still have a question. For this question, let’s assume I am not confined to any particular programming language or framework.

How does one usually interact with an OSLC service provided by somone else?

In the scenario of a standard REST service with an OpenAPI file, one could generate the client from that file.

Is there a similar approach for an OSLC service?

5

The idea with OSLC services is that they are not OpenAPI-like, but more rich HATEOAS. This means that ideally, you have some client wrapper that offers you a number of operations based on the response you just received. And you cannot every server response to have the form you expected at compilation time. This means that languages like Clojure, Prolog, Javascript, Python would be best for such work.

Having said that, very few commercial APIs took advantage of that. Most of them are quite rigid, which means that your idea is quite realistic. We had an idea to build a discovery client for Lyo Designer that would scan the API endpoints, shapes, and generate the correct model that you can then use to generate a strongly typed client and POJOs, possibly with modifications to the model. But that was postponed due to other priorities. Talk to @jad for more on extending the Designer with more features.