1 / 22

New technology Trends April 2019 - Geneva

New technology Trends April 2019 - Geneva. Steven Capell: Enterprise Architect, Australian Government Department of Home Affairs steven.capell@homeaffairs.gov.au. UN/CEFACT for Web Developers. Summary.

thi
Download Presentation

New technology Trends April 2019 - Geneva

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. New technology TrendsApril 2019 - Geneva Steven Capell: Enterprise Architect, Australian Government Department of Home Affairs steven.capell@homeaffairs.gov.au UN/CEFACT for Web Developers

  2. Summary The last decade has seen an exponential rise of Web Platforms (like Alibaba, Amazon, etc). Theseplatforms all expose data exchange interfaces in a common style called « RESTful APIs » but mostly use proprietarysemantics. Wewillseethatthisbrings a pardaigm shift fromtraditional EDI style message exchange to a web of linked data resources and events. It alsoheralds a transition from a hub-centric EDI model to a peer-to-peer model of connectedplatforms. This presentationpresents a vision for web platforminteroperabilityusing UN/CEFACT semantic standards.

  3. The EDI Paradigm B2B Message exchange – how we communicate Purchase Order Purchase Order Buyer Seller EDI Hub Order Response Order Response EDIFACT/AS2 or XML/SOAP

  4. The EDI Paradigm B2B Message Semantics – how we understand Library (eg UNTDED) Message (eg ORDERS 06B) MIG (eg AU FMCG) Buyer Seller ORDER 12345

  5. The EDI Paradigm It’s the same model for XML messages Library (eg CCL) Context (eg BIE) Message (eg XML) Buyer Seller ORDER 12345

  6. The « Programmable Web » But that’s not how the web works. The web uses “Application Programming interfaces” (APIs). For example:” Facebook Auth API Login with Facebook Security Token Customer Google Map API My Business Website Find my business Stripe Payment API Pay Send invoice Its not about messages, its about a web of linked data Xero Invoice API

  7. The « Programmable Web » Token id=112233 name=bob smith abn=9876 assurance=level2 An international trade example Bob Smith GovPass Auth Auth API Token CertificateOfOrigin id=12344 tariffCode=5678 from=AU, to=CN invoice=acme.com:12345 My trade system AU Gov Repository GET CoO Recrods API GET invoice Invoice id=12345 from=acme abn=98765 value=2,000 Xero Invoice API GET business ABR business id=9876 name=acme pty ltd regDate=10-16-1987 Registry API

  8. The « Programmable Web » Almost every service provider business has developed, or is developing APIs for their services. That’s so that other businesses can embed them. This is the “programmable web”. And it’s big. • 100,000’s of APIs (vs few dozen EDIFACT) • Millions of developers (vs 1000’s of EDI devs) • Billions of users (vs a few 100,000?)

  9. The « Programmable Web » APIs use different technologies. • JSON syntax • HTTPS transport • HTTP verbs (GET, POST, PATCH) • OAuth2 / JWT security (aka “login with ..”) BUT, it’s not just a different syntax for messages

  10. The « Programmable Web » Its about a distributed web of linked data. • Focus is on granular identifiable “Resources” • That are discoverable (name -> URL) • That have data model and state lifecycle • And communicate state with “events” (webhooks). Resource Microservice Actions Events Created Domain GET Updated Resource GET POST Lodged PUT PATCH Assessed DELETE API Gateway Event Hub Data Lifecycle Devops

  11. Whydoesthismatter? Because B2B processes are increasingly the domain of cloud applications. The integration paradigm is changing from this Buyer Seller EDI Hub To this Discovery & Identity Buyer Seller

  12. But there’ssomethingmissing Consistent semantics are conspicuously absent! • Many emerging trade data pipelines – different APIs • Dozens of cloud based ERPs – all different APIs APIs have so far mostly been created by developers with an “inside->out” mentality – reflecting internal system semantics. But increasingly APIs need to be interoperable – so should be developed with “outside->in” thinking – based on standard semantics.

  13. But there’ssomethingmissing UN/CEFACT standards are well known to a few 1000 EDI developers / service providers. Virtually unknown to millions of web developers. “If it’s not on GitHub, it doesn’t exist”

  14. RDMs to the Rescue The UN/CEFACT best kept secret That is an API “Resource”

  15. Bringing UN/CEFACT to the Web edi3.org On Github at An unofficial experimentation site! Follow the “community” link and join up

  16. BackingBothHorses Messages and APIs can work together. The glue is resource discovery. Given a unique identifier (eg received in an EDIFACT message), I can use the framework to find the API for the resource. Message Schema BRS (UMM) RDMs & Libraries Resource Discovery API Specification Edi3.orgI There’s no need to pick a winner. Back both horses!

  17. Web Platforms in Government Why is AU government interested in all this? • Because we think a single window is really a set of Web APIs that we offer to industry. • Because we want to leverage commercial data sources by consuming their APIs. • And because we realise that most regulatory reporting is essentially commercial data. So that EDIFACT guide will be replaced with commercially aligned REST APIs. • And we want to do all this as part of an international standards effort.

  18. A Use Case – Single Windows UNECE Rec 33 describes a single window as “Within the context of this Recommendation, a Single Window is defined as a facility that allows parties involved in trade and transport to lodge standardized information and documents with a single entry point to fulfil all import, export, and transit-related regulatory requirements. If information is electronic, then individual data elements should only be submitted once.” First released in 2004, the proposal represented an improvement over paper based lodgments to multiple regulatory authorities. Trader Trader Single Window Multiple different forms Unified data Agency1 Agency2 Agency3 Agency4

  19. A Use Case – Single Windows In today’s world, most data is already electronic (99% of AU gov regulatory reports are lodged electronically today) and traders use highly integrated systems to deal with multiple stakeholders of which one national regulator is only a small part. This is the real “single window”! Integrated System Trader / Forwarder EDIFACT There’s no value in a govt single window here. The trader wont use it

  20. A Use Case – Single Windows In reality there are 100’s of “single windows’ serving different communities and one consignment may touch several of these. Will a single user really “use” 100 single windows? (cert case). Agents, carriers, intermediaries Regulator Exporter Freight Forwarder Systems E-commerce systems Importer Regulator Trade Pipeline CHA Ports SW CHA Prov SW AU Gov SW AU Ports SW Trade Pipeline CHA Ports SW CHA Prov SW CHA Prov SW Exporting Country Importing Country

  21. A Use Case – Single Windows So the best thing government can do is just implement simple, stable, modern “Application Programming Interfaces” (APIs) over their legacy systems so that any trader system can easily integrate. Based on a permissioned ledger. This is the real “single window”! Integrated System Trader Blockchain DLT API API API API API API

  22. Thank youQ&A Steven Capell: Enterprise Architect, Australian Government Department of Home Affairs steven.capell@homeaffairs.gov.au

More Related