[Architecture] Assigning Permanent Unique Element Identifiers for the Elements in a Siddhi Query

[Miyuru Dayarathna]

Hi,

Snapshotable [1] is the parent interface in Siddhi which should be
implemented by every processing element of a Siddhi event processing chain
to enable their state to be persisted and restored. Snapshotable
interface's getElementId()
method returns unique element identifiers (i.e., element ID) for each of
the elements in the Siddhi query.

@app:name('Test')
define stream StockStream ( symbol string, price float, volume int );
@info(name = 'query1')
from StockStream[price>10]#window.length(10)
select symbol, price, sum(volume) as totalVol
insert into OutStream

For a Siddhi query such as the one shown above, the length window may get
assigned an element ID such as "AbstractStreamProcessor-Test-1". The format
of this element ID is --.

These unique element identifiers are unique only for that particular Siddhi
query. Such characteristics is completely fine as long as the Siddhi
application does not change. However, if new elements get added to the
Siddhi query, there is a rare possibility of loading invalid state into the
stream application. An example of such scenario has been reported in [2].
Similar issues would have to be faced in scenarios such as upgrades and
rollbacks, cross datacenter failover, state archiving, application
migration, etc. One solution for this issue is to keep track of the changes
made to the Siddhi application while maintaining a permanent unique ID
across the application's life cycle. If for example a new segment Y was
added to a Siddhi application X which creates a new application XY, we
could load the state of the already checkpointed segment (X) to the new
Siddhi application (XY) and then assign new IDs for the elements in the
newly added segment (Y). If we delete a segment Z from XY, then we will be
loading only elements pertaining to the remaining portion. The checkpoints
corresponding to the segment Z will be eventually cleaned by the state
management mechanism.

[1]
https://github.com/wso2/siddhi/blob/master/modules/siddhi-core/src/main/java/org/wso2/siddhi/core/util/snapshot/Snapshotable.java

[2] https://github.com/wso2/siddhi/issues/776

-- 
Thanks,
Miyuru Dayarathna
Senior Technical Lead
Mobile: +94713527783
Blog: http://miyurublog.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [RRT] XACML based scope validator (during OAuth2 token validation)

[Senthalan Kanagalingam]

Hi Denuwanthi, DinushaD,

As the order of the scope validators was shuffled when transferring from
service to UI. So we decided to show them in alphabetical order to maintain
consistency in the UI. Before we haven't thought about the execution
order.  As it's valuable to the users, we will change the order as in the
identity.xml.

Thanks,
Senthalan

On Mon, Mar 5, 2018 at 4:36 PM, Dinusha Dissanayake 
wrote:

> Hi Senthalan,
>
> Could you please explain if there is a specific reason not to show scope
> validators in the same order defined in identity.xml ? :)
> The reason I am asking this because, as Denuwanthi had mentioned, it would
> be better to include the execution order in the documentation and in the UI
> IMO.
> If we could list the scope validators in the same order as defined in
> registry.xml, it would be easier for user to understand the execution order
> from the UI.
> WDYT?
>
> Thanks,
> DinushaD.
>
> On Mon, Mar 5, 2018 at 3:49 PM, Denuwanthi De Silva 
> wrote:
>
>>
>>
>> On Mon, Mar 5, 2018 at 3:10 PM, Senthalan Kanagalingam <
>> sentha...@wso2.com> wrote:
>>
>>> Hi all,
>>>
>>> please find the inline comments.
>>>

 On Mon, Mar 5, 2018 at 2:04 PM, Johann Nallathamby 
 wrote:

> Hi Senthalan,
>

>>>

> JDBC Scope Validator doesn't make any sense. Can we have a more
> meaningful name for that? Isn't this the role based scope validator?
>

>>> yes, we can use role-based scope validator for JDBC Scoper Validator. I
>>> will correct it.
>>>
>>>

> Regards,
> Johann.
>
> On Mon, Mar 5, 2018 at 5:12 AM, Senthalan Kanagalingam <
> sentha...@wso2.com> wrote:
>
>> Hi Johann,
>>
>> Please find the screenshot.
>>
>>
>>
 Hi Senthalan,

>>>
>>>
 If both the validators are checked as in your UI, does it imply both
 validation will happen?
 Then what is the order? Is it the order in which it is listed as in
 your UI?

