Autonomous APIs (O’Reilly Software Architecture 2019)

Slide 1

Slide 1 text

goodapi.co Autonomous APIs The next chapter begins

Slide 2

Slide 2 text

goodapi.co supermodel.io

Slide 3

Slide 3 text

goodapi.co Pleasure to meet you! Networking encouraged Let’s spend a couple of minutes introducing ourselves to the people next to us, say what company or organization you are from, and what you are looking to learn from this session.

Slide 4

Slide 4 text

goodapi.co Autonomous Cars source: https://www.bmw.com/en/automotive-life/autonomous-driving.html

Slide 5

Slide 5 text

goodapi.co Autonomous APIs?

Slide 6

Slide 6 text

goodapi.co How can we have autonomous cars but not autonomous APIs?

Slide 7

Slide 7 text

goodapi.co API styles over time REST vs. GraphQL @zdne

Slide 8

Slide 8 text

goodapi.co Interest over time

Slide 9

Slide 9 text

goodapi.co BREAKTHROUGH ANNOUNCEMENT Paradigm Shift 1. CUSTOMER-SPECIFIC APIS 2. GENERIC APIS 3. HARMONIZED APIS 4. AUTONOMOUS APIS one-to-many one-to-one many-to-many machine-to-machine l C P l C P l C l C l C P l C l C P P l C P l C l C P P 3P

Slide 10

Slide 10 text

goodapi.co goodapi.co EVERY CHAPTER HAS ITS API ARCHITECTURAL STYLE–API – PARADIGM

Slide 11

Slide 11 text

goodapi.co Customer-speciﬁc APIs • Large organizations embracing IT • years 1990-2000s • SOAP, EDI, FTP & ESB • one-to-one, point-to-point 1. CUSTOMER-SPECIFIC APIS one-to-one l C P

Slide 12

Slide 12 text

goodapi.co Problems • API providers face issues with size complexity of point to point integrations and the ESB “failure” • New API consumers ﬁnd the APIs too complex and cumbersome to use • New API consumers often ignored or misunderstood, and over/under served by SOAP API providers 1. CUSTOMER-SPECIFIC APIS one-to-one l C P

Slide 13

Slide 13 text

goodapi.co Generic APIs one-to-many: many mid- or small- size customers one-to-one: few large established customers l C P l C P l C l C

Slide 14

Slide 14 text

goodapi.co Generic APIs • Ubiquitous internet & software development • years 2005-2019+ • so-called-REST, later also GraphQL • one-to-many 2. GENERIC APIS one-to-many l C P l C l C

Slide 15

Slide 15 text

goodapi.co Problems • API providers are facing complexity issues from increasing number of own APIs, client integrations, server & client deployments and api versions • New consumers ﬁnd complex and costly to integrate and maintain the integrations with multiple diﬀerent apis • API consumers often ignored or misunderstood, and over/under served by Fragmented, siloed APIs and its providers 2. GENERIC APIS one-to-many l C P l C l C

Slide 16

Slide 16 text

goodapi.co Harmonized APIs many-to-many: clients consuming multiple APIs one-to-many: many mid- or small- size customers l C P l C l C l C P l C l C P P 3P

Slide 17

Slide 17 text

goodapi.co API Landscapes APIs are no longer in silos goodapi.co

Slide 18

Slide 18 text

goodapi.co HARMONIZED APIS one-to-many Organizations landscapes

Slide 19

Slide 19 text

goodapi.co HARMONIZED APIS one-to-many Organizations landscapes

Slide 20

Slide 20 text

goodapi.co HARMONIZED APIS B C D . . . If I am building an e-shop do I want to integrate with 400 logistics providers? e-shop Domain Landscapes

Slide 21

Slide 21 text

goodapi.co Harmonized APIs Examples

Slide 22

Slide 22 text

goodapi.co –Radek Novotny; CEO & founder MyStay “There are few integrators for hospitality APIs consolidating as many as 40 PMS but they are either not-duplex or slow in reactions” Challenge: Integration with many property management systems (PMS)

Slide 23

Slide 23 text

goodapi.co Accommoda tion B Accommoda tion C Accommoda tion D Accommoda tion E Existing Customer Existing Customer Existing Customer 3rd party New Type of Customer New Type of Customer New Type of Customer Logistics Metapack integrates over 400 carriers Over 100 3rd Party vendors

