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}/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
>
>
--
Asanka Abeyweera
Associate Technical Lead
WSO2 Inc.
Phone: +94 712228648
Blog: a5anka.github.io
<https://wso2.com/signature>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
