The Emissary Design Pattern and RIAs Rich Internet

The Emissary Design Pattern and RIAs (Rich Internet Applications) Pat Helland Partner Architect Microsoft Corporation

Outline • • Introduction The Emissary Design Pattern RIAs – Rich Internet Applications Emissaries and the Boundary to the Trust Sphere • Coding for the Boundary • Conclusion Slide 2

Disclaimer! These are just ideas! --------------They will not necessarily make it into products!!! Besides… those of you who’ve known me for a while know I’m nuts!!! Slide 3

Takeaways • • Emissaries help interact with Servers or Services • They work outside the trust sphere but understand lots about the trusted app • They present data to the user and accept “humble” requests for work • Manage a (potentially) long-running relationship between user and app RIAs run in the browser and offer rich User Interfaces • User experience is like a client machine but installation is browser-like • Identity of app defined by URL / App-Domain • Sandboxed security (can’t break browsing machine) • Application navigation patterns closer to browser than classic smart client Prescriptive Emissaries drive separation of user and server concerns • Focus on the flow of data and work to / from the user • Browser emphasizes User Experience of seeing data and doing work • Server implements the trusted business logic and manages internal application data the business focus Prescriptive Emissaries allow some shared code across browser and server • The server has rules and constraints – enforced within the trust boundary • The emissary (browser) helps ensure valid work is submitted Slide 4

1999: The Old “Fiefdoms and Emissaries” Talk • Fiefdoms • Independent code and data • A separate trust sphere • Separate transaction boundary • Today, called “Services” • Emissaries • Code designed specially for working with one fiefdom • Not trusted! • Lives to help prepare requests for the fiefdom Please, kindly consider my humble request…. User Emissary Fiefdom Slide 5

Trust Spheres and Emissaries – Some Examples Today • Amazon • Browsing, looking at the catalog, shopping cart work… • Everything you do before pushing “Submit” • After submit, recheck, verify, and process with trust! • Mortgage Broker • Not trusted by the bank… helps fill out the forms • Usually ensures the loan is accepted (knows the rules) • Everything is verified when the loan packet hits bank Slide 6

Architectural Evolution – Shedding No Tiers… Service RIA - Single Computer - All-in-One Trust - Single Database - Multiple Clients - All-in-One Trust - 1 DB - Many Clients - Mid-Tier Servers - One Trust - Distrust! - Message Interface - Private Implementation - 1 Service? - Client / Browser Hybrid - Easy & Safe Install Mainframe Two-Tier N-Tier SOA Saa. S + RIA Server Work Moving to the Cloud (Software as a Service) Client Work Moving to RIA (Rich Internet Applications) Slide 7

The Emergence of RIA • Application install and trust are HUGE issues! • HTML is boring but safe! • AJAX and Java. Script add some punch to the boredom • Most people would rather be bored than terrified… • Requirements for RIA • Safe, easy, and fast install • Safe, safe, and safe • Cannot screw up my machine! • Web look and feel • URLs, deep-linking, back-button, and more • Application identity based on URL • Per-application, per-user isolated state Slide 8

Using Emissaries in a RIA Framework • Emissaries use data: • Reference data is published by the server/service • Used to prepare messages to the server/service • For example, product-catalog and price-list • Per-user state is accumulated during ongoing work • For example, entries in the shopping cart • Emissaries submit work to the server/service • This is the packaged up “user’s intent” • Emissaries interpret the server/service’s messages • Where are we in the ongoing long-running work? • Emissaries are the user’s friend in dealing with the app • They know the app and what to expect • They help the user navigate working with the application • RIA environments are natural for emissaries • App-centric but need not leave a lasting footprint on the client! Slide 9

