Home » Eclipse Projects » Eclipse Titan » The unfinished business of multiple encodings
| The unfinished business of multiple encodings [message #1738922] |
Tue, 26 July 2016 07:39  |
|
Dear all,
by now you might be aware that, although the Abstract Test Suite (ATS), written in TTCN-3, describes the test evolution in the abstract space, in order to connect to the SUT (System Under Test) , the abstract structures are to be encoded into a representation that can be sent over the communication channel.
Converting back and forth between the abstract and the transfer representation ( or otherwise named 'syntax' ) is in charge of codecs. Titan, as we have seen, has a number of such codecs for different representations: RAW for binary, XML , JSON etc.
So far we have encountered examples where a certain type was encoded with one specified codec; there are practical situations though ,
when the same type has to be encoded by more than one codec. A good example might be testing web services:
a web service could answer ones' query differently depending on the "language" one turns to it to: it answers XML with XML and JSON with JSON.
This means that when testing web services, it would be convenient to encode the same message structure both in XML and JSON, depending on context, and understand (be able to decode) both representations.
Let's see first what support the standard offers along the line of multiple encodings.
Well, unfortunately there is no explicit answer to the question "Is multiple encoding of a type supported in TTCN-3 ?", but let's examine
the encoding function encvalue closely:
encvalue(in template (value) any_type inpar) return bitstring
This function encodes a value or template into a bitstring by invoking the encode that is specified for that particular type.
This also means that only one encode is permitted at any given moment for any given type in the system, else the encvalue could not identify the encode unambiguously.
So here's your , though implicit, but definitive answer.
If we need multiple encoding, we need to modify the language standard to support it, and there are several degrees of support possible.
After consulting with other TTCN-3 tool vendors, we have opened a change request CR 0007448 http://forge.etsi.org/mantis/view.php?id=7448
to ETSI that mainly describes the following changes:
-multiple encodes permitted for a type
for instance:
type record PDU {
Payload payload
} with {
encode "XML";
encode "JSON";
}
(currently only one encode statement is considered legal)
-as this creates an ambiguous situation for encvalue/decvalue and the like, a new parameter has to be introduced to identify the desired encoding
(if only one encoding exists for the type, this parameter can be omitted)
encvalue(in template (value) any_type inpar, in charstring encoding) return bitstring
It can be seen that the encoding parameter in encvalue can originate in e.g a constant value or a configuration parameter,
hence it has to be known and pegged at compile time or start of execution; the above CR does not support changing the encoding dynamically, say from one message to another.
For that, further modifications of the language will be needed.
However, we can hack ourselves around this restriction (and in fact all restrictions related to multiple encodings); and here's for instance how:
we can create two types
type record PDU_A {
Payload payload
} with {
encode "XML";
}
type record PDU_B {
Payload payload
} with {
encode "JSON";
}
which are exactly the same as the type PDU we wish to double encode.
If we want a message to be encoded in XML, we send it to e.g. port A; at reception it will be mapped to type PDU_A and encoded in XML; else we send it to port B and ends up encoded in JSON.
+---------------------------------------+
| |
| |
| |
| A B |
| |
+----------+----------------+-----------+
| |
| |
| |
| |
+----------v----------------v-----------+
| |
| map to PDU_A map to PDU_B |
| &XML codec &JSON codec |
| |
| |
+---------------------------------------+
so we multiplex codecs on the ports.
But if we want to multiplex codecs within a single port, we need to send the information related to encoding together with the message,
something like:
portA.send (message, "XML")
which implies modifying all synchronous and asynchronous sending and receiving statements of the language.
For those interested in darwinian evolution, this is a moment when one can catch a glimpse into its' very mechanism when
changes in the environment are forcing a change of the entity itself. Just kidding.
Best regards
Elemer
|
|
| |
| Re: The unfinished business of multiple encodings [message #1739180 is a reply to message #1738922] |
Thu, 28 July 2016 07:08  |
 Gyorgy Rethy
Messages: 31
Registered: April 2015 |
Member |
|
|
The ETSI TTCN-3 language team have already discussed the topic and they have a good proposal for the dynamic handling of the encoding that would overcome of the abovementioned change of sending and receiving operations.
In short it would be based on an "encoding state" of ports and the component, like:
self.encode(all, "XML"); //this will set the encoding state of all ports of the component and envcalue/decvalue for all messages to "XML"
p.encode(PDU,"JSON");//this will set the encoding state of port p for the messages of type PDU to "JSON"
all port.encode(all,"JSON");//this will set the encoding state of all ports, but not encvalue/decvalue-s to "JSON"
So, the actually active encoding can be controlled at a component, port and even type levels.
The proposal has pros and cons, of course.
Pros:
- existing code is almost unchanged, just encoding state control lines need to be inserted here and there; in particular, most existing functions can remain untouched;
- as a per session selection of the actual encoding is much more probable as a per sending/receiving one, it is less code to write and the code remains more readable.
Cons:
- the actual encoding state may be difficult to know at a given place in the code; however, as TTCN-3 is an abstract language, where the test behaviour and test data content is separated from its actual serialization and transport; in majority of the test cases the actual encoding state should not be relevant anyway;
- it will result more code in the negative test cases that targets sending/responding with incorrectly encoded messages, using "the other" encoding.
But it's important to note that the work is still ongoing, the final resolution may be slightly different.
|
|
|
Goto Forum:
Current Time: Fri Apr 26 09:02:18 GMT 2024
Powered by FUDForum. Page generated in 0.03460 seconds |
] 
Search
Help
Register
Login
Home