Slide 24

Slide 24 text

goodapi.co Client Client Client Client Client Client Hospitality & Travel Accommoda tion B Accommoda tion C Accommoda tion D Accommoda tion E

Slide 25

Slide 25 text

Slide 26

Slide 26 text

goodapi.co Existing Customer Existing Customer 3rd party New Type of Customer New Type of Customer New Type of Customer Provider Provider Provider Uniform interface Uniform Interface to incumbents B C D e-shop 3rd party

Slide 27

Slide 27 text

goodapi.co goodapi.co How are incumbents loosing contact with their customers

Slide 28

Slide 28 text

goodapi.co Incumbent Existing Customer Existing Customer Existing Customer Facilitator New Type of Customer Ignored at the start Second wave of API customers Facilitator–Disruptor A 3rd party between API customer and API provider. Unrecognized or ignored it is either an external provider or shadow IT. Second Wave

Slide 29

Slide 29 text

goodapi.co Incumbent Existing Customer Existing Customer Existing Customer 3rd party New Type of Customer New Type of Customer New Type of Customer Second wave of API consumers Second Wave

Slide 30

Slide 30 text

goodapi.co Incumbent Existing Customer Existing Customer Existing Customer 3rd party New Type of Customer New Type of Customer New Type of Customer First chapter customers moving to 3rd Party

Slide 31

Slide 31 text

goodapi.co Unable to adapt to the incumbents are loosing their positions to disruptors

Slide 32

Slide 32 text

goodapi.co The fear of becoming commodity, lack of knowledge lack of understanding and inability to innovate leads to isolation and leaves incumbents once again vulnerable to third parties

Slide 33

Slide 33 text

goodapi.co Website A Client Client Client Client Client Client Are your customers really yours? Website B Website C Website D Website E

Slide 34

Slide 34 text

goodapi.co How to integrate with thousands of IoT devices from diﬀerent vendors deployed in diﬀerent environments?

Slide 35

Slide 35 text

goodapi.co IOT

Slide 36

Slide 36 text

goodapi.co goodapi.co Multiple Domains The situation is even worse when you consider…

Slide 37

Slide 37 text

goodapi.co Accommoda tion B Accommoda tion C Accommoda tion D Accommoda tion E API Consumer APIs Accommoda tion B Accommoda tion E consuming multiple APIs Cross-domain

Slide 38

Slide 38 text

goodapi.co Accommoda tion B Accommoda tion C Accommoda tion D Accommoda tion E Customer 3rd party consuming multiple APIs Cross-domain

Slide 39

Slide 39 text

goodapi.co Universe of capabilities This is what Amazon (Alexa skills), Google (Home skills) & VIV (Samsung) are doing. Database of knowledge and services with uniform interface

Slide 40

Slide 40 text

goodapi.co Harmonized APIs • Clients consuming multiple APIs • Micro-services, forming API landscapes • Year 2017+ • Complexity of consuming multiple diﬀerent APIs is tackled by standardization, design governance to achieve consistency • Harmonization is also often done with “wrapper” APIs 3. HARMONIZED APIS many-to-many l C P l C l C P P 3P

Slide 41

Slide 41 text

goodapi.co Problems • Harmonized APIs providers are facing complexity issues trying to normalize, govern or maintaining many integrations APIs manually • Harmonization, standardization & governance complexity tackled by automation • Complexity external API consumers are facing when consuming multiple domain or cross-domain APIs is still left unchecked 3. HARMONIZED APIS many-to-many l C P l C l C P P 3P

Slide 42

Slide 42 text

goodapi.co Complexity

Slide 43

Slide 43 text

goodapi.co COMPLEXITY Task-structure Complexity How difficult it is understand how to perform a task in a distributed system Unpredictability How difficult is to predict effect of an action in distributed system, amount of entropy Size Complexity Size of the system implies cognitive complexity, large number of concepts and the knowledge required Chaotic Complexity Small variations in a certain part of the system can have large effects on overall system behavior Algorithmic Complexity Both traditional algorithm complexity in the term of time and space and cognitive complexity of understanding algorithm

Slide 44

Slide 44 text