Emissaries versus “Classic” SOA Service Schema “Classic” SOA Client Service Schema What is exposed? ? Chattier relationship! Other Service Emissary • “Classic SOA” is about the message boundary • The XML/SOAP definition is specified • The calling application must comply with the definition • Lots of attention to adaptive relationships • Extensibility and loose-coupling of schema are all the rage • Emissaries: Code with deep understanding running outside the trust • Written by folks with deep knowledge of the specific service • Written to run without trust Client Emissaries and SOA Slide 10

Outline • • Introduction The Emissary Design Pattern RIAs – Rich Internet Applications Emissaries and the Boundary to the Trust Sphere • Coding for the Boundary • Conclusion Slide 11

The Trusted “Service” or “Server” • • Essential to this model is the trusted server or service • An application with its own code and data • Published application identity as a URL It is not essential to distinguish between one or many computers implementing the service • It would be fine to implement this as a single server • From here forward, we will refer to it as a service • This is classic SOA as well as ASP. NET Service Schema Indistinguishable behavior (except, perhaps, for scalability) Implementing the “Service” as a set of machines Service Schema Implementing the “Service” as a single machines Slide 12

The Request for Service • An important aspect of “trust” and “encapsulation” is the request for service • An incoming message is received, inspected, and processed • Only if the request is well-formed and good will it be processed Trust and encapsulation are about ensuring the messages meet the business rules = = = OK… I’ll do that for you! Different services will have different business rules… Service Slide 13

The Evolving Workflow of Interaction • • It’s not just request / response! • Many messages may flow • Not directly one for one There may be a complex workflow of messages • Messages may cross paths The messages may be asynchronous • Offline interactions add confusion The messages may need to be viewed as a workflow • Complex business rules! Correlating the messages with each workflow is one challenge. Must correlate by 2 -party communication Service Slide 14

Reference Data • Reference data is published by the service for use in messages • Incoming (and outgoing) messages may include reference data • Examples: Product catalog, price list, insurance rates, etc. Emissary Product Catalog: Tuesday SKU# 1 SKU# 3 SKU# 2 SKU# 4 Reference Data Other Service Schema Notice the use of reference data in the messages! Emissary Client Emissaries and Their Use of Reference Data Slide 15

Publication of Reference Data to the Emissary • The service is responsible for periodically publishing reference data • It is up to the service how often it wants to publish • It is up to the service how up-to-date the reference data must be in interacting with the emissary Tuesday’s price list is only valid on Tuesday! Not the best behavior at 11: 59 PM Tuesday… • May be push or pull to publish • Somehow the service makes the reference data available • Somehow the emissary finds it to use external to the service • Usually, the reference data is current enough to be useful Slide 16

Explicit or Implicit Versioning of Reference Data Sometimes, explicit versions are used to manage reference data The work says: “Version: XYZ” Mail-order catalog The values used are compared against those in version XYZ Phone operator asks for catalog code then knows the version! Sometimes, implicit versions are used to manage reference data Has that price been valid sometime in the last 24 hours? ? If so, accept it… The service defines the rules for using the reference data Does the message need to explicitly list the version of the reference data? Slide 17

Using Reference Data within the Workflow • Incoming messages can have information from reference data • Used to describe the desired work • For example SKU-# or Medical-Treatment-Code • Outgoing messages can have information from reference data • Used to describe the desired work • For example SKU-# or Medical-Treatment-Code Product Catalog: Tuesday SKU# 1 SKU# 3 SKU# 2 SKU# 4 Reference Data Service Slide 18

Consider Paper Forms… • Paper forms (with copies) were used for years • You fill out part one • Keep the pink copy and submit to HR • HR fills out part two, HR keeps the blue copy and sends to your boss… Part 1 Part 2 Part 3 … … The workflow is represented in the data filled out in the parts of the form Information is appended to the form as parts are filled out Slide 19

Modeling the Workflow on Paper Forms • What if we map the messages between the Service and the Emissary to the “Paper Form” model? • Need to (sometimes) allow the “Parts” of the form to be filled out of order Part 3 Part 2 Part 1 Part 2 Part 3 Service … … Slide 20

