| Author |
Message
|
| yaakovd_new |
 Posted: Fri Mar 07, 2008 4:51 am Post subject: Parsing of ASN.1 using Message Broker 6.1 |
 |
|
Apprentice
Joined: 03 Feb 2004
Posts: 25
Location: Israel
|
Hello,
My project is in Telecommunication area and deals with different formats of data to be parsed by Message Broker.
The major challenge is a parsing of files in ASN.1 (Abstract Syntax Notation One) format.
In general it is tagged binary format with encoded length.
I need some help (pretty urgent) with modeling of message format.
What should I use - CWF or TDS (even in binary)?
General Encoding Rule for ASN.1 Values Type -> Length -> Value
| Code: |
Identifier Field --> Length Field --> Contents Field
1. Primitive, definite-length encoding for simple types
2. Constructed, definite-length encoding for structured types (SEQUENCE[OF], SET[OF])
3. Constructed, indefinite-length encoding for structured types (SEQUENCE[OF], SET[OF]) |
Same value of tag can be used for different purposes in different structures and it cannot be defined on Global Element level.
| Code: |
[01] Client
[01] name
[02] surname
[03] address
[02] Car
[01] type
[03] color
[04] weight |
| Code: |
Encoding of Identifier Field Tag numbers < 31
[code]
<---- Identifier Octet ----->
Bits | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
| Class | P/C | Tag number |
| |
| |
| |----- 0 = Primitive
| |----- 1 = Constructed
|
|----- 0 0 = Universal
|----- 0 1 = Application
|----- 1 0 = Context-specific
|----- 1 1 = Private[/code]
|
Another issue is flexibility of encoded length:
BER Encoding of Length Field
| Code: |
Short definite form ( L < 128 octets)
<--- one octet ---> <----- L octets ----->
| 0 | Length L | | Contents field |
Long definite form ( 128 ≤ L < 21008 octets)
<--- one octet ---> <----- K octets -----> <----- L octets ----->
| 0 | K | | Length L | | Contents field |
Indefinite form; content field terminated by EOC
<--- one octet ---> <--- two octets --->
| 1 | 0 0 0 0 0 0 0 | | Contents field | | EOC '0000'H |
|
Thanks
Note: I have deep 7 ears experience with MB. I'm looking for expertise and not for cursory knowledge.
_________________
_________________
Best regards.
Yaakov Dolgov
E-Business Solutions Consultant
IBM Global Services, Israel
preiger.yaakov@il.ibm.com |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Mar 07, 2008 5:15 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I haven't personally processed ASN.1 messages.
You may not be able to use MRM at all - you can't make use of sub-byte fields which seem to be necessary if I'm reading your description correctly.
I have flashes of memory that relate to this topic of ASN.1 and Broker - but nothing concrete. This might be a case where there's a good solution available using WTX integration... or there might be a parser/solution available from the Dublin offering team... or something else that I recall even less.
Hopefully kimbert will be along in a bit to correct everything I've said.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| yaakovd_new |
| Posted: Fri Mar 07, 2008 8:11 am Post subject: |
|
|
Apprentice
Joined: 03 Feb 2004
Posts: 25
Location: Israel
|
Thanks for you reply...
seems to me that you are right... I'll appreciate any details or references to possible solution.
_________________
_________________
Best regards.
Yaakov Dolgov
E-Business Solutions Consultant
IBM Global Services, Israel
preiger.yaakov@il.ibm.com |
|
| Back to top |
|
|
| shanson |
| Posted: Mon Mar 10, 2008 2:34 am Post subject: |
|
|
Partisan
Joined: 17 Oct 2003
Posts: 344
Location: IBM Hursley
|
You might be able to use MRM TDS at 6.1 level here.
6.1 added hex support for TDS tags and delimiters. 6.1 added length prefixed strings as a new physical type (same as CWF). TDS already supported length references and local elements.
The crucial issue is the identifier octet.
If bits 8,7,6 of the octet are fixed for a given field, then the TDS tag is a fixed binary value and you should try and use MRM to model this.
If bits 8,7,6 can vary you should try WTX. Although it does not support bit fields as such, it allows you to use 'component rules' to aid parsing, and the rules can use bitwise functions. |
|
| Back to top |
|
|
| mqpaul |
| Posted: Mon Mar 10, 2008 5:00 am Post subject: Are you using DER or other encoding rules? |
|
|
Acolyte
Joined: 14 Jan 2008
Posts: 66
Location: Hursley, UK
|
The initial example showed BER (basic? encoding rules) data. That worries me - BER is not a "canonical" encoding - i.e. there are several equivalent ways of encoding the same data . In particular, AFAIR, it allows "undefined" length elements. IMHO these features along with the bit-level manipulation would make it hard to define using MRM-CWF or MRM-TDS. DER - (distinguished encoding rules) data would at least remove the ambiguous encodings, but it's usually impossible to force the incoming data to any particular encoding.
ASN.1 is a complex encoding. I worked with it some years ago, on the easier 1984 version, and parsing that required something not unlike a language compiler. In broker terms, IMHO ASN.1 really needs a dedicated parser. My guess is you'd do best to find something that already speaks ASN.1 and works with broker. Sorry, I don't have any suggestions to make as to where to find that!
_________________
Paul |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Mar 10, 2008 5:58 am Post subject: Re: Are you using DER or other encoding rules? |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
|
| Back to top |
|
|
| shanson |
| Posted: Mon Mar 10, 2008 6:31 am Post subject: |
|
|
Partisan
Joined: 17 Oct 2003
Posts: 344
Location: IBM Hursley
|
OK - so the options are:
a) If using friendly subset might be possible with MRM-TDS 6.1
b) More generally, need a parser that handles full ASN.1, options:
i) Check whether WTX has an industry pack
ii) Author own plugin parser using a library
iii) See if WDP XI50 appliance can handle, and offload parsing |
|
| Back to top |
|
|
|
|