>>>
>>> Yes, two validators will be implied during the token validation time. In
>>> the UI, I have shown the name of the scope validators sorted by
>>> alphabetical order. Beacuse previously, the names were shuffled in the UI.
>>> Validators are implied in the order of scope validators defined in
>>> identity.xml.
>>>
>>
>> ok. So scope validators will be executed  In the order specified in
>> identity.xml. Ex: JDBC Scope validator will be executed first and after
>> that XACML scope validator will be executed.
>>
>> If so, how the order of execution happens should be documented or a note
>> should be available in the UI itself I believe.
>>
>>>
>>> Thanks and regards,
>>> Senthalan
>>>

>> I have introduced a new abstract method called "getValidatorName()"
>> in OAuth2ScopeValidator. That name is used to display in the UI and to
>> store in the database.
>>
>> thanks and regards,
>> Senthalan.
>>
>> On Sat, Mar 3, 2018 at 1:50 PM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Senthalan,
>>>
>>> What does the final UI look like? Can you attach a screenshot?
>>>
>>> Regards,
>>> Johann.
>>>
>>> On Tue, Feb 20, 2018 at 1:48 PM, Darshana Gunawardana <
>>> darsh...@wso2.com> wrote:
>>>
 +1 for second option.

 On Tue, Feb 20, 2018 at 5:55 PM, Senthalan Kanagalingam <
 sentha...@wso2.com> wrote:

> hi all,
>
> In the UI of this implementation currently, we are showing only
> the class name of the registered validators. If there are two scope
> validators with the same class name registered in two different 
> packages.
> Then the UI will show mixed up with duplicate values. There are two 
> options
> to solve this problem,
>
>1. Show the class name with the package name
>2. Implement a method in OAuth2ScopeValidator API to get
>meaning full name.
>
> Please provide feedback regarding this.
>
> Thanks and Regards,
> Senthalan.
>
> On Thu, Feb 8, 2018 at 5:29 PM, Johann Nallathamby <
> joh...@wso2.com> wrote:
>
>> Hi Folks,
>>
>> I also have another concern here. Sorry I didn't bring this up
>> earlier in the mail. Why do we show the scope validators in the SP 
>> UI?
>> Scope validators are options given for the Resource Providers (API
>> Provider/API Admins) to choose how they want to protect their APIs. 
>> In that
>> sense these options are only suitable to be configured at against 
>> Resources
>> or Resource groups by OAuth2 admins; not at service provider level. 
>> So I
>> don't think having it in the SP UI is conceptually correct. However I
>> understand that the SP UI is mostly 

Re: [Architecture] [BMB] Full In-memory operating mode for message broker

[Asanka Abeyweera]

Hi Chanaka,

Yes, We would lose all data if the node goes down.

This mode is mainly targeted for the embedded broker use cases. There can
be scenarios where we only have publishers and non-durable topic
subscribers. For such scenarios, it does not matter if we have configured a
database or not ,since the underline queue is non-durable.This is different
from the message store use case where we expect messages to be persisted.
Previously even for non-durable use cases, we had to configure a database.
By implementing this feature we are trying to avoid that.

Another use case is dev and unit testing as you have mentioned.


On Mon, Mar 5, 2018 at 2:07 PM, Chanaka Fernando  wrote:

> Hi Asanka,
>
> Could you please list down the advantages of this in-memory mode over
> database backed (default) mode? We used to have in-memory JMS store in the
> WSO2 ESB/EI world but it was never used in a real production system (in
> fact we recommended not to use that in production). More or less, it was
> used for demonstration purposes. I'm a bit unclear on why we need an
> in-memory mode without any database backup.
>
> In this mode, if the node goes down, is there a way to write the status
> periodically to a database and revert to the last active state once the
> server restarted?
>
> Thanks,
> Chanaka
>
> On Wed, Feb 28, 2018 at 11:05 AM, Shazni Nazeer  wrote:
>
>> yeah that makes sense. No memory system is reliable ☺. But certainly good
>> to have for some scenarios like the throttling events mentioned above.
>>
>> On Tue, Feb 27, 2018 at 11:24 PM, Asanka Abeyweera 
>> wrote:
>>
>>> HA is not supported in in-memory mode. This is a non-reliable broker
>>> mode (unless your memory/system is reliable ;)). If you need to have HA for
>>> your use case you should not use in-memory mode.
>>>
>>> On Wed, Feb 28, 2018 at 10:19 AM, Shazni Nazeer  wrote:
>>>
 Hi Asanka,

 How would the in-memory storage be handled between high availability
 scenario where we have two MB nodes used? Do we have any distributed
 caching of some sort?

 On Tue, Feb 27, 2018 at 12:30 AM, Asanka Abeyweera 
 wrote:

