46
How to connect workshop Copenhagen April 14th 2009 PEPPOL Architecture overview Mikkel Hippe Brun Technical Director @ PEPPOL Chief Consultant Danish National IT and Telecom Agency
| Date post: | 29-Jun-2015 |
| Category: |
Technology |
| Upload: | hippebrun |
| View: | 543 times |
| Download: | 1 times |
How to connect workshopCopenhagenApril 14th 2009
PEPPOL Architecture overview
Mikkel Hippe BrunTechnical Director @ PEPPOLChief ConsultantDanish National IT and Telecom Agency
Contents
Goals and vision
The “AS-IS” situationPeer-2-peer, Three/Four-corner-models
Business roles and requirements
Initial profilesFull profile
Queued profile
Lightweight profile
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.
WP8 vision
Pan European exchange of business documents between any private company and any EU governmental institution should be as easy as sending emails.
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”
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
The ”As-is-situation”
Several solutions to the same problemNational / Regional / Local / Sector specific / Public / Private
Much variance complexity and designPeer-2-peer
Three-corner-models
Four corner-models
Web-based or based on machine-2-machine interaction
Many different business models
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
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
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
High level view
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
Business Requirements
Business concern Service provider Large Organization Company
Business Requirements
Business concern Service provider Large Organization Company
Low cost of entry
Business Requirements
Business concern Service provider Large Organization Company
Low cost of entry Other cost of entry
(e.g.complexity, contractual, etc)
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
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
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
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
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
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
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
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?)
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
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
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
A four-corner-model is needed because…
The requirements differs a lot between service providers and SME’s
Trust requirement raises the barrierThe 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.
Basically a four corner model
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 equallyBusiness model not considered
Anyone meeting requirements can become an Access Point
Direct connection possible
Roles and transports
Company
SP
SP
Large Company or government agency
Company
Key
PEPPOL full profilePEPPOL queued profilePEPPOL lightweight profileOut of Scope / Legacy protocol
SP (e.g. Bank)
Company
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
Roles and Transports
Company
PSP
SP
Large Company or government agency
Company
Key
PEPPOL full profilePEPPOL queued profilePEPPOL lightweight profileOut of Scope / Legacy protocol
SP (e.g. Bank)
Company
PUTGET
PUT
PUT
PUT
PUT
PUT
PUT
PUT
Message exchange in PEPPOL
• The main questions are:– Who, where, why, how?
Trust
Registry
Sender Receiver
Why should I trust?
How do I advertise my capabilities?Who can I reach?
Where can I send my document?
How do I transport my document?
Scenario – CA based trust
Scenario – TLS based trust
VAN
SME 1
Large company
Govt. agency
SME 5
PEPPOL infrastructure
sphere
Existing infrastructure
sphere
Access Point 1
Large company
Access Point 3
Access Point 4
Portal
SME 4
SME 3
Access Point 2
TrustedService
List
Message + SAML token
Message + SAML token
PEPPOL infra-structure sphere
Existing infra-structure sphere
Trust lookup
Trust
PEPPOLRelay
ServiceSME 2
PUT
3rd partySTS
Gettoken
Scenario – STS based trust
Scenario 1: Basic send
Company ACompany B
Country A
Country B
Operator 1
Company C
Operator 2
PEDRI
PEDRI Registry
Access point, VAN 1
Access point 2, Operator 2
Transport properties• Secure• ReliableProfile properties• Transport + QoS
Invoice
Send to company C –
how??
Public agency D
• Key: CompanyC
• Doc: Invoice• Profile:
Peppol• Country: B
Endpoint: • Access point
2•
http://ap2.de/
WS-* over internet AMQP /
WS-* over internet
Other options..
This is the area that PEDRI adresses
Decentralized registry infrastructure
• 2 central questions:– Which registry has information on the recipient?– Where can I find the recipient?
Service registry
Sender
Registry locator service
Which registry?
Which endpoint?
Register
• These questions can be answered through many different strategies
Registry overview
Transport layer- Open standards- Secure & reliable transport
Top level registry
2nd level registry A
Replicated registries
Operator A
2nd level registry B
Operator B
Point to
Point to
Register
Lookup
Sender entry point
Recipient endpoint
Send payload
Receive payload
Sender
Recipient
Register & manage
Sender
Lookup
Scenario II: Multiple operators
Company ACompany B
Country A
Country B
Operator 1
Company C
Operator 2
PEDRI
Access point, national
Company F
Operator 3
Access point 3, Operator 3 Company E
PEDRI RegistryRegistry A
Invoice
Access point, VAN 1
Access point 2, Operator 2
Registry BTransport properties• Secure• ReliableProfile properties• Transport + QoS
Registry C
Public agency D
• Key: Agency D
• Doc: Invoice• Profile:
Peppol
Endpoint: • Access point
2•
http://ap2.de/
Send to Agency D – how??
• Key: Agency D
Registry: • Registry C•
http://reg.c.de/
Scenario V – Lightweight Profile
Company ACompany B
Country A
Country B
Operator 1
Company C
Operator 2
PEDRI
Company F
Operator 3
Company E
PEDRI Top-level Registry
Invoice
Access point, VAN 1
Access point 2, Operator 2
Transport properties• WS-* based
Registry C
Public agency D
• Bus. key: Company H
• Doc: Invoice• Profile: Peppol
Endpoint: • Company H•
http://compH.de/
• PGP key
Send to company H –
how??
• Key: Company H
Registry: • Registry C•
http://reg.c.de/
Company G
Company H Register with:• Bus. key:
Company H• Doc: Invoice• Profile: Peppol
Access point 4(PEPPOL service provider)
PUT
Access point 5(PEPPOL service provider)
GET
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
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
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
http://www.peppol.eu
http://www.peppolinfrastructure.com – WP8 Solution architecture – technical stuff
![Pragmatic Rails Architecture [SF Rails, 24 Apr 14]](https://static.documents.pub/doc/80x56/558238b2d8b42a0d368b4c3b/pragmatic-rails-architecture-sf-rails-24-apr-14.jpg)