goodapi.co COMPLEXITY API Designs x Versions x Deployment Hosts x Clients x Client Deployments IS HIGHER THAN TWO You are likely to face complexity using, maintaining and evolving your API 130 APIs 3 x 6 (environments x availability zones) 70 versions 1500 integrations own deployments: 3 x 6 on-premise deployments: 1000 apps: 3 000 000 IoT: ????? = 1,10565×10^9 IF THE NUMBER OF

Slide 45

Slide 45 text

goodapi.co Cost of Change 6,1% chance of breaking change every day (java library)

Slide 46

Slide 46 text

goodapi.co Solutions

Slide 47

Slide 47 text

goodapi.co SOLUTIONS TO COMPLEXITY 1. Hire more people 2. Standardization 3. Automation 4. Autonomy of the components

Slide 48

Slide 48 text

goodapi.co Solutions to complexity 1. Hire More People Mechanical turks, eyeballing documentation for changes in design, ﬁxing clients and implementations accordingly. CUSTOMER-SPECIFIC & GENERIC APIS ROLE OF HUMANS IN APIS

Slide 49

Slide 49 text

goodapi.co MACHINE EXPOSES INTERFACE ANOTHER MACHINE LEARNS & USES INTERFACE MACHINES MEET OVER THE NETWORK discovery What we think API is Hire more people

Slide 50

Slide 50 text

goodapi.co Hire more people Reality MACHINE EXPOSES INTERFACE ANOTHER HUMAN READS DOCUMENTATION HUMAN WRITES DOCUMENTATION ANOTHER MACHINE IS TAUGHT TO USE INTERFACE HUMANS MEET discovery

Slide 51

Slide 51 text

goodapi.co Hire more people Reality HUMANS INSIDE VS. • time and money spent • not scaling • chance of misinterpretation • error-prone

Slide 52

Slide 52 text

goodapi.co SOLUTIONS TO COMPLEXITY 2. Standardization HARMONIZED APIS API DESIGN, LIFECYCLE & DEVELOPMENT STANDARDIZATION

Slide 53

Slide 53 text

goodapi.co Standardization Product consistency

Slide 54

Slide 54 text

goodapi.co Standardization API Guidelines & design checks

Slide 55

Slide 55 text

goodapi.co 3. Automation AUTOMATED HARMONIZED APIS Solutions to complexity AUTOMATED CONTRACT-DRIVEN API LIFECYCLE

Slide 56

Slide 56 text

goodapi.co Automation INTERFACE ACTUALLY EXPOSED INTERFACE DOCUMENTED INTERFACED USED are they the same? are they the same? are they the same? Keeping things in check is hard

Slide 57

Slide 57 text

goodapi.co Contract-driven Automation

Slide 58

Slide 58 text

goodapi.co https://goodapi.co/api-lifecycle Automation Entire lifecycle

Slide 59

Slide 59 text

goodapi.co Tools are our limits

Slide 60

Slide 60 text

goodapi.co Tools are our limits • Existing investments (tools, infrastructure & processes) • Bloated API Management Tools • Missing automation • Lifecycle orchestration • Limiting API description formats • Data modeling from the past • Missing tooling for structured data

Slide 61

Slide 61 text

goodapi.co 4. Autonomy AUTONOMOUS APIS AUTONOMY IS THE SOLUTION TO THE DIFFICULTY OF MANAGING MANY COMPONENTS CENTRALLY Components autonomy in an API Landscape reduces the complexity, enables scaling, and promotes the service commoditization. Solutions to complexity

Slide 62

Slide 62 text

goodapi.co Autonomy “Autonomy: freedom from external control or inﬂuence; independence; sovereignty in making decisions and changes.” –New Oxford American Dictionary

Slide 63

Slide 63 text

goodapi.co Attacking the complexity with autonomy Self-driving Clients Clients can self- navigate the API landscape, perform self-conﬁguration, self-repair, self- optimization and make choices at various decisions points automatically High-level, declarative programming Reducing the cognitive algorithmic complexity, decoupling from components implementation, programming for domain, not service Automated, contract-driven API lifecycle Handling API provider complexity by keeping, versions, implementations and deployments in check Hierarchical and context-bound knowledge Divide and conquer size complexity with domain deﬁnitions and bounded contexts. Reusable representation of domain knowledge– ontologies– published language

Slide 64

Slide 64 text

goodapi.co Autonomous APIs • Machine-to-machine APIs, self-driving, no human intervention, cross-domain landscapes • Rise of IoT & AI • Year 2020+ 4. AUTONOMOUS APIS machine-to-machine l C P l C l C P P

