ETSI's Bug Tracker - Ext Pack: Extended TRI (ES 202 789)
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0005888 | Ext Pack: Extended TRI (ES 202 789) | New Feature | public | 25-05-2011 10:04 | 15-12-2011 13:53

Reporter | Ina Schieferdecker |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | major | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v1.1.1 (published 2012-04) | Fixed in Version | v1.1.1 (published 2012-04) |
Clause Reference(s) | Part 5
Source (company - Author) | Ina Schieferdecker, FOKUS

Summary | 0005888: An alternative TRI to handle messages and objects directly

Description

Historically, TTCN has been used to test communication protocols which typically use encoded messages.
This has been reflected in the TRI SA and TCI CD design of TTCN-3 by encoding and decoding mesages to/from bitstrings.
However, TTCN-3 also supports signature-based communication for which the transformation of objects into bitstrings and vice versa is cumbersome.
Furthermore, some protocols use also structured messages for which the bitstring encoding is not helpful.
Therefore, an alternative API is being proposed along which TTCN-3 values can be directly passed to/from the SUT.
Further details are given in the attached ppt.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0004275 | closed | Ina Schieferdecker | Part 01: TTCN-3 Core Language | New Concepts to be defined via Packages

Attached Files

An alternative TTCN-3 TRI API to address software.pptx (62,413) 25-05-2011 14:17
http://oldforge.etsi.org/mantis/file_download.php?file_id=2482&type=bug
An alternative TTCN-3 TRI API to address software_v2.pptx (65,825) 26-05-2011 16:58
http://oldforge.etsi.org/mantis/file_download.php?file_id=2511&type=bug
Tutorial_T3UC_2011_new_architecture_concrete_layer_v4.pdf (1,050,415) 13-06-2011 19:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=2522&type=bug
es_TTCN3Package_XTRI_v003.doc (323,584) 30-06-2011 10:45
http://oldforge.etsi.org/mantis/file_download.php?file_id=2531&type=bug
es_TTCN3Package_XTRI_v004.docx (190,653) 30-09-2011 11:37
http://oldforge.etsi.org/mantis/file_download.php?file_id=2580&type=bug
es_TTCN3Package_XTRI_v005.docx (189,400) 01-12-2011 13:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=2643&type=bug
es_TTCN3Package_XTRI_v006.zip (184,783) 01-12-2011 14:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=2644&type=bug
es_TTCN3Package_XTRI_v007.docx (195,093) 02-12-2011 12:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=2656&type=bug

