1. Should Mirror Operations Be Dropped? David Booth W3C 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 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)

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 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

6. 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

7. 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 B1 T

8. 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

9. 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 T3T2T1 T

10. TA3TA2 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 TB3TB2TB1 T TA1

11. TA3TA2 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 TB3TB2TB1 T TA1TCTS

12. TA3TA2 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 TB3TB2TB1 T TA1

13. 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 ~TT Service B3 Service B2 Service B1 Service A3 Service A2 Client A1

14. Complementary: Observation Complementary approach requires mirror ops –Inputs of T are Outputs of ~T –Outputs of T are Inputs of ~T ~TT Service B3 Service B2 Service B1 Service A3 Service A2 Client A1

15. TA3TA2 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 TB3TB2TB1 ~T TA1 T

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

17. END

18. 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

19. Observations on MEPs

20. MEPs Sequence: 1.A sends W to B 2.B sends X to A 3.A sends Y to B 4.B sends Z to A XYZW 1 2 3 4 B's ViewA's View

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

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

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

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

25. 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 XYZW 1 2 3 4 A's View PXY PW PZ

26. 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 XYZW 1 2 3 4 A's View PX PW PZ PY

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

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

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

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

31. Role-Specific Information

32. 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., " " (from B's perspective) A, B use the same software T to generate Sender and Receiver from X ReceiverSender X T

33. 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 " " is unnecessary in X ReceiverSender T X

34. 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: –" ", " ", "one-way", address ReceiverSender T X