> We are planning to complete the feature in this week's milestone.
> Configuration wise, you will have to set the in-memory mode to "true" in
> the config. We will explain this in the doc.
>
> On a separate note, When you use non durable queues (for example with
> non durable topic subscribers) with BMB it will operate in memory (without
> persisting to database) irrespective of the configured mode.
>
>
> On Tue, Feb 27, 2018 at 11:40 AM, Sanjeewa Malalgoda <
> sanje...@wso2.com> wrote:
>
>> +1 This will be perfect implementation for throttling events like
>> messages( due to high efficiency, small message size, no durable
>> requirements etc).
>> Do you have any time line estimation for this feature? I believe from
>> user point of view there will be no any changes other than remove 
>> database
>> configuration.
>>
>> Thanks,
>> sanjeewa.
>>
>> On Fri, Feb 23, 2018 at 4:31 PM, Hasitha Hiranya 
>> wrote:
>>
>>> Hi Asanka,
>>>
>>> I think we should not restrict.
>>> What we are doing is, configuring MB to work with an "in-memory
>>> store".
>>> It should be a configuration at broker side (applied to all
>>> queues/topics).
>>> When coding, better keep all logics same attached to an in-memory
>>> impl of the  store.
>>>
>>> Thoughts?
>>>
>>> Thanks
>>>
>>> On Fri, Feb 23, 2018 at 3:32 PM, Pamod Sylvester 
>>> wrote:
>>>
 Hi Asanka,

 If we're considering to handle durable subscriptions in-memory it
 would be good if we can inform the client on it.

 IMHO Semantically it also could mislead the applications. Otherwise
 isn't it an option for us to restrict connection creation as durable ? 
 (if
 the broker is started in, "in-memory" mode)

 Thanks,
 Pamod

 On Fri, Feb 23, 2018 at 2:14 PM, Asanka Abeyweera <
 asank...@wso2.com> wrote:

> Hi all,
>
> I am working on the $subject. In the previous versions of message
> broker, we configured H2 database in the in-memory mode to run the 
> broker
> in in-memory mode. But we are thinking of having a mode where we 
> would skip
> the database layer completely when in-memory mode is enabled in the 
> broker.
> This means we will be doing all of the following tasks in memory.
>
>- Persistent message storing
>- Durable queue information storing
>- Durable exchange information storing
>- Durable binding information 

Re: [Architecture] [RRT] XACML based scope validator (during OAuth2 token validation)

[Dinusha Dissanayake]

Hi Senthalan,

Could you please explain if there is a specific reason not to show scope
validators in the same order defined in identity.xml ? :)
The reason I am asking this because, as Denuwanthi had mentioned, it would
be better to include the execution order in the documentation and in the UI
IMO.
If we could list the scope validators in the same order as defined in
registry.xml, it would be easier for user to understand the execution order
from the UI.
WDYT?

Thanks,
DinushaD.

On Mon, Mar 5, 2018 at 3:49 PM, Denuwanthi De Silva 
wrote:

>
>
> On Mon, Mar 5, 2018 at 3:10 PM, Senthalan Kanagalingam  > wrote:
>
>> Hi all,
>>
>> please find the inline comments.
>>
>>>
>>> On Mon, Mar 5, 2018 at 2:04 PM, Johann Nallathamby 
>>> wrote:
>>>
 Hi Senthalan,

>>>
>>
>>>
 JDBC Scope Validator doesn't make any sense. Can we have a more
 meaningful name for that? Isn't this the role based scope validator?

>>>
>> yes, we can use role-based scope validator for JDBC Scoper Validator. I
>> will correct it.
>>
>>
>>>
 Regards,
 Johann.

 On Mon, Mar 5, 2018 at 5:12 AM, Senthalan Kanagalingam <
 sentha...@wso2.com> wrote:

