1 / 34

Should Mirror Operations Be Dropped? Analyzing Current Message Exchange Patterns

This document discusses the relevance of mirror operations in the context of Message Exchange Patterns (MEPs) such as Input-Output, Input-Only, Output-Input, and Output-Only. Highlighting issues like ambiguous interpretations, lack of usage evidence, and inconsistent fault handling, it questions the necessity of keeping these operations. Through abstract analyses, it evaluates scenarios like market dynamics involving multiple clients and services, proposing more effective ways to share client and service information while emphasizing the separation of identity-specific details from shared knowledge.

judah-santana
Télécharger la présentation

Should Mirror Operations Be Dropped? Analyzing Current Message Exchange Patterns

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. Multiple Clients, Multiple Services Any Client can talk to any Service (of the same type) Potential Application: Markets Client A1 Service B1 Service A2 Service B2 Service A3 Service B3

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

  7. 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 Service Descriptions Client A1 T Service B1 Service A2 Service B2 Service A3 Service B3

  8. {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" T3 T2 T1 Shared: One WSDL per Service Client A1 Service B1 Service A2 Service B2 Service A3 Service B3

  9. {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" T3 T2 T1 Shared: Referencing a Common T Client A1 T Service B1 Service A2 Service B2 Service A3 Service B3

  10. {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 TB3 TB2 TB1 TA3 TA2 TA1 Shared: Client, Service Ref T Client A1 T Service B1 Service A2 Service B2 Service A3 Service B3

  11. 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 Client A1 Service B1 TB1 TB2 TB3 TC TA1 TA3 TA2 TS Service A2 Service B2 Service A3 Service B3 Shared: Role-Specific Descriptions T

  12. Sharing requires mirror ops only if you think they're important Need Output-Input? Need Output-Only? TB3 TB2 TB1 TA3 TA2 TA1 Shared: Conclusion Client A1 T Service B1 Service A2 Service B2 Service A3 Service B3

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

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

  15. {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 TB3 TB2 TB1 TA3 TA2 TA1 Complementary: Identity-Specific Info Client A1 ~T T Service B1 Service A2 Service B2 Service A3 Service B3

  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: • 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. Sequence: A sends W to B B sends X to A A sends Y to B B sends Z to A X Y Z W A's View B's View MEPs 1 2 3 4

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

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

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

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

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

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

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

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

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

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

  31. Role-Specific Information

  32. 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 X <in> Service A Service B Sender Receiver T

  33. 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 X <in> Service A Service B Sender Receiver T

  34. Conclusion: Information that is shared between different roles should not contain role-specific information Examples of role-specific information: "<input>", "<output>", "one-way", address Role-Specific Information X <in> Service A Service B Sender Receiver T

More Related