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>
Also, is it correct to use the term "destination" to generalize queues and
topics? AFAIK it's coming from the JMS world.
Thanks,
On Wed, Jan 10, 2018 at 6:29 PM, Asitha Nanayakkara <asi...@wso2.com> 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 <malint...@wso2.com>
> 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 <sanje...@wso2.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, Jan 10, 2018 at 5:40 PM, Asitha Nanayakkara <asi...@wso2.com>
>>> wrote:
>>>
>>>> Adding Harshak, Sanjeewa and Malinthaa
>>>>
>>>> On Wed, Jan 10, 2018 at 5:37 PM, Asitha Nanayakkara <asi...@wso2.com>
>>>> 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
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
*Eranda Rajapakshe*
Software Engineer
WSO2 Inc.
Mobile : +94784822608
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