Issue History
Date Modified | Username | Field | Change
25-05-2011 10:04 | Ina Schieferdecker | New Issue |
25-05-2011 10:04 | Ina Schieferdecker | File Added: An alternative TTCN-3 TRI API to address software.pptx |
25-05-2011 10:04 | Ina Schieferdecker | Clause Reference(s) | => Part 5
25-05-2011 10:04 | Ina Schieferdecker | Source (company - Author) | => Ina Schieferdecker, FOKUS
25-05-2011 11:54 | Ina Schieferdecker | File Deleted: An alternative TTCN-3 TRI API to address software.pptx |
25-05-2011 11:54 | Ina Schieferdecker | File Added: An alternative TTCN-3 TRI API to address software.pptx |
25-05-2011 14:16 | Ina Schieferdecker | File Deleted: An alternative TTCN-3 TRI API to address software.pptx |
25-05-2011 14:17 | Ina Schieferdecker | File Added: An alternative TTCN-3 TRI API to address software.pptx |
25-05-2011 14:17 | Ina Schieferdecker | Project | TTCN-3 Change Requests => Ext Pack: Extended TRI (ES 202 789)
25-05-2011 14:17 | Ina Schieferdecker | Status | new => assigned
25-05-2011 14:17 | Ina Schieferdecker | Assigned To | => Ina Schieferdecker
25-05-2011 14:30 | Jacob Wieland - Spirent | Note Added: 0010053 |
26-05-2011 12:35 | Ina Schieferdecker | File Added: An alternative TTCN-3 TRI API to address software_v2.pptx |
26-05-2011 12:36 | Ina Schieferdecker | Note Added: 0010083 |
26-05-2011 15:48 | Ina Schieferdecker | Relationship added | related to 0004275
26-05-2011 16:57 | Ina Schieferdecker | File Deleted: An alternative TTCN-3 TRI API to address software_v2.pptx |
26-05-2011 16:58 | Ina Schieferdecker | File Added: An alternative TTCN-3 TRI API to address software_v2.pptx |
27-05-2011 12:36 | Jacob Wieland - Spirent | Note Added: 0010100 |
13-06-2011 19:50 | Bernard Stepien | File Added: Tutorial_T3UC_2011_new_architecture_concrete_layer_v4.pdf |
13-06-2011 19:53 | Bernard Stepien | Note Added: 0010115 |
13-06-2011 19:54 | Bernard Stepien | Note Edited: 0010115 |
15-06-2011 17:38 | Ming Shang | Note Added: 0010116 |
30-06-2011 10:45 | Ina Schieferdecker | File Added: es_TTCN3Package_XTRI_v003.doc |
30-06-2011 14:46 | Ina Schieferdecker | Note Added: 0010159 |
30-06-2011 14:54 | Ina Schieferdecker | Resolution | open => fixed
30-06-2011 14:54 | Ina Schieferdecker | Target Version | => v1.1.1
30-09-2011 11:37 | Ina Schieferdecker | File Added: es_TTCN3Package_XTRI_v004.docx |
30-11-2011 09:33 | Jacob Wieland - Spirent | Note Added: 0010416 |
30-11-2011 09:55 | Jacob Wieland - Spirent | Note Added: 0010422 |
01-12-2011 12:30 | Ina Schieferdecker | Note Added: 0010471 |
01-12-2011 12:30 | Ina Schieferdecker | Note Added: 0010472 |
01-12-2011 12:31 | Ina Schieferdecker | Note Added: 0010473 |
01-12-2011 12:31 | Ina Schieferdecker | Note Added: 0010474 |
01-12-2011 12:33 | Ina Schieferdecker | Note Added: 0010475 |
01-12-2011 13:54 | Ina Schieferdecker | File Added: es_TTCN3Package_XTRI_v005.docx |
01-12-2011 13:56 | Ina Schieferdecker | Note Added: 0010481 |
01-12-2011 13:56 | Ina Schieferdecker | Assigned To | Ina Schieferdecker => Jacob Wieland - Spirent
01-12-2011 14:04 | Ming Shang | Note Added: 0010482 |
01-12-2011 14:27 | Jacob Wieland - Spirent | File Added: es_TTCN3Package_XTRI_v006.zip |
01-12-2011 14:30 | Jacob Wieland - Spirent | Note Added: 0010485 |
01-12-2011 14:31 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Ina Schieferdecker
02-12-2011 12:41 | Ina Schieferdecker | Note Added: 0010514 |
02-12-2011 12:41 | Ina Schieferdecker | File Added: es_TTCN3Package_XTRI_v007.docx |
02-12-2011 12:42 | Ina Schieferdecker | Note Added: 0010515 |
15-12-2011 13:52 | Ina Schieferdecker | Status | assigned => resolved
15-12-2011 13:52 | Ina Schieferdecker | Fixed in Version | => v1.1.1
15-12-2011 13:53 | Ina Schieferdecker | Status | resolved => closed

Notes

(0010053)
Jacob Wieland - Spirent
25-05-2011 14:30

I think this is a well-rounded concept. One question that remains is how to change the names of the interfaces/functions so they don't clash with the existing names in TRI so that they can exist side-by-side.
I would propose to change the TRI/tri consistently to something else:
- ETRI (Extended TRI)
- VTRI (Value-Based TRI)
- TVRI (TTCN-3 Value-based Runtime Interface)
- STRI (Software-TRI)
- ... ?

(0010083)
Ina Schieferdecker
26-05-2011 12:36

Agreed on a name for the new interface: XTRI. Agreed to add a decode function for those cases where the type is not known by the adaptor. Next is to develop the draft extension package as outlined.

(0010100)
Jacob Wieland - Spirent
27-05-2011 12:36

