'objectiser' wrote:

With the WS-CDL scenario, I would imagine that the choreography would be stored in the repository as an independent artefact, and then when the service is registered, it would include the meta-data to reference the WS-CDL, and also meta-data to identify the participant type.

Eventually (hopefully) it will be possible to also record the endpoint's behavioural description with the service itself - but this will also be compatible with the WS-CDL approach - as the endpoint description could then be frequently checked against the endpoint description to ensure continued conformance. The problem with the WS-CDL only reference, is that if the WS-CDL was to be updated, it does not guarantee to continue to represent the endpoint behaviour represented by the service implementation.

So there are a number of issues to be addressed, and it may depend how you wish users to work with the repository/registry - so needs further thought/discussion.

"mark.little" wrote:

Yes, I was wondering if we could add something like Atom support to a filter in the ESB so that updates could be pushed through to the service container when they happen. I like Atom for this sort of thing, but the downside is that there are no guarantees on delivery or notification, so for some choreographies it may be too lax.

"mark.little wrote:

There are some other approaches we could consider apart from the one mentioned above. For instance, we could instrument the choreography with a time-to-live attribute, so that the service can poll for updates less frequently.