Should Mirror Operations Be Dropped?

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

B1T

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

T3T2T1T

TA3

TA2

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

TB3

TB2

TB1TTA1

TA3

TA2

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

TB3

TB2

TB1TTA1 TC TS

TA3

TA2

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

TB3

TB2

TB1TTA1

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

~T T

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

~T T

Service

B3

Service

B2

Service

B1

Service

A3

Service

A2

Client

A1

TA3

TA2

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

TB3

TB2

TB1~TTA1

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 B2. B sends X to A3. A sends Y to B4. B sends Z to A

X

Y

Z

W 12

34

B's ViewA's View

MEP: B's View

One big MEP:

• PWXYZ: Receive W, send X, receive Y, send Z

B's View

X

Y

Z

W 12

34

A's ViewPWXYZ

MEP: B's View

Two "Request-Response" MEPs:

• PWX: Receive W, send X

• PYZ: Receive Y, send Z

B's View

X

Y

Z

W 12

34

A's ViewPWX

PYZ

MEP: B's View

Q: Should B care how A models its interactions with B?

A: Of course not.

B's View

X

Y

Z

W 12

34

A's ViewPWX

PYZ

MEP: A's View 1

Two "Solicit-Response" MEPs:

• PWX: Send W, receive X

• PYZ: Send Y, receive Z

B's View

X

Y

Z

W 12

34

A's ViewPWX

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

X

Y

Z

W 12

34

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

X

Y

Z

W 12

34

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

X

Y

Z

W 12

34

A's ViewPWZ

PXY

MEPs Are Relative

Observation:

• MEPs are role-specific

B's View

X

Y

Z

W 12

34

A's ViewPWZ

PXY

PWX

PYZ

MEPs Are Relative

• A makes PWZ from half of PWX and half of PYZ

B's View

X

Y

Z

W 12

34

A's View

PXY

PWX

PYZ

PWZ

MEPs Are Relative

• A makes PXY from half of PWX and half of PYZ

B's View

X

Y

Z

W 12

34

A's ViewPWZ

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., "<in>" (from B's

perspective)• A, B use the same software T to generate Sender and Receiver

from X

ReceiverSender

X

<in>

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 "<in>" is unnecessary in X

ReceiverSender

<in>

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:– "<input>", "<output>", "one-way", address

ReceiverSender

<in>

T

X