Presentation is loading. Please wait.

Presentation is loading. Please wait.

The Emissary Design Pattern and RIAs (Rich Internet Applications)

Similar presentations


Presentation on theme: "The Emissary Design Pattern and RIAs (Rich Internet Applications)"— Presentation transcript:

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

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

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!!!

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

5 1999: The Old “Fiefdoms and Emissaries” Talk
Please, kindly consider my humble request…. 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 User Emissary Fiefdom

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

7 Architectural Evolution – Shedding No Tiers…
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 SaaS + RIA 1 Service? Client / Browser Hybrid Easy & Safe Install Service RIA Server Work Moving to the Cloud (Software as a Service) Client Work Moving to RIA (Rich Internet Applications)

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

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!

10 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 Emissaries and SOA Service Other Client Emissary Schema “Classic” SOA Service Other Client Schema What is exposed?? Chattier relationship!

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

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)

13 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 Service 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…

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

15 Emissaries and Their Use of 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 Other Service Reference Data Product Catalog: Tuesday SKU# 1 SKU# 2 SKU# 3 SKU# 4 Emissary Notice the use of reference data in the messages! Service Schema Client Emissary

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…

17 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?

18 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 Service Reference Data Product Catalog: Tuesday SKU# 1 SKU# 2 SKU# 3 SKU# 4

19 Information is appended to the form as parts are filled out
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

20 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 Service Part 1 Part 2 Part 3

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 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

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

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

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

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??”

26 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

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… I know (via SSL + CA) that I am talking to Web Site Who the Hell are you, mister browser???

28 Trust, Sandboxing, RIA, and Sharing
Same User Same App Same Machine 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?

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??

30 Deep-Linking and the RIA Experience
Deep-Linking is the use of a URL to enter the app Date/dp/ /ref=pd_bbs_sr_1?ie=UTF8&s=books&qid = &sr=1-1 Will give you: What Deep-Linking Navigation will you get with your RIA solution?? There are challenges with this!!

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?

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!

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

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! Services encapsulate by only exposing business operations to their partners Things I’ll Do for Outsiders Deposit Withdrawal Transfer Account Balance Check Service This limits their risk to that work only! 34

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 Data for Export Private Internal Data Data

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: Monday SKU# 1 SKU# 2 SKU# 3 SKU# 4 Reference Data Product Catalog: Tuesday SKU# 1 SKU# 2 SKU# 3 SKU# 4

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 The Shared Data is like the stuff in the paper form! Service Part 1 Part 2 Part 3 Written by the emissary Written by the service

38 Written by the emissary
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 1 Part 2 Part 3 Service Written by the emissary Part 1 Part 2 Part 3 Part 1 Part 2 Part 3 Part 1 Written by the service Part 2 Part 3

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

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 stuff Service Part 1 Part 2 Part 3 Written by the service ----- But the service is down!

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 Service Emissary Part 1 Part 2 Part 3 Part 1 Part 2 Part 3 We can use replication of the shared data as the mechanism to cope with offline That’s easy when each side works on its own parts of the shared data…

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

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 Customer Address Shipping Emissary-Activity Unique-ID Line Item 1 SKU Quant Price Line Item 2 Total Item Price Delivery Required Date Line Item N Shipping Weight Written by the emissary Part 1 Part 2 Part 3

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: Tuesday SKU# 1 SKU# 2 SKU# 3 SKU# 4 Part 1 Customer Address Shipping Emissary-Activity Unique-ID Line Item 1 SKU Quant Price Line Item 2 Total Item Price Delivery Required Date Line Item N Shipping Weight Reference Data Price List: Tuesday SKU# 1 SKU# 2 SKU# 3 SKU# 4

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.

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! Service Emissary Part 1 Part 2 Part 3 Rules Logic Part 1 Part 2 Part Rules Logic Part 1 Part 2 Part Rules & Logic Can’t, May, Should… Etc

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! Part 1 Part 2 Part 3 RIA Client Reference Data Rules Logic Part 1 Part 2 Part Par Emissary State and Work in Progress UI and Data Controls Bound to Shared Data Rules & Logic Can’t, May, Should… Etc

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

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


Download ppt "The Emissary Design Pattern and RIAs (Rich Internet Applications)"

Similar presentations


Ads by Google