Hi Hasitha, We close the connection from the server side.
Thank you, Sasikala On Tue, Jul 10, 2018 at 1:57 PM Hasitha Hiranya <[email protected]> wrote: > Hi Sasikala, > > Close Connection - here we close the connection from server side? Or ask > client to close itself? Former is better, if we can do, because then sever > has the control of it. > > Thanks > > On Tue, Jul 10, 2018 at 10:19 AM Sasikala Kottegoda <[email protected]> > wrote: > >> Hi all, >> >> I am working on adding a separate api for managing AMQP connections. >> Following are the operations that are planned to be implemented. >> >> *Base path: /broker/v1.0/amqp* >> >> Operation Method Path Response >> >> 1 >> Get All Connection >> GET >> /connections >> HTTP/1.1 200 OK >> [ >> { >> connectedIp: "/127.0.0.1:48508", >> channelCount: 1, >> connectedTime: 2018-06-21T17:32:28Z >> }, >> { >> connectedIp: "/127.0.0.1:48524", >> channelCount: 2, >> connectedTime: 2018-06-21T17:32:28Z >> } >> ] >> 2 Close Connection DELETE /connections/{address} HTTP/1.1 200 OK >> { >> message: successfuly closed connection >> } >> Please provide any feed back on the design. A concern was raised if it is >> correct to have the *version in the middle of the context*. Is there a >> better way we can design this since the version is applicable for the >> broker. >> >> I have also attached the swagger.yaml file below. >> >> On Thu, Mar 8, 2018 at 11:14 AM Sanjeewa Malalgoda <[email protected]> >> wrote: >> >>> +1. That looks good. >>> >>> Thanks, >>> sanjeewa. >>> >>> On Thu, Mar 8, 2018 at 11:08 AM, Asanka Abeyweera <[email protected]> >>> wrote: >>> >>>> Hi Sanjeewa, >>>> >>>> Thank you for the feedback. Currently, queue purging is a synchronous >>>> call and we are planning to send back the number of messages removed. >>>> Therefore we are planning to use following response format. >>>> >>>> HTTP/1.1 200 OK >>>> { >>>> "numberOfMessagesDeleted": 0 >>>> } >>>> >>>> >>>> On Thu, Mar 8, 2018 at 10:41 AM, Sanjeewa Malalgoda <[email protected]> >>>> wrote: >>>> >>>>> If purging is handle by background task and completes sometime after >>>>> response return to client then ideal status code would be 202 Accepted. >>>>> Reason is we really do not know what will happen. All we can say is we >>>>> accepted purging job. >>>>> >>>>> If you do not send response but only send status code after purging we >>>>> should use 204. >>>>> >>>>> Thanks, >>>>> sanjeewa. >>>>> >>>>> On Thu, Mar 8, 2018 at 8:49 AM, Asanka Abeyweera <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> I am working adding queue purge functionality to the admin API. I am >>>>>> thinking of using following design. >>>>>> >>>>>> *Request:* >>>>>> >>>>>> DELETE/queues/*queueName*/messages >>>>>> >>>>>> >>>>>> *Success Response:* >>>>>> >>>>>> HTTP/1.1 200 OK >>>>>> >>>>>> >>>>>> WDYT? >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jan 17, 2018 at 10:41 AM, Malintha Amarasinghe < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi Asitha/All, >>>>>>> >>>>>>> The paths overall look good to me too and +1 to the >>>>>>> Harsha's suggestion on pagination. >>>>>>> >>>>>>> I have a small suggestion regarding below concern Asitha has >>>>>>> mentioned: >>>>>>> >>>>>>> >>>>>>> I have few concerns regarding deleting bindings. There is no unique >>>>>>>> key for the binding hence I was thinking of something like following >>>>>>>> for >>>>>>>> the delete binding (combination of routing key and queue name is >>>>>>>> unique) >>>>>>>> */exchanges/{exchangeName}/bindings/{routingKey}/{queueName}* >>>>>>>> What about using something like >>>>>>>> */exchanges/{exchangeName}/bindings?routingKey=myTopic&queueName=tmp_1234 >>>>>>>> *for >>>>>>>> the delete? Can we consider a URI with query params as a unique >>>>>>>> resource? >>>>>>>> >>>>>>> >>>>>>> Shall we introduce a new ID to identify binding? It can be a unique >>>>>>> UUID. This is the approach we have been using in APIM APIs. >>>>>>> >>>>>>> When we create a new binding, the response will include the unique >>>>>>> UUID. >>>>>>> >>>>>>> Eg: >>>>>>> >>>>>>> *Request:* >>>>>>> >>>>>>> POST /exchanges/*exchange1*/bindings >>>>>>> { >>>>>>> "routingKey": "routingPattern", >>>>>>> "queueName": "myQueue", >>>>>>> "filterExpression": "MessageId = 12345" >>>>>>> } >>>>>>> >>>>>>> *Response:* >>>>>>> >>>>>>> HTTP/1.1 201 Created >>>>>>> Location: *https://localhost:9292/admin/1.0 >>>>>>> <https://localhost:9292/admin/1.0>*/exchanges/*exchange1*/bindings/ >>>>>>> *4a349d47-12fa-490c-bb06-d90610a4897d* >>>>>>> >>>>>>> { >>>>>>> * "id" : "4a349d47-12fa-490c-bb06-d90610a4897d"* >>>>>>> "routingKey": "routingPattern", >>>>>>> "queueName": "myQueue", >>>>>>> "filterExpression": "MessageId = 12345" >>>>>>> } >>>>>>> >>>>>>> >>>>>>> We can use this ID for next operations with it. >>>>>>> >>>>>>> Eg: >>>>>>> >>>>>>> GET *https://localhost:9292/admin/1.0 >>>>>>> <https://localhost:9292/admin/1.0>*/exchanges/*exchange1*/bindings/ >>>>>>> *4a349d47-12fa-490c-bb06-d90610a4897d* >>>>>>> DELETE *https://localhost:9292/admin/1.0 >>>>>>> <https://localhost:9292/admin/1.0>*/exchanges/*exchange1*/bindings/ >>>>>>> *4a349d47-12fa-490c-bb06-d90610a4897d* >>>>>>> >>>>>>> Also binding list can include each bindings IDs: >>>>>>> >>>>>>> eg: >>>>>>> >>>>>>> GET /exchanges/*exchange1*/bindings?offset=20&limit=10 >>>>>>> { >>>>>>> "count": 10, >>>>>>> "list": [ { >>>>>>> * "id" : "4a349d47-12fa-490c-bb06-d90610a4897d"* >>>>>>> "routingKey": "routingPattern", >>>>>>> "queueName": "myQueue", >>>>>>> "filterExpression": "MessageId = 12345" >>>>>>> }, >>>>>>> { >>>>>>> * "id" : "d6cf5769-33a1-48e7-b9fd-3db8580292e0"* >>>>>>> "routingKey": "routingPattern2", >>>>>>> "queueName": "myQueue2", >>>>>>> "filterExpression": "MessageId = 123456789" >>>>>>> }, >>>>>>> ... >>>>>>> ... >>>>>>> ], >>>>>>> "pagination": { >>>>>>> "total": 134, >>>>>>> "offset": 20, >>>>>>> "limit": 10, >>>>>>> "next": "/exchanges/*exchange1*/bindings?offset=30&limit=10", >>>>>>> >>>>>>> "previous": "/exchanges/*exchange1* >>>>>>> /bindings?offset=10&limit=10" >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> On Mon, Jan 15, 2018 at 10:49 PM, Harsha Kumara <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jan 12, 2018 at 9:35 AM, Asitha Nanayakkara < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Taking all the concerns discussed in to account I did some updates >>>>>>>>> on the design. >>>>>>>>> >>>>>>>>> With this design, I'll be exposing the exchanges, bindings, >>>>>>>>> queues, and consumers. This is to avoid confusion in coming up with a >>>>>>>>> design to expose topics (pub-sub pattern) as a first-class citizen >>>>>>>>> (Since >>>>>>>>> it is another exchange within the broker). >>>>>>>>> >>>>>>>>> Following is the updated design >>>>>>>>> >>>>>>>>> >>>>>>>>> Base path /broker/v.1.0 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Queues >>>>>>>>> >>>>>>>>> >>>>>>>>> 5 Create Queue/Topic POST /queues/ { "name": "queueName", >>>>>>>>> "durable": true, "autoDelete": false } >>>>>>>>> 6 List Queues/Topics GET /queues >>>>>>>>> 7 Get Queue Details GET /queues/{queueName} >>>>>>>>> 8 Delete Queue DELETE /queues/{queueName} >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Subscriptions for a queue or topic >>>>>>>>> >>>>>>>>> >>>>>>>>> 9 List subscriptions for a destination GET >>>>>>>>> /queues/{queueName}/consumers >>>>>>>>> 10 Get subscriber details GET >>>>>>>>> /queues/{queueName}/consumers/{consumerTag} >>>>>>>>> 11 Close subscriber DELETE >>>>>>>>> /queues/{queueName}/consumers/{consumerTag} >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Exchanges >>>>>>>>> >>>>>>>>> >>>>>>>>> 1 Create Exchange POST /exchanges { "name": "exchangeName", >>>>>>>>> "type": "amq.direct", "durable": true } >>>>>>>>> 2 Get All exchanges GET /exchanges >>>>>>>>> 3 Get Exchange GET /exchanges/{exchangeName} >>>>>>>>> 4 Delete Exchange DELETE /exchanges/{exchangeName} >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Bindings >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> List bindings for exchange GET /exchanges/{exchangeName}/bindings >>>>>>>>> >>>>>>>>> Add binding POST /exchanges/{exchangeName}/bindings {"routingKey": >>>>>>>>> "routingPattern", "queueName": "myQueue", "filterExpression": >>>>>>>>> "MessageId = >>>>>>>>> 12345"} >>>>>>>>> >>>>>>>>> Delete binding DELETE >>>>>>>>> /exchanges/{exchangeName}/bindings/{routingKey}/{queueName} >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I have few concerns regarding deleting bindings. There is no >>>>>>>>> unique key for the binding hence I was thinking of something like >>>>>>>>> following >>>>>>>>> for the delete binding (combination of routing key and queue name is >>>>>>>>> unique) >>>>>>>>> */exchanges/{exchangeName}/bindings/{routingKey}/{queueName}* >>>>>>>>> >>>>>>>>> What about using something like >>>>>>>>> */exchanges/{exchangeName}/bindings?routingKey=myTopic&queueName=tmp_1234 >>>>>>>>> *for the delete? Can we consider a URI with query params as a >>>>>>>>> unique resource? >>>>>>>>> >>>>>>>>> I have attached the swagger file for the API as well. >>>>>>>>> >>>>>>>> Attached swagger is looks fine. You will need to add the details >>>>>>>> about authetication schemes in to the swagger itself which will be >>>>>>>> useful. >>>>>>>> Also the results which returns lists such as queues will be required to >>>>>>>> have pagination. In APIM we are using separate pagination context in >>>>>>>> response as follow. >>>>>>>> >>>>>>>> { >>>>>>>> "count": 2, >>>>>>>> ... >>>>>>>> ... >>>>>>>> "pagination": { >>>>>>>> "total": 4, >>>>>>>> "offset": 0, >>>>>>>> "limit": 2 >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> } >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Asitha >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Jan 11, 2018 at 8:36 AM, Asanka Abeyweera < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi Asitha, >>>>>>>>>> >>>>>>>>>> I think it is better to say queues rather than destinations since >>>>>>>>>> the actions mean different things in queues and topics. For example, >>>>>>>>>> >>>>>>>>>> - Create >>>>>>>>>> - Queues - we can create the queue in broker core. This >>>>>>>>>> will be useful in assigning permissions >>>>>>>>>> - Topics - We can't do anything at broker code. >>>>>>>>>> Corresponding queues will depend on the subscription id if >>>>>>>>>> durable, random >>>>>>>>>> name if non durable. >>>>>>>>>> - Search >>>>>>>>>> - Queues - we can return queues matching the search criteria >>>>>>>>>> - Topics - It's hard to decide what to return since their >>>>>>>>>> can be unlimited number of options. >>>>>>>>>> - Delete >>>>>>>>>> - Queues - we can delete the specified queues >>>>>>>>>> - Topics - Again bit ambiguous what to delete. Maybe we >>>>>>>>>> can go through the matching bindings and delete the matching >>>>>>>>>> queues. My >>>>>>>>>> opinion is we should not do such a thing. >>>>>>>>>> >>>>>>>>>> Addtionally when we are desiging the REST API better if we dont >>>>>>>>>> expose functionalities that we are expecting to expose through the >>>>>>>>>> HTTP >>>>>>>>>> transport. I think the main objective in the first iteration should >>>>>>>>>> be to >>>>>>>>>> assist the users in debugging issues. Some information that a user >>>>>>>>>> might >>>>>>>>>> need is, >>>>>>>>>> >>>>>>>>>> - Queue list >>>>>>>>>> - Subscriptions for a given queue >>>>>>>>>> - Queue details - number messages etc >>>>>>>>>> - Message details >>>>>>>>>> - Permission details >>>>>>>>>> - Binding details of a queue. Will be very useful for topic >>>>>>>>>> scenarios. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Jan 11, 2018 at 12:41 AM, Eranda Rajapakshe < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Asitha, >>>>>>>>>>> >>>>>>>>>>> Thanks for the explanation. >>>>>>>>>>> >>>>>>>>>>> On Wed, Jan 10, 2018 at 10:29 PM, Asitha Nanayakkara < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Eranda, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Jan 10, 2018 at 6:47 PM, Eranda Rajapakshe < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> Small addition to the Malintha's suggestion, I think a binding >>>>>>>>>>>>> should be a 3-tuple element <exchange-name, queue-name, >>>>>>>>>>>>> routing-key> >>>>>>>>>>>>> >>>>>>>>>>>> For Bindings, we'll be using queue-name, routing-key, and >>>>>>>>>>>> filters. Exchange name can be inferred since we define bindings >>>>>>>>>>>> for a given >>>>>>>>>>>> exchange. >>>>>>>>>>>> >>>>>>>>>>> +1 >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Also, is it correct to use the term "destination" to >>>>>>>>>>>>> generalize queues and topics? AFAIK it's coming from the JMS >>>>>>>>>>>>> world. >>>>>>>>>>>>> >>>>>>>>>>>> Yes, If we are going with a separate path for queues, outside >>>>>>>>>>>> /exchanges, we can have something like /queues. Used destinations >>>>>>>>>>>> to avoid >>>>>>>>>>>> the confusion with queues and topics. >>>>>>>>>>>> >>>>>>>>>>> Understood. +1 >>>>>>>>>>> I think its better to use the term "queue" if we are going to >>>>>>>>>>> expose this as a AMQP broker. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Jan 10, 2018 at 6:29 PM, Asitha Nanayakkara < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> @Eranda: Thanks for pointing out the concern. We will be able >>>>>>>>>>>>>> to get over this concern by way of following the approach >>>>>>>>>>>>>> suggested by >>>>>>>>>>>>>> Malintha. >>>>>>>>>>>>>> >>>>>>>>>>>>>> @Malintha; Only concern I have with exposing GET >>>>>>>>>>>>>> /destinations is, we will expose all the queues, including >>>>>>>>>>>>>> temporary queues >>>>>>>>>>>>>> created for topics. Maybe we might be able to get over this by >>>>>>>>>>>>>> way of using >>>>>>>>>>>>>> filters. >>>>>>>>>>>>>> >>>>>>>>>>>>>> @Sanjeewa: We are planning to write this admin service using >>>>>>>>>>>>>> MSF4J and we are exposing this to do administrative tasks on the >>>>>>>>>>>>>> broker. >>>>>>>>>>>>>> Eventually the broker UI will use these servises as well. I will >>>>>>>>>>>>>> work on >>>>>>>>>>>>>> creating the swagger definitions based on these suggessions. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> Asitha >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Jan 10, 2018 at 6:10 PM, Malintha Amarasinghe < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> A suggestion for Eranda's concern, for that I think we need >>>>>>>>>>>>>>> to remove the "exchanges" from the destinations APIs. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> One possible solution is: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Create Queue/Topic* >>>>>>>>>>>>>>> POST /destinations { "name": "queueName", "durable": true, >>>>>>>>>>>>>>> "autoDelete": false } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *List Queues/Topics * >>>>>>>>>>>>>>> GET /destinations >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Get Queue Details * >>>>>>>>>>>>>>> GET /destinations/{destinationName} >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Delete Queue * >>>>>>>>>>>>>>> DELETE /destinations/{destinationName} >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *New APIs for adding/retrieving bindings:* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Add a new binding: (not sure about the name "binding" is >>>>>>>>>>>>>>> appropriate)* >>>>>>>>>>>>>>> POST /bindings >>>>>>>>>>>>>>> { >>>>>>>>>>>>>>> "exchangeName" : "exchange1", >>>>>>>>>>>>>>> "destinationName" : "destination1" >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Get bindings for a particular exchange:* >>>>>>>>>>>>>>> GET /bindings?exchangeName="exchange1" => Provides a list of >>>>>>>>>>>>>>> bindings for the particular exchange >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> During a discussion, Asitha mentioned about default >>>>>>>>>>>>>>> exchange; If exchangeName is not provided can we use it as its >>>>>>>>>>>>>>> default >>>>>>>>>>>>>>> value? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Jan 10, 2018 at 5:59 PM, Sanjeewa Malalgoda < >>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Jan 10, 2018 at 5:40 PM, Asitha Nanayakkara < >>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Adding Harshak, Sanjeewa and Malinthaa >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wed, Jan 10, 2018 at 5:37 PM, Asitha Nanayakkara < >>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> In the new message broker implementation we are >>>>>>>>>>>>>>>>>> implementing broker semantics based on AMQP 0.9.1 >>>>>>>>>>>>>>>>>> specification. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> From an administrative operations perspective, we have >>>>>>>>>>>>>>>>>> identified following resources to be exposed through restful >>>>>>>>>>>>>>>>>> web services. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - exchanges >>>>>>>>>>>>>>>>>> - queues >>>>>>>>>>>>>>>>>> - topics >>>>>>>>>>>>>>>>>> - consumers >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> There are currently two types of exchange. Namely, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - direct exchange - relates to mostly known queue >>>>>>>>>>>>>>>>>> scenarios >>>>>>>>>>>>>>>>>> - topic exchange - relates to topic scenarios >>>>>>>>>>>>>>>>>> (pub-sub pattern) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> *Queues and topics* >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Within the broker, there are only queues. These queues >>>>>>>>>>>>>>>>>> are bound to direct and topic exchanges. Depending on the >>>>>>>>>>>>>>>>>> bound exchange we >>>>>>>>>>>>>>>>>> perceive them as either pub-sub pattern or queue pattern. >>>>>>>>>>>>>>>>>> Therefore within the Admin API's we refer to either a >>>>>>>>>>>>>>>>>> queue or a topic as a *destination.* >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> *Consumers* >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> For each internal queue (a destination) there will be >>>>>>>>>>>>>>>>>> consumers. Messages are delivered to consumers in round >>>>>>>>>>>>>>>>>> robin manner. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> In topic scenario (pub-sub pattern) topic exchange will >>>>>>>>>>>>>>>>>> bind a separate queue (a destination) per each consumer with >>>>>>>>>>>>>>>>>> the same topic >>>>>>>>>>>>>>>>>> name. When a message is published it will get delivered to >>>>>>>>>>>>>>>>>> the set of >>>>>>>>>>>>>>>>>> queues with the matching topic and then to the relevant >>>>>>>>>>>>>>>>>> consumers on those >>>>>>>>>>>>>>>>>> queues >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Considering the above broker semantics we have come up >>>>>>>>>>>>>>>>>> with the following Admin API design for the broker >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Base path /broker/v.1.0 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> *Exchanges* >>>>>>>>>>>>>>>>>> *Method* >>>>>>>>>>>>>>>>>> *Path* >>>>>>>>>>>>>>>>>> *Payload* >>>>>>>>>>>>>>>>>> 1 Create Exchange POST /exchanges { "name": >>>>>>>>>>>>>>>>>> "exchangeName", "type": "amq.direct", "durable": true } >>>>>>>>>>>>>>>>>> 2 Get All exchanges GET /exchanges >>>>>>>>>>>>>>>>>> 3 Get Exchange GET /exchanges/{exchangeName} >>>>>>>>>>>>>>>>>> 4 Delete Exchange DELETE /exchanges/{exchangeName} >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> *Destinations (Queues/Topics)* >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 5 Create Queue/Topic POST >>>>>>>>>>>>>>>>>> /exchanges/{exchangeName}/destinations { "name": >>>>>>>>>>>>>>>>>> "queueName", "durable": true, "autoDelete": false } >>>>>>>>>>>>>>>>>> 6 List Queues/Topics GET >>>>>>>>>>>>>>>>>> /exchanges/{exchangeName}/destinations >>>>>>>>>>>>>>>>>> 7 Get Queue Details GET >>>>>>>>>>>>>>>>>> /exchanges/{exchangeName}/destinations/{destinationName} >>>>>>>>>>>>>>>>>> 8 Delete Queue DELETE >>>>>>>>>>>>>>>>>> /exchanges/{exchangeName}/destinations/{destinationName} >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> *Consumers (for a queue or topic)* >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 9 List subscriptions for a destination GET >>>>>>>>>>>>>>>>>> /exchanges/{exchangeName}/destinations/{destinationName}/consumers >>>>>>>>>>>>>>>>>> 10 Get subscriber details GET >>>>>>>>>>>>>>>>>> /exchanges/{exchangeName}/destinations/{destinationName}/consumers/{consumerTag} >>>>>>>>>>>>>>>>>> 11 Close subscriber DELETE >>>>>>>>>>>>>>>>>> /exchanges/{exchangeName}/destinations/{destinationName}/consumers/{consumerTag} >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> When retrieving a set of exchanges, destinations or >>>>>>>>>>>>>>>>>> consumers we will be able to filter the result set by way of >>>>>>>>>>>>>>>>>> using query >>>>>>>>>>>>>>>>>> parameters. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This API looks good and followed REST nature. I assume >>>>>>>>>>>>>>>> exchange name, destination name, consumer tag etc are unique. >>>>>>>>>>>>>>>> Then only we >>>>>>>>>>>>>>>> can build above mentioned resource model. >>>>>>>>>>>>>>>> Also do we need to let users to check the possibility of >>>>>>>>>>>>>>>> creating exchange, destination or consumer tag before we >>>>>>>>>>>>>>>> create it. Then we >>>>>>>>>>>>>>>> might need http head method as well. >>>>>>>>>>>>>>>> If you need to update que details then you have to use put >>>>>>>>>>>>>>>> as well. Ex: enable/disable auto delete after we create it >>>>>>>>>>>>>>>> first time. >>>>>>>>>>>>>>>> Also lets define proper response codes as well(201 to >>>>>>>>>>>>>>>> created, 202 accepted etc). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> What is the plan to expose this API to outside? Is it >>>>>>>>>>>>>>>> MSF4J? If that is the case you can start with swagger >>>>>>>>>>>>>>>> definition and move >>>>>>>>>>>>>>>> forward. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> sanjeewa. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>> Asitha >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> *Asitha Nanayakkara* <http://asitha.github.io/> >>>>>>>>>>>>>>>>>> Associate Technical Lead >>>>>>>>>>>>>>>>>> WSO2, Inc. <http://wso2.com/> >>>>>>>>>>>>>>>>>> Mob: +94 77 853 0682 <+94%2077%20853%200682> >>>>>>>>>>>>>>>>>> [image: https://wso2.com/signature] >>>>>>>>>>>>>>>>>> <https://wso2.com/signature> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> *Asitha Nanayakkara* <http://asitha.github.io/> >>>>>>>>>>>>>>>>> Associate Technical Lead >>>>>>>>>>>>>>>>> WSO2, Inc. <http://wso2.com/> >>>>>>>>>>>>>>>>> Mob: +94 77 853 0682 <077%20853%200682> >>>>>>>>>>>>>>>>> [image: https://wso2.com/signature] >>>>>>>>>>>>>>>>> <https://wso2.com/signature> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *Sanjeewa Malalgoda* >>>>>>>>>>>>>>>> WSO2 Inc. >>>>>>>>>>>>>>>> Mobile : +94713068779 <+94%2071%20306%208779> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Malintha Amarasinghe >>>>>>>>>>>>>>> *WSO2, Inc. - lean | enterprise | middleware* >>>>>>>>>>>>>>> http://wso2.com/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Mobile : +94 712383306 <+94%2071%20238%203306> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> *Asitha Nanayakkara* <http://asitha.github.io/> >>>>>>>>>>>>>> Associate Technical Lead >>>>>>>>>>>>>> WSO2, Inc. <http://wso2.com/> >>>>>>>>>>>>>> Mob: +94 77 853 0682 <+94%2077%20853%200682> >>>>>>>>>>>>>> [image: https://wso2.com/signature] >>>>>>>>>>>>>> <https://wso2.com/signature> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> *Eranda Rajapakshe* >>>>>>>>>>>>> Software Engineer >>>>>>>>>>>>> WSO2 Inc. >>>>>>>>>>>>> Mobile : +94784822608 >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> *Asitha Nanayakkara* <http://asitha.github.io/> >>>>>>>>>>>> Associate Technical Lead >>>>>>>>>>>> WSO2, Inc. <http://wso2.com/> >>>>>>>>>>>> Mob: +94 77 853 0682 <+94%2077%20853%200682> >>>>>>>>>>>> [image: https://wso2.com/signature] >>>>>>>>>>>> <https://wso2.com/signature> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> *Eranda Rajapakshe* >>>>>>>>>>> Software Engineer >>>>>>>>>>> WSO2 Inc. >>>>>>>>>>> Mobile : +94784822608 >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Architecture mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Asanka Abeyweera >>>>>>>>>> Associate Technical Lead >>>>>>>>>> WSO2 Inc. >>>>>>>>>> >>>>>>>>>> Phone: +94 712228648 <+94%2071%20222%208648> >>>>>>>>>> Blog: a5anka.github.io >>>>>>>>>> >>>>>>>>>> <https://wso2.com/signature> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Asitha Nanayakkara* <http://asitha.github.io/> >>>>>>>>> Associate Technical Lead >>>>>>>>> WSO2, Inc. <http://wso2.com/> >>>>>>>>> Mob: +94 77 853 0682 <+94%2077%20853%200682> >>>>>>>>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Architecture mailing list >>>>>>>>> [email protected] >>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Harsha Kumara >>>>>>>> Software Engineer, WSO2 Inc. >>>>>>>> Mobile: +94775505618 <+94%2077%20550%205618> >>>>>>>> Blog:harshcreationz.blogspot.com >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Malintha Amarasinghe >>>>>>> *WSO2, Inc. - lean | enterprise | middleware* >>>>>>> http://wso2.com/ >>>>>>> >>>>>>> Mobile : +94 712383306 <+94%2071%20238%203306> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Asanka Abeyweera >>>>>> Associate Technical Lead >>>>>> WSO2 Inc. >>>>>> >>>>>> Phone: +94 712228648 <071%20222%208648> >>>>>> Blog: a5anka.github.io >>>>>> >>>>>> <https://wso2.com/signature> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Sanjeewa Malalgoda* >>>>> WSO2 Inc. >>>>> Mobile : +94713068779 <+94%2071%20306%208779> >>>>> >>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> >>>> -- Sasikala Kottegoda *Senior Software Engineer* WSO2 Inc., http://wso2.com/ lean. enterprise. middleware Mobile: +94 774835928 [image: https://wso2.com/signature] <https://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
