Hi Sanjeewa,
Thank you for the feedback. Currently, queue purging is a synchronous call
and we are planning to send back the number of messages removed. Therefore
we are planning to use following response format.
HTTP/1.1 200 OK
{
"numberOfMessagesDeleted": 0
}
On Thu, Mar 8, 2018 at 10:41 AM, Sanjeewa Malalgoda <sanje...@wso2.com>
wrote:
> If purging is handle by background task and completes sometime after
> response return to client then ideal status code would be 202 Accepted.
> Reason is we really do not know what will happen. All we can say is we
> accepted purging job.
>
> If you do not send response but only send status code after purging we
> should use 204.
>
> Thanks,
> sanjeewa.
>
> On Thu, Mar 8, 2018 at 8:49 AM, Asanka Abeyweera <asank...@wso2.com>
> wrote:
>
>> Hi All,
>>
>> I am working adding queue purge functionality to the admin API. I am
>> thinking of using following design.
>>
>> *Request:*
>>
>> DELETE/queues/*queueName*/messages
>>
>>
>> *Success Response:*
>>
>> HTTP/1.1 200 OK
>>
>>
>> WDYT?
>>
>>
>>
>> On Wed, Jan 17, 2018 at 10:41 AM, Malintha Amarasinghe <
>> malint...@wso2.com> wrote:
>>
>>> Hi Asitha/All,
>>>
>>> The paths overall look good to me too and +1 to the Harsha's suggestion
>>> on pagination.
>>>
>>> I have a small suggestion regarding below concern Asitha has mentioned:
>>>
>>>
>>> I have few concerns regarding deleting bindings. There is no unique key
>>>> for the binding hence I was thinking of something like following for the
>>>> delete binding (combination of routing key and queue name is unique)
>>>> */exchanges/{exchangeName}/bindings/{routingKey}/{queueName}*
>>>> What about using something like
>>>> */exchanges/{exchangeName}/bindings?routingKey=myTopic&queueName=tmp_1234
>>>> *for
>>>> the delete? Can we consider a URI with query params as a unique resource?
>>>>
>>>
>>> Shall we introduce a new ID to identify binding? It can be a unique
>>> UUID. This is the approach we have been using in APIM APIs.
>>>
>>> When we create a new binding, the response will include the unique UUID.
>>>
>>> Eg:
>>>
>>> *Request:*
>>>
>>> POST /exchanges/*exchange1*/bindings
>>> {
>>> "routingKey": "routingPattern",
>>> "queueName": "myQueue",
>>> "filterExpression": "MessageId = 12345"
>>> }
>>>
>>> *Response:*
>>>
>>> HTTP/1.1 201 Created
>>> Location: *https://localhost:9292/admin/1.0
>>> <https://localhost:9292/admin/1.0>*/exchanges/*exchange1*/bindings/
>>> *4a349d47-12fa-490c-bb06-d90610a4897d*
>>>
>>> {
>>> * "id" : "4a349d47-12fa-490c-bb06-d90610a4897d"*
>>> "routingKey": "routingPattern",
>>> "queueName": "myQueue",
>>> "filterExpression": "MessageId = 12345"
>>> }
>>>
>>>
>>> We can use this ID for next operations with it.
>>>
>>> Eg:
>>>
>>> GET *https://localhost:9292/admin/1.0
>>> <https://localhost:9292/admin/1.0>*/exchanges/*exchange1*/bindings/
>>> *4a349d47-12fa-490c-bb06-d90610a4897d*
>>> DELETE *https://localhost:9292/admin/1.0
>>> <https://localhost:9292/admin/1.0>*/exchanges/*exchange1*/bindings/
>>> *4a349d47-12fa-490c-bb06-d90610a4897d*
>>>
>>> Also binding list can include each bindings IDs:
>>>
>>> eg:
>>>
>>> GET /exchanges/*exchange1*/bindings?offset=20&limit=10
>>> {
>>> "count": 10,
>>> "list": [ {
>>> * "id" : "4a349d47-12fa-490c-bb06-d90610a4897d"*
>>> "routingKey": "routingPattern",
>>> "queueName": "myQueue",
>>> "filterExpression": "MessageId = 12345"
>>> },
>>> {
>>> * "id" : "d6cf5769-33a1-48e7-b9fd-3db8580292e0"*
>>> "routingKey": "routingPattern2",
>>> "queueName": "myQueue2",
>>> "filterExpression": "MessageId = 123456789"
>>> },
>>> ...
>>> ...
>>> ],
>>> "pagination": {
>>> "total": 134,
>>> "offset": 20,
>>> "limit": 10,
>>> "next": "/exchanges/*exchange1*/bindings?offset=30&limit=10",
>>> "previous": "/exchanges/*exchange1*/bindings?offset=10&limit=10"
>>> }
>>> }
>>>
>>> Thanks!
>>>
>>> On Mon, Jan 15, 2018 at 10:49 PM, Harsha Kumara <hars...@wso2.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Jan 12, 2018 at 9:35 AM, Asitha Nanayakkara <asi...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Taking all the concerns discussed in to account I did some updates on
>>>>> the design.
>>>>>
>>>>> With this design, I'll be exposing the exchanges, bindings, queues,
>>>>> and consumers. This is to avoid confusion in coming up with a design to
>>>>> expose topics (pub-sub pattern) as a first-class citizen (Since it is
>>>>> another exchange within the broker).
>>>>>
>>>>> Following is the updated design
>>>>>
>>>>>
>>>>> Base path /broker/v.1.0
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Queues
>>>>>
>>>>>
>>>>> 5 Create Queue/Topic POST /queues/ { "name": "queueName", "durable":
>>>>> true, "autoDelete": false }
>>>>> 6 List Queues/Topics GET /queues
>>>>> 7 Get Queue Details GET /queues/{queueName}
>>>>> 8 Delete Queue DELETE /queues/{queueName}
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Subscriptions for a queue or topic
>>>>>
>>>>>
>>>>> 9 List subscriptions for a destination GET
>>>>> /queues/{queueName}/consumers
>>>>> 10 Get subscriber details GET /queues/{queueName}/consumers/
>>>>> {consumerTag}
>>>>> 11 Close subscriber DELETE /queues/{queueName}/consumers/{consumerTag}
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Exchanges
>>>>>
>>>>>
>>>>> 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}
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Bindings
>>>>>
>>>>>
>>>>>
>>>>> List bindings for exchange GET /exchanges/{exchangeName}/bindings
>>>>>
>>>>> Add binding POST /exchanges/{exchangeName}/bindings {"routingKey":
>>>>> "routingPattern", "queueName": "myQueue", "filterExpression": "MessageId =
>>>>> 12345"}
>>>>>
>>>>> Delete binding DELETE /exchanges/{exchangeName}/bind
>>>>> ings/{routingKey}/{queueName}
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I have few concerns regarding deleting bindings. There is no unique
>>>>> key for the binding hence I was thinking of something like following for
>>>>> the delete binding (combination of routing key and queue name is unique)
>>>>> */exchanges/{exchangeName}/bindings/{routingKey}/{queueName}*
>>>>>
>>>>> What about using something like
>>>>> */exchanges/{exchangeName}/bindings?routingKey=myTopic&queueName=tmp_1234
>>>>> *for the delete? Can we consider a URI with query params as a unique
>>>>> resource?
>>>>>
>>>>> I have attached the swagger file for the API as well.
>>>>>
>>>> Attached swagger is looks fine. You will need to add the details about
>>>> authetication schemes in to the swagger itself which will be useful. Also
>>>> the results which returns lists such as queues will be required to have
>>>> pagination. In APIM we are using separate pagination context in response as
>>>> follow.
>>>>
>>>> {
>>>> "count": 2,
>>>> ...
>>>> ...
>>>> "pagination": {
>>>> "total": 4,
>>>> "offset": 0,
>>>> "limit": 2
>>>>
>>>> }
>>>>
>>>> }
>>>>>
>>>>>
>>>>> Regards,
>>>>> Asitha
>>>>>
>>>>>
>>>>> On Thu, Jan 11, 2018 at 8:36 AM, Asanka Abeyweera <asank...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> 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 <eran...@wso2.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Hi Asitha,
>>>>>>>
>>>>>>> Thanks for the explanation.
>>>>>>>
>>>>>>> On Wed, Jan 10, 2018 at 10:29 PM, Asitha Nanayakkara <
>>>>>>> asi...@wso2.com> wrote:
>>>>>>>
>>>>>>>> Hi Eranda,
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jan 10, 2018 at 6:47 PM, Eranda Rajapakshe <
>>>>>>>> eran...@wso2.com> 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 <
>>>>>>>>> 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}/dest
>>>>>>>>>>>>>> inations { "name": "queueName", "durable": true,
>>>>>>>>>>>>>> "autoDelete": false }
>>>>>>>>>>>>>> 6 List Queues/Topics GET /exchanges/{exchangeName}/dest
>>>>>>>>>>>>>> inations
>>>>>>>>>>>>>> 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}/con
>>>>>>>>>>>>>> sumers
>>>>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> *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
>>>>>>> Architecture@wso2.org
>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Asanka Abeyweera
>>>>>> Associate Technical Lead
>>>>>> WSO2 Inc.
>>>>>>
>>>>>> Phone: +94 712228648 <+94%2071%20222%208648>
>>>>>> Blog: a5anka.github.io
>>>>>>
>>>>>> <https://wso2.com/signature>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Harsha Kumara
>>>> Software Engineer, WSO2 Inc.
>>>> Mobile: +94775505618 <+94%2077%20550%205618>
>>>> Blog:harshcreationz.blogspot.com
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Malintha Amarasinghe
>>> *WSO2, Inc. - lean | enterprise | middleware*
>>> http://wso2.com/
>>>
>>> Mobile : +94 712383306 <+94%2071%20238%203306>
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Asanka Abeyweera
>> Associate Technical Lead
>> WSO2 Inc.
>>
>> Phone: +94 712228648 <071%20222%208648>
>> Blog: a5anka.github.io
>>
>> <https://wso2.com/signature>
>>
>> _______________________________________________
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779 <+94%2071%20306%208779>
>
> <http://sanjeewamalalgoda.blogspot.com/>blog
> :http://sanjeewamalalgoda.blogspot.com/
> <http://sanjeewamalalgoda.blogspot.com/>
>
>
>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Asanka Abeyweera
Associate Technical Lead
WSO2 Inc.
Phone: +94 712228648 <+94%2071%20222%208648>
Blog: a5anka.github.io
<https://wso2.com/signature>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
