Post on 16-Dec-2015
The Emissary Design Pattern and RIAs (Rich Internet Applications)
Pat HellandPartner ArchitectMicrosoft Corporation
Slide 2
Outline
• Introduction
• The Emissary Design Pattern
• RIAs – Rich Internet Applications
• Emissaries and the Boundary to the Trust Sphere
• Coding for the Boundary
• Conclusion
Slide 3
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 4
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 5
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 humblerequest….
User Emissary Fiefdom
Slide 6
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 7
Architectural Evolution – Shedding No Tiers…
SaaS + RIA
- 1 Service?
- Client /BrowserHybrid
- Easy & Safe Install
Service
RIA RIA
Server Work Moving to the Cloud
(Software as a Service)
Client Work Moving to RIA(Rich Internet Applications)
Mainframe
- Single Computer
- All-in-One Trust
Two-Tier
- Single Database
- Multiple Clients
- All-in-One Trust
N-Tier
- 1 DB- Many
Clients- Mid-Tier
Servers- One Trust
SOA
Service
- Distrust!- Message
Interface- Private
Imple-mentation
Slide 8
The Emergence of RIA• Application install and trust are HUGE issues!
• HTML is boring but safe!• AJAX and JavaScript add some punch to the
boredom• Most people would rather be bored than
terrified…
• Requirements for RIA• Safe, easy, and fast install• Safe, 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 9
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 10
Emissaries and SOA
Service
OtherService
ClientEm
issa
ry
Em
issa
ry
Schema
Emissaries versus “Classic” SOA• “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
“Classic” SOA
Service
OtherService
Client
SchemaWhat is
exposed??Chattier
relationship!
Slide 11
Outline
• Introduction
• The Emissary Design Pattern
• RIAs – Rich Internet Applications
• Emissaries and the Boundary to the Trust Sphere
• Coding for the Boundary
• Conclusion
Slide 12
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
Implementing the “Service” as a set of
machines
Service
Schema Implementing the “Service” as a single
machines
Service
Schema
Indistinguishable behavior
(except, perhaps, for scalability)
Slide 13
Service
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
=
=
==
=
OK… I’ll do
that for you!
Trust and encapsulation are about ensuring the messages meet the
business rules
Different services will
have different business rules…
Slide 14
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!
Service
Correlating the messages with each workflow is one challenge.
Must correlate by 2-party communication
Slide 15
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.
Emissaries and Their Use of Reference Data
Service
Schema
OtherService
Client
Reference Data
Product Catalog: TuesdaySKU# 1
SKU# 2SKU# 3SKU# 4
Em
issa
ryEm
issa
ry
Notice the use of reference data in the messages!
Slide 16
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
• 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
Tuesday’s price list is only valid on Tuesday!Not the best behavior at 11:59PM Tuesday…
Slide 17
Explicit or Implicit Versioning of Reference Data
Sometimes, explicit versions are used to manage reference data
The work says: “Version: XYZ”The values used are
compared against those in version XYZ
Mail-order catalogPhone 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 dataDoes the message need to explicitly list the version of the reference
data?
Slide 18
Service
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
Reference Data
Product Catalog: TuesdaySKU# 1
SKU# 2SKU# 3SKU# 4
Slide 19
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
…
Part 1
Part 2
Part 3
…
Part 1
Part 2
Part 3
…
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 20
Service
Part 1
Part 2
Part 3
…
Part 1
Part 2
Part 3
…
Part 1
Part 2
Part 3
……
Part
1Pa
rt 2
Part
3
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
Slide 21
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 formConsider 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 patternDifferent parts of the form arrive asynchronously
A richer, more complex, manifestation of the paper form
Slide 22
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 23
Outline
• Introduction
• The Emissary Design Pattern
• RIAs – Rich Internet Applications
• Emissaries and the Boundary to the Trust Sphere
• Coding for the Boundary
• Conclusion
Slide 24
Clients HTML AJAX RIA
Smart Client
Full Trust
Rich and Vibrant UI (w/
Controls)
Lots of Local Storage
AsynchronousServer Calls
Possible
Heavy WeightInstall
HTML
Safe and Sane
Limited Experience
No Local Storage
SynchronousServer Calls
Only
NoInstall
HTML + AJAX
Safe and Sane
Richer Java Experience
No Local Storage
AsynchronousServer Calls
Possible
NoInstall
RIA
Safe and Sane
Rich and Vibrant UI (w/
Controls)
Sandboxed and Limited (?)
Local Storage
AsynchronousServer Calls
Possible
LimitedInstall
Slide 25
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 26
The State in the Cloud
Application State Separated from the Machine
Per-UserPer-App
State
Safetyand
Sand-Boxing
Controlledand SafeSharingacross Apps
Controlledand SafeSharingacross Users
Slide 27
Browser-Based Security (Asymmetry)• SSL gives the client confidence in the server’s
identity• Public-key technology plus certificate
authorities
• The web site has to implement its own security to authenticate the browser and / or user• Many different schemes are in use…
Web Sitewww.WebSite.Co
m
I know (via SSL + CA) that I am talking to
www.WebSite.Com
Who the Hell are you, mister browser???
Slide 28
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?
• How do we allow users to access their state from different machines?
Same User
Same App
Same Machine
Slide 29
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 30
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=UTF8&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 31
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 32
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 33
Outline
• Introduction
• The Emissary Design Pattern
• RIAs – Rich Internet Applications
• Emissaries and the Boundary to the Trust Sphere
• Coding for the Boundary
• Conclusion
Slide 34
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!
34
Things I’ll Do for Outsiders• Deposit• Withdrawal• Transfer• Account Balance Check
Service
Services encapsulate by only exposing business
operations to their partners
This limits their risk to that work only!
Slide 35
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
Service
Business Request
Exported Data
Sanitized Datafor Export
PrivateInternal
Data
Data
Slide 36
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
Service
Reference Data
Product Catalog: MondaySKU# 1
SKU# 2SKU# 3SKU# 4
Reference Data
Product Catalog: TuesdaySKU# 1
SKU# 2SKU# 3SKU# 4
Slide 37
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
Service
Part 1
Part 2
Part 3
…
Part 1
Part 2
Part 3
…
Part 1
Part 2
Part 3
……
Part
1Pa
rt 2
Part
3
Written by the
emissary
Written by the service
The Shared Data is like the stuff in the
paper form!
Slide 38
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…
Service
Part 1
Part 2
Part 3
…
Part 1
Part 2
Part 3
…
Part 1
Part 2
Part 3
…
Part 1
Part 2
Part 3
…
Written by the service
Written by the
emissary
Slide 39
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 40
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
stuffService Part 1
Part 2
Part 3
…
Part 1
Part 2
Part 3
…
Part 1
Part 2
Part 3
……
Part
1Pa
rt 2
Part
3
Written by the service
-----
But the service is
down!
Slide 41
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
offline-able shared data
Part 1
Part 2
Part 3
…
Part 1
Part 2
Part 3
…
Part 1
Part 2
Part 3
……
Part
1Pa
rt 2
Part
3
Part 1
Part 2
Part 3
…
Part 1
Part 2
Part 3
…
Part 1
Part 2
Part 3
……
Part
1Pa
rt 2
Part
3
EmissaryService
We can use replication of the shared data as the mechanism to cope with
offlineThat’s easy when each side works on its own parts of the shared data…
Slide 42
Outline
• Introduction
• The Emissary Design Pattern
• RIAs – Rich Internet Applications
• Emissaries and the Boundary to the Trust Sphere
• Coding for the Boundary
• Conclusion
Slide 43
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 1
Part 2
Part 3
…
Part 1
Part 2
Part 3
…
Part 1
Part 2
Part 3
……
Part
1Pa
rt 2
Part
3
Written by the
emissary
Part 1
Customer
Address
ShippingAddress
Emissary-Activity
Unique-ID
Line Item 1
SKUQuan
tPrice
Line Item 2
SKUQuan
tPrice
…Total ItemPrice
Delivery Required Date
Line Item N
SKUQuan
tPrice
Shipping Weight
Slide 44
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
Reference Data
Product Catalog: TuesdaySKU# 1
SKU# 2SKU# 3SKU# 4
Reference Data
Price List: TuesdaySKU# 1SKU# 2
SKU# 3SKU# 4
Part 1
Customer
Address
ShippingAddress
Emissary-Activity
Unique-ID
Line Item 1
SKUQuan
tPrice
Line Item 2
SKUQuan
tPrice
…Total ItemPrice
Delivery Required Date
Line Item N
SKUQuan
tPrice
Shipping Weight
Slide 45
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 46
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!
Emissary
ServicePart 1
Part 2
Part 3
…
Part 1
Part 2
Part 3
…
Part 1
Part 2
Part 3
……
Rules & Logic
Can’t, May, Should… Etc
RulesLogic
Part 1Part 2Part
Part 1Part 2
Part 1Part 2PartRules
Logic
Part 1Part 2Part
Part 1Part 2
Part 1Part 2Part
Slide 47
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!RIA Client
Reference Data
RulesLogic
Part 1Part 2Part
Part 1Part 2
Part 1Part 2Par
Emissary
State and
Work in Progress
UI and Data
Controls Bound to Shared Data
Part 1
Part 2
Part 3
…
Part 1
Part 2
Part 3
…
Part 1
Part 2
Part 3
……
Rules & Logic
Can’t, May, Should… Etc
Slide 48
Outline
• Introduction
• The Emissary Design Pattern
• RIAs – Rich Internet Applications
• Emissaries and the Boundary to the Trust Sphere
• Coding for the Boundary
• Conclusion
Slide 49
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