Embed Size (px)
DESCRIPTION
Should Mirror Operations Be Dropped?. David Booth W3C Fellow / Hewlett-Packard. 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") - PowerPoint PPT Presentation
Citation preview
Should Mirror Operations Be Dropped?
David BoothW3C Fellow / Hewlett-Packard
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
Problems with Mirror Ops
1. Multiple interpretations: event? callback?
2. Little evidence of use
3. Where to get the Client's address?
4. 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)
What I Did
Abstract analysis:
• Suppose we used WS descriptions in a larger context. Would we want mirror ops?
• Example: Markets
Potential Application: Markets
• Multiple Clients, Multiple Services• Any Client can talk to any Service (of the same
type)
Service
A3
Service
A2
Client
A1
Service
B3
Service
B2
Service
B1
Markets
• Ways to match Client and Service:– Client and Service share same WSDL– Client and Service have complementary
WSDLs
Service
A3
Service
A2
Client
A1
Service
B3
Service
B2
Service
B1
Shared Service Descriptions
• 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?
Service
A3
Service
A2
Client
A1
Service
B3
Service
B2
Service
B1T
Shared: One WSDL per Service
• {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"
Service
A3
Service
A2
Client
A1
Service
B3
Service
B2
Service
B1
T3T2T1
Shared: Referencing a Common T
• {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"
Service
A3
Service
A2
Client
A1
Service
B3
Service
B2
Service
B1
T3T2T1T
TA3
TA2
Shared: Client, Service Ref T
• {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
Service
A3
Service
A2
Client
A1
Service
B3
Service
B2
Service
B1
TB3
TB2
TB1TTA1
TA3
TA2
Shared: Role-Specific Descriptions
• 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
Service
A3
Service
A2
Client
A1
Service
B3
Service
B2
Service
B1
TB3
TB2
TB1TTA1 TC TS
TA3
TA2
Shared: Conclusion
• Sharing requires mirror ops only if you think they're important
– Need Output-Input?– Need Output-Only?
Service
A3
Service
A2
Client
A1
Service
B3
Service
B2
Service
B1
TB3
TB2
TB1TTA1
Complementary Service Descriptions
• 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
~T T
Service
B3
Service
B2
Service
B1
Service
A3
Service
A2
Client
A1
Complementary: Observation
• Complementary approach requires mirror ops
– Inputs of T are Outputs of ~T– Outputs of T are Inputs of ~T
~T T
Service
B3
Service
B2
Service
B1
Service
A3
Service
A2
Client
A1
TA3
TA2
Complementary: Identity-Specific Info
• {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
Service
A3
Service
A2
Client
A1
Service
B3
Service
B2
Service
B1
TB3
TB2
TB1~TTA1
T
Conclusions
• Mirror ops add flexibility
• Identity-specific info (address) should be separated from shared info
• Other binding info can be shared:transport protocol, etc.
END
WSDL Information Sharing
From most shared to least shared:1. Message types
2. Message direction (input/output)
3. Transport protocol, Message encoding
4. Address (Not shared!)
The least shared info should be latest bound
Observations on MEPs
MEPs
Sequence:1. A sends W to B2. B sends X to A3. A sends Y to B4. B sends Z to A
X
Y
Z
W 12
34
B's ViewA's View
MEP: B's View
One big MEP:
• PWXYZ: Receive W, send X, receive Y, send Z
B's View
X
Y
Z
W 12
34
A's ViewPWXYZ
MEP: B's View
Two "Request-Response" MEPs:
• PWX: Receive W, send X
• PYZ: Receive Y, send Z
B's View
X
Y
Z
W 12
34
A's ViewPWX
PYZ
MEP: B's View
Q: Should B care how A models its interactions with B?
A: Of course not.
B's View
X
Y
Z
W 12
34
A's ViewPWX
PYZ
MEP: A's View 1
Two "Solicit-Response" MEPs:
• PWX: Send W, receive X
• PYZ: Send Y, receive Z
B's View
X
Y
Z
W 12
34
A's ViewPWX
PYZ
MEP: A's View 2
Three MEPs:• PW: Send W ("Notification")• PXY: Receive X, send Y ("Request-Response")• PZ: Receive Z ("One-way")
B's View
X
Y
Z
W 12
34
A's View
PXY
PW
PZ
MEP: A's View 3
Four MEPs:• PW: Send W ("Notification")• PX: Receive X ("One-way")• PY: Send Y ("Notification")• PZ: Receive Z ("One-way")
B's View
X
Y
Z
W 12
34
A's View
PX
PW
PZ
PY
MEP: A's View 4
Two MEPs:• PWX: Send W, receive X ("Solicit-Response")• PYZ: Send Y, receive Z ("Request-Response")
B's View
X
Y
Z
W 12
34
A's ViewPWZ
PXY
MEPs Are Relative
Observation:
• MEPs are role-specific
B's View
X
Y
Z
W 12
34
A's ViewPWZ
PXY
PWX
PYZ
MEPs Are Relative
• A makes PWZ from half of PWX and half of PYZ
B's View
X
Y
Z
W 12
34
A's View
PXY
PWX
PYZ
PWZ
MEPs Are Relative
• A makes PXY from half of PWX and half of PYZ
B's View
X
Y
Z
W 12
34
A's ViewPWZ
PXY
PWX
PYZ
Role-Specific Information
Service
B
Service
A
Role-Specific Information
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., "<in>" (from B's
perspective)• A, B use the same software T to generate Sender and Receiver
from X
ReceiverSender
X
<in>
T
Service
B
Service
A
Role-Specific Information
Observation:• Q: How does T know whether to generate
Sender or Receiver from X?• A: T must have other information• Therefore "<in>" is unnecessary in X
ReceiverSender
<in>
T
X
Service
B
Service
A
Role-Specific Information
• Conclusion: Information that is shared between different roles should not contain role-specific information
• Examples of role-specific information:– "<input>", "<output>", "one-way", address
ReceiverSender
<in>
T
X
