• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Data-centric Invocable Services
 

Data-centric Invocable Services

on

  • 391 views

These are slides from a talk I gave on 18 April, 2012, at the Object Management Group's (OMG's) Real-Time Workshop in Paris, France.

These are slides from a talk I gave on 18 April, 2012, at the Object Management Group's (OMG's) Real-Time Workshop in Paris, France.

Statistics

Views

Total Views
391
Views on SlideShare
390
Embed Views
1

Actions

Likes
1
Downloads
7
Comments
0

1 Embed 1

http://www.slashdocs.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Pseudo-code!
  • Since many here are interested in DDS and use IDL…
  • Since many here are interested in DDS and use IDL…

Data-centric Invocable Services Data-centric Invocable Services Presentation Transcript

  • Your systems. Working as one.Data-centric Invocable ServicesWorkshop on Real-Time, Embedded and Rick WarrenEnterprise-Scale Time-Critical Systems rick.warren@rti.com Rajive JoshiApril 2012; Paris rajive@rti.com
  • Data-Centricity by Example: CalendaringImperative Process:1. Email: “Meet Monday at 10:00.”2. Email: “Meeting moved to Tuesday.”3. Email: “Here’s conference call info…”4. You: “Where do I have to be? When?”5. You: (sifting through email…) © 2012 RTI 2
  • Data-Centricity by Example: CalendaringData-centric Process:1. Calendar: (add meeting Monday at 10:00)2. Calendar: (move meeting to Tuesday)3. Calendar: (add dial-in info)4. You: “Where do I have to be? When?”5. You: (check calendar) © 2012 RTI 3
  • Data-centric vs. Imperative Styles• Imperative Functions coupled; – Tell someone to do something State implicit – Check whether they did it• Data-centric Functions decoupled; Canonical SQL HTTP DDS State explicit Create INSERT POST write Read SELECT GET read Update UPDATE PUT write Delete DELETE DELETE dispose on_event TRIGGER — on_data_ available © 2012 RTI 4
  • Conflict?• Data-centricity benefits system designers – (Eventually) Consistent “truth” – Scalability and elasticity, because of stateless logic – Evolvability, because of functional decoupling – Robustness to communication failures• Programmers think imperatively try { doSomethingThatMayFail(); doSomethingOnSuccess(); } catch (FailureOccurred) { doSomethingElseOnFailure(); } © 2012 RTI 5
  • Conflict? Are these models fundamentally in conflict? No. © 2012 RTI 6
  • Reconciliation “Dude, instructions are just data.” — John Von Neumann, 1945• Desires are also just data• Objectives are also just dataBest practice: Don’t tell someone to dosomething; assert your desired future state © 2012 RTI 7
  • ReconciliationImperative View Data-centric Viewtry { structThingDesired{doSomething(); string thingWanted;doOnSuccess(); }} catch (Failure) { structThingHappened{doOnFailure(); string thingWanted;} booleansuccess; }; … © 2012 RTI 8
  • ReconciliationImperative View Data-centric Viewtry { … create(doSomething(); thingWanted = “something”) on_event(doOnSuccess(); thingWanted == “something” &&} catch (Failure) { success == true) {doOnFailure(); update( thingWanted = “onSuccess”)} } on_event( thingWanted== “something” && success == false) { update( thingWanted = “onFailure”) } © 2012 RTI 9
  • ReconciliationImperative View Data-centric View This way is easier This way is easier …to write the first time …to scale out …to understand top- …to extend down, sequentially …to maintain incrementally …to understand bottom- up, causally © 2012 RTI 10
  • ReconciliationImperative View Data-centric ViewExpress application Express interop.code this way GOOD this way This is what we mean by “data-centric invocable service”: • Request looks like explicit “call” (RMI or similar) • Interoperability on the basis of data, not functional implementation • Caller and Callee may use different programming models © 2012 RTI 11
  • ReconciliationImperative View Data-centric ViewExpress application Express interop.code this way GOOD this wayMake app programmers Express interop.wire that up HARD this wayExpress application Express interop. basedcode this way BAD on one app’s code © 2012 RTI 12
  • ProcessArchitect Programmer Platform 1. Define data 4. Generate 6. Govern data model code from flows based 2. Define and architect- on architect- group data defined defined streams using contract(s) (OPTIONAL) contract(s) those types 3. Define 5. Produce and deployment of respond to producers and data according consumers of to app algo’s those streams © 2012 RTI 13
  • Process Example: WSDL Architect Programmer class MyService { Standard WSDL Result1 doThis( bindings exist Args1) { for … SOAP, REST, and } SMTP. Result2 doThat( Additional Args2) { bindings could … } be defined for … DDS or other } technologies.Figure courtesy of ICONIX, © 2012 RTI 14http://www.iconixsw.com/Articles/SOARoadmap.html
  • Hypothetical DDS IDL ExamplestructFoo { local interface Svc { @Key long id; @InTopic("FooTpc")long x; @OutTopic("BarTpc")double y; Bar doFoo(in Foo f);}; };structBar { @Key string who; Control binding to topics for easy subscription, filtering,short baz; and QoS control}; © 2012 RTI 15
  • Hypothetical DDS IDL ExamplestructFoo { local interface Svc { @InTopic( @Key long id; value="T1”, key="42")long x; @OutTopic(double y; value="T2", key="me")}; Bar doFoo1(in Foo f); @InTopic(structBar { value="T1”, key="29") @Key string who; @OutTopic(short baz; value="T2", key="you")}; Bar doFoo2(in Foo f); }; © 2012 RTI 16
  • Hypothetical DDS IDL Counter-Examplelocal interface Svc { union Svc_Type switch (WhichOpEnum){Foo doFoo( case Svc_doFoo_CALL: out string x, Svc_doFoo_InStruct inout long y, sdfis; in double z); Reverse case Svc_doFoo_RETURN: Bar doBar( Engineer Svc_doFoo_OutStruct sdfos; in long a, case Svc_doBar_CALL: out float b, Svc_doBar_InStruct inout short c); sdbis;}; case Svc_doBar_RETURN: Svc_doBar_OutStruct sdbos; }; © 2012 RTI 17
  • Why is This Gross? Insane data type to make a DBA cringe in horror union Svc_Type switch (WhichOpEnum){ Segregates data model: human- case Svc_doFoo_CALL: written vs. machine-generated Svc_doFoo_InStruct sdfis; (Someone’s) API constraints baked case Svc_doFoo_RETURN: into shared interop. interface Svc_doFoo_OutStruct Heavily influenced by sdfos; scalability assumptions case Svc_doBar_CALL: …which may or may not be valid Svc_doBar_InStructOver-reliance on complex filtering on sdbis; subscriber side case Svc_doBar_RETURN: Svc_doBar_OutStructFine-grained QoS governance almost sdbos; impossible }; © 2012 RTI 18
  • Summary• Data-centricity remains an • These two sets of benefits architectural best practice are not exclusive – Many of its benefits accrue – Design system interop. at the systems level interface• App programmers may be – Design programming more comfortable with interface higher-level API – Bind them together • Proven examples exist: – Architecture – Workflow – Data and service description – Programming model © 2012 RTI 19