Docstoc

output-input

Document Sample
output-input Powered By Docstoc
					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
    Client                                  Service
      A1
    Service                                   B1
                                            Service
      A2
    Service                                   B2
                                            Service
      A3                                      B3




•     Multiple Clients, Multiple Services
•     Any Client can talk to any Service (of the same
      type)
                       Markets
    Client                                  Service
      A1
    Service                                   B1
                                            Service
      A2
    Service                                   B2
                                            Service
      A3                                      B3




•     Ways to match Client and Service:
     –     Client and Service share same WSDL
     –     Client and Service have complementary
           WSDLs
         Shared Service Descriptions
    Client                     T                     Service
      A1
    Service                                            B1
                                                     Service
      A2
    Service                                            B2
                                                     Service
      A3                                                 B3

•     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
    Client                           T1              Service
      A1
    Service                                            B1
                                                     Service
                                    T2
      A2
    Service                                            B2
                                                     Service
                                   T3
      A3                                                B3


•     {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
    Client                       T                      Service
                                               T1
      A1
    Service                                               B1
                                                        Service
                                              T2
      A2
    Service                                               B2
                                                        Service
                                             T3
      A3                                                   B3


•     {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
    Client                 T                 Service
               TA1                     TB1
      A1
    Service                                    B1
                                             Service
                TA2                   TB2
      A2
    Service                                    B2
                                             Service
                 TA3                  TB3
      A3                                       B3



•     {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
Client                           T                TB1   Service
           TA1        TC                 TS
Service
  A1                                                    Service
                                                          B1
               TA2                            TB2
Service
  A2                                                    Service
                                                          B2
               TA3                            TB3
  A3                                                      B3




       •   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
    Client                T             Service
               TA1                TB1
      A1
    Service                               B1
                                        Service
                TA2              TB2
      A2
    Service                               B2
                                        Service
                TA3             TB3
      A3                                  B3



•     Sharing requires mirror ops only if you
      think they're important
     –     Need Output-Input?
     –     Need Output-Only?
Complementary Service Descriptions
     Client        ~T                        T        Service
       A1
     Service                                            B1
                                                      Service
       A2
     Service                                            B2
                                                      Service
       A3                                               B3

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



•     Complementary approach requires mirror
      ops
     –     Inputs of T are Outputs of ~T
     –     Outputs of T are Inputs of ~T
Complementary: Identity-Specific Info
Client                  ~T        T               Service
              TA1                           TB1
  A1
Service                                             B1
                                                  Service
              TA2                          TB2
  A2
Service                                             B2
                                                  Service
               TA3                         TB3
  A3                                                B3



   •      {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:
  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
A's View                     B's View
                     W   1
                         2
                     X

                     Y   3
                         4
                     Z

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
           MEP: B's View
A's View                      B's View
                          PWXYZ
                  W   1
                      2
                  X

                  Y   3
                      4
                  Z


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


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


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

Two "Solicit-Response" MEPs:
• PWX: Send W, receive X
• PYZ: Send Y, receive Z
           MEP: A's View 2
A's View                           B's View
         PW
                     W    1
         PXY              2
                     X

                     Y    3
         PZ               4
                     Z

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

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
A's View                            B's View
PWZ
                      W   1
         PXY              2
                      X

                      Y   3
                          4
                      Z

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

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

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

•   A makes PXY from half of PWX and half
    of PYZ
Role-Specific Information
      Role-Specific Information
                        X

                       <in>

  Service                                    Service
            Sender                Receiver
    A                                          B
                         T
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                              Service
           Sender          Receiver
   A                                    B
                     T

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                                  Service
           Sender              Receiver
    A                                       B
                      T

• Conclusion: Information that is shared
  between different roles should not contain
  role-specific information
• Examples of role-specific information:
  – "<input>", "<output>", "one-way", address

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:6
posted:9/8/2011
language:English
pages:34