bdxr message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Sample code and test data for Dynamic Discovery
- From: "Pim van der Eijk" <pvde@sonnenglanz.net>
- To: <bdxr@lists.oasis-open.org>
- Date: Wed, 27 Mar 2013 17:20:26 +0100
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 and 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]