Sample code and test data for Dynamic Discovery

Hello,

Dale Moberg has  provided a draft specification on Business Document Metadata Service Location  Discovery to BDX ( https://www.oasis-open.org/apps/org/workgroup/bdxr/download.php/47815/BDX-Location-v1.0-wd02.odt )  that is a further development of the SML concept.   He also  created
some sample client code that works with a sample DNS records  used for SIP Internet Telephony and more recently on a browser client  example.
I wanted to create some DNS data of the required type (NAPTR  records of the  U  type) that I could use for prototyping.  Others may find  this useful as well, so this email explains how to do this and some sample code  and data.

A very simple way to  create a DNS server that serves NAPTR records is to use Twisted Names ( http://twistedmatrix.com/documents/current/names/howto/names.html ),   a DNS server that uses the Twisted toolkit ( http://twistedmatrix.com/trac/ ).  Twisted currently requires Python 2.7 and can be downloaded from  http://twistedmatrix.com/trac/wiki/Downloads .   Twisted Names is used by some large DNS production sites.  But in this  email the focus is on a simple DNS server that a developer can run locally on  his laptop or some LAN server and that does not interfere with the regular DNS  services in his/her office.
Installation of Twisted  provides a Twisted daemon called  twistd , which can be used to create an  out-of-the-box DNS server with no coding:

    twistd -n dns --pyzone  <configfile>

Here,
configfile  (in the attached ZIP it is  called  samplezones.dat ) is a text file containing DNS record data  in a simple Python format. (The format of the BIND DNS tool is supported  too).   It has text records such as:

    CNAME('www.example-domain.com',  'example-domain.com'),     CNAME('ftp.example-domain.com',  'example-domain.com'),

    MX('example-domain.com', 0,  'mail.example-domain.com'),     A('mail.example-domain.com',  '123.0.16.43'),

    NAPTR(  'govello-1234567890123-456789012.production.ecodex.eu', 10, 1, 'U', 'meta', '',  'https://somedomain.de/productionservice.xml', 1000 ),      NAPTR( 'govello-1234567890123-456789012.test.ecodex.eu', 10, 1, 'U', 'meta', '',  'https://somedomain.de/testservice.xml', 1000 ),

    NAPTR(  '2228f94745c706c63e24dcbb705144df16202dfa.production.ecodex.eu', 10, 1, 'U',  'service', '', 'http://somedomain.de/service.xml', 1000 ),      NAPTR( 'metadata.example-domain.com', 30, 1, 'U', 'ebcpp3', '',  'https://lastditch/cpp.xml', 1000 ),     NAPTR(  'metadata.example-domain.com', 10, 1, 'U', 'ebcpp3', '',  'https://somedomain/cpp.xml', 1000 ),     NAPTR(  'metadata.example-domain.com', 20, 1, 'U', 'ebcpp3', '',  'https://failoverdomain/cpp.xml', 1000 ),     NAPTR(  'metadata.example-domain.com', 1, 1, 'U', 'smp2', '',  'https://otherdomain/smp.xml', 1000 )

The CNAME record  type is the type of DNS record used in the PEPPOL SML.  I'll not discuss  those as Dale's spec explains that NAPTR records are the more appropriate  records for the business service discovery scenarios that we're interested in in  BDXR.  But someone interested in supporting the older SML records in a  metadata service in addition to the newer format could use the same server  toolkit.

The NAPTR records  show examples of various service formats (e.g.  smp2  or
ebcpp3 ), of domain names normalized by hashing and/or with service  provider or community domains,  and for communities that provide separate  branches for separate environments (e.g.  production  or
test ).  As already explained in Dale's draft, there are many  options and the good news is that it is not difficult to provide  multiple options in parallel.  A service provider or community could easily  provide support for various formats (using different string values for the
service  field) or various versions of these formats (using version  number suffixes).
On the client side,

I've also enhanced  Dale's example that used the dnspython library ( http://www.dnspython.org/ ) and verified  that it worked with NAPTR  U  records, and a
nd generalized it somewhat to  support an ability to filter search based on service,  do searches in  community domains and specific environments in these domains,  optionally  apply normalization using hash algorithms etc.  There is the beginning of a  library module in the attached ZIP.

The main lesson is  that a combination of naming conventions, service typing and simple  parameterization in toolkits would make it very easy to support multiple  publication and discovery scenarios, protocol formats and data  formats simultaneously (either permanently or temporarily, during a  migration to a newer version of protocol), as far as the initial discovery is  concerned (SML, DDDS), without any business  impact.
The fact that there is an installed base of users of a  first version of a discovery protocol and format is no reason not to  consider newer protocols and formats even if they are not backward  compatible.   A full explanation would also cover the service  description formats (SMP and others), I hope to cover that during our face to  face meeting.

Enjoy,

Pim


Attachment:
bdmsl.zip
Description:  Zip compressed data