Issue 276

[Kevin Conner <Kevin.Conner@arjuna.com>]

In response to my AI from the last meeting.

Summary of the issue:

The RegistrationContextType may contain a list of participant service references representing those participants already enlisted in the coordination, the same information also being available from the Registration Service using the getParticipants message.  This information is, presumably, to allow interested parties to communicate with those participants.  At present this information does not specify the protocol(s) for which each endpoint is registered.

There are three ways in which this issue could be addressed, each with their own failing.

 - Specify each endpoint and associated protocols independently.
 - Associate a single protocol with a group of endpoints.
 - Associate a set of protocols with a group of endpoints.

The first could be specified within a context as follows: -

  <wsctx:protocol>protocol1</wsctx:protocol>
  <wsctx:protocol>protocol2</wsctx:protocol>
  <wsctx:participant-service>
    <wsa:EndpointReference>
      <wsa:Address>endpoint reference 1</wsa:Address>
    </wsa:EndpointReference>
  </wsctx:participant-service>
  <wsctx:protocol>protocol3</wsctx:protocol>
  <wsctx:participant-service>
    <wsa:EndpointReference>
      <wsa:Address>endpoint reference 2</wsa:Address>
    </wsa:EndpointReference>
  </wsctx:participant-service>
  <wsctx:protocol>protocol2</wsctx:protocol>
  <wsctx:protocol>protocol3</wsctx:protocol>
  <wsctx:protocol>protocol4</wsctx:protocol>
  <wsctx:participant-service>
    <wsa:EndpointReference>
      <wsa:Address>endpoint reference 3</wsa:Address>
    </wsa:EndpointReference>
  </wsctx:participant-service>
  <wsctx:protocol>protocol3</wsctx:protocol>
  <wsctx:participant-service>
    <wsa:EndpointReference>
      <wsa:Address>endpoint reference 4</wsa:Address>
    </wsa:EndpointReference>
  </wsctx:participant-service>

Pros - easy to parse
Cons - duplication of protocol information.  Requires some work to discover which endpoints support a particular protocol.

The second could be specified within a context as follows: -

  <wsctx:participant-services>
    <wsctx:protocol>protocol1</wsctx:protocol>
    <wsctx:participant-service>
      <wsa:EndpointReference>
        <wsa:Address>endpoint reference 1</wsa:Address>
      </wsa:EndpointReference>
    </wsctx:participant-service>
  </wsctx:participant-services>

  <wsctx:participant-services>
    <wsctx:protocol>protocol2</wsctx:protocol>
    <wsctx:participant-service>
      <wsa:EndpointReference>
        <wsa:Address>endpoint reference 1</wsa:Address>
      </wsa:EndpointReference>
    </wsctx:participant-service>
    <wsctx:participant-service>
      <wsa:EndpointReference>
        <wsa:Address>endpoint reference 3</wsa:Address>
      </wsa:EndpointReference>
    </wsctx:participant-service>
  </wsctx:participant-services>

  <wsctx:participant-services>
    <wsctx:protocol>protocol3</wsctx:protocol>
    <wsctx:participant-service>
      <wsa:EndpointReference>
        <wsa:Address>endpoint reference 2</wsa:Address>
      </wsa:EndpointReference>
    </wsctx:participant-service>
    <wsctx:participant-service>
      <wsa:EndpointReference>
        <wsa:Address>endpoint reference 3</wsa:Address>
      </wsa:EndpointReference>
    </wsctx:participant-service>
    <wsctx:participant-service>
      <wsa:EndpointReference>
        <wsa:Address>endpoint reference 4</wsa:Address>
      </wsa:EndpointReference>
    </wsctx:participant-service>
  </wsctx:participant-services>

  <wsctx:participant-services>
    <wsctx:protocol>protocol4</wsctx:protocol>
    <wsctx:participant-service>
      <wsa:EndpointReference>
        <wsa:Address>endpoint reference 3</wsa:Address>
      </wsa:EndpointReference>
    </wsctx:participant-service>
  </wsctx:participant-services>

Pros - easy to identify which endpoints support a particular protocol (protocol appears only once)
Cons - duplication of participant service information and extra level for grouping.

The third could be specified within a context as follows: -

  <wsctx:participant-services>
    <wsctx:protocol>protocol1</wsctx:protocol>
    <wsctx:protocol>protocol2</wsctx:protocol>
    <wsctx:participant-service>
      <wsa:EndpointReference>
        <wsa:Address>endpoint reference 1</wsa:Address>
      </wsa:EndpointReference>
    </wsctx:participant-service>
  </wsctx:participant-services>

  <wsctx:participant-services>
    <wsctx:protocol>protocol3</wsctx:protocol>
    <wsctx:participant-service>
      <wsa:EndpointReference>
        <wsa:Address>endpoint reference 2</wsa:Address>
      </wsa:EndpointReference>
    </wsctx:participant-service>
    <wsctx:participant-service>
      <wsa:EndpointReference>
        <wsa:Address>endpoint reference 4</wsa:Address>
      </wsa:EndpointReference>
    </wsctx:participant-service>
  </wsctx:participant-services>

  <wsctx:participant-services>
    <wsctx:protocol>protocol2</wsctx:protocol>
    <wsctx:protocol>protocol3</wsctx:protocol>
    <wsctx:protocol>protocol4</wsctx:protocol>
    <wsctx:participant-service>
      <wsa:EndpointReference>
        <wsa:Address>endpoint reference 3</wsa:Address>
      </wsa:EndpointReference>
    </wsctx:participant-service>
  </wsctx:participant-services>

Pros - easy to identify which protocols are supported by an endpoint.
Cons - duplication of protocol information and extra level for grouping.  Requires some work to discover which endpoints support a particular protocol.

I suspect that the majority of the coordination framework contexts will involve a number of endpoints registered for the same protocols.  If others believe this to be the case then my preference would be to use the third suggestion, however I don't see a great difference between first and third (apart from legibility :-) ).

	Kev

-- 
Kevin Conner
Arjuna Technologies Ltd.