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