OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

amqp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [amqp] Groups - amqp-man-v1.0-wd15.docx uploaded


Hi AMQP TC Committee,

 

I would like to clarify my suggestion to model versioning.

 

As per my previous email, currently amqp management spec does not provide a versioning of entire model. It only offers versioning of entity types through property “type version”. The latter does not allow to access the same entity using different versions of management model. Though, it allows to have entities of different versions.

 

I think, that amqp management should provide versioning of management model similar to versioning of REST API. The version of management model can automatically apply to all entity types within the model. Thus, if client only supports previous management model and that management model is still supported by the broker, it should be able to access all broker management entities using previous model version operations, collections, etc.

 

I think that root $management discovery document should only provide information about current and supported versions. Thus, request to $management should return json with current version and relative addresses of all supported versions. As result, the particular version management URLs would look like

 

$management/v1.0

$management/v2.0

$management/latest

 

By navigating to the version link, the version specific model discovery document should be returned to the user (containing collections, types, operations, configuration)

 

Apart from latest model version and supported version management addresses, the $management document can contain such information like

·         Amqp management spec version it is compatible with

·         Open API spec version (provided that entity management operations would be described using OpenAPI spec for operationObject - https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md#operationObject)

·         Potentially, root  $management can contains information as specified in Open API infoObject https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md#infoObject

 

The versioning of entire model would make  redundant “type version” in meta-type.

 

Kind Regards,

Alex

 

 

From: Rudyy, Oleksandr
Sent: Friday, June 28, 2019 6:05 PM
To: 'Clemens Vasters' <clemensv@microsoft.com>; 'amqp@lists.oasis-open.org' <amqp@lists.oasis-open.org>; 'Rob Godfrey' <rgodfrey@redhat.com>
Subject: RE: [amqp] Groups - amqp-man-v1.0-wd15.docx uploaded

 

Hi,

I would like to re-iterate the issue I raised during last TC meeting about versioning of entire model.

 

The current management draft only defines versioning of entities. There is no versioning defined for entire management model.

I think it would be useful to add it in some way.

 

That should allow to distinguish current management model from previous ones by client connecting to management nodes and expecting a support of certain management model version.

 

Additionally, it would be useful to add a mechanism of communicating of supported management models. Thus, if broker supports management model versions 1.0 and 2.0, and, client only supports management model version 1.0, it can switch to older management.

 

I hope that the above makes sense J

 

Kind Regards,

Alex

This message is confidential and subject to terms at: https://www.jpmorgan.com/emaildisclaimer including on confidential, privileged or legal entity information, viruses and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]