Slide 65

Slide 65 text

goodapi.co Autonomous APIs 1. Consuming more than one API 2. Cross-domain 3. Demanding reduction of complexity 4. Self-driving in API Landscape 5. Autonomous-decoupled from particular API provider NEXT-GEN CONSUMERS

Slide 66

Slide 66 text

goodapi.co Navigation through autonomic units Countries, Regions, Cities, City Quarters are autonomous regions but when you are driving from A to B you need to navigate through their roads A B Design-time & Runtime Navigation You need both to follow a map and traﬃc signs to navigate eﬀectively Autonomous APIs Navigate safely in API landscape

Slide 67

Slide 67 text

goodapi.co 5 Levels of Autonomy goodapi.co

Slide 68

Slide 68 text

goodapi.co Levels of autonomy –Autonomous Client “The level of autonomy is the ability to safely navigate in the API landscape (where the constraints are time and price)”

Slide 69

Slide 69 text

goodapi.co Levels of Autonomy Autonomy Autonomous APIs Brittle System Documented Brittle System Automated System Decoupled Automated System Autonomous System 1 2 3 4 5

Slide 70

Slide 70 text

goodapi.co Level 1: Brittle system • Tightly coupled components • No semantics, interface or lifecycle data • Pros • Time to delivery for point to point integrations when complexity is low • Cons • Everything breaks when something changes • Not scaling with growing complexity Level 1

Slide 71

Slide 71 text

goodapi.co Level 2: Documented Brittle System • Tightly coupled components • Interface metadata available • Human only-semantics metadata available • No lifecycle metadata (is the documentation documenting the interface implementation?) • Pros • Possible API productization • Reusability • Cons • Lock on changes, unable to evolve Level 2

Slide 72

Slide 72 text

goodapi.co Level 3: Automated system • Mostly tightly coupled components • Metadata are veriﬁed, valid and reliable • Metadata are human or machine readable • Advertisement of the interface, semantics and lifecycle metadata • Client subscription to future changes • Pros • Explicit understanding of price and risk of making changes in the API landscape • Quality Control • Cons • Advanced mindset change involving many people • Cultural denial, hard to get buy-in Level 3

Slide 73

Slide 73 text

goodapi.co Level 4: Decoupled automated system • Uniform Interface • Decoupled components • Evolvability of the components in their respective environments • Share understanding-metadata at RUNTIME • Pros • Harmonized within the system • Reducing price and risk of making changes (by design) • Cons • No machine autonomy • Diﬃcult taking everything into account, prone to chaotic & size complexity Level 4

Slide 74

Slide 74 text

goodapi.co Building blocks Level 4 Decoupled Automated System 4

Slide 75

Slide 75 text

goodapi.co Building block 1/3 Uniform Interface A consistent, predictable way to query data and exercise actions regardless of the service provider

Slide 76

Slide 76 text

goodapi.co Uniform interface 1957 2018 Engineering principle of generality

Slide 77

Slide 77 text

goodapi.co Engineering Principle of Generality

Slide 78

Slide 78 text

goodapi.co Uniform interface Engineering principle of generality Existing Customer Existing Customer 3rd party New Type of Customer New Type of Customer New Type of Customer Provider Provider Provider Uniform Interface to incumbents B C D e-shop 3rd party

Slide 79

Slide 79 text

goodapi.co Beneﬁts of UI Engineering principle of generality • Simpliﬁes architecture • Improves visibility of interactions • Decouple components, enables evolution • Improves interoperability, reduces cost of integration • Reduces costs and time to market • Enables autonomous service discovery • ENABLES FOR GENERAL AI • Automatic clients • Autonomous clients

Slide 80

Slide 80 text

goodapi.co Cross-domain Uniform interface Accommoda tion B Accommoda tion C Accommoda tion D Accommoda tion E Customer Customer Customer 3rd party Customer Customer Customer Uniform Interface

Slide 81

Slide 81 text

goodapi.co Path To Uniform interface 1. Apply Modern Architectural Styles (REST) and Linked Data (JSON-LD) 2. “Wrapper APIs”, build or leave it up to 3rd Party Vendors (Metapack, Amazon, Google..) to become the intermediaries to the universe 3. Autonomous APIs (coming later)

