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 HellandPartner ArchitectMicrosoft Corporation
2 Outline Introduction The Emissary Design Pattern RIAs – Rich Internet ApplicationsEmissaries and the Boundary to the Trust SphereCoding for the BoundaryConclusion
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 appThey present data to the user and accept “humble” requests for workManage a (potentially) long-running relationship between user and appRIAs run in the browser and offer rich User InterfacesUser experience is like a client machine but installation is browser-likeIdentity of app defined by URL / App-DomainSandboxed security (can’t break browsing machine)Application navigation patterns closer to browser than classic smart clientPrescriptive Emissaries drive separation of user and server concernsFocus on the flow of data and work to / from the userBrowser emphasizes User Experience of seeing data and doing workServer implements the trusted business logic and manages internal application data the business focusPrescriptive Emissaries allow some shared code across browser and serverThe server has rules and constraints – enforced within the trust boundaryThe emissary (browser) helps ensure valid work is submitted
5 1999: The Old “Fiefdoms and Emissaries” Talk Please,kindly considermy humblerequest….FiefdomsIndependent code and dataA separate trust sphereSeparate transaction boundaryToday, called “Services”EmissariesCode designed specially for working with one fiefdomNot trusted!Lives to help prepare requests for the fiefdomUserEmissaryFiefdom
6 Trust Spheres and Emissaries – Some Examples Today AmazonBrowsing, looking at the catalog, shopping cart work…Everything you do before pushing “Submit”After submit, recheck, verify, and process with trust!Mortgage BrokerNot trusted by the bank… helps fill out the formsUsually ensures the loan is accepted (knows the rules)Everything is verified when the loan packet hits bank
7 Architectural Evolution – Shedding No Tiers… MainframeSingle ComputerAll-in-One TrustTwo-TierSingle DatabaseMultiple ClientsAll-in-One TrustN-Tier1 DBMany ClientsMid-Tier ServersOne TrustSOAServiceDistrust!Message InterfacePrivate Imple-mentationSaaS + RIA1 Service?Client / Browser HybridEasy & Safe InstallServiceRIAServer Work Moving to the Cloud(Software as a Service)Client Work Moving to RIA(Rich Internet Applications)
9 Using Emissaries in a RIA Framework Emissaries use data:Reference data is published by the server/serviceUsed to prepare messages to the server/serviceFor example, product-catalog and price-listPer-user state is accumulated during ongoing workFor example, entries in the shopping cartEmissaries submit work to the server/serviceThis is the packaged up “user’s intent”Emissaries interpret the server/service’s messagesWhere are we in the ongoing long-running work?Emissaries are the user’s friend in dealing with the appThey know the app and what to expectThey help the user navigate working with the applicationRIA environments are natural for emissariesApp-centric but need not leave a lasting footprint on the client!
10 Emissaries versus “Classic” SOA “Classic SOA” is about the message boundaryThe XML/SOAP definition is specifiedThe calling application must comply with the definitionLots of attention to adaptive relationshipsExtensibility and loose-coupling of schema are all the rageEmissaries: Code with deep understanding running outside the trustWritten by folks with deep knowledge of the specific serviceWritten to run without trustEmissaries and SOAServiceOtherClientEmissarySchema“Classic” SOAServiceOtherClientSchemaWhat is exposed??Chattier relationship!
11 Outline Introduction The Emissary Design Pattern RIAs – Rich Internet ApplicationsEmissaries and the Boundary to the Trust SphereCoding for the BoundaryConclusion
12 The Trusted “Service” or “Server” Essential to this model is the trusted server or serviceAn application with its own code and dataPublished application identity as a URLIt is not essential to distinguish between one or many computers implementing the serviceIt would be fine to implement this as a single serverFrom here forward, we will refer to it as a serviceThis is classic SOA as well as ASP.NETImplementing the “Service” as a set of machinesServiceSchemaImplementing the “Service” as a single machinesServiceSchemaIndistinguishable behavior (except, perhaps, for scalability)
13 The Request for Service An important aspect of “trust” and “encapsulation” is the request for serviceAn incoming message is received, inspected, and processedOnly if the request is well-formed and good will it be processedServiceTrust 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 flowNot directly one for oneThere may be a complex workflow of messagesMessages may cross pathsThe messages may be asynchronousOffline interactions add confusionThe messages may need to be viewed as a workflowComplex business rules!ServiceCorrelating 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 messagesIncoming (and outgoing) messages may include reference dataExamples: Product catalog, price list, insurance rates, etc.Emissaries and Their Use of Reference DataOtherServiceReference DataProduct Catalog: TuesdaySKU# 1SKU# 2SKU# 3SKU# 4EmissaryNotice the use of reference data in the messages!ServiceSchemaClientEmissary
16 Publication of Reference Data to the Emissary The service is responsible for periodically publishing reference dataIt is up to the service how often it wants to publishIt is up to the service how up-to-date the reference data must be in interacting with the emissaryMay be push or pull to publishSomehow the service makes the reference data availableSomehow the emissary finds it to use external to the serviceUsually, the reference data is current enough to be usefulTuesday’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 usedto manage reference dataThe work says: “Version: XYZ”Mail-order catalogThe values used are compared against those in version XYZPhone operator asks for catalog code then knows the version!Sometimes, implicit versions are usedto manage reference dataHas 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?
18 Using Reference Data within the Workflow Incoming messages can have information from reference dataUsed to describe the desired workFor example SKU-# or Medical-Treatment-CodeOutgoing messages can have information from reference dataServiceReference DataProduct Catalog: TuesdaySKU# 1SKU# 2SKU# 3SKU# 4
19 Information is appended to the form as parts are filled out Consider Paper Forms…Paper forms (with copies) were used for yearsYou fill out part oneKeep the pink copy and submit to HRHR fills out part two, HR keeps the blue copy and sends to your boss…Part 1Part 2Part 3…The workflow is represented in the data filled out in the parts of the formInformation 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 orderServicePart 1Part 2Part 3…
21 Activities: Append-Only Shared-Data Interactions Consider the emissary-to-service interactionsThe emissary tells the service some stuff…The service tells the emissary some stuff…This interaction is about a (potentially long-running) business operationThe state is the dynamic updates to the shared dataThe activity state is EXACTLY like the paper formConsider a “one-at-a-time” usage patternWrite a new part… tear off (and file) the back copy… send the form…Consider a concurrent usage patternDifferent parts of the form arrive asynchronouslyA richer, more complex, manifestation of the paper form
22 Progression and Retirement of Activities Activities have a lifetime and they age through itThink of advancing through the parts of the formWhen the work is done, the form is filled outSometimes, 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 ApplicationsEmissaries and the Boundary to the Trust SphereCoding for the BoundaryConclusion
24 Clients HTML AJAX RIA Smart ClientFull TrustRich and Vibrant UI (w/ Controls)Lots of Local StorageAsynchronousServer CallsPossibleHeavy WeightInstallHTMLSafe and SaneLimited ExperienceNo Local StorageSynchronousServer CallsOnlyNoInstallHTML + AJAXSafe and SaneRicher Java ExperienceNo Local StorageAsynchronousServer CallsPossibleNoInstallRIASafe and SaneRich and Vibrant UI (w/ Controls)Sandboxed and Limited (?) Local StorageAsynchronousServer CallsPossibleLimitedInstall
25 What’s a RIA App? What’s This RIA Crap? RIA apps blend browser and client models:Rich UI experienceSAFE and (hopefully) lightweight installSandboxed StorageMany new issues to define:Browser based app-identity modelHybrid browser and client mode for UI, navigation, focus, back-button and moreWhat 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 StateSafety and Sand- BoxingControlled and Safe Sharing across AppsControlled and Safe Sharing across Users
27 Browser-Based Security (Asymmetry) SSL gives the client confidence in the server’s identityPublic-key technology plus certificate authoritiesThe web site has to implement its own security to authenticate the browser and / or userMany different schemes are in use…I know (via SSL + CA) that I am talking toWeb SiteWho the Hell are you, mister browser???
28 Trust, Sandboxing, RIA, and Sharing Same UserSame AppSame MachineSandboxing is how Silverlight contains data safelyData 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 UIIt has notions of UI-focus, input of characters, clicking on buttons and much moreThe mechanisms for navigation a classic rich-client application are variedBrowsers have simple (but powerful) notions for theseBack-buttons, link traversal, and more are differentHow can we combine these worlds?We need the richness of the classic clientWe need the linking of the browser modelThe 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 appDate/dp/ /ref=pd_bbs_sr_1?ie=UTF8&s=books&qid = &sr=1-1Will 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 workedIt is stored in the sandboxed isolated RIA storageCan 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 ApplicationsEmissaries and the Boundary to the Trust SphereCoding for the BoundaryConclusion
34 Bounding Trust via Encapsulation Services only do limited things for their partnersThis is how they bound their trustEncapsulation is about bounding trustBusiness logic ensures only the desired operations happenNo changes to the data occur except through locally controlled business logic!Services encapsulate by only exposing business operations to their partnersThings I’ll Do for OutsidersDepositWithdrawalTransferAccount Balance CheckServiceThis limits their risk to that work only!34
35 Encapsulating Both Change and Reads Encapsulating changeEnsures integrity of the service’s workEnsures integrity of the service’s dataEncapsulating exported data for readEnsures privacy by controlling what’s exportedAllows planning for loose coupling and expirationsE.G. Wednesday’s price-listServiceBusiness RequestExported DataSanitized Data for ExportPrivate Internal DataData
36 Shared Data: Reference Data Reference Data is shared across the service and it emissariesTypically, it is pushed out as versionsPeriodically, new updates are publishedServiceReference DataProduct Catalog: MondaySKU# 1SKU# 2SKU# 3SKU# 4Reference DataProduct Catalog: TuesdaySKU# 1SKU# 2SKU# 3SKU# 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 dataSome parts are dedicated to the emissarySome parts are dedicated to the serviceThe Shared Data is like the stuff in the paper form!ServicePart 1Part 2Part 3…Written by the emissaryWritten by the service
38 Written by the emissary Trust and Shared DataWe can bound trust by only letting each partner write on a portion of the shared dataHere’s where I can write…Here’s where you can write…The schema can keep you from writing on my stuffThis would be enforced by the systemThen, I don’t have to worry about you scribbling on my stuff…Part 1Part 2Part 3…ServiceWritten by the emissaryPart 1Part 2Part 3…Part 1Part 2Part 3…Part 1Written by the servicePart 2Part 3…
39 Modeling Activities as Shared Data An activity is one long-running piece of work as viewed from the emissary-to-service basisCapture the flow of work between the twoStructure the flow into the information to be capturedWhen 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” modelEach 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-dateIt fills out the parts it can fill out while offlineLater, these flow to the service which fills out more of the stuffServicePart 1Part 2Part 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 offlineThat definitely takes some design considerationsAnother challenge is to ensure the system can implement offline- able shared dataServiceEmissaryPart 1Part 2Part 3…Part 1Part 2Part 3…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…
42 Outline Introduction The Emissary Design Pattern RIAs – Rich Internet ApplicationsEmissaries and the Boundary to the Trust SphereCoding for the BoundaryConclusion
43 Defining the Shared Data As one defines the “paper-form”, you define the fields, and patterns for extensions within the fieldsThis specifies who supplies what parts of the dataPart 1CustomerAddressShippingEmissary-ActivityUnique-IDLine Item 1SKUQuantPriceLine Item 2…Total Item PriceDelivery Required DateLine Item NShipping WeightWritten by the emissaryPart 1Part 2Part 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-dataReference DataProduct Catalog: TuesdaySKU# 1SKU# 2SKU# 3SKU# 4Part 1CustomerAddressShippingEmissary-ActivityUnique-IDLine Item 1SKUQuantPriceLine Item 2…Total Item PriceDelivery Required DateLine Item NShipping WeightReference DataPrice List: TuesdaySKU# 1SKU# 2SKU# 3SKU# 4
45 Can’t-Fill, Should-Fill, May-Fill It is possible to define the WORKFLOW for the UI by its stateBased on fields filled out by the emissary,Based on fields filled out by the service, (and visible at the emissary), andBased on declarative (or procedural) values calculated derived from what else is knownEach input field has a state (which changes based on the known state of the emissary):Cannot Input: The field is disabled for inputMay Input: It is OK to fill this in nowShould input: This is the recommended next fieldImagine a UI which guides the user through the workThe next recommended field is the focusThe user may navigate to stuff out of order where it makes senseSometimes, 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 serviceGuidance for validation within the emissary?Single development point!ServiceEmissaryPart 1Part 2Part 3…RulesLogicPart 1Part 2PartRulesLogicPart 1Part 2PartRules & LogicCan’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 1Part 2Part 3…RIA ClientReference DataRulesLogicPart 1Part 2PartParEmissaryState and Work in ProgressUI and Data Controls Bound to Shared DataRules & LogicCan’t, May, Should… Etc
48 Outline Introduction The Emissary Design Pattern RIAs – Rich Internet ApplicationsEmissaries and the Boundary to the Trust SphereCoding for the BoundaryConclusion
49 Takeaways Emissaries help interact with Servers or Services They work outside the trust sphere but understand lots about the trusted appThey present data to the user and accept “humble” requests for workManage a (potentially) long-running relationship between user and appRIAs run in the browser and offer rich User InterfacesUser experience is like a client machine but installation is browser-likeIdentity of app defined by URL/App-DomainSandboxed security (can’t break browsing machine)Application navigation patterns closer to browser than classic smart clientPrescriptive Emissaries drive separation of user and server concernsFocus on the flow of data and work to/from the userBrowser emphasizes User Experience of seeing data and doing workServer implements the trusted business logic and manages internal application data the business focusPrescriptive Emissaries allow some shared code across browser and serverThe server has rules and constraints – enforced within the trust boundaryThe emissary (browser) helps ensure valid work is submitted