Should%20Mirror%20Operations%20Be%20Dropped? - PowerPoint PPT Presentation

About This Presentation
Title:

Should%20Mirror%20Operations%20Be%20Dropped?

Description:

Should Mirror Operations Be Dropped? David Booth W3C Fellow / Hewlett-Packard – PowerPoint PPT presentation

Number of Views:82
Avg rating:3.0/5.0
Slides: 35
Provided by: DavidB518
Learn more at: https://www.w3.org
Category:

less

Transcript and Presenter's Notes

Title: Should%20Mirror%20Operations%20Be%20Dropped?


1
Should Mirror Operations Be Dropped?
  • David BoothW3C Fellow / Hewlett-Packard

2
Current Status
  • Four Message Exchange Patterns (MEPs)
  • Input-Output (was "Request-Response")
  • Input-Only (was "One-Way")
  • Output-Input (was "Solicit-Response")
  • Output-Only (was "Notification")
  • "Mirror ops" Output-Input, Output-Only

3
Problems with Mirror Ops
  • Multiple interpretations event? callback?
  • Little evidence of use
  • Where to get the Client's address?
  • Inconsistent treatment of Faults?
  • Input-Output Fault is an alternate Output
  • Input-Only  (no Faults)
  • Output-Input Fault is an alternate Input
  • Output-Only (no Faults)

4
What I Did
  • Abstract analysis
  • Suppose we used WS descriptions in a larger
    context.  Would we want mirror ops?
  • Example Markets

5
Potential Application Markets
Client A1
Service B1
Service A2
Service B2
Service A3
Service B3
  • Multiple Clients, Multiple Services
  • Any Client can talk to any Service (of the same
    type)

6
Markets
Client A1
Service B1
Service A2
Service B2
Service A3
Service B3
  • Ways to match Client and Service
  • Client and Service share same WSDL
  • Client and Service have complementary WSDLs

7
Shared Service Descriptions
Client A1
Service B1
T
Service A2
Service B2
Service A3
Service B3
  • Role must be separately indicated
  • Client "I'm a T Client"
  • Service "I'm a T Service"
  • Binding information is lopsided (Service-centric)
  • Binding has Service-specific info (address)
  • Where is Client-specific info placed?

8
Shared One WSDL per Service
Client A1
Service B1
Service A2
Service B2
Service A3
Service B3
  • T1, T2, T3 could be specific to B1, B2, B3
  • T1 has B1's address, T2 has B2's address, etc.
  • B1 "I'm a T1 Service"
  • B2 "I'm a T2 Service", etc.
  • Each Client could reference all T1, T2,
    T3"I'm a T1Client, a T2 Client and a T3 Client"

9
Shared Referencing a Common T
Client A1
Service B1
T
Service A2
Service B2
Service A3
Service B3
  • T1, T2, T3 could reference generic T
  • T1 has B1's address, T2 has B2's address, etc.
  • B1 "I'm a T1"
  • T is Service-centric, but not identity-centric
    (I.e., no address)
  • Client could reference generic T
  • "I'm a T Client"

10
Shared Client, Service Ref T
Client A1
Service B1
T
Service A2
Service B2
Service A3
Service B3
  • TA1, TA2, TA3, TB1, TB2, TB3 are all
    identity-specific
  • TA1 "A1 is a T Client"
  • TB1 "B1 is a T Service"
  • T does not contain address

11
Shared Role-Specific Descriptions
T
  • TC and TS are role-specific, but not
    identity-specific
  • TC "I am a T Client"
  • TS "I am a T Service"
  • T does not contain address or role info

12
Shared Conclusion
Client A1
Service B1
T
Service A2
Service B2
Service A3
Service B3
  • Sharing requires mirror ops only if you think
    they're important
  • Need Output-Input?
  • Need Output-Only?

13
Complementary Service Descriptions
T
T
Service B1
Client A1
Service B2
Service A2
Service B3
Service A3
  • Symmetric ("Peer-to-Peer")
  • T describes Service T describes Client
  • T, T indicate
  • Generic info (T)
  • Role-specific info (Client vs. Service)
  • Identity-specific info (address)
  • Requires (complementary) equivalence to match

