OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bdx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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 business documents in a
>>secure and reliable way through the use of gateways (sometimes also
>>referred to as access points), which is also known as the "four-corner
>>model"
>
>
>On 13/02/12 10:57 AM, Jens Jakob Andersen wrote:
>> Hi Kenneth and others
>>
>> Thank you for presenting this charter as the next step.
>>
>> When I read it - I cant find the 4-corner model mentioned - as well as
>>the original notion that the important design-goal is to connect
>>"islands of networks" - i.e. the importance that we deliver a model that
>>can work across different networks/protocols.
>>
>> Can some of the authors kindly update me where we find the 4-corner
>>model in this new charter - as well as the important capabilit of being
>>protocol-neutral? I might have overlooked it and just need guidance.
>>
>> Best regards
>>
>> Jens Jakob
>> ________________________________________
>> Fra: bdx@lists.oasis-open.org [bdx@lists.oasis-open.org] P&#229; vegne
>> af Kenneth Bengtsson [kenneth@alfa1lab.com]
>> Sendt: 12. februar 2012 17:47
>> Til: bdx@lists.oasis-open.org
>> Emne: [bdx] Proposal for a TC recharter
>>
>> Dear BDX TC
>>
>> To move the work of the TC into a broader scope and to accommodate
>>requirements raised by BDX adopters, some members of the TC have worked
>>out a proposal for a rechartering of the OASIS Business Document
>>Exchange TC. The proposal for the rechartering is submitted in
>>accordance with the OASIS TC Process section 2.12:
>>
>> http://oasis-open.org/policies-guidelines/tc-process#rechartering
>>
>> The proposed new charter is being submitted by the following members of
>>the TC:
>>
>> Roger Bass, Traxian
>> Kenneth Bengtsson, Alfa1lab
>> Pim van der Eijk, Sonnenglanz Consulting Klaus Vilstrup Pedersen,
>> Difi-Agency for Public Management and eGovernment Sven Rasmussen,
>> Danish Ministry of Science, Technology and Innovation Susanne Wigard,
>> Land Nordrhein-Westfalen
>>
>> We kindly request that the TC chairs arrange for a TC meeting the week
>>of February 27 2012 to discuss the proposed new charter below. Depending
>>on the outcome of these discussions we can proceed to formally adopt the
>>changes using the process described in the OASIS TC Process.
>>
>> ====================================================
>>
>> Name of TC:
>> OASIS Business Document Exchange TC
>>
>> Statement of Purpose:
>> The BDX standard will describe an architecture (or sets of reference
>>architectures) where two entities exchange business documents in a
>>secure and reliable way through the use of gateways (sometimes also
>>referred to as access points), which is also known as the "four-corner
>>model".
>>
>> 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. Here, a "domain" can be any
>>community whose members (a) are connected through a shared system, and
>>(b) may interact with others across domains.
>>
>> Regardless of each domain's internal workings, such interactions entail
>>them each consuming and exposing to others over the Internet certain
>>interfaces. These specifications should provide a framework for domains
>>to interoperate securely and reliably (via Web Services), which can
>>therefore be viewed as an Inter-cloud Web Services framework.
>>
>> The TC specifications should be lightweight but, 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.  Approaches that are modular and agnostic about
>>data content and implementation architectures will be preferred.
>>
>> The TC will focus first on requirements for exchanges between groups of
>>related domains around standardized processes/data. Requirements of
>>cross-domain business documents exchange, with its corresponding use
>>cases, and implied interoperability requirements will inform
>>prioritization of the TC's initial deliverables. The TC will
>>specifically address requirements from the Large Scale Pilots ("LSPs")
>>in the area of e-government PEPPOL, e-CODEX and SPOCS.
>>
>> 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 TC may define or profile more than one such
>>specification(s).
>>
>> In other areas, published specifications today may be absent or have
>>gaps.  In such cases the TC will attempt to identify relevant standards
>>or work-in-progress at OASIS or other SDOs to establish liaisons with
>>and provide requirements for such efforts, as needed.
>>
>> Scope of work of the TC:
>> The specific objectives will be to define, specify and maintain the
>>following:
>>
>> 1) Use cases and requirements, based on submissions;
>>
>> 2) Profiling / gap analysis of existing standards with reference to the
>>use cases and requirements, potentially including:
>>    a) Addressing / Routing / Discovery (SML and related technologies)
>>    b) Service profiles/Capabilities (SMP, CPA and others)
>>    c) Identity/Authentication
>>    d) Trust Frameworks
>>    e) Transport / Reliable Messaging (e.g. AS4)
>>
>> 3) Unified architecture for all processes necessary and sufficient for
>> the superset of supported use cases;
>>
>> 4) Specifications for SML/SMP will be developed within the TC;
>>
>> 5) PEPPOL specifications for the START and LIME protocols.
>>
>> List of deliverables:
>> Technical specifications for protocols supporting distributed discovery
>>of locations and e-business and technical capabilities of exchange
>>partners.
>>
>> Profiles of B2B messaging protocols for use in four-corner (or
>>multi-corner) topologies.
>>
>> IPR Mode under which the TC will operate:
>> The TC will operate under the Non-Assertion Mode.
>>
>> The anticipated audience or users of the work:
>> The initial target groups for the TC are:
>>
>>    - Enterprise procurement vendors and supplier networks
>>    - Software companies (e.g. providers of middleware and business
>>applications)
>>    - Supplier information management providers
>>    - Public institutions
>>    - Financial institutions and payment networks
>>    - Large private companies
>>
>> Language of the Technical Committee:
>> The business of the Technical Committee will be conducted in English.
>>
>> Liaisons:
>> The initial list of liaisons that will be established includes: OASIS
>>ebXML Technical Committees, ETSI ESI and OASIS Identity in the Cloud TC.
>>
>> Other liaisons will be established in the course of the work.
>>
>> ====================================================
>>
>> Best regards,
>>
>> Kenneth Bengtsson
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: bdx-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: bdx-help@lists.oasis-open.org
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: bdx-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: bdx-help@lists.oasis-open.org
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]