Activities: Append-Only Shared-Data Interactions • Consider the emissary-to-service interactions • The emissary tells the service some stuff… • The service tells the emissary some stuff… • This interaction is about a (potentially long-running) business operation • The state is the dynamic updates to the shared data The activity state is EXACTLY like the paper form Consider a “one-at-a-time” usage pattern Write a new part… tear off (and file) the back copy… send the form… Consider a concurrent usage pattern Different parts of the form arrive asynchronously A richer, more complex, manifestation of the paper form Slide 21

Progression and Retirement of Activities • Activities have a lifetime and they age through it • Think of advancing through the parts of the form • When the work is done, the form is filled out • Sometimes, forms (activities) can have variable length parts (similar to “Line-Items” in a PO) • When the work completes, the activity “retires” Retired “activities” become read-only and referenced less and less often over time Slide 22

Outline • • Introduction The Emissary Design Pattern RIAs – Rich Internet Applications Emissaries and the Boundary to the Trust Sphere • Coding for the Boundary • Conclusion Slide 23

Clients HTML AJAX RIA Full Trust Safe and Sane Heavy Weight Install No Install Limited Install Richer Java Experience Rich and Vibrant UI (w/ Controls) Limited Experience Lots of Local Storage No Local Storage Sandboxed and Limited (? ) Local Storage Asynchronous Server Calls Possible Synchronous Server Calls Only Asynchronous Server Calls Possible Smart Client HTML + AJAX RIA Slide 24

What’s a RIA App? What’s This RIA Crap? • RIA apps blend browser and client models: • Rich UI experience • SAFE and (hopefully) lightweight install • Sandboxed Storage • Many new issues to define: • Browser based app-identity model • Hybrid browser and client mode for UI, navigation, focus, back-button and more • What state is per-user but cross-machine? • What state is per-user but cross-app? What Does It Mean to Have “State in the Cloud? ? ” Slide 25

The State in the Cloud Application State Separated from the Machine Per-User Per-App State Safety and Sand. Boxing Controlled and Safe Sharing across Apps Controlled and Safe Sharing across Users Slide 26

Browser-Based Security (Asymmetry) • SSL gives the client confidence in the server’s identity • Public-key technology plus certificate authorities I know (via SSL + CA) that I am talking to www. Web. Site. Com Who the Hell are you, mister browser? ? ? Web Site www. Web. Site. Com • The web site has to implement its own security to authenticate the browser and / or user • Many different schemes are in use… Slide 27

Trust, Sandboxing, RIA, and Sharing • Sandboxing is how Silverlight contains data safely • Data may not cross boundaries… • How do we share across apps? • The sandboxing disallows it! • How do we share across users? Same User Same App Same Machine • How do we allow users to access their state from different machines? Slide 28

Navigation, UI, Focus, and Back-Buttons • The client has a model for UI • It has notions of UI-focus, input of characters, clicking on buttons and much more • The mechanisms for navigation a classic rich-client application are varied • Browsers have simple (but powerful) notions for these • Back-buttons, link traversal, and more are different • How can we combine these worlds? • We need the richness of the classic client • We need the linking of the browser model • The Silverlight app is defined to reside within a single page… • Does the back button leave the app to another page? • What does the back-button mean? ? Slide 29

Deep-Linking and the RIA Experience • Deep-Linking is the use of a URL to enter the app http: //www. amazon. com/Essential-Silverlight-Up. Date/dp/0596519982/ref=pd_bbs_sr_1? ie=UTF 8&s=books&qid =1212794176&sr=1 -1 Will give you: What Deep-Linking Navigation will you get with your RIA solution? ? There are challenges with this!! Slide 30

Deep-Linking and State Management • Suppose there is state on the RIA client: • We have accumulated some stuff as we’ve worked • It is stored in the sandboxed isolated RIA storage • Can we generate a deep link that includes that state? • Do we want to? ? • What if the state is advanced by the RIA client after the deep link is generated? ? • Do we need deep links that reference the ongoing work including potential changes after the deep link is made? • What are the semantics of such a deep link? Slide 31