> Hi Johann,
>
> Please find the screenshot.
>
>
>
>>> Hi Senthalan,
>>>
>>
>>
>>> If both the validators are checked as in your UI, does it imply both
>>> validation will happen?
>>> Then what is the order? Is it the order in which it is listed as in your
>>> UI?
>>>
>>
>> Yes, two validators will be implied during the token validation time. In
>> the UI, I have shown the name of the scope validators sorted by
>> alphabetical order. Beacuse previously, the names were shuffled in the UI.
>> Validators are implied in the order of scope validators defined in
>> identity.xml.
>>
>
> ok. So scope validators will be executed  In the order specified in
> identity.xml. Ex: JDBC Scope validator will be executed first and after
> that XACML scope validator will be executed.
>
> If so, how the order of execution happens should be documented or a note
> should be available in the UI itself I believe.
>
>>
>> Thanks and regards,
>> Senthalan
>>
>>>
> I have introduced a new abstract method called "getValidatorName()"
> in OAuth2ScopeValidator. That name is used to display in the UI and to
> store in the database.
>
> thanks and regards,
> Senthalan.
>
> On Sat, Mar 3, 2018 at 1:50 PM, Johann Nallathamby 
> wrote:
>
>> Hi Senthalan,
>>
>> What does the final UI look like? Can you attach a screenshot?
>>
>> Regards,
>> Johann.
>>
>> On Tue, Feb 20, 2018 at 1:48 PM, Darshana Gunawardana <
>> darsh...@wso2.com> wrote:
>>
>>> +1 for second option.
>>>
>>> On Tue, Feb 20, 2018 at 5:55 PM, Senthalan Kanagalingam <
>>> sentha...@wso2.com> wrote:
>>>
 hi all,

 In the UI of this implementation currently, we are showing only the
 class name of the registered validators. If there are two scope 
 validators
 with the same class name registered in two different packages. Then 
 the UI
 will show mixed up with duplicate values. There are two options to 
 solve
 this problem,

1. Show the class name with the package name
2. Implement a method in OAuth2ScopeValidator API to get
meaning full name.

 Please provide feedback regarding this.

 Thanks and Regards,
 Senthalan.

 On Thu, Feb 8, 2018 at 5:29 PM, Johann Nallathamby  wrote:

> Hi Folks,
>
> I also have another concern here. Sorry I didn't bring this up
> earlier in the mail. Why do we show the scope validators in the SP UI?
> Scope validators are options given for the Resource Providers (API
> Provider/API Admins) to choose how they want to protect their APIs. 
> In that
> sense these options are only suitable to be configured at against 
> Resources
> or Resource groups by OAuth2 admins; not at service provider level. 
> So I
> don't think having it in the SP UI is conceptually correct. However I
> understand that the SP UI is mostly used by admins and not the real 
> service
> providers. The real service providers actually interact with a portal 
> like
> the API Store and IS is used only as the backend where API calls are 
> made.
> So when it comes to usage it might not be a big deal but still 
> conceptually
> it's not right.
>
> Regards,
> Johann.
>
> On Fri, Feb 2, 2018 at 10:06 AM, Senthalan Kanagalingam <
> sentha...@wso2.com> wrote:
>
>> Hi Darshana, Johann,
>>
>> 

Re: [Architecture] [RRT] XACML based scope validator (during OAuth2 token validation)

[Denuwanthi De Silva]

On Mon, Mar 5, 2018 at 3:10 PM, Senthalan Kanagalingam 
wrote:

> Hi all,
>
> please find the inline comments.
>
>>
>> On Mon, Mar 5, 2018 at 2:04 PM, Johann Nallathamby 
>> wrote:
>>
>>> Hi Senthalan,
>>>
>>
>
>>
>>> JDBC Scope Validator doesn't make any sense. Can we have a more
>>> meaningful name for that? Isn't this the role based scope validator?
>>>
>>
> yes, we can use role-based scope validator for JDBC Scoper Validator. I
> will correct it.
>
>
>>
>>> Regards,
>>> Johann.
>>>
>>> On Mon, Mar 5, 2018 at 5:12 AM, Senthalan Kanagalingam <
>>> sentha...@wso2.com> wrote:
>>>
 Hi Johann,

 Please find the screenshot.



