[
https://issues.apache.org/jira/browse/PLC4X-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16820853#comment-16820853
]
Matthias Milan Strljic commented on PLC4X-113:
----------------------------------------------
Yes, with this we have to determine how we are willing to support the various
domain-specific models such as OPC UA or ADS.
In my opinion, a complex value representation similar to JSON-a-like is a good
compromise. Because in many communication protocols you have a struct system.
If you go in this fieldbus direction, the entire system consists only of
periodically sent structures. Beckhoff ADS enables complex types that are
arranged like in a C++ memory of an assigned structure or object. The extreme
here is OPC UA, which consists of a node structure containing a series of
metainformations (hierarchy structure, inheritance, node attributes) and
complex types for values. There I would make a cut with opc ua and concentrate
on complex values or add a generic MataInformationType, which alone is only a
map with attributes. These additional meta-information then have the additional
effort to define "What are relevant meta-informations" "how to map them to the
structure". So first I would ignore meta-informations and use a JSON-a-like
approach to represent complex values.
The question "Why should we support complex types" is very simple in my mind.
In most protocols you can enclose complex types because you can only call each
attribute in a structure individually. This works, but is time-consuming,
performance-intensive, and loses a lot of consistent information. The advantage
of calling a complex object/structure is that the client gets the overall state
of that structure as a snapshot, so that this information is not lost when the
values are related.
> Implement support for complex field types in the PLC4X API
> ----------------------------------------------------------
>
> Key: PLC4X-113
> URL: https://issues.apache.org/jira/browse/PLC4X-113
> Project: Apache PLC4X
> Issue Type: New Feature
> Components: API
> Reporter: Julian Feinauer
> Priority: Critical
>
> *This is a (possibly) incompatible change.*
> Currently we have support for primitives as well as lists (arrays) as first
> class "ciitzens" of the PLC4X model.
> Especially, when thinking about OPC UA, but also other protocols like ADS
> (and even S7) support complex objects in their programming model.
> Thus, it is necessary to refactor / extend the API to support these complex
> objects.
> I guess we need at least
> * primitives
> * lists
> * maps (should be equal to "structs")
> Basically, this should be roughly equivalent to what one can represent with
> JSON.
> Thus, the API could be structured i two ways.. first, we could use an
> internal Node Tree to represent the objects, but we could also provide to use
> someone elses NodeTree or structure to represent the Objects.
> For example Jackson.. this would even allow us to directly map these objects
> to POJOs via Jackson.
> As example for such a model, one can look at that of Apache Calcite:
> https://github.com/apache/calcite/blob/3fa29455664bec0056c436491b369e0cd72242ea/core/src/main/java/org/apache/calcite/rel/type/RelDataType.java
> They have an interface with methods
> {code:java}
> public interface DataType
> {
> // Checker
> boolean isMap();
> boolean isList();
> boolean isPrimitive();
> // Getter for complex types
> DataType get(String key);
> DataType get(Long i);
>
> // Primitive getters
> long getLong();
> String getString();
> //...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