Deep-Linking and Security/Privacy • If I generate a deep link and hand it to you can it include my private information with you start the app? • How do we think about the limitations of the state? • If I’m authorized and then generate a deep link, how much authority is transferred by me giving you a link? • Can you see what I can see? • Can you do what I can do? • What is the meaning of a deep link to unauthorized information or partially performed work? The way we think about partial work, location, and authorization may need rethinking! Slide 32

Outline • • Introduction The Emissary Design Pattern RIAs – Rich Internet Applications Emissaries and the Boundary to the Trust Sphere • Coding for the Boundary • Conclusion Slide 33

Bounding Trust via Encapsulation • Services only do limited things for their partners • This is how they bound their trust • Encapsulation is about bounding trust • Business logic ensures only the desired operations happen • No changes to the data occur except through locally controlled business logic! Services encapsulate by only exposing business operations to their partners This limits their risk to that work only! 34 Service Things I’ll Do for Outsiders • Deposit • Withdrawal • Transfer • Account Balance Check Slide 34

Encapsulating Both Change and Reads • Encapsulating change • Ensures integrity of the service’s work • Ensures integrity of the service’s data • Encapsulating exported data for read • Ensures privacy by controlling what’s exported • Allows planning for loose coupling and expirations • E. G. Wednesday’s price-list Sanitized Data for Export Data Exported Data Private Internal Data Business Request Service Slide 35

Shared Data: Reference Data • Reference Data is shared across the service and it emissaries • Typically, it is pushed out as versions • Periodically, new updates are published Product Catalog: Monday SKU# 1 SKU# 3 SKU# 2 SKU# 4 Reference Data Product Catalog: Tuesday SKU# 1 SKU# 3 SKU# 2 SKU# 4 Service Reference Data Slide 36

Shared Data: the Paper Form Model • If the service and the emissary use different parts of the “paper form” model, then they write different data • Some parts are dedicated to the emissary • Some parts are dedicated to the service Written by the emissary Part 3 Part 2 Part 1 Part 2 The Shared Data is like the stuff in the Part 3 paper form! Part 3 Service … … Written by … the service … Slide 37

Trust and Shared Data • • We can bound trust by only letting each partner write on a portion of the shared data • Here’s where I can write… • Here’s where you can write… The schema can keep you from writing on my stuff • This would be enforced by the system • Then, I don’t have to worry about you scribbling on my stuff… Part 11 Part Written by the service Service Written by the emissary Part 2 Part 3 … … Slide 38

Modeling Activities as Shared Data • An activity is one long-running piece of work as viewed from the emissary-to-service basis • Capture the flow of work between the two • Structure the flow into the information to be captured • When are there dependencies? • What does the emissary need to provide before this information can be sent by the service? • Does the service need to provide “Part-X” before the emissary can fill out “Part-Y”? ? ? • The information to be provided can be specified as parts of the “paper form” model • Each side understands the dependencies of which parts need to be specified before others can be filled Slide 39

Designing for Offline-able Emissaries • Imagine rules for doing work with only some of the “parts” filled in… • Perhaps the emissary can create a new piece of shared-date • It fills out the parts it can fill out while offline • Later, these flow to the service which fills out more of the stuff Written by the service ----- But the service is down! Part 1 Part 3 Part 2 Part 1 Service Part 2 Part 3 … … Slide 40

Offline-able Shared Data • It is a challenge to make the application cope with offline • That definitely takes some design considerations • Another challenge is to ensure the system can implement offlineable shared data Emissary Service Part 2 Part 1 Part 3 Part 2 Part 1 Part 2 Part 3 Part 3 We can use replication of the shared data … … as the …mechanism to cope with offline … … easy when each side works … That’s on its own parts of the shared data… Slide 41