>> Hi Senthalan,
>>
>
>
>> If both the validators are checked as in your UI, does it imply both
>> validation will happen?
>> Then what is the order? Is it the order in which it is listed as in your
>> UI?
>>
>
> Yes, two validators will be implied during the token validation time. In
> the UI, I have shown the name of the scope validators sorted by
> alphabetical order. Beacuse previously, the names were shuffled in the UI.
> Validators are implied in the order of scope validators defined in
> identity.xml.
>

ok. So scope validators will be executed  In the order specified in
identity.xml. Ex: JDBC Scope validator will be executed first and after
that XACML scope validator will be executed.

If so, how the order of execution happens should be documented or a note
should be available in the UI itself I believe.

>
> Thanks and regards,
> Senthalan
>
>>
 I have introduced a new abstract method called "getValidatorName()"
 in OAuth2ScopeValidator. That name is used to display in the UI and to
 store in the database.

 thanks and regards,
 Senthalan.

 On Sat, Mar 3, 2018 at 1:50 PM, Johann Nallathamby 
 wrote:

> Hi Senthalan,
>
> What does the final UI look like? Can you attach a screenshot?
>
> Regards,
> Johann.
>
> On Tue, Feb 20, 2018 at 1:48 PM, Darshana Gunawardana <
> darsh...@wso2.com> wrote:
>
>> +1 for second option.
>>
>> On Tue, Feb 20, 2018 at 5:55 PM, Senthalan Kanagalingam <
>> sentha...@wso2.com> wrote:
>>
>>> hi all,
>>>
>>> In the UI of this implementation currently, we are showing only the
>>> class name of the registered validators. If there are two scope 
>>> validators
>>> with the same class name registered in two different packages. Then the 
>>> UI
>>> will show mixed up with duplicate values. There are two options to solve
>>> this problem,
>>>
>>>1. Show the class name with the package name
>>>2. Implement a method in OAuth2ScopeValidator API to get meaning
>>>full name.
>>>
>>> Please provide feedback regarding this.
>>>
>>> Thanks and Regards,
>>> Senthalan.
>>>
>>> On Thu, Feb 8, 2018 at 5:29 PM, Johann Nallathamby 
>>> wrote:
>>>
 Hi Folks,

 I also have another concern here. Sorry I didn't bring this up
 earlier in the mail. Why do we show the scope validators in the SP UI?
 Scope validators are options given for the Resource Providers (API
 Provider/API Admins) to choose how they want to protect their APIs. In 
 that
 sense these options are only suitable to be configured at against 
 Resources
 or Resource groups by OAuth2 admins; not at service provider level. So 
 I
 don't think having it in the SP UI is conceptually correct. However I
 understand that the SP UI is mostly used by admins and not the real 
 service
 providers. The real service providers actually interact with a portal 
 like
 the API Store and IS is used only as the backend where API calls are 
 made.
 So when it comes to usage it might not be a big deal but still 
 conceptually
 it's not right.

 Regards,
 Johann.

 On Fri, Feb 2, 2018 at 10:06 AM, Senthalan Kanagalingam <
 sentha...@wso2.com> wrote:

> Hi Darshana, Johann,
>
> Yes sure, I will change the UI.
>
> Thanks,
> Senthalan
>
> On Thu, Feb 1, 2018 at 11:48 AM, Johann Nallathamby <
> joh...@wso2.com> wrote:
>
>> Hi Senthalan,
>>
>> On Thu, Feb 1, 2018 at 9:30 AM, Senthalan Kanagalingam <
>> sentha...@wso2.com> wrote:
>>
>>> Hi Malithi,
>>>
>>> On Wed, Jan 31, 2018 at 12:06 PM, Malithi Edirisinghe <
>>> malit...@wso2.com> wrote:
>>>

 Hi Senthalan,

 On Tue, Jan 30, 2018 at 9:33 AM, Senthalan Kanagalingam <
 sentha...@wso2.com> wrote:

> Hi all,
>
> We had 

Re: [Architecture] [BMB] Full In-memory operating mode for message broker

[Chanaka Fernando]

Hi Asanka,