Slide 82

Slide 82 text

goodapi.co Do you want to provide an uniform interface or leave it to third-party vendor to do it? Client Client Client Client Client Client Provider Provider Provider Client Client Client Linked Data & Architecural Style Client Client Client Provider Provider Provider - OR - Building your next API

Slide 83

Slide 83 text

goodapi.co Building block 2/3 Decoupled components A component does not duplicate or rely on any other component internal logic neither it relies on any other component information shared ahead of time Abstraction Layer Comp-A Comp-B

Slide 84

Slide 84 text

goodapi.co API TASKS IS TO ABSTRACT AWAY THE INTERNALS OF SERVICE COMPONENT

Slide 85

Slide 85 text

goodapi.co DEGRADED EFFICIENCY UI Transformation Comp-A Comp-B Transformation The Tradeoﬀ of Decoupled components and Uniform interface

Slide 86

Slide 86 text

goodapi.co Building block 3/3 Understanding shared at runtime • Available HATEOAS state transitions • HAL, Siren, RESTful JSON • Non-authoritative parameter validations • JSON Schema, Code on Demand • API Description - map • OpenAPI Speciﬁcation, API Blueprint … • GraphQL Schema

Slide 87

Slide 87 text

goodapi.co Level 5: Autonomous System • Self driving clients • Landscape discovery • Machine understanding • Vocabulary not data structure • Declarative programming • Autonomy of the components • Leveraging learned data from simulation for infrastructure • Pros • Higher level of abstraction • Implicit harmonization • Full autonomy of components • Independent evolution • Cons • Cognitive (Algorithmic) Complexity • Demanding on computational power • Higher level of abstraction Level 5

Slide 88

Slide 88 text

goodapi.co Building blocks Level 5 Autononomous System 5

Slide 89

Slide 89 text

goodapi.co Building block 1/3 Declarative programming // HTTP Request GET /v1/balance HTTP/1.1 Host: api.stripe.com Authorization: Basic c2tfdGVzdF9CUW9raWtKT3ZCaUkySGxXZ0g0b2xmUTI // Imperative, hard-coded fetch(‘http://api.stripe.com/v1/balance‘, { ‘Authorization': 'Basic ' + base64.encode(username + ":" + password) } ).then.. // Declarative, decoupled if (hasAffordance(‘retrieve-balance’) { exerciseAffordance(‘retrieve-balance’).then.. }

Slide 90

Slide 90 text

goodapi.co Building block 2/3 Machine understanding Protocol Message Application HTTP Protocol Semantics Message Format Semantics (e.g. HAL) Application Domain Semantics (e.g. Hospitality domain) Program for vocabulary not data structure

Slide 91

Slide 91 text

goodapi.co Data models & vocabularies, ontologies

Slide 92

Slide 92 text

goodapi.co Canonical data model is anti-pattern goodapi.co in modern systems architecture

Slide 93

Slide 93 text

goodapi.co Domain-Driven Design Divide and conquer complexity by bounded context and context mapping images from Domain-Driven-Distilled

Slide 94

Slide 94 text

goodapi.co Context Mapping images from Domain-Driven-Distilled

Slide 95

Slide 95 text

goodapi.co Linked data - semantics for Humans & machines

Slide 96

Slide 96 text

goodapi.co –Autonomous Client “I am looking for a person, but I see a user, should I treat it as person?”

Slide 97

Slide 97 text

goodapi.co Shared vocabularies

Slide 98

Slide 98 text

goodapi.co https://supermodel.io

Slide 99

Slide 99 text

goodapi.co Program for vocabulary NOT Data Structure

Slide 100

Slide 100 text

goodapi.co Program for Vocabulary // Programming for data structure display todo.title // Programming for vocabulary if (todo.has('title')) { display todo(‘title') }

Slide 101

Slide 101 text

goodapi.co JSON-LD (linked data) { "@context": "https://json-ld.org/contexts/person.jsonld", "@id": "http://dbpedia.org/resource/John_Lennon", "name": "John Lennon", "born": "1940-10-09", "spouse": "http://dbpedia.org/resource/Cynthia_Lennon" } https://json-ld.org

Slide 102

Slide 102 text

goodapi.co Hydra JSON-LD meets HATEOAS http://www.markus-lanthaler.com/hydra/console/

Slide 103

Slide 103 text