Outline • • Introduction The Emissary Design Pattern RIAs – Rich Internet Applications Emissaries and the Boundary to the Trust Sphere • Coding for the Boundary • Conclusion Slide 42

Defining the Shared Data • As one defines the “paper-form”, you define the fields, and patterns for extensions within the fields • This specifies who supplies what parts of the data Part 3 Part 2 Part 1 Written by Part 1 the emissary Part 1 Part 2 Part 3 … … Customer Address Delivery Required Date Part 1 Total Item Price Shipping Address Emissary-Activity Unique-ID Line SKU Item 1 Quant Price Line SKU Item 2 Quant Price Line SKU Item N … Shipping Weight Slide 43

Defining Simple Validation • You can define declarative validation: • Validate within emissary-to-service shared “paper-form” • Validate against the emissary-to-service shared reference-data Customer Address Delivery Required Date Part 1 Total Item Price Shipping Address Emissary-Activity Unique-ID Line SKU Item 1 Quant Price Line SKU Item 2 Quant Price Line SKU Item N … Product Catalog: Tuesday SKU# 1 SKU# 3 SKU# 2 SKU# 4 Reference Data Price List: Tuesday SKU# 1 SKU# 3 SKU# 2 SKU# 4 Reference Data Shipping Weight Slide 44

Can’t-Fill, Should-Fill, May-Fill • It is possible to define the WORKFLOW for the UI by its state • Based on fields filled out by the emissary, • Based on fields filled out by the service, (and visible at the emissary), and • Based on declarative (or procedural) values calculated derived from what else is known • Each input field has a state (which changes based on the known state of the emissary): • Cannot Input: The field is disabled for input • May Input: It is OK to fill this in now • Should input: This is the recommended next field • Imagine a UI which guides the user through the work • The next recommended field is the focus • The user may navigate to stuff out of order where it makes sense • Sometimes, previously entered stuff may need correcting based on newly input data or new information from the service. Slide 45

Sharing the Rules and the Logic! • Can we define the rules once and use them for both the service and the emissary? • Trusted enforcement within the service • Guidance for validation within the emissary? • Single development point! Service Part Part 111 Part 222 Rules Logic Emissary Part 11 Part 22 Part 33 Part 3 … … Part Part 111 Part 222 Rules Logic Rules & Logic Can’t, May, Should… Etc Slide 46

Generating the Emissary Automatically? • Can we generate the RIA emissary automatically? • The fields, validation, interdependency are all there! • The Can’t-Fill, May-Fill, Should-Fill are all there! • Will the form-driven UI for business activities address the needs of a bunch of RIA apps? • May-Fill / Should-Fill allows dynamic and flexible usage! Part 11 Part 22 Part 33 Part 3 … … Rules & Logic Can’t, May, Should… Etc Emissary Part Part 111 Part Par 222 Rules Logic UI and Data Controls Bound to Shared Data State and Work in Progress RIA Client Reference Data Slide 47

Outline • • Introduction The Emissary Design Pattern RIAs – Rich Internet Applications Emissaries and the Boundary to the Trust Sphere • Coding for the Boundary • Conclusion Slide 48

Takeaways • • Emissaries help interact with Servers or Services • They work outside the trust sphere but understand lots about the trusted app • They present data to the user and accept “humble” requests for work • Manage a (potentially) long-running relationship between user and app RIAs run in the browser and offer rich User Interfaces • User experience is like a client machine but installation is browser-like • Identity of app defined by URL/App-Domain • Sandboxed security (can’t break browsing machine) • Application navigation patterns closer to browser than classic smart client Prescriptive Emissaries drive separation of user and server concerns • Focus on the flow of data and work to/from the user • Browser emphasizes User Experience of seeing data and doing work • Server implements the trusted business logic and manages internal application data the business focus Prescriptive Emissaries allow some shared code across browser and server • The server has rules and constraints – enforced within the trust boundary • The emissary (browser) helps ensure valid work is submitted Slide 49