Maybe we should rename the decode method to 'cast' (and the decodingHypothesis parameter simply to type) - because that is in essence, what it does. Value cast(Value value, Type type)

(0010115)
Bernard Stepien
13-06-2011 19:53 (edited on: 13-06-2011 19:54)

We (University of Ottawa and Research and Motion ltd) have implemented this concept in January 2010 and also convinced one of the tool vendors to include it in their current release. Thus, we have 18 months of successful usage of this concept and can happilly agree that this concept is very useful. See our T3UC 2011 tutorial at http://www.site.uottawa.ca/~bernard/Tutorial_T3UC_2011_new_architecture_concrete_layer_v4.pdf [^]

(0010116)
Ming Shang
15-06-2011 17:38

This is Ming Shang from Research In Motion (RIM), Bernard Stepien and I took another approach to solve this problem. Instead of changing the interface specification, we recommended that the TriMessage interface be extended to contain extra information at the runtime. The extended methods for TriMessage look like:
void setAttachement(Object attachement),
Object getAttachment()
Advantages:
No fundamental changes required for the TRI
Disadvantages:
Applied only to the single-rooted inheritance language like Java, under which Object object can represent anything. May not work in the C/C++ domain.
Prerequisite for the Java implementation Runtime (if Java domain):
Classloader(s) for codec and TestAdapter plugins have to be consistent to avoid java.lang.ClassCastException

(0010159)
Ina Schieferdecker
30-06-2011 14:46

We have discussed the proposal by RIM and came to the conclusion that the seperation between tri and xtri is the cleaner method to enable direct access to objects via the SA. Old and new TRI could be used in combination - depending on which TSI interfaces should be adapted how. We continue with xtri as proposed.

(0010416)
Jacob Wieland - Spirent
30-11-2011 09:33

For using arbitrary objects in the C-world, I propose to use a type construct like this:
typedef enumerated {
e_int,
e_long,
...
e_ptr
} type_kind;
typedef void *value;
typedef struct {
type_kind tag,
value val
} Object;
The value-pointer shall always be a pointer to the type corresponding to the the tag, so it can then be cast (and dereferenced if it is a base type).
Alternatively, value could be defined as a union over all C primitive types and pointer.
typedef union {
int v_int,
long v_long,
...
void *v_ptr
} value;
In this case, instead of casting, the proper union-variant must be used depending on the tag. Again, consistency between tag and value must be assumed.
With these definitions, in the C mapping whenever a C-value needs to be passed into the TTCN-3 world without the target type being known (i.e. for receive and catch), you would use this kind of Object type.
The convert function to be implemented by the test adapter (and to be used both by the Test Adapter and the TE) would then become like this:
TciValue convert(Object value, TciType type)
I don't think that we should use Object for passing DOWN to the adapter as then it would fall to the TE to decide how to map Value to Object where it knows nothing about the target to be adapted. (Is the function parameter a long or an int?). Only the adapter layer can know this and has already a clean way via the TCI value interface of accessing the values to be mapped.
For procedure based communication, we should still use some TciParameterList which encapsulates a list of TciParameters (i.e. tuple of name, mode, Value). Then, for out or inout parameters, the convert function would need to be called by the testadapter layer with the value obtained from the target world and the type of the parameter obtainable from the parameter-Value object.
So, to summarize:
- xtriSend, xtriRaise should use TciValue
- xtriCall, xtriReply, xtriEnqueueReply, xtriEnqueueCall should use TciParameterList (and TciValue for reply result)
- triEnqueueMsg, triEnqueueException should use Object

(0010422)
Jacob Wieland - Spirent
30-11-2011 09:55

