Your SlideShare is downloading. ×
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Canonical Models for API Interoperability
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Canonical Models for API Interoperability

507

Published on

Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/1mdrda3. …

Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/1mdrda3.

Ted Epstein shows how a shared canonical model can make life easier for API consumers, while still allowing the flexibility to expose different services, with different contextual requirements. Filmed at qconnewyork.com.

Ted Epstein has over 20 years of experience in commercial and enterprise software development, and has been working on model-oriented solutions for API design and large-scale software integration since 2006. In 2010, Ted left his position at Morgan Stanley to found ModelSolv, a company dedicated to providing innovative technologies and solutions in enterprise API management.

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

No Downloads
Views
Total Views
507
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Canonical Modeling for API Interoperability QCON NEW YORK, JUNE 2014 TED EPSTEIN, FOUNDER AND CEO MODELSOLV, INC. 1COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 2. InfoQ.com: News & Community Site • 750,000 unique visitors/month • Published in 4 languages (English, Chinese, Japanese and Brazilian Portuguese) • Post content from our QCon conferences • News 15-20 / week • Articles 3-4 / week • Presentations (videos) 12-15 / week • Interviews 2-3 / week • Books 1 / month Watch the video with slide synchronization on InfoQ.com! http://www.infoq.com/presentations /canonical-models-api-interop
  • 3. Presented at QCon New York www.qconnewyork.com Purpose of QCon - to empower software development by facilitating the spread of knowledge and innovation Strategy - practitioner-driven conference designed for YOU: influencers of change and innovation in your teams - speakers and topics driving the evolution and innovation - connecting and catalyzing the influencers and innovators Highlights - attended by more than 12,000 delegates since 2007 - held in 9 cities worldwide
  • 4. Overview • How APIs help developers, how they don’t • Canonical models: promises and challenges • Tackling variability in message representations • A Better Client Library • Demo and walkthrough 2COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 5. Developers in the API Jungle 3COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 6. Services Built in isolation • Many services built to service a single application or org unit. • No data or API governance, no shared data models. • No meaningful guidelines. “Just use schema.” • No easy path to eventual integration or promotion to shared services. 4COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 7. Heavy Burden on Developers 5COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 8. Heavy Burden on Developers • Find the right service 6COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 9. Heavy Burden on Developers • Find the right service • Negotiate data formats 7COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 10. Heavy Burden on Developers • Find the right service • Negotiate data formats • Point-to-point integrations: each one is different 8COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 11. Strained Ecosystem • Bloated code 9COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 12. Strained Ecosystem • Bloated code • Memory footprint 10COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 13. Strained Ecosystem • Bloated code • Memory footprint • High integration costs 11COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 14. Strained Ecosystem • Bloated code • Memory footprint • High integration costs • Slow delivery 12COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 15. Canonical Models: Promises and Challenges 13COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 16. A Modest Proposal • Define a common model for all data communicated between systems. • Common recommendation in one form or another ◦ Patterns of Enterprise Integration (Fowler) ◦ SOA Design Patterns (Erl) 14COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 17. Different Uses for Canonical Data Models: API Design ◦ SOA Governance: Enforce consistency with the canonical model (“canonical schema”) ◦ Tools: Compose message formats from canonical data models SDK Development ◦ Abstract physical format ◦ Optimize for performance and/or developer productivity Integration ◦ Transform messages to/from canonical format. ◦ Boundary translation to/from industry standards Analysis ◦ Analyzing data landscape, service landscape ◦ Compliance, internal audit, MDM, large-scale integration efforts. 15COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 18. Why is this so hard? Intrinsic Challenges ◦ Getting everyone to the table, getting to agreement ◦ Versioning, Change impact analysis, and lifecycle management Economic Alignment Challenges ◦ Service developers need to get it done ◦ Code-first frameworks promise low-cost to service developers Modeling Mismatch: Viewpoint ◦ What's the purpose of the model? ◦ What level of abstraction? What level of detail? ◦ How does it related to concrete representations? Modeling Mismatch: Language and Method ◦ ER, UML, OWL, etc. ◦ The attractive nuisance of XML Schema Result: confusion about what the canonical model is supposed to be. 16COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 19. The Pervasive Problem: Variability • One size fits none • Message representations vary by ◦ Level of detail ◦ Perspective ◦ Topology, Granularity ◦ Contextual constraints ◦ Metadata 17COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 20. Realization: Decoupling Models and Messages 18COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 21. Another Look at the Variability Problem • There’s a common theme (canon) underneath these variations. • Can we describe the theme and variations separately? • Can we model the variations as adaptations, augmentations of the theme? • There’s a name for that: Realization. 19COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 22. Realization: Property Subset 20COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. API requests or responses may only need a subset of properties defined in the canonical model. Realization model may specify a list of included properties.
  • 23. Realization: Perspective 21COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. Message and resource structures project different views from the same logical data model Canonical model should support bi-directional references. Realization model should allow embedded or linked representations.
  • 24. Realization: Metadata 22COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. Business Information Model Account ID Balance Margin Status Account Party ID Name Party 1 0..n Data Aspects · Deltas · Data Source · Data Security · Explicit Null Values ... Message Structure <party dataSource=“MSDB”> <partyId>123</partyId> <partyName xsi:nil=“true” nullValue=“Not Available” /> <accounts> <account dataSource=“A2” transType=“insert”> <accountId>XYZ</accountId> <balance xsi:nil=“true” isRestricted=“true” /> … </account> … </accounts> </party> APIs may need to augment essential data with descriptive metadata. Data aspects are cross-cutting concerns that may be woven together with canonical data as part of the interface realization.
  • 25. Realization: Contextual Constraints <=$10MM Asset Class = Bond 23COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. Trade Services may have specific constraints that are not intrinsic to the data definitions. Realization model may specify constraints on requests or responses. Constraints may take different forms: range, subtype, logical expression, etc.
  • 26. Canonical Modeling Reloaded • New understanding of the model vs. message: • Canonical data models describe business information at the conceptual level ◦ Semantically rich ◦ Technology independent • Realization models afford variability, with clear limits ◦ Bend the canonical model, don’t break it ◦ Realized representations must be recognizable as instances of the canonical model. • Some new terms: ◦ Interface Data Model: A realization model used to define data exchanged through an API. ◦ Resource Data Model: An interface data model for a RESTful (resource-oriented) API. 24COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 27. A Better Client Library 25COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 28. Today’s Client Library 26COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 29. How many ways from Sunday does this suck? 1. Canonical data model gets lost in the translation. 2. Awkward structures introduced by message format. 3. Annotations are specific to a single API, message format. 4. Not usable as business objects 5. Extra code to populate these DTOs, move data between them and internal representations. 6. High memory footprint 27COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. Just say no to DTO.
  • 30. Canonical Serializer No DTOs, no need to code transformations Single object graph serialized to multiple RDMs, message formats. Canonical classes/interfaces can be used as business objects. Flexibility: pluggable formats for canonical model, RDM, object graph and media type. 28COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 31. Canonical Serializer: Implementation What do we call a serializer that shoots representations out of a canon? Kaboom Serializer! https://github.com/modelsolv/Kaboom (Just a demo now, but feedback & contributions welcome.) 29COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 32. Scenario • TaxBlaster: new tax preparation app. • Integrates with e-filing service • Integrates with client billing service • Common data model, different views 30COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 33. TaxBlaster: Canonical Data Model 31COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. filingID : string jurisdiction : string currency : string year : date period : int grossIncome : decimal taxLiability : decimal TaxFiling taxpayerID : string lastName : string firstName : string otherNames : string* Person street 1 : string street2: string city : string stateOrProvince : string postalCode : string Address companyID : string companyName : string EIN : string form : string active : boolean Company employees employer 0..1 0..* taxpayer 1..1 0..* addresses
  • 34. Internal Metamodel Pluggable implementations: • CDM • RDM • Canonical Object Reader/Writer • Serializer 32COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED. name : string CanonicalDataType type : primitiveDataType CDMPrimitiveProperty CDMReferenceProperty name : string cardinality : Cardinality CDMProperty properties0..* inverseProperty targetDataType name : string ResourceDataModel type : primitiveDataType RDMPrimitiveProperty RDMReferenceProperty name : string cardinality : Cardinality RDMProperty includedProperties0..* linkRelation : string ReferenceLink ReferenceEmbed embeddedDataModel
  • 35. Recipe for a model-oriented API client ◦ A canonical modeling language ◦ Data available at runtime that conforms to the canonical model ◦ An API description facility that ◦ Realizes the canonical model as an Interface Data Model ◦ Described as formalized variations ◦ A runtime serializer/deserializer that ◦ Interprets the API model ◦ Serializes and deserializes between the the canonical object graph and the the realized message format. 33COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 36. Conclusion Canonical models are a way to capture organizational agreement on data definitions We need the right degree of coupling between the canonical model and API representations. We do this by identifying the kinds of variations that we need to support, and formalizing these in a realization mapping. Tooling can support realization modeling and apply it in client libraries, SDKs, middleware, etc. Potential benefits: better interoperability, lower integration cost, higher developer productivity. 34COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 37. Questions THANK YOU! 35COPYRIGHT © 2014, MODELSOLV, INC. | ALL RIGHTS RESERVED.
  • 38. Watch the video with slide synchronization on InfoQ.com! http://www.infoq.com/presentations/canonical- models-api-interop

×