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. > > 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. > > 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 [image: https://wso2.com/signature] <https://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
