Hi Pim
I'm not sure this discussion is relevant for the rechartering, but interesting just the same.
To answer your question first: In DNS the frequency for querying changes to a registration is specified in the Time To Live (TTL) value. If you have a DNS registration that frequently changes then you put a low TTL value. If your registration seldom changes, then you put a high TTL value. The system querying your registration caches the response and will know by the TTL value when to check again. This is all existing technology that we all use thousands of times every day. It's probably important for the TC members to understand how this work, but most importantly is that we know that it works.
We had several reasons in PEPPOL for choosing DNS as part of the SMLP. It was an important design goal for us to separate metadata (capabilities) from the transport protocol, and to make it orthogonal so that other transport protocols could coexist with our own START protocol. I think this philosophy serves BDX well now. Also important was to create an architecture with no single-point-of-failure. The distributed nature of DNS solves this in way that centralized systems (such as UDDI) cannot, and the DNS technology is already widely available (we all use it thousands of times every day).
Best regards,
Kenneth
Hello Mikkel, Lightweight and reliable are adjectives that I'm sure we all
like, so I'm ok with this. I'm also not against using DNS, and it's great that a
DNS-based registry solution draft has been submitted to the TC as it's always
good to have a starting point for discussions, but,
separately from the rechartering discussion, and having been in
this TC for some time, I would like to understand the requirement for DNS-scale
scalability better. To explain why I'm asking, let me sketch a scenario, a
question and two extreme possible answers: Assume company A manages to get itself registered successfully
using SML/SMP/CPP or similar technologies in the BDX infrastructure. Assume a current or prospective trading partner B
retrieves the registration records for A. Now B has information that it can send documents of type
T to some gateway G using a protocol P and possibly other
configuration information C, from a starting data/time S to an ending date
time E. E may be several months or or even years in the
future My question is: How often, if at all, does B (or B's service provider)
need to actively retrieve the registration information for A
? Answer 1: Whenever B is about to send a document to A, as B may
have changed its registration information (e.g. selected a different service
provider, or acquired a new ERP system that handles a different set of XML
schemas etc.). This is a bit like checking your friends' telephone number in the telephone directory whenever you're about to call
them, as they may have changed their numbers without telling you.
It's certainly possible, though in my social network I don't know anybody
who actually does this .. Answer 2: Only if/when A's configuration information changes, as
B subscribes to A's social network update list and gets updates
delivered to itself if/when needed. A pushes
configuration updates directly to its partners, for instance using something
like a generalization of the IETF CEM message, or some other protocol we design
in BDX. In this scenario, B only ever uses
a directory for initial discovery of new trading partners. All subsequent
updates among its social network are peer-to-peer (though possibly mediated via
various services providers). In many industries, this year's trading partner
list on average has a 95% overlap with last'years list, especially among
SMEs. If A and B are in
a closed community (say government agencies collaborating in some specialized
area of government), they may skip the initial discovery step altogether
(and may prefer to not be discoverable at all) as they will get their initial configuration information some other way, yet an update
mechanism could still be useful in a closed
community. The scalability requirements for (1) and (2) are
obviously vastly different. But they are also different
in architectural and functional ways, and support different types of communities
and requirements in different ways.
Pim Thank you for this clarification Susanne. I am very exited about the
prospect of getting new resources into the TC. I have re-read the proposed charter multiple times and I can see where you are coming from and that you
really intend to make the TC very operational.
The only thing I miss from the old charter is the emphasis on the resulting
infrastructure in itself being lightweight. It also follows from the
infrastructure being federated, but the critical part is that any centralized
infrastructure components have as little footprint as possible. The more we can
piggybag on existing infrastructure the better. Such a framing would also scope
discussions about service discovery and addressing specifications like UDDI and
ebXML RegRep.
I would then sugges the following change to the proposed charter:
Original:
The purpose of the TC is therefore to define the
specifications of a federated messaging and trust infrastructure for data
exchange and web services interoperability between domains.
Proposed: The purpose of the TC is therefore to define the
specifications of a lightweight
and federated messaging and trust infrastructure for
reliable data exchange between domains.
I have taken out the "web services interoperability" because this is
covered by other OASIS TC's and I dont think that we should limit ourselvs to
web services (in the classical sence). The old charter mentioned "messaging
service standards" and I think this term covers the intention better.
All
the best Mikkel
On Thu, Mar 1, 2012 at 11:01 PM, <Susanne.Wigard@it.nrw.de>
wrote:
Dear
all,
First let me
apologize for failing to join the telco. I'll have more comments when I get to
see the minutes - for now let me just emphasize that indeed the intention
of broadening the scope goes anlong with the goal to add resources to the
TC, in particular from the LSP project that I'm working with, e-CODEX,
and connected to activities in the context of creating a common transport
infrastructure for the ongoing and future LSPs. So it's not about disreagrding
the PEPPOL work, but quite to the contrary about continuning it into new projects and domains.
Regards
Susanne
____________________________________
Thank you for the clarification Kenneth. This sounds very good and I
look forward to the continued discussion and the next
meeting. Regards / Hilsen
Mikkel
Dear Tim and Mikkel
I agree with your comments, and it was as such also the intention
with the proposed charter to reflect these viewpoints. I'm sure the
wording can be improved:
In the statement of purpose it says that TC specifications should
be...
"...wherever and to the extent possible, based on profiles of
existing standards from OASIS and elsewhere that are widely-used and
proven, or otherwise seen to be generally
applicable.".
The intended meaning of this is, exactly as both of you commented: To
focus on technologies that already exist and can be put into immediate use
in the work of the TC.
Also in the statement of purpose:
"In certain areas the work will therefore initially be centered
on the work of these LSPs (notably on SMLP around identity and service
discovery, addressing and profiling), and will also consider other approaches and related specifications (e.g. DNS, ebXML CPA, UDDI, ebXML
RegRep, WS-Discovery)...".
The intended meaning here is to say: We will leverage the work
already done by PEPPOL and other LSPs - this is our starting point.
However, if along the way we accept specific requirements or if we see
that our work can benefit from it, then we shouldn't by default disregard
other technologies. We have a solid starting point with the work already
produced by the LSPs and it is from there that we progress. However we
shouldn't progress wearing blinkers.
In the scope of work is specifically mentioned that the
specifications from PEPPOL (namely SML, SMP, START and LIME) will have
their home in the TC. The SML/SMP technology are the foundation for
discovery, whereas START and LIME may have more PEPPOL-specific uses. I'd
like to stress again that it is not the intention to disregard the work
already produced.
I'm sure that the wordings in the proposed charter can be improved to
better reflect the intended meaning. There is no pride in ownership, so
please feel free to make all the suggestions for improvement that you
like! At yesterday's meeting we agreed to postpone the vote for the
recharter until March 14 to allow for comments and specific
proposals.
With regards to the "speed with which the TC can work": Mike made the
comment yesterday that broadening the scope of the TC means that more work
has to be produced, and that adding more resources is by no means a
guarantee that work will progress any faster. This is a valid comment and
it is in most cases true. However, in our specific case it is a specific
objective with the recharter to make the TC a platform for producing specifications for an ongoing convergence of the LSPs respective eDelivery
technologies. A widening of the scope will therefore enable the LSPs to
add resources to the TC and to take a leading role. As the LSPs are also
working with milestones and deadlines I do in fact believe that the
proposed recharter will make the TC gain momentum rather than loosing
it.
Joao volunteered yesterday to make a suggestion to the proposed charter for clarifying/underlining the role and significance of the LSPs
(and the LSP convergence process) in the TC.
Best regards,
Kenneth
I also have a call conflict for
today's call. i support Mikkel's view on this - the rechartering is a good
step forward, but there is a risk of loosing momentum. We should be
capitalizing on the progress PEPPOL and other LSPs have made in this area. That is, we should be building on what we have, not what we
would like to see. On 29/02/12 10:28 PM, Mikkel Hippe Brun wrote:
Dear
all,
I will
unfortunately be in transit during todays call due to a delayed
flight.
I do support the
change to the TC's charter if it means wider support to the TC's work
from the other large scale pilots. I do however have concerns about the
widening of the scope as it will impact the speed with which the TC can
work (Mike's argument).
One important
criteria that is fundamental for the large scale pilots mentioned in the
charter is that there is very little willingness to establish and fund
more than the most essential shared infrastructure components. It is
therefore in my opinion very important that the technologies that the TC
explores for service discovery and addressing piggybacks on existing
Internet infrastructure like DNS.
I dont find
UDDI or ebXML RegRep to be operational and scalable for large scale
infrastructures. We may as a TC and individuals find the standards behind UDDI or ebXML RegRep
to be appropriate, but the reference implementations are not battle
proven for large scale use. And it is my very strong opinion that the TC
should focus on technologies that are battle proven and can be put into
use immediately.
Finally - I would like to step
down as chair for the TC, but I would like to continue as TC
member.
Best regards Mikkel
On Tuesday, February 21, 2012, Kenneth Bengtsson wrote:
Hi Jens Jakob
I very much agree with you that
this is an important design goal and objective for a number of
applications (PEPPOL for example). At the same time I also believe
we must acknowledge that other applications can have different
requirements and implementation architectures.
One of the important reasons for the proposed recharter is to allow for
a broader and more general application of the BDX specifications.
This doesn't mean that we in PEPPOL will accept to have specific
protocol requirements imposed on the "final leg" between gateway
and enduser, I strongly agree with you on this. What it means is
that we see an advantage in opening up the possible use cases for
BDX, and not let the requirements of one project stand in the way
of a more broad adoption.
Best
regards,
Kenneth
On 2/20/12 8:15 AM, "Jens Jakob
Andersen" <jjan@itst.dk> wrote:
>Hi
Kenneth > >Thank you for the
clarifications. > >I still cant see in the specs, that is
is a _must_, that the protocols to >be used between gateways
must be agnostic to whatever is used on the >first & last
legs. > >Some of the "GW to GW" protocols I have seen
demonstrated, has many >features that can only be usefull, when
the same family of protocol is >used
end-2-end. > >The original design-goal of BDX was to deliver a "meta-protocol" to be >used between gateways - to
interconnect different domains. And supporting >many different
transport-protocols below. > >From my (fast fading
viewpoint as I am leaving the TC), these >design-goals should be
kept as the TC's design-goals. > >Best
regards > >Jens Jakob > >-----Oprindelig meddelelse----- >Fra: Kenneth Bengtsson
[mailto:kenneth@alfa1lab.com] >Sendt: 13. februar 2012
15:58 >Til: Jens Jakob Andersen; Tim McGrath >Cc:
bdx@lists.oasis-open.org >Emne: Re: SV: [bdx] SV:
Proposal for a TC recharter > >Hi Jens
Jakob > >As Tim already mentioned, the 4-corner model is
described already in the >first paragraph. > >With
regards to "connecting islands": > >In the first paragraph
is stated that BDX describes a model "where two >entities
exchange business documents in a secure and reliable way
through >the use of gateways". If we can agree that it is in the
definition of a >gateway that it has two sides, then it is in
logic that the two entities >exchanging business documents must
each connect to their respective >gateways, and that the
gateways must connect to one another. Then you >have the first,
the last, and the middle "leg" of the transaction. If you >read
the second and third paragraph of the statement of purpose
and >replace "domain" with "island", then I think you will agree
that it is >actually in the proposed purpose statement to
"connect different islands >of networks". >It is my
understanding that the term "island" is mainly used
in >procurement jargon, why we have used the more generic term
"domain" to >describe exactly the same. This is also to signal
that the potential use >of BDX goes beyond procurement and e-commerce business documents - BDX >can be used for any type of
electronic business document. > >Best
regards, > >Kenneth > > >On 2/13/12 9:44
AM, "Jens Jakob Andersen" <jjan@itst.dk>
wrote: > >>Hi Tim >> >>Thank you for
the clarification. >> >>That is half of
it. >> >>What I am looking for is the other part of
the 4-corner model, that >>different protocols can be used on
the "first leg" and "last leg" and >>the "inbetween" part can
be a standardized "meta-protocol" such as >>START - open for
mapping to "any" actual protocol. >> >>This is the
core of the idea of START /and BusDox and BDX/ - that
the >>challenge is to "connect different islands of
networks". >> >>The acid-test for any change should
(IMHO) be: "Can it deliver the >>value mentioned, in a setup
with different protols/implementations on >>the first and
last leg". >> >>Best
regards >> >>Jens
Jakob >> >>-----Oprindelig
meddelelse----- >>Fra: Tim McGrath
[mailto:tim.mcgrath@documentengineeringservices.com] >>Sendt:
13. februar 2012 11:22 >>Til: Jens Jakob
Andersen >>Cc: Kenneth Bengtsson;
bdx@lists.oasis-open.org >>Emne: Re: [bdx] SV:
Proposal for a TC recharter >> >>it is in the
statement of purpose. >>> The BDX standard will describe
an architecture (or sets of reference >>>architectures)
where two entities exchange bu
-- Best
regards, Mikkel
Mikkel Hippe Brun Chief Strategy Officer,
Cofounder
Voice: +45 3118 9102 Skype: hippebrun Twitter:
@hippebrun @tradeshift Mail: mhb@tradeshift.com Web: http://tradeshift.com
-- INVOICING HAS NEVER
BEEN EASIER
--
|