14
Complementary Observation
T
T
Service B1
Client A1
Service B2
Service A2
Service B3
Service A3
  • Complementary approach requires mirror ops
  • Inputs of T are Outputs of T
  • Outputs of T are Inputs of T

15
Complementary Identity-Specific Info
Client A1
Service B1
T
T
Service A2
Service B2
Service A3
Service B3
  • TA1, TA2, TA3, TB1, TB2, TB3 are all
    identity-specific
  • TA1 "A1 is a T"
  • TB1 "B1 is a T"
  • T, T do not contain addresses

16
Conclusions
  • Mirror ops add flexibility
  • Identity-specific info (address) should be
    separated from shared info
  • Other binding info can be sharedtransport
    protocol, etc.

17
END
18
WSDL Information Sharing
  • From most shared to least shared
  • Message types
  • Message direction (input/output)
  • Transport protocol, Message encoding
  • Address (Not shared!)
  • The least shared info should be latest bound

19
Observations on MEPs
20
MEPs
B's View
A's View
1
2
3
4
  • Sequence
  • A sends W to B
  • B sends X to A
  • A sends Y to B
  • B sends Z to A

21
MEP B's View
B's View
A's View
PWXYZ
1
2
3
4
  • One big MEP
  • PWXYZ Receive W, send X, receive Y, send Z

22
MEP B's View
B's View
A's View
PWX
1
2
PYZ
3
4
  • Two "Request-Response" MEPs
  • PWX Receive W, send X
  • PYZ Receive Y, send Z

23
MEP B's View
B's View
A's View
PWX
1
2
PYZ
3
4
  • Q Should B care how A models its interactions
    with B?
  • A Of course not.

24
MEP A's View 1
B's View
A's View
PWX
1
2
PYZ
3
4
  • Two "Solicit-Response" MEPs
  • PWX Send W, receive X
  • PYZ Send Y, receive Z

25
MEP A's View 2
B's View
A's View
PW
1
2
PXY
3
4
PZ
  • Three MEPs
  • PW Send W ("Notification")
  • PXY Receive X, send Y ("Request-Response")
  • PZ Receive Z ("One-way")

26
MEP A's View 3
B's View
A's View
PW
1
2
PX
PY
3
4
PZ
  • Four MEPs
  • PW Send W ("Notification")
  • PX Receive X ("One-way")
  • PY Send Y ("Notification")
  • PZ Receive Z ("One-way")

27
MEP A's View 4
B's View
A's View
PWZ
1
2
PXY
3
4
  • Two MEPs
  • PWX Send W, receive X ("Solicit-Response")
  • PYZ Send Y, receive Z ("Request-Response")

28
MEPs Are Relative
B's View
A's View
PWZ
PWX
1
2
PXY
PYZ
3
4
  • Observation
  • MEPs are role-specific

29
MEPs Are Relative
B's View
A's View
PWX
PWZ
1
2
PXY
PYZ
3
4
  • A makes PWZ from half of PWX and half of PYZ

30
MEPs Are Relative
B's View
A's View
PWZ
PWX
1
2
PXY
PYZ
3
4
  • A makes PXY from half of PWX and half of PYZ

31
Role-Specific Information
32
Role-Specific Information
X
ltingt
Service B
Service A
Receiver
Sender
T
  • Suppose
  • A must send B messages in format X
  • X represents message format definition
  • A, B reference X
  • X contains role-specific information, e.g.,
    "ltingt" (from B's perspective)
  • A, B use the same software T to generate Sender
    and Receiver from X

33
Role-Specific Information
X
ltingt
Service B
Service A
Receiver
Sender
T
  • Observation
  • Q How does T know whether to generate Sender or
    Receiver from X?
  • A T must have other information
  • Therefore "ltingt" is unnecessary in X

34
Role-Specific Information
X
ltingt
Service B
Service A
Receiver
Sender
T
  • Conclusion Information that is shared between
    different roles should not contain role-specific
    information
  • Examples of role-specific information
  • "ltinputgt", "ltoutputgt", "one-way", address
Write a Comment
User Comments (0)
About PowerShow.com