PEPPOL Architecture Overview - Apr. 2009

797 views

Published on

PEPPOL architecture overview presentet on April 14th 2009 in Copenhagen.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
797
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • TODO perhaps also show company A to AP national to AP3 to Company F
  • TODO perhaps also show company A to AP national to AP3 to Company F
  • PEPPOL Architecture Overview - Apr. 2009

    1. 1. PEPPOL Architecture overview Mikkel Hippe Brun Technical Director @ PEPPOL Chief Consultant Danish National IT and Telecom Agency How to connect workshop Copenhagen April 14th 2009
    2. 2. Contents Goals and vision The “AS-IS” situation Peer-2-peer, Three/Four-corner-models Business roles and requirements Initial profiles Full profile Queued profile Lightweight profile
    3. 3. WP8 goals Solutions architecture – design and validation – will focus on design and validation of the common specifications and building blocks which together will define the technical interoperability layer required to provide an operational e-business infrastructure.
    4. 4. WP8 vision Pan European exchange of business documents between any private company and any EU governmental institution should be as easy as sending emails.
    5. 5. WP - Outcomes An architecture – A federated, secure and reliable infrastructure for electronic document transport. Specifications – Based on internationally recognized open standards – For secure and reliable transport of electronic documents. Software – Dual license (EUPL and MPL 1.1 where applicable) – Lowering barriers for implementers – Provides reference implementations – Demonstrates “that it is easy”
    6. 6. Expected benefits Easy to exchange business documents Easy to use the PEPPOL infrastructure Easy for… – Service providers • e.g. banks • e.g. Value Added Networks • e.g. E-procurement Platform Providers – Public sector institutions – Large companies – SME's
    7. 7. The ”As-is-situation” Several solutions to the same problem National / Regional / Local / Sector specific / Public / Private Much variance complexity and design Peer-2-peer Three-corner-models Four corner-models Web-based or based on machine-2-machine interaction Many different business models
    8. 8. The peer-2-peer-model Characteristics (simplified) Agreed upon standards for transport open or proprietary Perhaps - agreed upon standards for content Difficult to match business requirements
    9. 9. The three-corner-model Characteristics (simplified) Proprietary standards (whole stack) Service provider lock-in / Limited competition Customers may have to connect to more than one service provider
    10. 10. The four-corner-model Characteristics (simplified) Agreed upon standards for transport open or proprietary Perhaps - agreed upon standards for content Freedom to choose service provider
    11. 11. High level view
    12. 12. Roles / Actors We identified 3 distinct roles (with respect to transports) – Service Provider (SP) • An existing e-business network provider with legacy customers – e.g. banks – e.g. Value Added Networks – e.g. E-procurement Platform Providers • Service Providers may in addition offer a standardized lightweight access to their customers – A new role that may be played by existing VANs, Government agencies or private sector initiatives – Supports (C) using PEPPOL specific interfaces – Large company or government agency – with hosted services (LC) • A company that is willing to install and maintain a gateway with endpoints available 24x7 – Company or government agency without hosted services (C) • A company (of any size) that is not able or interested in connecting directly to PEPPOL
    13. 13. Business Requirements Business concern Service provider Large Organization Company
    14. 14. Business Requirements Business concern Service provider Large Organization Company Low cost of entry   
    15. 15. Business Requirements Business concern Service provider Large Organization Company Low cost of entry    Other cost of entry    (e.g.complexity, contractual, etc)
    16. 16. Business Requirements Business concern Service provider Large Organization Company Low cost of entry    Other cost of entry    (e.g.complexity, contractual, etc) Low cost per msg   
    17. 17. Business Requirements Business concern Service provider Large Organization Company Low cost of entry    Other cost of entry    (e.g.complexity, contractual, etc) Low cost per msg    Technology comfort zone   
    18. 18. Business Requirements Business concern Service provider Large Organization Company Low cost of entry    Other cost of entry    (e.g.complexity, contractual, etc) Low cost per msg    Technology comfort zone    Reliability   
    19. 19. Business Requirements Business concern Service provider Large Organization Company Low cost of entry    Other cost of entry    (e.g.complexity, contractual, etc) Low cost per msg    Technology comfort zone    Reliability    Integrity   
    20. 20. Business Requirements Business concern Service provider Large Organization Company Low cost of entry    Other cost of entry    (e.g.complexity, contractual, etc) Low cost per msg    Technology comfort zone    Reliability    Integrity    Transport-level non-repudiation   
    21. 21. Business Requirements Business concern Service provider Large Organization Company Low cost of entry    Other cost of entry    (e.g.complexity, contractual, etc) Low cost per msg    Technology comfort zone    Reliability    Integrity    Transport-level non-repudiation    Privacy   
    22. 22. Business Requirements Business concern Service provider Large Organization Company Low cost of entry    Other cost of entry    (e.g.complexity, contractual, etc) Low cost per msg    Technology comfort zone    Reliability    Integrity    Transport-level non-repudiation    Privacy    Trust   
    23. 23. Business Requirements Business concern Service provider Large Organization Company Low cost of entry    Other cost of entry    (e.g.complexity, contractual, etc) Low cost per msg    Technology comfort zone    Reliability    Integrity    Transport-level non-repudiation    Privacy    Trust    Avg. latency lower than 5 min.   + (tender?)
    24. 24. Business Requirements Business concern Service provider Large Organization Company Low cost of entry    Other cost of entry    (e.g.complexity, contractual, etc) Low cost per msg    Technology comfort zone    Reliability    Integrity    Transport-level non-repudiation    Privacy    Trust    Avg. latency lower than 5 min.   + (tender?) High volume   
    25. 25. Business Requirements Business concern Service provider Large Organization Company Low cost of entry    Other cost of entry    (e.g.complexity, contractual, etc) Low cost per msg    Technology comfort zone    Reliability    Integrity    Transport-level non-repudiation    Privacy    Trust    Avg. latency lower than 5 min.   + (tender?) High volume   
    26. 26. Architectural goals Secure and reliable Realizable with internet technologies Federated and scalable Lower barriers Leverage investments in existing infrastructures Allow existing business models to co-exist
    27. 27. A four-corner-model is needed because… The requirements differs a lot between service providers and SME’s Trust requirement raises the barrier The technical solution requires a trusted third party Also the “low latency” and “availability” requirements raises the barrier Requires hosted service with good SLA Conclusion: No single transport profile matches all the requirements. The four-corner-model caters for this inherent problem.
    28. 28. Basically a four corner model
    29. 29. However…. All access points must meet a number of requirements: Sign roaming agreement Meet SLA requirements Certificate listed in TSL Have full transport interoperability Every access points are treated equally Business model not considered Anyone meeting requirements can become an Access Point
    30. 30. Direct connection possible
    31. 31. Roles and transports SP (e.g. Bank) Company Company SP SP Key Company Large Company or government agency PEPPOL full profile PEPPOL queued profile PEPPOL lightweight profile Out of Scope / Legacy protocol
    32. 32. Initial thinking on transport profiles • Full profile – High fidelity, guaranteed secure delivery of messages from Access Point to Access Point – Based on open standards such as WS-* – The only “required” profile • Queued profile – High fidelity, guaranteed secure delivery of messages from Access Point to Access Point using a message queuing model – An optional profile to enable efficient delivery of high volume between two VANs • Lightweight profile – A simple low cost profile that enables a disconnected company to access stored messages via a PEPPOL Service Provider – Analogous to using SMTP Relay and POP3/IMAP
    33. 33. Roles and Transports PUT SP PUT (e.g. Bank) Company PUT Company PUT PUT PUT SP GET PUT PSP PUT Company Key PEPPOL full profile Large PEPPOL queued profile Company or PEPPOL lightweight profile government Out of Scope / Legacy protocol agency
    34. 34. Message exchange in PEPPOL • The main questions are: – Who, where, why, how? Why should I trust? Trust How do I transport my document? Sender Receiver How do I advertise Who can I reach? Registry my capabilities? Where can I send my document?
    35. 35. Scenario – CA based trust
    36. 36. Scenario – TLS based trust PEPPOL infra- structure sphere Existing Existing infra- infrastructure structure sphere sphere PEPPOL infrastructure sphere Govt. Message + agency SAML token Access SME 1 Trust Point 4 Trust Get VAN lookup token Trusted 3rd party Access Service STS Point 1 List Message + SAML token Large company PUT Access PEPPOL Point 3 Large Relay company Service SME 2 Access Point 2 Portal SME 5 SME 4 SME 3
    37. 37. Scenario – STS based trust
    38. 38. Scenario 1: Basic send Send to Country A company C – • how??Key: CompanyC Invoice • Doc: Invoice • Profile: Peppol PEDRI • Country: B Registry Endpoint: Operator • Access point 2 1 Company B • http://ap2.de/ Company A PEDRI This is the area that Access point, PEDRI adresses VAN 1 Transport properties • Secure • Reliable Profile properties • Transport + QoS Country B Access point 2, Operator 2 WS-* over internet AMQP / Operator WS-* over 2 Company C Public internet agency D Other options..
    39. 39. Decentralized registry infrastructure • 2 central questions: – Which registry has information on the recipient? – Where can I find the recipient? Registry Which registry? locator service Sender Register Service Which endpoint? registry • These questions can be answered through many different strategies
    40. 40. Registry overview Top level registry Lookup Sender Point to Point to Register & manage 2nd level registry A 2nd level registry B Operator A Operator B Register Replicated registries Recipient Lookup Receive payload Sender Transport layer Send payload - Open standards - Secure & reliable transport Recipient Sender endpoint entry point
    41. 41. Scenario II: Multiple operators Send to Agency D – how?? Country A Invoice • Key: Agency D PEDRI Registry: Registry • Registry C Operator Registry A Endpoint: • http://reg.c.de/Key: Agency D • 1 Company B • Access point 2 • Doc: Invoice Company A • http://ap2.de/ • Profile: Peppol Access point, PEDRI VAN 1 Transport properties Registry B • Secure • Reliable Access point, Profile properties Registry C national • Transport + QoS Country B Access point 2, Operator 2 Operator 2 Company C Public agency D Access point 3, Operator 3 Company E Operator 3 Company F
    42. 42. Scenario V – Lightweight Profile Country A PEDRI Top-level • Key: Company H Registry Operator 1 Company B Registry: Company A • Registry C • http://reg.c.de/ Access point, PEDRI VAN 1 Transport properties • WS-* based Endpoint: Country B • Company H Access point 2, PUT Access point 4 • http://compH.de/ Operator 2 (PEPPOL service provider) • PGP key Operator 2 Invoice Company C Public Send to agency D company H – how?? •Bus. key: Company H Company G Company E • Doc: Invoice Operator • Profile: Peppol Registry C 3 Company F GET Company H Register with: • Bus. key: Company H • Doc: Invoice • Profile: Peppol Access point 5 (PEPPOL service provider)
    43. 43. Fees for using PEPPOL infrastructure? There is no fee associated with sending and receiving messages between PEPPOL Access Point There may be fees to: – Have an entry listed in a registry – Use an STS / Certificate Validation Service However.. Service providers choose their own business model
    44. 44. Roadmap for PEPPOL Infrastructure May 2009 – April 2010 : Construction – May – Hands on workshop for developers – October – New release – January - PEPPOL 2010 – February – New release – May 1st – Production May 2010 – April 2011 : Pilot – Workshops – Standardization – Aid to pilots – Patches
    45. 45. Summary PEPPOL offers: A pan European registry architecture – Business entities, Business processes, Business documents, Transport, Security information A trust model Certificate validation Secure and reliable transport Specifications Reference implementations A governance model
    46. 46. http://www.peppol.eu http://www.peppolinfrastructure.com – WP8 Solution architecture – technical stuff

    ×