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

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

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

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

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

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

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

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

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 B 2.B sends X to A 3.A sends Y to B 4.B sends Z to A XYZW B's ViewA's View

MEP: B's View One big MEP: PWXYZ: Receive W, send X, receive Y, send Z B's View XYZW A's View PWXYZ

MEP: B's View Two "Request-Response" MEPs: PWX: Receive W, send X PYZ: Receive Y, send Z B's View XYZW A's View PWX PYZ

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

MEP: A's View 1 Two "Solicit-Response" MEPs: PWX: Send W, receive X PYZ: Send Y, receive Z B's View XYZW A's View PWX 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 XYZW 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 XYZW 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 XYZW A's View PWZ PXY

MEPs Are Relative Observation: MEPs are role-specific B's View XYZW A's View PWZ PXY PWX PYZ

MEPs Are Relative A makes PWZ from half of PWX and half of PYZ B's View XYZW A's View PXY PWX PYZ PWZ

MEPs Are Relative A makes PXY from half of PWX and half of PYZ B's View XYZW A's View PWZ 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., " " (from B's perspective) A, B use the same software T to generate Sender and Receiver from X ReceiverSender X 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 " " is unnecessary in X ReceiverSender 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: –" ", " ", "one-way", address ReceiverSender T X