SamCooper / COMMON_SPEC_RIDS

1 stars 0 forks source link

StoreCurrent and the service provider #84

Closed lacourte closed 6 years ago

lacourte commented 6 years ago

I meet with two issues implementing the storeCurrent operation. These issues look important enough to me to necessitate a change in the specification. Here is attached a description of services interactions during the execution of the storeCurrent algorithm. The communication between the Configuration service and the service provider goes through the Event service. Common-StoreCurrent-diag.pdf Issue 1 relates to the ability of the Configuration service to return the identifier required in its response message. The storeCurrent operation returns the instance identifier of the Configuration object created during the call to the consumer. 3.4.13.2.i) The response shall contain the object identifier of the new configuration object. The creation of this object has been delegated to the service provider itself. 3.4.13.2.f) The service provider that implements the selected service shall, after the reception of the event, store the current Configuration in the COM Archive. In the diagram I have represented the creation of the identifier by the Archive service itself. However I have no means to pass it back to the Configuration service, so that it can be included in the response message. The choice of allocating the identifier by the Archive service is actually not defined in the specification. Other possibilities may be considered. However the issue remains. If the id is set by the service provider, it still cannot pass it back to the Configuration service. If the configuration service itself wants to set the id, it has no means to pass it to the service provider.

For this issue I advise to change the body type of the ConfigurationStored event to hold this id. A NULL value would replace a false value in the original Boolean type.

Issue 2 relates to the ability of the Configuration service to receive the ConfigurationStored event from the service provider. As I understand the Java mapping interface of Pub/Sub operations, the service publishing a message must define a provider typed as an Event service. In the examples I have seen, the provider is created with the publishing service endpoint. On the other side, the service intending to receive the message must define a consumer typed as an event service, and initialize it with the uri of the Event service provider. In the test code I have seen, the binding between provider and consumer uses the FileBasedDirectory. The provider registers its URIs (two of them) in the directory, and the consumer retrieves them based on a name. I cannot apply this technique here. The Event service provider is the service provider. It may create the provider and register its URIs under a name of its choice. The Event service consumer is the Configuration service. We cannot assume that it knows the name used by the service provider, because it could interact with any services. And nothing in the specification tells it how it can retrieved it dynamically, based on the information it has got at the moment (e.g. source URI ?). As a result we need to use a shared Event service, and I think this should be explicitely stated in the specification.

SamCooper commented 6 years ago

Issue1: Good work, I have made the suggested change Issue2: I have made a note that as the event service is used participating providers should ensure they are all using the same event service provider!