To be more precise, we would need the following enum:
typedef enumerated {
e_int, // signed int
e_short, // signed short int
e_long, // signed long int
e_char, // char
e_uint, // unsigned int
e_ushort, // unsigned short int
e_ulong, // unsigned long int
e_uchar, // unsigned char
e_schar, // signed char
e_float, // float
e_double, // double
e_long_double, // long double
e_ptr // void *
} type_kind;
and the following union (if the union variant is used:
typedef union {
signed int v_int,
signed short int v_short,
signed long int v_long,
char v_char,
unsigned int v_uint,
unsigned short int v_ushort,
unsigned long int v_ulong,
unsigned char v_uchar,
signed char v_schar,
float v_float,
double v_double,
long double v_long_double,
void *v_ptr //
} type_kind;

(0010471)
Ina Schieferdecker
01-12-2011 12:30

Am 30.09.2011 um 09:47 schrieb Schieferdecker, Ina:
Dear all
We have developed the extended TRI (XTRI) package, which defines a more efficient handling of software values. It does not use binary encoded messages for the communication with the SUT, but uses the values as they are; meaning e.g. that software objects or serialized data can be passed directly between the SUT and the TE. The current proposal is available at http://t-ort.etsi.org/view.php?id=5888 [^]
This week we have been pointed to the possibility to base the extended TRI operations on Objects instead of Values in order to handle a more general case where any object could be treated by extended TRI that way. There are pros and cons and finally we decided to ask you in order to go for the solution that is considered the best for extended TRI.
Hence, please be so kind to respond by end of next week:
Should the extended TRI handle TCI Values or generic Objects?
Thank you in advance
Ina

(0010472)
Ina Schieferdecker
01-12-2011 12:30

Hi Ina, we would prefer generic objects for the extended TRI. Best regards, Stephan

(0010473)
Ina Schieferdecker
01-12-2011 12:31

Hello Ina,
Looks like I started a discussion... My mention of the idea of
passing generic Objects from the TA to the TE via the xenqueue() method was
not from me but from a Java intensive collegue at RIM. I think, what most of
the people do not understand is that with the new extension, the codec no
longer needs to reside in the TE or better is invoked by the TE but instead
is residing in the TA or more precisely is invoked by the TA. This is what I
extensively presented in my tutorial at T3UC'11. In my special case, web
testing using frameworks, this is essential.
Hope this helps
Bernard Stepien

(0010474)
Ina Schieferdecker
01-12-2011 12:31

Elvior prefers generic objects. Best Regards, Andres Kull

(0010475)
Ina Schieferdecker
01-12-2011 12:33

Dear Ina,
Thank you for your kind answer during your holiday.
In the light of this new information I think you are more prepared to
select the correct API by yourself based on the feedback you have received
already.
Kind regards,
Vesa-Matti
> Dear Vesa-Matti
>
> Sorry for answering only now - the difference would be basically that the
> operations defined by extended TRI would work on generic objects instead
> of values and that the conversion would allow to transform objects into
> specific values and vice versa. It would give even more flexibility than
> working on Values.
>
> Best regards
>
> Ina
>
> Subject: Re: RfC: Extended TRI for software testing based on Value or on
> Object ?!
>
>
> Dear Ina,
>
>>> Should the extended TRI handle TCI Values or generic Objects?
>
> I wonder if I have missed something last week but I have not yet received
> reply to my question about what was the difference between the two
> proposals given earlier.
>
> What would be the technical difference between "TCI Values" and "generic
> Objects" proposals?
>
> Kind regards,
> Vesa-Matti

(0010481)
Ina Schieferdecker
01-12-2011 13:56

generic objects represented as IDL any. representations for any defined in C, C++ (struct with type tag), C# and Java (Object) main principle: TE works with Value, SA works with Value/TciParameter when type is clear, otherwise with any Please review.

(0010482)
Ming Shang
01-12-2011 14:04

From RIM perspective, generic object is strongly perferred.

(0010485)
Jacob Wieland - Spirent
01-12-2011 14:30

mostly editorial changes, for xtriEnqueueExc Value was replaced by any/Object (resp. mapping) as TTCN-3 type is not known by TA. Value/ValueList parameter names replaced by SUTaddress/SUTaddresses according to header. Deleted sentence about ValueList being used as parameter list. renamed decodingHypothesis to typeHypothesis

(0010514)
Ina Schieferdecker
02-12-2011 12:41

made ValueList TciValueList - no need to define an extra type renamed decodingHypothesis consistently into typeHypothesis some final editing

(0010515)
Ina Schieferdecker
02-12-2011 12:42

Ready for final review - please check