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