goodapi.co ALPS Proﬁle Application-Level Proﬁle Semantics (ALPS) http://alps.io

Slide 104

Slide 104 text

goodapi.co Building block 3/3 Autonomous service discovery MACHINE EXPOSES INTERFACE ANOTHER MACHINE LEARNS & USES INTERFACE MACHINES MEET OVER THE NETWORK discovery

Slide 105

Slide 105 text

goodapi.co Yahoos of API World Global Landscapes • Rapid API • Any API • APIS.json • Hitch HQ (acquired) • GraphQL Hub Internal Landscapes • Internal Developer Portals • API Repositories (Apiary, SwaggerHub) Human-only, hand picked

Slide 106

Slide 106 text

goodapi.co Micro service discovery • Netﬂix Zulu / Eureka • Apache / Kafka / Zookeper • Hashicorp / Consul • Linkerd No API Landscape Metadata discovery Services

Slide 107

Slide 107 text

goodapi.co But these are not enough We need publish-subscribe model for API Landscape and API discovery

Slide 108

Slide 108 text

goodapi.co Autonomous service discovery “Registry, look for a service that knows weather in Paris.” “Registry, look for a service that can fulfill the shipment of 6 pallets from Prague to Paris.” “Registry, look for a service that can play every movie by the director of movie Avatar.”

Slide 109

Slide 109 text

goodapi.co Autonomous service discovery // Using a terms from schema.org dictionary, // find services that offers WeatherForecast. services = apiLandscape.find(WeatherForecast, { vocabulary: http:// schema.org}) // Query a service for WeatherForecast at GeoCoordinates. forecast = service.retrieve(WeatherForecast, { GeoCoordinates: … }) // Display Temperature display forecast(Temperature)

Slide 110

Slide 110 text

goodapi.co Building blocks of Autonomous APIs Level 5 Autonomous System Level 4 Decoupled Automated System • Declarative programming • Machine understanding • Autonomous discovery 4 3 • Uniform Interface • Decoupled components • Autonomous navigation

Slide 111

Slide 111 text

goodapi.co goodapi.co Early four-engine jets required ﬂight engineers. Later four-engine jets were designed with suﬃcient automation to eliminate the position. 747 FLIGHT ENGINEERS ...this will also happen in the world of APIs.

Slide 112

Slide 112 text

goodapi.co

Slide 113

Slide 113 text

goodapi.co API Chapters one-to-many one-to-one many-to-many machine-to-machine Drivers behind the changes API CONSUMERS EXPECTATIONS COMPLEXITY task-structure unpredictability chaotic size algorithmic + GROWING # OF API CONSUMERS + INCREASING DEMAND EVOLVING DEMAND INCREASING PROBLEMS

Slide 114

Slide 114 text

goodapi.co 1. CUSTOMER-SPECIFIC APIS 2. GENERIC APIS 3. HARMONIZED APIS 4. AUTONOMOUS APIS one-to-many one-to-one many-to-many machine-to-machine API Chapters

Slide 115

Slide 115 text

goodapi.co Digital wholesale presence & service commoditization “Look for a service that can fulfill the shipment of 6 pallets from Prague to Paris under 100 EUR.” “Look for a service that provides information about adidas stan smith” “Is there an air condition service in my landscape?” “Look for a service that has gs1:Offer where gs1:itemOffered gs1:gpcCategoryCode is MILK.” “The level of autonomy is the ability to safely navigate in the API landscape (where the constraints are time and price)”

Slide 116

Slide 116 text

superface.io Commoditization CUSTOMER SPECIFIC APIS (SOAP) GENERIC APIS (SO-CALLED-REST) HARMONIZED APIS AUTONOMOUS APIS HARMONIZED APIS (AUTOMATED) Graph by Simon Wardley, “How commodity is something?”

Slide 117

Slide 117 text

goodapi.co

Slide 118

Slide 118 text

IMAGES BY UNSPLASH.COM ICONS BY MARTINFOWLER.COM

Slide 119

Slide 119 text

goodapi.co What would MyStay do? • Deﬁne Hospitality Domain • Deﬁne Hotel Room subdomain • Train MyStay Mobile app for the subdomain if (room.roomService.available) display room.roomService.offer if (room.ac.available) display acControls • Deploy mobile clients • Provide IoT integration components-hubs for hotels