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