Could you please list down the advantages of this in-memory mode over
database backed (default) mode? We used to have in-memory JMS store in the
WSO2 ESB/EI world but it was never used in a real production system (in
fact we recommended not to use that in production). More or less, it was
used for demonstration purposes. I'm a bit unclear on why we need an
in-memory mode without any database backup.

In this mode, if the node goes down, is there a way to write the status
periodically to a database and revert to the last active state once the
server restarted?

Thanks,
Chanaka

On Wed, Feb 28, 2018 at 11:05 AM, Shazni Nazeer  wrote:

> yeah that makes sense. No memory system is reliable ☺. But certainly good
> to have for some scenarios like the throttling events mentioned above.
>
> On Tue, Feb 27, 2018 at 11:24 PM, Asanka Abeyweera 
> wrote:
>
>> HA is not supported in in-memory mode. This is a non-reliable broker mode
>> (unless your memory/system is reliable ;)). If you need to have HA for your
>> use case you should not use in-memory mode.
>>
>> On Wed, Feb 28, 2018 at 10:19 AM, Shazni Nazeer  wrote:
>>
>>> Hi Asanka,
>>>
>>> How would the in-memory storage be handled between high availability
>>> scenario where we have two MB nodes used? Do we have any distributed
>>> caching of some sort?
>>>
>>> On Tue, Feb 27, 2018 at 12:30 AM, Asanka Abeyweera 
>>> wrote:
>>>
 We are planning to complete the feature in this week's milestone.
 Configuration wise, you will have to set the in-memory mode to "true" in
 the config. We will explain this in the doc.

 On a separate note, When you use non durable queues (for example with
 non durable topic subscribers) with BMB it will operate in memory (without
 persisting to database) irrespective of the configured mode.


 On Tue, Feb 27, 2018 at 11:40 AM, Sanjeewa Malalgoda  wrote:

> +1 This will be perfect implementation for throttling events like
> messages( due to high efficiency, small message size, no durable
> requirements etc).
> Do you have any time line estimation for this feature? I believe from
> user point of view there will be no any changes other than remove database
> configuration.
>
> Thanks,
> sanjeewa.
>
> On Fri, Feb 23, 2018 at 4:31 PM, Hasitha Hiranya 
> wrote:
>
>> Hi Asanka,
>>
>> I think we should not restrict.
>> What we are doing is, configuring MB to work with an "in-memory
>> store".
>> It should be a configuration at broker side (applied to all
>> queues/topics).
>> When coding, better keep all logics same attached to an in-memory
>> impl of the  store.
>>
>> Thoughts?
>>
>> Thanks
>>
>> On Fri, Feb 23, 2018 at 3:32 PM, Pamod Sylvester 
>> wrote:
>>
>>> Hi Asanka,
>>>
>>> If we're considering to handle durable subscriptions in-memory it
>>> would be good if we can inform the client on it.
>>>
>>> IMHO Semantically it also could mislead the applications. Otherwise
>>> isn't it an option for us to restrict connection creation as durable ? 
>>> (if
>>> the broker is started in, "in-memory" mode)
>>>
>>> Thanks,
>>> Pamod
>>>
>>> On Fri, Feb 23, 2018 at 2:14 PM, Asanka Abeyweera >> > wrote:
>>>
 Hi all,

 I am working on the $subject. In the previous versions of message
 broker, we configured H2 database in the in-memory mode to run the 
 broker
 in in-memory mode. But we are thinking of having a mode where we would 
 skip
 the database layer completely when in-memory mode is enabled in the 
 broker.
 This means we will be doing all of the following tasks in memory.

- Persistent message storing
- Durable queue information storing
- Durable exchange information storing
- Durable binding information storing

 Alternatively, we could reject all durable calls when we put the
 broker in in-memory mode. But If we do that we will be limiting some 
 of the
 existing applications from using the message broker in in-memory mode.
 Therefore I think It is better not to that.

 WDYT?
 --
 Asanka Abeyweera
 Associate Technical Lead
 WSO2 Inc.

 Phone: +94 712228648 <071%20222%208648>
 Blog: a5anka.github.io

 

>>>
>>>
>>>
>>> --
>>> *Pamod Sylvester *
>>>
>>> *WSO2 Inc.; http://wso2.com *
>>> cell: +94 77 7779495 <077%20777%209495>
>>>
>>
>>
>>
>> --
>> *Hasitha Abeykoon*
>> Associate