Use YANG Tools as a Java code generator for MD-SAL in Opendaylight - generator

Recently I study the API definition for Opendaylight.
As we know, YANG is a modeling language for NETCONF. However, Opendaylight uses it as a Java code generator for MD-SAL.
So I am wondering :
How does YANG Tool help generate Java code for MD-SAL?
Do you have some YANG code generator tutorials?
Thanks.

How does YANG Tool help generate Java code for MD-SAL?
YANG defines the data definition model which is used by MD-SAL to model messages sent by client application.
There are two types of API used by client applications. DOM and Binding Aware. Data models in both API types can be modeled by YANG.
Binding Aware APIs
have a method for each leaf in the yang model, they
are compiled against the YANG model and they
have concrete data structure.
DOM APIs
used in datastore
,they can implement general purpose models, runtime adaption of model is possible and they are not typesafe.

Check out https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL.
There are loads of tutorials there, as well as a WebEx recording etc.

Related

Classification tree tool and integration with a web site

A general question. I have used i.e. Weka classifier model functionallity in their tool. But is there a way to "call Weka" and get a model in response from a website?
It is not important that it is Weka, but I want to implement some simple classification based on a json coming from a web-site.
Thanks.
You can write a REST webservice in Java which loads your model and makes predictions using data it receives, sending back the predictions in a suitable format. There are a number of frameworks for writing such webservices (e.g., JAX-RS).
In terms of using the Weka API, check out the Use Weka in your Java code article.

Building UI using Litho and JSON

I was looking for Backend Driven UI libraries for Android and came across Litho for Declarative UI. I was wondering if there is any helper/extension library for Litho that can generate the UI based on JSON.
Not smth we are aware of. But due to its declarative nature it's not hard to build one by yourself. Conceptually, you'll just need to propagate all props from json fields to Component props and a special field for a Component type.

Is there a Simple OSLC Metamodel Showing Entities and Relationships?

There seems to be any amount of RDF-format for the OSLC but what I'm looking for is a simple E-R-like view of the OSLC metamodel which shows the concepts and relationships which can be used to understand the organisation and possible queries.
Is there a (graphic) representation of the OSLC metamodel anywhere?
If you are after a simple graphical diagram, you can find UML models under this Lyo-Docs
repo. you can find the source .emx files, as well as .png snapshots under the folder "OSLC-V2/images/".
I you are developing OSLC applications, you might want to consider the modelling tool Lyo Designer.
There, you can find a graphical model of the OSLC Core and Domain concepts. The models are based on a OSLC-specific modelling language. Lyo Designer allows you define/extend your own models, from which you can generate an OSLC application, based on the Eclipse Lyo SDK.
I here assume you are aware of the java class implementations of the OSLC Core concepts in Eclipse Lyo. There is also an implementation of the domain specifications.

Yang used as Xml or Json?

i just want to know is yang modeling language specific and can only be used with NetConf protocol, or can it be used to model data like Xml and Json ?
Thank you
YANG was originally intended to model data exchanged between peers in a NETCONF session, but this is no longer the only case. There are now other protocols that (will) make use of it, such as RESTCONF and CoMI.
YANG is a data modeling language originally designed to model
configuration and state data manipulated by the Network Configuration
Protocol (NETCONF), NETCONF Remote Procedure Calls, and NETCONF
notifications [RFC6241]. Since the publication of YANG version 1
[RFC6020], YANG has been used or proposed to be used for other
protocols (e.g., RESTCONF [RESTCONF] and the Constrained Application
Protocol (CoAP) Management Interface (CoMI) [CoMI]). Further,
encodings other than XML have been proposed (e.g., JSON [RFC7951]).
RFC7950, Section 1
In fact the recent new YANG specification release (1.1) has made a move toward decoupling the model from its encoding. In the future, we will probably see separate XML and JSON encoding documents (plus perhaps others) and a single document dealing only with the language specifics.
You could use YANG to model data for other more general purposes if you ignore statements like rpc, action, notification, config, etc. Those that are only relevant in specific contexts. Of course you would have to define the context in which you wish to use the model and what it means to you. Some modelers make use of the extension statement to define such requirements, then implement a specialized YANG compiler that recognizes the extensions and acts accordingly - this allows you to make use of the language for things not originally intended by the authors.
There are some definitions in the specification that could make it harder to make YANG a general purpose modeling language (like what XML Schema is for XML). Concepts like configuration datastore, configuration data, state data, client, server, etc. are pretty darn specific. You can always turn a blind eye to those and just make it work for you, however. I believe that is how it is already done in the OpenDaylight project.

Do Jackson and Gson directly implement the standard JSR-353?

I couldn't find an answer to my question on the net (maybe I did not search well enough, since I am still a novice on this).
Could anyone tell me if Jackson and Gson implement the standard JSR 353: Java™ API for JSON Processing. I would like to write using standard code.
This link has the reply (apparently by the Jackson founder), and it essentially says that Jackson doesn't implement the JSR:
Reply by Tatu Saloranta on January 26, 2014 at 8:21pm
I am not a big fan of JSR-353 (I consider it a big fail) and unless something drastic happens, Jackson core will not implement JSR-353. There is no benefit from data-binding to use it; both because implementations do not bring anything to table (none are particularly fast), nor implement all that databind needs (base64 encoding, multi-format support capabilities) -- and worst of all ALL existing (de)serializers would need to be rewritten use new, less capable API. And baseline for Jackson would need to become Java 8. So I see no upside.
However, the reverse is possible; it is possible to have a JSR-353 implementation based on Jackson streaming package, and this has been done already:
https://github.com/pgelinas/jackson-javax-json.
Or, to make Jackson capable of reading/writing JSR-353 JSON object types, a simple datatype module is needed. I wrote one a while back:
https://github.com/FasterXML/jackson-datatype-jsr353
So if Java developers end up following "the standard" track, Jackson can play along.
Google didn't (couldn't?) vote on the JSR, and I couldn't find anything on Gson's roadmap either to suggest that they'd want to comply.
tl;dr
Use:
JSON-P
JSON-B
Update
The other two Answers are correct, but outdated. As they explain, Jackson does not directly implement any JSR.
However:
There is a project providing a datatype module to help make Jackson more compatible with JSR 353: jackson-datatype-jsr353.
JSR 353 is superseded by JSR 374: Java™ API for JSON Processing 1.1.
The JCP continued work on JSON support, for processing of JSON as well as binding yielding the pair of JSRs: 374 JSON-P & 367 JSON-B.
JSR 374 defines JSON processing (JSON-P).
See project page for JSON-P.
A reference implementation can be found in Glassfish, the reference implementation of Jakarta EE (formerly known as Java EE).
JSR 367 provides binding capabilities (JSON-B).
See the project page for JSON-B.
Yasson is the reference implementation.
So you may indeed now write in standard code using JSON libraries other than Jackson.
No, neither implements this API natively, nor has plans (that I know of) to implement it. As far as JCP standards go, this is DOA; it offers very little (dumbed-down streaming API, no data-binding at all), and there is very little incentive for anyone to implement it, except to add compatibility check-box for set of JSRs implemented.
There is a Jackson-based JSR-353 implementation available at https://github.com/pgelinas/jackson-javax-json/ however, if you really think it is good idea to base your code on this API.