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}/dest >>>>>>> inations/{destinationName} >>>>>>> 8 Delete Queue DELETE /exchanges/{exchangeName}/dest >>>>>>> inations/{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}/dest >>>>>>> inations/{destinationName}/consumers/{consumerTag} >>>>>>> 11 Close subscriber DELETE /exchanges/{exchangeName}/dest >>>>>>> inations/{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
