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") |
|
|
|
"Mirror ops": Output-Input,
Output-Only |
|
|
|
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) |
|
|
|
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) |
|
Markets
|
|
|
|
Ways to match Client and Service: |
|
Client and Service share same WSDL |
|
Client and Service have complementary
WSDLs |
|
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? |
|
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" |
|
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" |
|
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 |
|
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 |
|
Shared: Conclusion
|
|
|
|
Sharing requires mirror ops only if you
think they're important |
|
Need Output-Input? |
|
Need Output-Only? |
|
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 |
|
|
|
Complementary: Observation
|
|
|
|
Complementary approach requires mirror
ops |
|
Inputs of T are Outputs of ~T |
|
Outputs of T are Inputs of ~T |
|
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 |
|
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: |
|
Message types |
|
Message direction (input/output) |
|
Transport protocol, Message
encoding |
|
Address (Not shared!) |
|
The least shared info should be latest
bound |
|
Observations on MEPs
|
MEPs
|
|
|
Sequence: |
|
A sends W to B |
|
B sends X to A |
|
A sends Y to B |
|
B sends Z to A |
|
MEP: B's View
|
|
|
One big MEP: |
|
PWXYZ: Receive W, send X, receive Y,
send Z |
|
MEP: B's View
|
|
|
Two "Request-Response" MEPs: |
|
PWX: Receive W, send X |
|
PYZ: Receive Y, send Z |
|
MEP: B's View
|
|
|
Q: Should B care how A models its
interactions with B? |
|
A: Of course not. |
|
MEP: A's View 1
|
|
|
Two "Solicit-Response" MEPs: |
|
PWX: Send W, receive X |
|
PYZ: Send Y, receive Z |
|
MEP: A's View 2
|
|
|
Three MEPs: |
|
PW: Send W ("Notification") |
|
PXY: Receive X, send Y
("Request-Response") |
|
PZ: Receive Z ("One-way") |
|
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") |
|
MEP: A's View 4
|
|
|
Two MEPs: |
|
PWX: Send W, receive X
("Solicit-Response") |
|
PYZ: Send Y, receive Z
("Request-Response") |
|
MEPs Are Relative
|
|
|
Observation: |
|
MEPs are role-specific |
|
MEPs Are Relative
|
|
|
A makes PWZ from half of PWX and half of
PYZ |
|
MEPs Are Relative
|
|
|
A makes PXY from half of PWX and half of
PYZ |
|
|
|
Role-Specific Information
|
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 |
|
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 |
|
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 |
|