[Configuration Service] Operation Activate should wait until the provider has switched its configuration

[ochurlaud]

The Operation Activate should wait until the provider has switched its configuration to keep the service status coherent with the managed provider.

[SamCooper]

That would make it a potentially long running operation and we would therefore have to change it to an INVOKE or PROGRESS operation.

What inconsistency results of the current behaviour?

[lacourte]

This operation currently follows a Submit IP. It terminates successfully as soon as the Configuration service has sent a ConfigurationSwitch event to the provider. However the actual algorithm is not complete. It continues in the provider itself, and it might fail at that point. In that case it is stated that the provider must revert to its previous configuration, and the Configuration service learns it when it receives the ConfigurationSwitchResult event. However this creates a window where the Configuration service is not sure about the "currently active configuration" of the provider. If anyone calls it for a getCurrent, it may be optimistic and provide the new configuration, or cautious and still provide the old one.

Making the operation wait for the result does not remove the uncertainty window. It does not help if another client calls the Configuration service in between. But at least it makes the result clear for the original caller of the activate operation. With the current definition, the original client of the activate operation should register for the ConfigurationSwitchResult event from the provider to know the result of its operation. If the activate wait for the event, it could return the failure with an error (UNKNOWN, or a new one to declare).

If the operation may be long running, then i understand that at least the Java interface provides an asynchronous calling pattern. This reduces the trouble of a blocking operation.

[ochurlaud]

IMO, if the update of the provider configuration can be long, it should be done with an event that the Consumer has to be subscribed to. Progress seems overkill. If if we go toward this, we will then the spec has to be updated accordingly

[SamCooper]

I think we should leave it as an Event based pattern but I should change the operation to "requestActivation" or some such naming to indicate that it is requesting the activation.

Does this work?

[lacourte]

This does not really answer to the original caller question. Do you think the original caller might want to know if the operation has actually succeeded ? If so, as the function is now, he will need to subscribe for the ConfigurationSwitchResult event from the provider, which is really not comfortable. What do you think of the point I raise about the asynchronous calling pattern in the Java interface ? This would not block the caller, and make it more comfortable for him to know the actual result of the operation.

[SamCooper]

The async interface is an API specific feature and we cannot use that in the service specification.

Yes I agree the caller probably does want to know that it completes (or fails). We can do that either by changing the pattern (I think we all agree SUBMIT isn't enough) or by requiring them to listen for the completion event.

I am happy to go either way, what is your preference?

[ochurlaud]

I would go to the event based pattern. anyway in the future I forsee that we will have more of such cases where you send a request and, some day, get a notification that it's over. For instance if you want to execute remote processes or have a system share a file with another one. The duration is unknown so you cannot block the caller. I don't see how to do it otherwise.

[SamCooper]

@lacourte what is your view?

[lacourte]

My favor goes on the Progress pattern instead. Here is some rationale:

• currently the eventual success or failure of the operation is signaled by the (configured) service provider with the ConfigurationSwitchResult event. This event is read by the Configuration service. I don't think that the consumer could easily react to this event. The event pattern would then require the definition of a new event type to be published by the Configuration service.
• from the point of view of the consumer, it is much more comfortable to use a Progress IP than a Request IP followed by a PubSub to get the result.
• the problem of an interaction with unknown duration should not be a problem for Progress IP. Here is a quote from the MAL book:

  The PROGRESS pattern is expected to be used when there is a significant or indeterminate amount of time taken to process the request and produce the data response, ...

[SamCooper]

What would the progress pattern report during its progress? I am not sure there is anything that would be reported. For example if the Configuration service provider is just looking for the events of the actual service provider(s) then it is still indeterminate whether you will get anything back until the configuration change has been made.

If there is nothing to report then I recommend we consider INVOKE:

The INVOKE pattern is expected to be used when there is a significant or indeterminate amount of time taken to process the request and produce the data response.

[lacourte]

You are right. There is only an ACK to send in between, reporting that the parameters are correct and that the order has been sent to the configured service provider.

[SamCooper]

@ochurlaud what do you think? BTW the Event broadcast is still there, this is just something on top. @lacourte can confirm but I think the Configuration service provider is already needing to listen for the Event to update its internal details so it is actually not a big change in terms of implementation.

[lacourte]

Yes the Configuration service provider needs to listen to events from the configured service provider. This is required also for other events.

[ochurlaud]

I thought invoke was already ruled out. If not, I think it's a better option than progress. I don't have strong opinion between using invoke or an event. maybe the invoke helps with considering the transaction as a whole and that it ends when the actual action is over on the provider side

[SamCooper]

Ok, so I'll make it INVOKE, the events stay the same.

I'll see if there is anything useful the INVOKE-ACK can return (@lacourte do you have any ideas), but the INVOKE-RESPONSE should return the information held in the final Event I think,

[SamCooper]

Done, we can open new issues for when you see the update and no-doubt find the problems in it!