Re: [Architecture] Proposed Key Schema for LevelDB Store of Message Broker

[Asanka Abeyweera]

Hi Wishmitha,

   1. How are we going to support HA deployment with LevelDB? Are we going
   to use a network file system or replicate data?
   2. If we wanted to get a set of message matching a given queue ID, do we
   have to traverse all messages to get that? In RDBMS this is easier to do
   with a where clause.
   3. What happens if we insert data while traversing?
   4. It seems "*only a single process (possibly multi-threaded) can access
   a particular database at a time*"[1] in LevelDB. Will this be a
   bottleneck when we need to access the DB concurrently?
   5. How are the transactions handled in LevelDB? When
   implementing distributed transactions feature we required row level
   locking instead of table level locking. Does LevelDB support that?

[1] https://github.com/google/leveldb

On Tue, Aug 15, 2017 at 10:47 AM, Wishmitha Mendis 
wrote:

> Hi Sumedha,
>
> The Java library for LevelDB (leveldbjni) creates the database as follows
> as mentioned in the docs. [1]
>
> Options options = new Options();
> DB db = factory.open(new File("example"), options);
>
> This will create the database in a directory on a given path. And in the
> library docs, it is mentioned that the library supports several platforms
> if not specifically configured. Therefore using this library does not
> require to ship LevelDB and it also won't take away platform agnostic
> installation capability of MB. However the implementation is currently only
> tested on Linux, I will test it on Windows and other platforms and let you
> know.
>
> When considering the LevelDB architecture, it is already used as a broker
> store in ActiveMQ. [2] [3] This proves that LevelDB has the architectural
> capability to efficiently insert and delete messages in a broker.
>
> [1] https://github.com/fusesource/leveldbjni
> [2] http://activemq.apache.org/leveldb-store.html
> [3] https://github.com/apache/activemq/tree/master/activemq-leveldb-store
>
> Best Regards,
>
> On Tue, Aug 15, 2017 at 2:29 AM, Sumedha Rubasinghe 
> wrote:
>
>> Hi Wishmitha,
>> Would leveldb architecture be efficient for a message broker where
>> removing delivered messages is very frequent?
>>
>> This requires WSO2 Message Broker to ship leveldb. leveldb (
>> https://github.com/google/leveldb) has native distributions for
>> platforms. AFAIC this will take away platform agnostic installation
>> capability of MB.
>>
>>
>>
>> On Tue, Aug 15, 2017 at 2:20 AM, Wishmitha Mendis 
>> wrote:
>>
>>> Hi all,
>>>
>>> I am working on a project to replace the current RDBMS based database of
>>> the message broker store with a file based database system. Currently the
>>> implementation is carried out in LevelDB which is a key-value based data
>>> store. The following is an explanation of suggested key schema for the data
>>> store with related design decisions.
>>>
>>> *Overview :*
>>>
>>> LevelDB is a key value based database where a value can be stored under
>>> a certain unique key. This key-value mapping is one directional which means
>>> a value only can be retrieved by accessing corresponding key. One of the
>>> main features in LevelDB is that it stores keys in a lexicographically
>>> (alphabetically) sorted order. All the keys and values are stored in byte
>>> array format in the database store which should be accordingly converted to
>>> string format within the application.
>>>
>>> For this LevelDB store implementation leveldbjni-1.8[1] is used which
>>> provides a Java based API for LevelDB by providing following main
>>> functionalities.
>>>
>>>
>>>1.
>>>
>>>put(key,value) : stores given value under the provided key
>>>2.
>>>
>>>get(key) : returns corresponding value to the key
>>>3.
>>>
>>>delete(key) : deletes given key
>>>4.
>>>
>>>batch() : provides atomicity for the operations
>>>5.
>>>
>>>iterator() : traverse through the stored keys
>>>
>>>
>>> When designing the key schema in Level DB the following factors are
>>> mainly considered.
>>>
>>>
>>>1.
>>>
>>>Lexicographical order of the stored keys
>>>2.
>>>
>>>Traversing through the keys
>>>3.
>>>
>>>Data organization
>>>
>>>
>>> *Key Schema :*
>>>
>>> The key schema implementation was carried out for following tables of
>>> the current RDBMS database.
>>>
>>> [image: Screenshot from 2017-08-14 01-13-33.png]
>>>
>>> The key schema is mainly designed by analyzing implemented queries for
>>> data retrieval and inserting in the RDBMS. The key schema for above three
>>> tables is represented below table.
>>>
>>>
>>> [image: Screenshot from 2017-08-15 02-11-24.png]
>>>
>>> *Key : Value*
>>>
>>> *Purpose*
>>>
>>> MESSAGE.$message_id.QUEUE_ID : queue_id
>>>
>>> Stores queue id of the message.
>>>
>>> MESSAGE.$message_id.DLC_QUEUE_ID : dlc_queue_id
>>>
>>> Stores dlc queue id of the message.
>>>
>>> MESSAGE.$message_id.MESSAGE_METADATA : message_metadata
>>>
>>> Stores metadata of the message.
>>>
>>> 

Re: [Architecture] Proposed Key Schema for LevelDB Store of Message Broker

[Sajith Kariyawasam]

Hi Wishmitha,

As per ActiveMQ [1] it says "The LevelDB store has been deprecated and is
no longer supported or recommended for use. The recommended store is
KahaDB" ... Are we aware of the reason LevelDB is not recommending in
ActiveMQ? In that case are we on the correct path to use LevelDB ?

[1]  http://activemq.apache.org/leveldb-store.html

On Tue, Aug 15, 2017 at 10:47 AM, Wishmitha Mendis 
wrote:

> Hi Sumedha,
>
> The Java library for LevelDB (leveldbjni) creates the database as follows
> as mentioned in the docs. [1]
>
> Options options = new Options();
> DB db = factory.open(new File("example"), options);
>
> This will create the database in a directory on a given path. And in the
> library docs, it is mentioned that the library supports several platforms
> if not specifically configured. Therefore using this library does not
> require to ship LevelDB and it also won't take away platform agnostic
> installation capability of MB. However the implementation is currently only
> tested on Linux, I will test it on Windows and other platforms and let you
> know.
>
> When considering the LevelDB architecture, it is already used as a broker
> store in ActiveMQ. [2] [3] This proves that LevelDB has the architectural
> capability to efficiently insert and delete messages in a broker.
>
> [1] https://github.com/fusesource/leveldbjni
> [2] http://activemq.apache.org/leveldb-store.html
> [3] https://github.com/apache/activemq/tree/master/activemq-leveldb-store
>
> Best Regards,
>
> On Tue, Aug 15, 2017 at 2:29 AM, Sumedha Rubasinghe 
> wrote:
>
>> Hi Wishmitha,
>> Would leveldb architecture be efficient for a message broker where
>> removing delivered messages is very frequent?
>>
>> This requires WSO2 Message Broker to ship leveldb. leveldb (
>> https://github.com/google/leveldb) has native distributions for
>> platforms. AFAIC this will take away platform agnostic installation
>> capability of MB.
>>
>>
>>
>> On Tue, Aug 15, 2017 at 2:20 AM, Wishmitha Mendis 
>> wrote:
>>
>>> Hi all,
>>>
>>> I am working on a project to replace the current RDBMS based database of
>>> the message broker store with a file based database system. Currently the
>>> implementation is carried out in LevelDB which is a key-value based data
>>> store. The following is an explanation of suggested key schema for the data
>>> store with related design decisions.
>>>
>>> *Overview :*
>>>
>>> LevelDB is a key value based database where a value can be stored under
>>> a certain unique key. This key-value mapping is one directional which means
>>> a value only can be retrieved by accessing corresponding key. One of the
>>> main features in LevelDB is that it stores keys in a lexicographically
>>> (alphabetically) sorted order. All the keys and values are stored in byte
>>> array format in the database store which should be accordingly converted to
>>> string format within the application.
>>>
>>> For this LevelDB store implementation leveldbjni-1.8[1] is used which
>>> provides a Java based API for LevelDB by providing following main
>>> functionalities.
>>>
>>>
>>>1.
>>>
>>>put(key,value) : stores given value under the provided key
>>>2.
>>>
>>>get(key) : returns corresponding value to the key
>>>3.
>>>
>>>delete(key) : deletes given key
>>>4.
>>>
>>>batch() : provides atomicity for the operations
>>>5.
>>>
>>>iterator() : traverse through the stored keys
>>>
>>>
>>> When designing the key schema in Level DB the following factors are
>>> mainly considered.
>>>
>>>
>>>1.
>>>
>>>Lexicographical order of the stored keys
>>>2.
>>>
>>>Traversing through the keys
>>>3.
>>>
>>>Data organization
>>>
>>>
>>> *Key Schema :*
>>>
>>> The key schema implementation was carried out for following tables of
>>> the current RDBMS database.
>>>
>>> [image: Screenshot from 2017-08-14 01-13-33.png]
>>>
>>> The key schema is mainly designed by analyzing implemented queries for
>>> data retrieval and inserting in the RDBMS. The key schema for above three
>>> tables is represented below table.
>>>
>>>
>>> [image: Screenshot from 2017-08-15 02-11-24.png]
>>>
>>> *Key : Value*
>>>
>>> *Purpose*
>>>
>>> MESSAGE.$message_id.QUEUE_ID : queue_id
>>>
>>> Stores queue id of the message.
>>>
>>> MESSAGE.$message_id.DLC_QUEUE_ID : dlc_queue_id
>>>
>>> Stores dlc queue id of the message.
>>>
>>> MESSAGE.$message_id.MESSAGE_METADATA : message_metadata
>>>
>>> Stores metadata of the message.
>>>
>>> MESSAGE.$message_id.$content_offset.MESSAGE_CONTENT : message_content
>>>
>>> Stores message content for a given message offset of the message.
>>>
>>> QUEUE.$queue_id.QUEUE_NAME : queue_name
>>>
>>> Stores name of the queue under the id.
>>>
>>> QUEUE.$queue_name.QUEUE_ID : queue_id
>>>
>>> Stores id of the queue under the name.
>>>
>>> QUEUE.$queue_name.message_id. MESSAGE_METADATA : message_metadata
>>>
>>> Stores metadata of the messages which belongs to 

Re: [Architecture] Proposed Key Schema for LevelDB Store of Message Broker

[Wishmitha Mendis]

Hi Sumedha,

The Java library for LevelDB (leveldbjni) creates the database as follows
as mentioned in the docs. [1]

Options options = new Options();
DB db = factory.open(new File("example"), options);

This will create the database in a directory on a given path. And in the
library docs, it is mentioned that the library supports several platforms
if not specifically configured. Therefore using this library does not
require to ship LevelDB and it also won't take away platform agnostic
installation capability of MB. However the implementation is currently only
tested on Linux, I will test it on Windows and other platforms and let you
know.

When considering the LevelDB architecture, it is already used as a broker
store in ActiveMQ. [2] [3] This proves that LevelDB has the architectural
capability to efficiently insert and delete messages in a broker.

[1] https://github.com/fusesource/leveldbjni
[2] http://activemq.apache.org/leveldb-store.html
[3] https://github.com/apache/activemq/tree/master/activemq-leveldb-store

Best Regards,

On Tue, Aug 15, 2017 at 2:29 AM, Sumedha Rubasinghe 
wrote:

> Hi Wishmitha,
> Would leveldb architecture be efficient for a message broker where
> removing delivered messages is very frequent?
>
> This requires WSO2 Message Broker to ship leveldb. leveldb (
> https://github.com/google/leveldb) has native distributions for
> platforms. AFAIC this will take away platform agnostic installation
> capability of MB.
>
>
>
> On Tue, Aug 15, 2017 at 2:20 AM, Wishmitha Mendis 
> wrote:
>
>> Hi all,
>>
>> I am working on a project to replace the current RDBMS based database of
>> the message broker store with a file based database system. Currently the
>> implementation is carried out in LevelDB which is a key-value based data
>> store. The following is an explanation of suggested key schema for the data
>> store with related design decisions.
>>
>> *Overview :*
>>
>> LevelDB is a key value based database where a value can be stored under a
>> certain unique key. This key-value mapping is one directional which means a
>> value only can be retrieved by accessing corresponding key. One of the main
>> features in LevelDB is that it stores keys in a lexicographically
>> (alphabetically) sorted order. All the keys and values are stored in byte
>> array format in the database store which should be accordingly converted to
>> string format within the application.
>>
>> For this LevelDB store implementation leveldbjni-1.8[1] is used which
>> provides a Java based API for LevelDB by providing following main
>> functionalities.
>>
>>
>>1.
>>
>>put(key,value) : stores given value under the provided key
>>2.
>>
>>get(key) : returns corresponding value to the key
>>3.
>>
>>delete(key) : deletes given key
>>4.
>>
>>batch() : provides atomicity for the operations
>>5.
>>
>>iterator() : traverse through the stored keys
>>
>>
>> When designing the key schema in Level DB the following factors are
>> mainly considered.
>>
>>
>>1.
>>
>>Lexicographical order of the stored keys
>>2.
>>
>>Traversing through the keys
>>3.
>>
>>Data organization
>>
>>
>> *Key Schema :*
>>
>> The key schema implementation was carried out for following tables of the
>> current RDBMS database.
>>
>> [image: Screenshot from 2017-08-14 01-13-33.png]
>>
>> The key schema is mainly designed by analyzing implemented queries for
>> data retrieval and inserting in the RDBMS. The key schema for above three
>> tables is represented below table.
>>
>>
>> [image: Screenshot from 2017-08-15 02-11-24.png]
>>
>> *Key : Value*
>>
>> *Purpose*
>>
>> MESSAGE.$message_id.QUEUE_ID : queue_id
>>
>> Stores queue id of the message.
>>
>> MESSAGE.$message_id.DLC_QUEUE_ID : dlc_queue_id
>>
>> Stores dlc queue id of the message.
>>
>> MESSAGE.$message_id.MESSAGE_METADATA : message_metadata
>>
>> Stores metadata of the message.
>>
>> MESSAGE.$message_id.$content_offset.MESSAGE_CONTENT : message_content
>>
>> Stores message content for a given message offset of the message.
>>
>> QUEUE.$queue_id.QUEUE_NAME : queue_name
>>
>> Stores name of the queue under the id.
>>
>> QUEUE.$queue_name.QUEUE_ID : queue_id
>>
>> Stores id of the queue under the name.
>>
>> QUEUE.$queue_name.message_id. MESSAGE_METADATA : message_metadata
>>
>> Stores metadata of the messages which belongs to the queue.
>>
>> LAST_MESSAGE_ID
>>
>> Stores last message id.
>>
>> LAST_QUEUE_ID
>>
>> Stores last queue id.
>>
>> As it can be seen some data repetition is higher when using this schema.
>> That is mainly due to one directional key-value mapping of LevelDB. As an
>> example two keys (QUEUE.$queue_id.QUEUE_NAME ,
>> QUEUE.$queue_name.QUEUE_ID) are required to build the bidirectional
>> relation (get queue name given queue id and get queue id given queue
>> name) between queue name and the queue id. As LevelDB has better writing
>> performances than RDBMS data repetition may not be an 

Re: [Architecture] How valid is sending TOTP code to email? How about sending it over SMS?

[Dakshika Jayathilaka]

+1 for support both options. Then, admin can configure either SMS or E-mail
or both depending on their service availability.

Regards,

*Dakshika Jayathilaka*
PMC Member & Committer of Apache Stratos
Associate Technical Lead
WSO2, Inc.
lean.enterprise.middleware
0771100911

On Mon, Jul 24, 2017 at 4:40 PM, Harsha Thirimanna  wrote:

>
>
> On 18 Jul 2017 10:14 am, "Johann Nallathamby"  wrote:
>
> Hi All,
>
> Usually we send long lived codes to email and short lived codes to SMS.
> Because opening email client and checking the code may take time, depending
> on whether user has to log in to his email account, use 2FA for his email,
> etc. The TOTP code is short lived (90s). I think it's better to send this
> code over SMS or have both functionalities. What do you think?
>
>
> Don't we need to have a choice to user to either email/sms or both ?
>
> Are there any chance to select one of phone number claim by multiple ?
>
>
> Thanks & Regards,
> Johann.
>
> --
>
> *Johann Dilantha Nallathamby*
> Senior Lead Solutions Engineer
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+9476950*
> Blog - *http://nallaa.wordpress.com *
>
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Proposed Key Schema for LevelDB Store of Message Broker

[Sumedha Rubasinghe]

Hi Wishmitha,
Would leveldb architecture be efficient for a message broker where removing
delivered messages is very frequent?

This requires WSO2 Message Broker to ship leveldb. leveldb (
https://github.com/google/leveldb) has native distributions for platforms.
AFAIC this will take away platform agnostic installation capability of MB.



On Tue, Aug 15, 2017 at 2:20 AM, Wishmitha Mendis 
wrote:

> Hi all,
>
> I am working on a project to replace the current RDBMS based database of
> the message broker store with a file based database system. Currently the
> implementation is carried out in LevelDB which is a key-value based data
> store. The following is an explanation of suggested key schema for the data
> store with related design decisions.
>
> *Overview :*
>
> LevelDB is a key value based database where a value can be stored under a
> certain unique key. This key-value mapping is one directional which means a
> value only can be retrieved by accessing corresponding key. One of the main
> features in LevelDB is that it stores keys in a lexicographically
> (alphabetically) sorted order. All the keys and values are stored in byte
> array format in the database store which should be accordingly converted to
> string format within the application.
>
> For this LevelDB store implementation leveldbjni-1.8[1] is used which
> provides a Java based API for LevelDB by providing following main
> functionalities.
>
>
>1.
>
>put(key,value) : stores given value under the provided key
>2.
>
>get(key) : returns corresponding value to the key
>3.
>
>delete(key) : deletes given key
>4.
>
>batch() : provides atomicity for the operations
>5.
>
>iterator() : traverse through the stored keys
>
>
> When designing the key schema in Level DB the following factors are mainly
> considered.
>
>
>1.
>
>Lexicographical order of the stored keys
>2.
>
>Traversing through the keys
>3.
>
>Data organization
>
>
> *Key Schema :*
>
> The key schema implementation was carried out for following tables of the
> current RDBMS database.
>
> [image: Screenshot from 2017-08-14 01-13-33.png]
>
> The key schema is mainly designed by analyzing implemented queries for
> data retrieval and inserting in the RDBMS. The key schema for above three
> tables is represented below table.
>
>
> [image: Screenshot from 2017-08-15 02-11-24.png]
>
> *Key : Value*
>
> *Purpose*
>
> MESSAGE.$message_id.QUEUE_ID : queue_id
>
> Stores queue id of the message.
>
> MESSAGE.$message_id.DLC_QUEUE_ID : dlc_queue_id
>
> Stores dlc queue id of the message.
>
> MESSAGE.$message_id.MESSAGE_METADATA : message_metadata
>
> Stores metadata of the message.
>
> MESSAGE.$message_id.$content_offset.MESSAGE_CONTENT : message_content
>
> Stores message content for a given message offset of the message.
>
> QUEUE.$queue_id.QUEUE_NAME : queue_name
>
> Stores name of the queue under the id.
>
> QUEUE.$queue_name.QUEUE_ID : queue_id
>
> Stores id of the queue under the name.
>
> QUEUE.$queue_name.message_id. MESSAGE_METADATA : message_metadata
>
> Stores metadata of the messages which belongs to the queue.
>
> LAST_MESSAGE_ID
>
> Stores last message id.
>
> LAST_QUEUE_ID
>
> Stores last queue id.
>
> As it can be seen some data repetition is higher when using this schema.
> That is mainly due to one directional key-value mapping of LevelDB. As an
> example two keys (QUEUE.$queue_id.QUEUE_NAME , QUEUE.$queue_name.QUEUE_ID)
> are required to build the bidirectional relation (get queue name given
> queue id and get queue id given queue name) between queue name and the
> queue id. As LevelDB has better writing performances than RDBMS data
> repetition may not be an much of an overhead in inserting data. Moreover
> batch operations can be used in multiple insertions.
>
> The main purpose of using of prefixes like MESSAGE and QUEUE in keys is to
> organize them properly. As LevelDB stores keys lexicographically these
> prefixes will make sure that message related and queue related keys are
> stored separately as displayed below. The following shows the keys of the
> LevelDB store after publishing a JMS message to the broker. It can be
> clearly seen that the keys are stored in lexicographical order.
>
> [image: Screenshot from 2017-08-14 19-57-13.png]
>
> Organize keys in such a manner also improves the efficiency of traversing
> the keys using iterators when retrieving and deleting data. As displayed in
> the diagram below, iterators traverse by starting from the first stored key
> in the store. When iterator head reaches a key it can either move to the
> next key or previous key. (similar to double linked list) Hence storing
> related keys successively improves the efficiency of traversing when
> retrieving and deleting data by reducing the seeking time.
>
>
> [image: Screenshot from 2017-08-15 02-11-40.png]
>
>
> Basically these are the factors and decisions which have been taken in
> implementing this key 

[Architecture] Proposed Key Schema for LevelDB Store of Message Broker

[Wishmitha Mendis]

Hi all,

I am working on a project to replace the current RDBMS based database of
the message broker store with a file based database system. Currently the
implementation is carried out in LevelDB which is a key-value based data
store. The following is an explanation of suggested key schema for the data
store with related design decisions.

*Overview :*

LevelDB is a key value based database where a value can be stored under a
certain unique key. This key-value mapping is one directional which means a
value only can be retrieved by accessing corresponding key. One of the main
features in LevelDB is that it stores keys in a lexicographically
(alphabetically) sorted order. All the keys and values are stored in byte
array format in the database store which should be accordingly converted to
string format within the application.

For this LevelDB store implementation leveldbjni-1.8[1] is used which
provides a Java based API for LevelDB by providing following main
functionalities.


   1.

   put(key,value) : stores given value under the provided key
   2.

   get(key) : returns corresponding value to the key
   3.

   delete(key) : deletes given key
   4.

   batch() : provides atomicity for the operations
   5.

   iterator() : traverse through the stored keys


When designing the key schema in Level DB the following factors are mainly
considered.


   1.

   Lexicographical order of the stored keys
   2.

   Traversing through the keys
   3.

   Data organization


*Key Schema :*

The key schema implementation was carried out for following tables of the
current RDBMS database.

[image: Screenshot from 2017-08-14 01-13-33.png]

The key schema is mainly designed by analyzing implemented queries for data
retrieval and inserting in the RDBMS. The key schema for above three tables
is represented below table.


[image: Screenshot from 2017-08-15 02-11-24.png]

*Key : Value*

*Purpose*

MESSAGE.$message_id.QUEUE_ID : queue_id

Stores queue id of the message.

MESSAGE.$message_id.DLC_QUEUE_ID : dlc_queue_id

Stores dlc queue id of the message.

MESSAGE.$message_id.MESSAGE_METADATA : message_metadata

Stores metadata of the message.

MESSAGE.$message_id.$content_offset.MESSAGE_CONTENT : message_content

Stores message content for a given message offset of the message.

QUEUE.$queue_id.QUEUE_NAME : queue_name

Stores name of the queue under the id.

QUEUE.$queue_name.QUEUE_ID : queue_id

Stores id of the queue under the name.

QUEUE.$queue_name.message_id. MESSAGE_METADATA : message_metadata

Stores metadata of the messages which belongs to the queue.

LAST_MESSAGE_ID

Stores last message id.

LAST_QUEUE_ID

Stores last queue id.

As it can be seen some data repetition is higher when using this schema.
That is mainly due to one directional key-value mapping of LevelDB. As an
example two keys (QUEUE.$queue_id.QUEUE_NAME , QUEUE.$queue_name.QUEUE_ID)
are required to build the bidirectional relation (get queue name given
queue id and get queue id given queue name) between queue name and the
queue id. As LevelDB has better writing performances than RDBMS data
repetition may not be an much of an overhead in inserting data. Moreover
batch operations can be used in multiple insertions.

The main purpose of using of prefixes like MESSAGE and QUEUE in keys is to
organize them properly. As LevelDB stores keys lexicographically these
prefixes will make sure that message related and queue related keys are
stored separately as displayed below. The following shows the keys of the
LevelDB store after publishing a JMS message to the broker. It can be
clearly seen that the keys are stored in lexicographical order.

[image: Screenshot from 2017-08-14 19-57-13.png]

Organize keys in such a manner also improves the efficiency of traversing
the keys using iterators when retrieving and deleting data. As displayed in
the diagram below, iterators traverse by starting from the first stored key
in the store. When iterator head reaches a key it can either move to the
next key or previous key. (similar to double linked list) Hence storing
related keys successively improves the efficiency of traversing when
retrieving and deleting data by reducing the seeking time.


[image: Screenshot from 2017-08-15 02-11-40.png]


Basically these are the factors and decisions which have been taken in
implementing this key schema. And this schema should be extended to provide
functionalities like storing message expiration data etc. It would be great
to to have a feedback on the proposed schema specially regarding how to
reduce data repetition and improve efficiency furthermore.

[1] https://github.com/fusesource/leveldbjni


Best Regards,
-- 

*Wishmitha Mendis*

*Intern - Software Engineering*
*WSO2*

*Mobile : +94 777577706*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Proposed Key Schema for LevelDB Store of Message Broker

[Wishmitha Mendis]

Hi all,

I am working on a project to replace the current RDBMS based database of
the message broker store with a file based database system. Currently the
implementation is carried out in LevelDB which is a key-value based data
store. The following is an explanation of suggested key schema for the data
store with related design decisions.

Overview :

LevelDB is a key value based database where a value can be stored under a
certain unique key. This key-value mapping is one directional which means a
value only can be retrieved by accessing corresponding key. One of the main
features in LevelDB is that it stores keys in a lexicographically
(alphabetically) sorted order. All the keys and values are stored in byte
array format in the database store which should be accordingly converted to
string format within the application.

For this LevelDB store implementation leveldbjni-1.8[1] is used which
provides a Java based API for LevelDB by providing following main
functionalities.


   1.

   put(key,value) : stores given value under the provided key
   2.

   get(key) : returns corresponding value to the key
   3.

   delete(key) : deletes given key
   4.

   batch() : provides atomicity for the operations
   5.

   iterator() : traverse through the stored keys


When designing the key schema in Level DB the following factors are mainly
considered.


   1.

   Lexicographical order of the stored keys
   2.

   Traversing through the keys
   3.

   Data organization


Key Schema :

The key schema implementation was carried out for following tables of the
current RDBMS database.

[image: Screenshot from 2017-08-14 01-13-33.png]

The key schema is mainly designed by analyzing implemented queries for data
retrieval and inserting in the RDBMS. The key schema for above three tables
can be represented as follows.



Key : Value

Purpose

MESSAGE.$message_id.QUEUE_ID : queue_id

Stores queue id of the message.

MESSAGE.$message_id.DLC_QUEUE_ID : dlc_queue_id

Stores dlc queue id of the message.

MESSAGE.$message_id.MESSAGE_METADATA : message_metadata

Stores metadata of the message.

MESSAGE.$message_id.$content_offset.MESSAGE_CONTENT : message_content

Stores message content for a given message offset of the message.

QUEUE.$queue_id.QUEUE_NAME : queue_name

Stores name of the queue under the id.

QUEUE.$queue_name.QUEUE_ID : queue_id

Stores id of the queue under the name.

QUEUE.$queue_name.message_id. MESSAGE_METADATA : message_metadata

Stores metadata of the messages which belongs to the queue.

LAST_MESSAGE_ID

Stores last message id.

LAST_QUEUE_ID

Stores last queue id.

As it can be seen some data repetition is higher when using this schema.
That is mainly due to one directional key-value mapping of LevelDB. As an
example two keys (QUEUE.$queue_id.QUEUE_NAME , QUEUE.$queue_name.QUEUE_ID)
are required to build the bidirectional relation (get queue name given
queue id and get queue id given queue name) between queue name and the
queue id. As LevelDB has better writing performances than RDBMS data
repetition may not be an much of an overhead in inserting data. Moreover
batch operations can be used in multiple insertions.

The main purpose of using of prefixes like MESSAGE and QUEUE in keys is to
organize them properly. As LevelDB stores keys lexicographically these
prefixes will make sure that message related and queue related keys are
stored separately as displayed below. The following shows the keys of the
LevelDB store after publishing a JMS message to the broker. It can be
clearly seen that the keys are stored in lexicographical order.

[image: Screenshot from 2017-08-14 19-57-13.png]

Organize keys in such a manner also improves the efficiency of traversing
the keys using iterators when retrieving and deleting data. As displayed in
the diagram below, iterators traverse by starting from the first stored key
in the store. When iterator head reaches a key it can either move to the
next key or previous key. (similar to double linked list) Hence storing
related keys successively improves the efficiency of traversing when
retrieving and deleting data by reducing the seeking time.


Basically these are the factors and decisions which have been taken in
implementing this key schema. And this schema should be extended to provide
functionalities like storing message expiration data etc. It would be great
to to have a feedback on the proposed schema specially regarding how to
reduce data repetition and improve efficiency furthermore.

[1] https://github.com/fusesource/leveldbjni


Best Regards,

-- 

*Wishmitha Mendis*

*Intern - Software Engineering*
*WSO2*

*Mobile : +94 777577706*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Cross Protocol Single Logout

[Malithi Edirisinghe]

On Mon, Aug 14, 2017 at 10:27 PM, Harsha Thirimanna 
wrote:

>
>
> On Mon, Aug 14, 2017 at 6:37 PM, Piraveena Paralogarajah <
> pirave...@wso2.com> wrote:
>
>> Hi Maninda,
>>
>> In OpenID Connect, there are three ways for SLO.
>>
>>1. OIDC Session management (see spec
>>)
>>2. OIDC Front-channel logout (see spec
>>)
>>3. OIDC Back-channel logout (see spec
>>)
>>
>> In federated authentication, WSO2-IS will act as an RP and also it will
>> act as an OP to the downstream RPs and  logout the  the downstream
>> logged-in sessions. You can refer these specifications.
>> But Facebook is not an OpenID provider. It uses its own OpenID-like
>> system called Facebook connect. You can refer this stackoverflow
>> question [1]
>> 
>>
>>
>> Regards,
>> Piraveena
>>
>> *Piraveena Paralogarajah*
>> Intern- Software Engineering | WSO2
>> *Email *: pirave...@wso2.com
>> *Mobile* : +94776099594 <+94%2077%20609%209594>
>> 
>>
>> On Mon, Aug 14, 2017 at 5:37 PM, Maninda Edirisooriya 
>> wrote:
>>
>>> Hi Sugirjan,
>>>
>>> How the SLO works with sessions logged in with federated authentication?
>>> For example if a user has logged in with Facebook authentication how that
>>> user be logged out from the Authentication framework when the user is
>>> logged out from Facebook? Does OIDC has some spec to notify the WSO2 IDP
>>> that the Facebook was logged out?
>>>
>>> Thanks.
>>>
>>>
>>> *Maninda Edirisooriya*
>>> Senior Software Engineer
>>>
>>> *WSO2, Inc.*lean.enterprise.middleware.
>>>
>>> *Blog* : http://maninda.blogspot.com/
>>> *E-mail* : mani...@wso2.com
>>> *Skype* : @manindae
>>> *Twitter* : @maninda
>>>
>>> On Thu, Aug 10, 2017 at 5:53 PM, Sugirjan Ragunaathan >> > wrote:
>>>
 Hi Kasun,

 On Thu, Aug 10, 2017 at 12:11 PM, KasunG Gajasinghe 
 wrote:

>
> Can you list possible customer usecases on why they want to use this?
>

 The main usecases are

 1. If user using multiple applications which supports different
 authentication protocols on same browser session and user gets logout from
 one application, then he will be automatically logged out from all other
 applications. For example if user user use SAML based application and OIDC
 based Application on same browser session and if he logs out from SAML
 based application then automatically he will be logged out from OIDC based
 application.
 Currently Identity Server supports only for Cross protocol Single Login
 only.

 2. If user administrator wants to logout from all the applications
 which are emerged with Identity Server on same browser session, he can do
 force logout from all those applications without regard to authentication
 protocols that are supported. For example if any security breaches is
 happened and admin user want to logout from all the applications he can
 initiate a force logout request for them.


 On Thu, Aug 10, 2017 at 11:47 AM, Sugirjan Ragunaathan <
 sugir...@wso2.com> wrote:

> Hi,
>
> Currently I’m working on a project 'Cross protocol single logout'.
> WSO2 Identity Server provides Single LogOut over applications,
> participating on the same session over the same authentication protocol 
> and
> Single SignOn over the different protocols.
>
> [image: 1.png]
>
> Objective:
>
> Design and provide a solution to support cross protocol SLO
>
> Problem :
>
> WSO2 Identity Server supports multiple applications which are using
> different authentication protocols. It does not provide cross protocol
> Single Logout. For example, Assume that  you are using SAML based
> application and OIDC based application is same browser session. when you
> logout from a SAML based application it will only log you out from other
> SAML applications not from OIDC based application with the same session.
>
> Solution:
>
> The proposed solution for this problem is implementing a common event
> handler over different protocols. When a session is terminated because of
> user logout, an event should be published to invoke the ‘SLO  Event
> Handler’.So 'SLO Event Handler' notifies all the inbound authenticators 
> and
> the authenticators handle respective logout actions. In order to
> listen the logout event, all the respective authenticators have to be
> subscribed in the ‘SLO event handler’ and have own separate event handlers
> to trigger the logout for their registered applications.
>
> [image: SolutionArchi.png]
>
>

Re: [Architecture] Securing Product Apis and Product artifacts

[Harsha Thirimanna]

We had same kind of implementation in C4 by using tomcat valve instead of
filters. May not be same pattern what we expect here.[1]

[1] http://harshathirimanna.blogspot.com/2016/11/
authentication-authorization-common.html

And as I remember we did that to C5 as well by Ruwan using C4
implementation to targeting SCIM. I am not sure the last status. If we have
already discussed about this before to the discussion, please ignore this.

On Mon, Aug 14, 2017 at 5:46 PM, Tanya Madurapperuma  wrote:

> Hi all,
>
> We (Prabath, NuwanD, Suho, few IS team members, few analytics team
> members) had an offline discussion regarding $ Subject.
>
> *Problem*
> With the new rewrite of C5 based products, we have moved from SOAP based
> backend product APIs to  REST APIs. And there needs to be a mechanism to
> secure these product APIs. It can be either OAuth tokens based approach or
> basic auth.
>
> But the products like Analytics do not have in built OAuth support for
> token generation, validation  etc to achieve the above requirement.
>
> Also there needs to be an approach to secure product level artifacts such
> as Dashboards, widgets etc as well.
>
> Regardless of the securing mechanism that we use, product users should be
> able to try out and evaluate the default distribution of the product
> without much effort of setting up an external IDP.
>
> *Suggested solution*
> We will be implementing a custom IDP that has OAuth capabilities (password
> grant type) and required SCIM api implementations (Initially from Analytics
> dashboard pov we will need SCIM api for getting role list of users).
> And this custom IDP will be shipped with the product.
>
>
> ​
>
>
> *Securing Product APIs*
> Product APIs can be secured either with OAuth or basic auth interceptors
> based on the request header.
>
> We will have to maintain a scope to role mapping list in the product side
> and using a scope registration service we can register those at the custom
> IDP as same as APIM C5 doing.
>
> *Securing Product Artifacts*
> Artifacts such as dashboards, widgets are secured using a role based
> approach. Each product will maintain its own list of resources (artifacts)
> and respective roles in a database. This database will be updated upon a
> new resource addition, modification etc.
>
> *Securing Product UI elements*
> User facing application of the product will require to hide/show certain
> UI elements based on the logged in user. This also we can achieve using the
> scopes that we use to secure the product apis and roles that we use to
> secure product artifacts. Scopes and roles will be stored in the browser.
>
> For example, if we want to show/hide "create dashboard" button depending
> on the logged in user, we can show/hide, if the logged in user has the
> create_dashboard scope which is required to call the product api for
> creating a dashboard.
>
> For the product artifacts, say to decide on showing Foo Dashboard's edit
> button, we can use roles for that resources.
>
>
> Thanks,
> Tanya
>
> --
> Tanya Madurapperuma
>
> Associate Technical Lead,
> WSO2 Inc. : wso2.com
> Mobile : +94718184439 <+94%2071%20818%204439>
> Blog : http://tanyamadurapperuma.blogspot.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Cross Protocol Single Logout

[Harsha Thirimanna]

On Mon, Aug 14, 2017 at 6:37 PM, Piraveena Paralogarajah  wrote:

> Hi Maninda,
>
> In OpenID Connect, there are three ways for SLO.
>
>1. OIDC Session management (see spec
>)
>2. OIDC Front-channel logout (see spec
>)
>3. OIDC Back-channel logout (see spec
>)
>
> In federated authentication, WSO2-IS will act as an RP and also it will
> act as an OP to the downstream RPs and  logout the  the downstream
> logged-in sessions. You can refer these specifications.
> But Facebook is not an OpenID provider. It uses its own OpenID-like system
> called Facebook connect. You can refer this stackoverflow question [1]
> 
>
>
> Regards,
> Piraveena
>
> *Piraveena Paralogarajah*
> Intern- Software Engineering | WSO2
> *Email *: pirave...@wso2.com
> *Mobile* : +94776099594 <+94%2077%20609%209594>
> 
>
> On Mon, Aug 14, 2017 at 5:37 PM, Maninda Edirisooriya 
> wrote:
>
>> Hi Sugirjan,
>>
>> How the SLO works with sessions logged in with federated authentication?
>> For example if a user has logged in with Facebook authentication how that
>> user be logged out from the Authentication framework when the user is
>> logged out from Facebook? Does OIDC has some spec to notify the WSO2 IDP
>> that the Facebook was logged out?
>>
>> Thanks.
>>
>>
>> *Maninda Edirisooriya*
>> Senior Software Engineer
>>
>> *WSO2, Inc.*lean.enterprise.middleware.
>>
>> *Blog* : http://maninda.blogspot.com/
>> *E-mail* : mani...@wso2.com
>> *Skype* : @manindae
>> *Twitter* : @maninda
>>
>> On Thu, Aug 10, 2017 at 5:53 PM, Sugirjan Ragunaathan 
>> wrote:
>>
>>> Hi Kasun,
>>>
>>> On Thu, Aug 10, 2017 at 12:11 PM, KasunG Gajasinghe 
>>> wrote:
>>>

 Can you list possible customer usecases on why they want to use this?

>>>
>>> The main usecases are
>>>
>>> 1. If user using multiple applications which supports different
>>> authentication protocols on same browser session and user gets logout from
>>> one application, then he will be automatically logged out from all other
>>> applications. For example if user user use SAML based application and OIDC
>>> based Application on same browser session and if he logs out from SAML
>>> based application then automatically he will be logged out from OIDC based
>>> application.
>>> Currently Identity Server supports only for Cross protocol Single Login
>>> only.
>>>
>>> 2. If user administrator wants to logout from all the applications which
>>> are emerged with Identity Server on same browser session, he can do force
>>> logout from all those applications without regard to authentication
>>> protocols that are supported. For example if any security breaches is
>>> happened and admin user want to logout from all the applications he can
>>> initiate a force logout request for them.
>>>
>>>
>>> On Thu, Aug 10, 2017 at 11:47 AM, Sugirjan Ragunaathan <
>>> sugir...@wso2.com> wrote:
>>>
 Hi,

 Currently I’m working on a project 'Cross protocol single logout'. WSO2
 Identity Server provides Single LogOut over applications, participating on
 the same session over the same authentication protocol and Single SignOn
 over the different protocols.

 [image: 1.png]

 Objective:

 Design and provide a solution to support cross protocol SLO

 Problem :

 WSO2 Identity Server supports multiple applications which are using
 different authentication protocols. It does not provide cross protocol
 Single Logout. For example, Assume that  you are using SAML based
 application and OIDC based application is same browser session. when you
 logout from a SAML based application it will only log you out from other
 SAML applications not from OIDC based application with the same session.

 Solution:

 The proposed solution for this problem is implementing a common event
 handler over different protocols. When a session is terminated because of
 user logout, an event should be published to invoke the ‘SLO  Event
 Handler’.So 'SLO Event Handler' notifies all the inbound authenticators and
 the authenticators handle respective logout actions. In order to
 listen the logout event, all the respective authenticators have to be
 subscribed in the ‘SLO event handler’ and have own separate event handlers
 to trigger the logout for their registered applications.

 [image: SolutionArchi.png]


 We would like to have your feedback and suggestions in this regard.

>>>

+1 for this approach and while triggering this subscribed events, shall we
have a API to call to send SLO request, because it may be useful like, 

Re: [Architecture] [Dev] [VOTE] Release of WSO2 IoT Server 3.1.0 RC version 4

[Milan Perera]

Hi all,

Thanks for testing and verifying the WSO2 IoT Server RC4. We are closing
the vote now. This vote has passed with 15 (+1)s and 0 (-1)s. Therefore we
are proceeding with the WSO2 IoT Server 3.1.0 release.

15  (+1)
0(-1)

Regards,

On Mon, Aug 14, 2017 at 6:32 PM, Nirothipan Mehalingam 
wrote:

> Hi ,
>
> I have tested the Android Virtual Device Installation with Linux and Mac
> OS and found no issues.
>
> [+] Stable - go ahead and release.
>
> Thank you
> M.Nirothipan
>
> On Fri, Aug 11, 2017 at 7:06 PM, Milan Perera  wrote:
>
>> Hi Devs,
>>
>> We are pleased to announce the release candidate version 4 of WSO2 IoT Server
>> 3.1.0.
>>
>> Please download, test the product and vote. Vote will be open for 72
>> hours or as needed.
>>
>> Known issues : https://github.com/wso2/product-iots/issues-RC4
>> 
>>
>> Source and binary distribution files:
>> https://github.com/wso2/product-iots/releases/tag/v3.1.0-RC4
>>
>> The tag to be voted upon:
>> https://github.com/wso2/product-iots/tree/v3.1.0-RC4
>>
>> Please vote as follows.
>> [+] Stable - go ahead and release
>> [-] Broken - do not release (explain why)
>>
>> Thank you
>>
>> Regards,
>> --
>> *Milan Perera *| Senior Software Engineer
>> WSO2, Inc | lean. enterprise. middleware.
>> #20, Palm Grove, Colombo 03, Sri Lanka
>> Mobile: +94 77 309 7088 | Work: +94 11 214 5345
>> Email: mi...@wso2.com  | Web: www.wso2.com
>> 
>> 
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "WSO2 IoT Team Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to iot-group+unsubscr...@wso2.com.
>> For more options, visit https://groups.google.com/a/wso2.com/d/optout.
>>
>
>
>
> --
>
> *M.Nirothipan*
> Software Engineer
> WSO2
>
>
>
> *Mobile : +94 77 2172692 <+94%2077%20217%202692>  Web :
> http://wso2.com/ *
>



-- 
*Milan Perera *| Senior Software Engineer
WSO2, Inc | lean. enterprise. middleware.
#20, Palm Grove, Colombo 03, Sri Lanka
Mobile: +94 77 309 7088 | Work: +94 11 214 5345
Email: mi...@wso2.com  | Web: www.wso2.com


___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Cross Protocol Single Logout

[Piraveena Paralogarajah]

Hi Maninda,

In OpenID Connect, there are three ways for SLO.

   1. OIDC Session management (see spec
   )
   2. OIDC Front-channel logout (see spec
   )
   3. OIDC Back-channel logout (see spec
   )

In federated authentication, WSO2-IS will act as an RP and also it will act
as an OP to the downstream RPs and  logout the  the downstream logged-in
sessions. You can refer these specifications.
But Facebook is not an OpenID provider. It uses its own OpenID-like system
called Facebook connect. You can refer this stackoverflow question [1]



Regards,
Piraveena

*Piraveena Paralogarajah*
Intern- Software Engineering | WSO2
*Email *: pirave...@wso2.com
*Mobile* : +94776099594


On Mon, Aug 14, 2017 at 5:37 PM, Maninda Edirisooriya 
wrote:

> Hi Sugirjan,
>
> How the SLO works with sessions logged in with federated authentication?
> For example if a user has logged in with Facebook authentication how that
> user be logged out from the Authentication framework when the user is
> logged out from Facebook? Does OIDC has some spec to notify the WSO2 IDP
> that the Facebook was logged out?
>
> Thanks.
>
>
> *Maninda Edirisooriya*
> Senior Software Engineer
>
> *WSO2, Inc.*lean.enterprise.middleware.
>
> *Blog* : http://maninda.blogspot.com/
> *E-mail* : mani...@wso2.com
> *Skype* : @manindae
> *Twitter* : @maninda
>
> On Thu, Aug 10, 2017 at 5:53 PM, Sugirjan Ragunaathan 
> wrote:
>
>> Hi Kasun,
>>
>> On Thu, Aug 10, 2017 at 12:11 PM, KasunG Gajasinghe 
>> wrote:
>>
>>>
>>> Can you list possible customer usecases on why they want to use this?
>>>
>>
>> The main usecases are
>>
>> 1. If user using multiple applications which supports different
>> authentication protocols on same browser session and user gets logout from
>> one application, then he will be automatically logged out from all other
>> applications. For example if user user use SAML based application and OIDC
>> based Application on same browser session and if he logs out from SAML
>> based application then automatically he will be logged out from OIDC based
>> application.
>> Currently Identity Server supports only for Cross protocol Single Login
>> only.
>>
>> 2. If user administrator wants to logout from all the applications which
>> are emerged with Identity Server on same browser session, he can do force
>> logout from all those applications without regard to authentication
>> protocols that are supported. For example if any security breaches is
>> happened and admin user want to logout from all the applications he can
>> initiate a force logout request for them.
>>
>>
>> On Thu, Aug 10, 2017 at 11:47 AM, Sugirjan Ragunaathan > > wrote:
>>
>>> Hi,
>>>
>>> Currently I’m working on a project 'Cross protocol single logout'. WSO2
>>> Identity Server provides Single LogOut over applications, participating on
>>> the same session over the same authentication protocol and Single SignOn
>>> over the different protocols.
>>>
>>> [image: 1.png]
>>>
>>> Objective:
>>>
>>> Design and provide a solution to support cross protocol SLO
>>>
>>> Problem :
>>>
>>> WSO2 Identity Server supports multiple applications which are using
>>> different authentication protocols. It does not provide cross protocol
>>> Single Logout. For example, Assume that  you are using SAML based
>>> application and OIDC based application is same browser session. when you
>>> logout from a SAML based application it will only log you out from other
>>> SAML applications not from OIDC based application with the same session.
>>>
>>> Solution:
>>>
>>> The proposed solution for this problem is implementing a common event
>>> handler over different protocols. When a session is terminated because of
>>> user logout, an event should be published to invoke the ‘SLO  Event
>>> Handler’.So 'SLO Event Handler' notifies all the inbound authenticators and
>>> the authenticators handle respective logout actions. In order to listen
>>> the logout event, all the respective authenticators have to be subscribed
>>> in the ‘SLO event handler’ and have own separate event handlers to trigger
>>> the logout for their registered applications.
>>>
>>> [image: SolutionArchi.png]
>>>
>>>
>>> We would like to have your feedback and suggestions in this regard.
>>>
>>> Thanks.
>>>
>>> Regards,
>>> *R. Sugirjan*
>>> Software Engineering - Intern | WSO2
>>>
>>> Email:  sugir...@wso2.com
>>> Mobile: +94768489892 <076%20848%209892>
>>> 
>>>
>>
>>
>>
>> --
>>
>> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
>> email: kasung AT spamfree wso2.com
>> linked-in: http://lk.linkedin.com/in/gajasinghe
>> blog: http://kasunbg.org
>> phone: +1 

Re: [Architecture] [Dev] [VOTE] Release of WSO2 IoT Server 3.1.0 RC version 4

[Nirothipan Mehalingam]

Hi ,

I have tested the Android Virtual Device Installation with Linux and Mac OS
and found no issues.

[+] Stable - go ahead and release.

Thank you
M.Nirothipan

On Fri, Aug 11, 2017 at 7:06 PM, Milan Perera  wrote:

> Hi Devs,
>
> We are pleased to announce the release candidate version 4 of WSO2 IoT Server
> 3.1.0.
>
> Please download, test the product and vote. Vote will be open for 72 hours
> or as needed.
>
> Known issues : https://github.com/wso2/product-iots/issues-RC4
> 
>
> Source and binary distribution files:
> https://github.com/wso2/product-iots/releases/tag/v3.1.0-RC4
>
> The tag to be voted upon:
> https://github.com/wso2/product-iots/tree/v3.1.0-RC4
>
> Please vote as follows.
> [+] Stable - go ahead and release
> [-] Broken - do not release (explain why)
>
> Thank you
>
> Regards,
> --
> *Milan Perera *| Senior Software Engineer
> WSO2, Inc | lean. enterprise. middleware.
> #20, Palm Grove, Colombo 03, Sri Lanka
> Mobile: +94 77 309 7088 | Work: +94 11 214 5345
> Email: mi...@wso2.com  | Web: www.wso2.com
> 
> 
>
> --
> You received this message because you are subscribed to the Google Groups
> "WSO2 IoT Team Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to iot-group+unsubscr...@wso2.com.
> For more options, visit https://groups.google.com/a/wso2.com/d/optout.
>



-- 

*M.Nirothipan*
Software Engineer
WSO2



*Mobile : +94 77 2172692  Web : http://wso2.com/ *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [VOTE] Release of WSO2 IoT Server 3.1.0 RC version 4

[Lasantha Dharmakeerthi]

Hi all,

Tested following areas in Linux platform,

   1. Sample device types deployment.
   2. Connected-Cup device type deployment.
   3. Geo fencing artifact deployment

*With Super Tenant *

Android

   1. Device enrollment
   2. Device operations (location, ring, lock)
   3. Device renaming

Virtual Fire Alarm

   1. Download
   2. Buzzer on/off operations
   3. Real time analytics
   4. Batch analytics

Raspberry Pi

   1. Download directly
   2. Download via link

Connected Cup

   1. Creating Instance
   2. Real Time Analytics
   3. Batch Analytics

*With Tenant Mode*

Android

   1. Device Enrollment
   2. Device operations (location, ring, lock)
   3. Device renaming

No issues were found.

[+] Stable - go ahead and release.

Thanks and Best Regards,
Lasantha.

On Mon, Aug 14, 2017 at 5:18 PM, Menaka Jayawardena  wrote:

> Hi All,
>
> I have tested the following functionalities for Android Sense device type.
>
> 1. Enrollment
> 2. Sensor Data publishing and viewing them in device view.
> 3. Removing device and re-enrolling to a new user.
> 4. Geo Fencing features.
>
> +1 Stable - Go ahead and release.
>
> Thanks and Regards,
> Menaka
>
>
> On Mon, Aug 14, 2017 at 5:03 PM, Madawa Soysa  wrote:
>
>> Hi All,
>>
>> I have tested following functionalities for IOS device type. (v 10.1.1)
>>
>>- Enrolling device with/without ios-agent.
>>- Operation execution (Device lock, Ring, Location, Notification,
>>Enterprise-Wipe)
>>- Changing platform configurations.
>>- Passcode and restriction policies.
>>
>> No issues were found.
>>
>> [+] Stable - go ahead and release.
>>
>> Thanks,
>> Madawa
>>
>> On Fri, Aug 11, 2017 at 7:06 PM, Milan Perera  wrote:
>>
>>> Hi Devs,
>>>
>>> We are pleased to announce the release candidate version 4 of WSO2 IoT 
>>> Server
>>> 3.1.0.
>>>
>>> Please download, test the product and vote. Vote will be open for 72
>>> hours or as needed.
>>>
>>> Known issues : https://github.com/wso2/product-iots/issues-RC4
>>> 
>>>
>>> Source and binary distribution files:
>>> https://github.com/wso2/product-iots/releases/tag/v3.1.0-RC4
>>>
>>> The tag to be voted upon:
>>> https://github.com/wso2/product-iots/tree/v3.1.0-RC4
>>>
>>> Please vote as follows.
>>> [+] Stable - go ahead and release
>>> [-] Broken - do not release (explain why)
>>>
>>> Thank you
>>>
>>> Regards,
>>> --
>>> *Milan Perera *| Senior Software Engineer
>>> WSO2, Inc | lean. enterprise. middleware.
>>> #20, Palm Grove, Colombo 03, Sri Lanka
>>> Mobile: +94 77 309 7088 | Work: +94 11 214 5345
>>> Email: mi...@wso2.com  | Web: www.wso2.com
>>> 
>>> 
>>>
>>
>>
>>
>> --
>>
>> Madawa Soysa / Software Engineer
>> mada...@wso2.com / +94714616050 <+94%2071%20461%206050>
>>
>> *WSO2 Inc.*
>> lean.enterprise.middleware
>>
>>   
>>
>>
>>
>>
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Menaka Jayawardena*
> *Software Engineer - WSO2 Inc*
> *Tel : 071 350 5470*
> *LinkedIn: https://lk.linkedin.com/in/menakajayawardena
> *
> *Blog: https://menakamadushanka.wordpress.com/
> *
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Dharmakeerthi Lasantha*
Software Engineer - WSO2

Email - lasant...@wso2.com
Mobile - +94774928852
Web - http://wso2.com/
http://wso2.com/signature
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Securing Product Apis and Product artifacts

[Tanya Madurapperuma]

Hi all,

We (Prabath, NuwanD, Suho, few IS team members, few analytics team members)
had an offline discussion regarding $ Subject.

*Problem*
With the new rewrite of C5 based products, we have moved from SOAP based
backend product APIs to  REST APIs. And there needs to be a mechanism to
secure these product APIs. It can be either OAuth tokens based approach or
basic auth.

But the products like Analytics do not have in built OAuth support for
token generation, validation  etc to achieve the above requirement.

Also there needs to be an approach to secure product level artifacts such
as Dashboards, widgets etc as well.

Regardless of the securing mechanism that we use, product users should be
able to try out and evaluate the default distribution of the product
without much effort of setting up an external IDP.

*Suggested solution*
We will be implementing a custom IDP that has OAuth capabilities (password
grant type) and required SCIM api implementations (Initially from Analytics
dashboard pov we will need SCIM api for getting role list of users).
And this custom IDP will be shipped with the product.


​


*Securing Product APIs*
Product APIs can be secured either with OAuth or basic auth interceptors
based on the request header.

We will have to maintain a scope to role mapping list in the product side
and using a scope registration service we can register those at the custom
IDP as same as APIM C5 doing.

*Securing Product Artifacts*
Artifacts such as dashboards, widgets are secured using a role based
approach. Each product will maintain its own list of resources (artifacts)
and respective roles in a database. This database will be updated upon a
new resource addition, modification etc.

*Securing Product UI elements*
User facing application of the product will require to hide/show certain UI
elements based on the logged in user. This also we can achieve using the
scopes that we use to secure the product apis and roles that we use to
secure product artifacts. Scopes and roles will be stored in the browser.

For example, if we want to show/hide "create dashboard" button depending on
the logged in user, we can show/hide, if the logged in user has the
create_dashboard scope which is required to call the product api for
creating a dashboard.

For the product artifacts, say to decide on showing Foo Dashboard's edit
button, we can use roles for that resources.


Thanks,
Tanya

-- 
Tanya Madurapperuma

Associate Technical Lead,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Cross Protocol Single Logout

[Maninda Edirisooriya]

Hi Sugirjan,

How the SLO works with sessions logged in with federated authentication?
For example if a user has logged in with Facebook authentication how that
user be logged out from the Authentication framework when the user is
logged out from Facebook? Does OIDC has some spec to notify the WSO2 IDP
that the Facebook was logged out?

Thanks.


*Maninda Edirisooriya*
Senior Software Engineer

*WSO2, Inc.*lean.enterprise.middleware.

*Blog* : http://maninda.blogspot.com/
*E-mail* : mani...@wso2.com
*Skype* : @manindae
*Twitter* : @maninda

On Thu, Aug 10, 2017 at 5:53 PM, Sugirjan Ragunaathan 
wrote:

> Hi Kasun,
>
> On Thu, Aug 10, 2017 at 12:11 PM, KasunG Gajasinghe 
> wrote:
>
>>
>> Can you list possible customer usecases on why they want to use this?
>>
>
> The main usecases are
>
> 1. If user using multiple applications which supports different
> authentication protocols on same browser session and user gets logout from
> one application, then he will be automatically logged out from all other
> applications. For example if user user use SAML based application and OIDC
> based Application on same browser session and if he logs out from SAML
> based application then automatically he will be logged out from OIDC based
> application.
> Currently Identity Server supports only for Cross protocol Single Login
> only.
>
> 2. If user administrator wants to logout from all the applications which
> are emerged with Identity Server on same browser session, he can do force
> logout from all those applications without regard to authentication
> protocols that are supported. For example if any security breaches is
> happened and admin user want to logout from all the applications he can
> initiate a force logout request for them.
>
>
> On Thu, Aug 10, 2017 at 11:47 AM, Sugirjan Ragunaathan 
> wrote:
>
>> Hi,
>>
>> Currently I’m working on a project 'Cross protocol single logout'. WSO2
>> Identity Server provides Single LogOut over applications, participating on
>> the same session over the same authentication protocol and Single SignOn
>> over the different protocols.
>>
>> [image: 1.png]
>>
>> Objective:
>>
>> Design and provide a solution to support cross protocol SLO
>>
>> Problem :
>>
>> WSO2 Identity Server supports multiple applications which are using
>> different authentication protocols. It does not provide cross protocol
>> Single Logout. For example, Assume that  you are using SAML based
>> application and OIDC based application is same browser session. when you
>> logout from a SAML based application it will only log you out from other
>> SAML applications not from OIDC based application with the same session.
>>
>> Solution:
>>
>> The proposed solution for this problem is implementing a common event
>> handler over different protocols. When a session is terminated because of
>> user logout, an event should be published to invoke the ‘SLO  Event
>> Handler’.So 'SLO Event Handler' notifies all the inbound authenticators and
>> the authenticators handle respective logout actions. In order to listen
>> the logout event, all the respective authenticators have to be subscribed
>> in the ‘SLO event handler’ and have own separate event handlers to trigger
>> the logout for their registered applications.
>>
>> [image: SolutionArchi.png]
>>
>>
>> We would like to have your feedback and suggestions in this regard.
>>
>> Thanks.
>>
>> Regards,
>> *R. Sugirjan*
>> Software Engineering - Intern | WSO2
>>
>> Email:  sugir...@wso2.com
>> Mobile: +94768489892 <076%20848%209892>
>> 
>>
>
>
>
> --
>
> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
> email: kasung AT spamfree wso2.com
> linked-in: http://lk.linkedin.com/in/gajasinghe
> blog: http://kasunbg.org
> phone: +1 650-745-4499 <(650)%20745-4499>, 77 678 0813
>
>
> Thanks.
>
> Regards,
> *R. Sugirjan*
> Software Engineering - Intern | WSO2
>
> Email:  sugir...@wso2.com
> Mobile: +94768489892 <076%20848%209892>
> 
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [VOTE] Release of WSO2 IoT Server 3.1.0 RC version 4

[Menaka Jayawardena]

Hi All,

I have tested the following functionalities for Android Sense device type.

1. Enrollment
2. Sensor Data publishing and viewing them in device view.
3. Removing device and re-enrolling to a new user.
4. Geo Fencing features.

+1 Stable - Go ahead and release.

Thanks and Regards,
Menaka


On Mon, Aug 14, 2017 at 5:03 PM, Madawa Soysa  wrote:

> Hi All,
>
> I have tested following functionalities for IOS device type. (v 10.1.1)
>
>- Enrolling device with/without ios-agent.
>- Operation execution (Device lock, Ring, Location, Notification,
>Enterprise-Wipe)
>- Changing platform configurations.
>- Passcode and restriction policies.
>
> No issues were found.
>
> [+] Stable - go ahead and release.
>
> Thanks,
> Madawa
>
> On Fri, Aug 11, 2017 at 7:06 PM, Milan Perera  wrote:
>
>> Hi Devs,
>>
>> We are pleased to announce the release candidate version 4 of WSO2 IoT Server
>> 3.1.0.
>>
>> Please download, test the product and vote. Vote will be open for 72
>> hours or as needed.
>>
>> Known issues : https://github.com/wso2/product-iots/issues-RC4
>> 
>>
>> Source and binary distribution files:
>> https://github.com/wso2/product-iots/releases/tag/v3.1.0-RC4
>>
>> The tag to be voted upon:
>> https://github.com/wso2/product-iots/tree/v3.1.0-RC4
>>
>> Please vote as follows.
>> [+] Stable - go ahead and release
>> [-] Broken - do not release (explain why)
>>
>> Thank you
>>
>> Regards,
>> --
>> *Milan Perera *| Senior Software Engineer
>> WSO2, Inc | lean. enterprise. middleware.
>> #20, Palm Grove, Colombo 03, Sri Lanka
>> Mobile: +94 77 309 7088 | Work: +94 11 214 5345
>> Email: mi...@wso2.com  | Web: www.wso2.com
>> 
>> 
>>
>
>
>
> --
>
> Madawa Soysa / Software Engineer
> mada...@wso2.com / +94714616050 <+94%2071%20461%206050>
>
> *WSO2 Inc.*
> lean.enterprise.middleware
>
>   
>
>
>
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Menaka Jayawardena*
*Software Engineer - WSO2 Inc*
*Tel : 071 350 5470*
*LinkedIn: https://lk.linkedin.com/in/menakajayawardena
*
*Blog: https://menakamadushanka.wordpress.com/
*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [VOTE] Release of WSO2 IoT Server 3.1.0 RC version 4

[Madawa Soysa]

Hi All,

I have tested following functionalities for IOS device type. (v 10.1.1)

   - Enrolling device with/without ios-agent.
   - Operation execution (Device lock, Ring, Location, Notification,
   Enterprise-Wipe)
   - Changing platform configurations.
   - Passcode and restriction policies.

No issues were found.

[+] Stable - go ahead and release.

Thanks,
Madawa

On Fri, Aug 11, 2017 at 7:06 PM, Milan Perera  wrote:

> Hi Devs,
>
> We are pleased to announce the release candidate version 4 of WSO2 IoT Server
> 3.1.0.
>
> Please download, test the product and vote. Vote will be open for 72 hours
> or as needed.
>
> Known issues : https://github.com/wso2/product-iots/issues-RC4
> 
>
> Source and binary distribution files:
> https://github.com/wso2/product-iots/releases/tag/v3.1.0-RC4
>
> The tag to be voted upon:
> https://github.com/wso2/product-iots/tree/v3.1.0-RC4
>
> Please vote as follows.
> [+] Stable - go ahead and release
> [-] Broken - do not release (explain why)
>
> Thank you
>
> Regards,
> --
> *Milan Perera *| Senior Software Engineer
> WSO2, Inc | lean. enterprise. middleware.
> #20, Palm Grove, Colombo 03, Sri Lanka
> Mobile: +94 77 309 7088 | Work: +94 11 214 5345
> Email: mi...@wso2.com  | Web: www.wso2.com
> 
> 
>



-- 

Madawa Soysa / Software Engineer
mada...@wso2.com / +94714616050

*WSO2 Inc.*
lean.enterprise.middleware

  
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [VOTE] Release of WSO2 IoT Server 3.1.0 RC version 4

[Pasindu Jayaweera]

Hi all,
I've tested the following for Android Device (Android 6.0 OS) from Admin
user.
1. Device enrollment
2. Device operations (Ring, Mute, Message, Change Lock-code, Clear
Lock-code, Enterprise-wipe)
3. App installation via App Store.
4. Observe Device status changing. (Active <-> Removed, Active <->
Unreachable )

No issues found.
[+] Stable - Go ahead and release.

Regards,
Pasindu



On Mon, Aug 14, 2017 at 4:48 PM, Sumedha Rubasinghe 
wrote:

> I tested following:
> Virtual firealarm (control operations,analytics - realtime & batch)
> Android Device Mgt(enrollment, ring, message)
> Device Type creation (HTTP,MQTT)
> Device pushing data (via API)
>
> No blockers were found.
>
> [+] Stable - Go ahead and release.
>
> Thanks,
> Sumedha
>
>
>
> On Mon, Aug 14, 2017 at 3:07 PM, Pubudu D.P  wrote:
>
>> Hi all,
>>
>> Tested following areas on Windows and Mac with an Android device.
>>
>>- Device enrollment
>>- Push notifications
>>- Device grouping
>>- Device location
>>- Geo Fencing
>>- Device status update
>>- Device search
>>- Operations
>>- Policy
>>- App install
>>
>> Also, verified bug fixes at [1].
>>
>> [1] https://github.com/wso2/product-iots/issues?utf8=%E2%9C%
>> 93=is%3Aissue%20label%3A3.1.0-RC3%20is%3Aclosed%20author%3Apubudup%20
>>
>> No blocking issues encountered.
>>
>> [+] Stable - Go ahead and release.
>>
>> Cheers,
>> Pubudu D.P
>> Senior Software Engineer - QA Team | WSO2 inc.
>> Mobile : +94775464547 <077%20546%204547>
>>
>> Linkedin: https://uk.linkedin.com/in/pubududp
>> Medium: https://medium.com/@pubududp
>>
>>
>> On Sun, Aug 13, 2017 at 10:13 PM, Megala Uthayakumar 
>> wrote:
>>
>>> Hi,
>>>
>>> I tested followings
>>>
>>>- Mobile Device and App Management Quick Start guide with android.
>>>- User Management and Role Management functionalities through device
>>>management console.
>>>- Android device enrollment as a normal user. Tested with some
>>>operations as well.
>>>- Android sense enrollment as a normal user. Was able to see the
>>>relevant graphs.
>>>
>>> Did not encounter any issues. Hence,
>>> [+] Stable - Go ahead and release.
>>>
>>> Thanks.
>>>
>>> Regards,
>>> Megala
>>>
>>> On Fri, Aug 11, 2017 at 7:06 PM, Milan Perera  wrote:
>>>
 Hi Devs,

 We are pleased to announce the release candidate version 4 of WSO2 IoT 
 Server
 3.1.0.

 Please download, test the product and vote. Vote will be open for 72
 hours or as needed.

 Known issues : https://github.com/wso2/product-iots/issues-RC4
 

 Source and binary distribution files:
 https://github.com/wso2/product-iots/releases/tag/v3.1.0-RC4

 The tag to be voted upon:
 https://github.com/wso2/product-iots/tree/v3.1.0-RC4

 Please vote as follows.
 [+] Stable - go ahead and release
 [-] Broken - do not release (explain why)

 Thank you

 Regards,
 --
 *Milan Perera *| Senior Software Engineer
 WSO2, Inc | lean. enterprise. middleware.
 #20, Palm Grove, Colombo 03, Sri Lanka
 Mobile: +94 77 309 7088 | Work: +94 11 214 5345
 Email: mi...@wso2.com  | Web: www.wso2.com
 
 

>>>
>>>
>>>
>>> --
>>> Megala Uthayakumar
>>>
>>> Software Engineer
>>> Mobile : 0779967122 <077%20996%207122>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Pasindu Jayaweera*
Software Engineer | WSO2 Inc
Mobile: +94 718187375
Blog: blog.pasindujayaweera.com

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [VOTE] Release of WSO2 IoT Server 3.1.0 RC version 4

[Sumedha Rubasinghe]

I tested following:
Virtual firealarm (control operations,analytics - realtime & batch)
Android Device Mgt(enrollment, ring, message)
Device Type creation (HTTP,MQTT)
Device pushing data (via API)

No blockers were found.

[+] Stable - Go ahead and release.

Thanks,
Sumedha



On Mon, Aug 14, 2017 at 3:07 PM, Pubudu D.P  wrote:

> Hi all,
>
> Tested following areas on Windows and Mac with an Android device.
>
>- Device enrollment
>- Push notifications
>- Device grouping
>- Device location
>- Geo Fencing
>- Device status update
>- Device search
>- Operations
>- Policy
>- App install
>
> Also, verified bug fixes at [1].
>
> [1] https://github.com/wso2/product-iots/issues?utf8=%E2%
> 9C%93=is%3Aissue%20label%3A3.1.0-RC3%20is%3Aclosed%20author%3Apubudup%20
>
> No blocking issues encountered.
>
> [+] Stable - Go ahead and release.
>
> Cheers,
> Pubudu D.P
> Senior Software Engineer - QA Team | WSO2 inc.
> Mobile : +94775464547 <077%20546%204547>
>
> Linkedin: https://uk.linkedin.com/in/pubududp
> Medium: https://medium.com/@pubududp
>
>
> On Sun, Aug 13, 2017 at 10:13 PM, Megala Uthayakumar 
> wrote:
>
>> Hi,
>>
>> I tested followings
>>
>>- Mobile Device and App Management Quick Start guide with android.
>>- User Management and Role Management functionalities through device
>>management console.
>>- Android device enrollment as a normal user. Tested with some
>>operations as well.
>>- Android sense enrollment as a normal user. Was able to see the
>>relevant graphs.
>>
>> Did not encounter any issues. Hence,
>> [+] Stable - Go ahead and release.
>>
>> Thanks.
>>
>> Regards,
>> Megala
>>
>> On Fri, Aug 11, 2017 at 7:06 PM, Milan Perera  wrote:
>>
>>> Hi Devs,
>>>
>>> We are pleased to announce the release candidate version 4 of WSO2 IoT 
>>> Server
>>> 3.1.0.
>>>
>>> Please download, test the product and vote. Vote will be open for 72
>>> hours or as needed.
>>>
>>> Known issues : https://github.com/wso2/product-iots/issues-RC4
>>> 
>>>
>>> Source and binary distribution files:
>>> https://github.com/wso2/product-iots/releases/tag/v3.1.0-RC4
>>>
>>> The tag to be voted upon:
>>> https://github.com/wso2/product-iots/tree/v3.1.0-RC4
>>>
>>> Please vote as follows.
>>> [+] Stable - go ahead and release
>>> [-] Broken - do not release (explain why)
>>>
>>> Thank you
>>>
>>> Regards,
>>> --
>>> *Milan Perera *| Senior Software Engineer
>>> WSO2, Inc | lean. enterprise. middleware.
>>> #20, Palm Grove, Colombo 03, Sri Lanka
>>> Mobile: +94 77 309 7088 | Work: +94 11 214 5345
>>> Email: mi...@wso2.com  | Web: www.wso2.com
>>> 
>>> 
>>>
>>
>>
>>
>> --
>> Megala Uthayakumar
>>
>> Software Engineer
>> Mobile : 0779967122 <077%20996%207122>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [VOTE] Release of WSO2 IoT Server 3.1.0 RC version 4

[Pubudu D.P]

Hi all,

Tested following areas on Windows and Mac with an Android device.

   - Device enrollment
   - Push notifications
   - Device grouping
   - Device location
   - Geo Fencing
   - Device status update
   - Device search
   - Operations
   - Policy
   - App install

Also, verified bug fixes at [1].

[1]
https://github.com/wso2/product-iots/issues?utf8=%E2%9C%93=is%3Aissue%20label%3A3.1.0-RC3%20is%3Aclosed%20author%3Apubudup%20

No blocking issues encountered.

[+] Stable - Go ahead and release.

Cheers,
Pubudu D.P
Senior Software Engineer - QA Team | WSO2 inc.
Mobile : +94775464547

Linkedin: https://uk.linkedin.com/in/pubududp
Medium: https://medium.com/@pubududp


On Sun, Aug 13, 2017 at 10:13 PM, Megala Uthayakumar 
wrote:

> Hi,
>
> I tested followings
>
>- Mobile Device and App Management Quick Start guide with android.
>- User Management and Role Management functionalities through device
>management console.
>- Android device enrollment as a normal user. Tested with some
>operations as well.
>- Android sense enrollment as a normal user. Was able to see the
>relevant graphs.
>
> Did not encounter any issues. Hence,
> [+] Stable - Go ahead and release.
>
> Thanks.
>
> Regards,
> Megala
>
> On Fri, Aug 11, 2017 at 7:06 PM, Milan Perera  wrote:
>
>> Hi Devs,
>>
>> We are pleased to announce the release candidate version 4 of WSO2 IoT Server
>> 3.1.0.
>>
>> Please download, test the product and vote. Vote will be open for 72
>> hours or as needed.
>>
>> Known issues : https://github.com/wso2/product-iots/issues-RC4
>> 
>>
>> Source and binary distribution files:
>> https://github.com/wso2/product-iots/releases/tag/v3.1.0-RC4
>>
>> The tag to be voted upon:
>> https://github.com/wso2/product-iots/tree/v3.1.0-RC4
>>
>> Please vote as follows.
>> [+] Stable - go ahead and release
>> [-] Broken - do not release (explain why)
>>
>> Thank you
>>
>> Regards,
>> --
>> *Milan Perera *| Senior Software Engineer
>> WSO2, Inc | lean. enterprise. middleware.
>> #20, Palm Grove, Colombo 03, Sri Lanka
>> Mobile: +94 77 309 7088 | Work: +94 11 214 5345
>> Email: mi...@wso2.com  | Web: www.wso2.com
>> 
>> 
>>
>
>
>
> --
> Megala Uthayakumar
>
> Software Engineer
> Mobile : 0779967122
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [VOTE] Release of WSO2 IoT Server 3.1.0 RC version 4

[Kamidu Punchihewa]

Hi all,

I tested the below mentioned as a super tenant user and tenant admin:

   1. User Management
   2. Policy Managment
   3. Role and Permission Managment
   4. Configuration Managment.
   5. IOS Device enrollment and policy publishing
   6. VFL Enrollment and Analytics
   7. Android mobile enrollment, policy, and operations.
   8. Disenrolling an Android device
   9. Android sense enrollment and analytics.

No issues were found.

[+] Stable - go ahead and release.

Thanks and Best Regards,

On Sun, Aug 13, 2017 at 10:13 PM, Megala Uthayakumar 
wrote:

> Hi,
>
> I tested followings
>
>- Mobile Device and App Management Quick Start guide with android.
>- User Management and Role Management functionalities through device
>management console.
>- Android device enrollment as a normal user. Tested with some
>operations as well.
>- Android sense enrollment as a normal user. Was able to see the
>relevant graphs.
>
> Did not encounter any issues. Hence,
> [+] Stable - Go ahead and release.
>
> Thanks.
>
> Regards,
> Megala
>
> On Fri, Aug 11, 2017 at 7:06 PM, Milan Perera  wrote:
>
>> Hi Devs,
>>
>> We are pleased to announce the release candidate version 4 of WSO2 IoT Server
>> 3.1.0.
>>
>> Please download, test the product and vote. Vote will be open for 72
>> hours or as needed.
>>
>> Known issues : https://github.com/wso2/product-iots/issues-RC4
>> 
>>
>> Source and binary distribution files:
>> https://github.com/wso2/product-iots/releases/tag/v3.1.0-RC4
>>
>> The tag to be voted upon:
>> https://github.com/wso2/product-iots/tree/v3.1.0-RC4
>>
>> Please vote as follows.
>> [+] Stable - go ahead and release
>> [-] Broken - do not release (explain why)
>>
>> Thank you
>>
>> Regards,
>> --
>> *Milan Perera *| Senior Software Engineer
>> WSO2, Inc | lean. enterprise. middleware.
>> #20, Palm Grove, Colombo 03, Sri Lanka
>> Mobile: +94 77 309 7088 | Work: +94 11 214 5345
>> Email: mi...@wso2.com  | Web: www.wso2.com
>> 
>> 
>>
>
>
>
> --
> Megala Uthayakumar
>
> Software Engineer
> Mobile : 0779967122
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Kamidu Sachith Punchihewa
*Senior Software Engineer*
WSO2, Inc.
lean . enterprise . middleware
Mobile : +94 (0) 770566749 <%2B94%20%280%29%20773%20451194>


Please Note that I have dyslexia and it may results in few misspelled words
in the content.
Disclaimer: This communication may contain privileged or other confidential
information and is intended exclusively for the addressee/s. If you are not
the intended recipient/s, or believe that you may have received this
communication in error, please reply to the sender indicating that fact and
delete the copy you received and in addition, you should not print, copy,
retransmit, disseminate, or otherwise use the information contained in this
communication. Internet communications cannot be guaranteed to be timely,
secure, error or virus-free. The sender does not accept liability for any
errors or omissions.
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [VOTE] Release of WSO2 IoT Server 3.1.0 RC version 4

[Sameera Gunarathne]

Hi,

I have tested followings in Linux and windows platforms,

   - Android mobile device enrollment and operations
   - Android policy compliance
   - Geo fencing alert generation
   - Device grouping
   - Enterprise App installation and scheduled app installation from mobile
   app store

No issues occurred.

[+] Stable - Go ahead and release.

Thanks,
Regards.

On Sun, Aug 13, 2017 at 10:13 PM, Megala Uthayakumar 
wrote:

> Hi,
>
> I tested followings
>
>- Mobile Device and App Management Quick Start guide with android.
>- User Management and Role Management functionalities through device
>management console.
>- Android device enrollment as a normal user. Tested with some
>operations as well.
>- Android sense enrollment as a normal user. Was able to see the
>relevant graphs.
>
> Did not encounter any issues. Hence,
> [+] Stable - Go ahead and release.
>
> Thanks.
>
> Regards,
> Megala
>
> On Fri, Aug 11, 2017 at 7:06 PM, Milan Perera  wrote:
>
>> Hi Devs,
>>
>> We are pleased to announce the release candidate version 4 of WSO2 IoT Server
>> 3.1.0.
>>
>> Please download, test the product and vote. Vote will be open for 72
>> hours or as needed.
>>
>> Known issues : https://github.com/wso2/product-iots/issues-RC4
>> 
>>
>> Source and binary distribution files:
>> https://github.com/wso2/product-iots/releases/tag/v3.1.0-RC4
>>
>> The tag to be voted upon:
>> https://github.com/wso2/product-iots/tree/v3.1.0-RC4
>>
>> Please vote as follows.
>> [+] Stable - go ahead and release
>> [-] Broken - do not release (explain why)
>>
>> Thank you
>>
>> Regards,
>> --
>> *Milan Perera *| Senior Software Engineer
>> WSO2, Inc | lean. enterprise. middleware.
>> #20, Palm Grove, Colombo 03, Sri Lanka
>> Mobile: +94 77 309 7088 | Work: +94 11 214 5345
>> Email: mi...@wso2.com  | Web: www.wso2.com
>> 
>> 
>>
>
>
>
> --
> Megala Uthayakumar
>
> Software Engineer
> Mobile : 0779967122
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Sameera Gunarathne
Software Engineer, WSO2 Inc. http://wso2.com

Email: samee...@wso2.com
Mobile: +94714155561
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Multiple runtime support for C5 based products

[Niranjan Karunanandham]

Hi Thusitha,

On Mon, Aug 14, 2017 at 12:08 PM, Thusitha Thilina Dayaratne <
thusit...@wso2.com> wrote:

> Hi Jayanga,
>
> From the beginning of C5, we tried to achieve a clear separation between,
>> User(Custom) space and Server space.
>> IMO, having just a single deployment directory (for both custom and
>> server artifacts) won't help to maintain that separation.
>
> We are having 2 deployment directories.
>
>1. //deployment
>2. /deployment
>
> The issue is in existing API we have a method to deploy/upload the given
> artifact to the deployment directory. This was not an issue previously coz
> we had only single deployment dir. But since now we have multiple
> deployment dirs, where should we deploy the artifact?
>
When are we using this method, i.e., the use-case? If the artifact is
within the either the runtime deployment or serverhome deployment
directory, then based on that the artifact can be deployed in the
corresponding directory.


>
> Thanks
> Thusitha
>
> On Mon, Aug 14, 2017 at 11:15 AM, Jayanga Dissanayake 
> wrote:
>
>> Hi Thusitha/Nira,
>>
>> From the beginning of C5, we tried to achieve a clear separation between,
>> User(Custom) space and Server space.
>> IMO, having just a single deployment directory (for both custom and
>> server artifacts) won't help to maintain that separation.
>>
>> WDYT?
>>
>> Thanks,
>> Jayanga.
>>
>> *Jayanga Dissanayake*
>> Associate Technical Lead
>> WSO2 Inc. - http://wso2.com/
>> lean . enterprise . middleware
>> email: jaya...@wso2.com
>> mobile: +94772207259 <+94%2077%20220%207259>
>> 
>>
>> On Mon, Aug 14, 2017 at 10:53 AM, Niranjan Karunanandham <
>> niran...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> On Fri, Aug 11, 2017 at 11:24 AM, Thusitha Thilina Dayaratne <
>>> thusit...@wso2.com> wrote:
>>>
 Hi All,

 In c5 carbon-deployment we have a method to manually deploy artifacts
 where we only provide artifact's path and artifact type. This was no issue
 until 5.2.0-m3 since we only had a single deployment directory.
 public void deploy(String artifactPath, ArtifactType artifactType)[1]

 But since we have 2 deployment directories with the new
 runtime architecture. So how should we handle this deployment?
 AFAIU options would be as follows

1. Add a new API(method) to get the relevant deployment dir and
deploy to that
2. We have to prioritize a deployment directory (Server or runtime)
and deploy only to the prioritized one
3. Deploy to both deployment dirs



>>> In the new deployment directory, each runtime will have a deployment
>>> directory and there will be on outside. The runtime deployment will be for
>>> wso2 artifacts. AFAIU with previous model (C4), the above method is used by
>>> when a user uploads the artifact from a UI. Therefore IMO the default
>>> method should deploy the artifact to the deployment directory outside the
>>> runtime, i.e., /deployment.
>>>
>>>
 [1] - https://github.com/wso2/carbon-deployment/blob/master/comp
 onents/org.wso2.carbon.deployment.engine/src/main/java/org/w
 so2/carbon/deployment/engine/DeploymentService.java#L43

 Thanks
 Thusitha


 On Fri, Jun 2, 2017 at 10:23 AM, Danesh Kuruppu 
 wrote:

> Hi all,
>
> Correction: Proposed directory structure needed to be change as below.
> instead of having deployment directory per runtime, we will have only
> deployment directory per server distribution. This deployment directory
> contains custom deployable artifacts. So ideally there won't be any
> artifact in default distribution.
>
> Though we have packaging all runtimes in one distribution. we are not
> encouraging to run all runtime from the single pack. So we are going to
> provide a script to exact runtime from the distribution pack.
>
> ServerHome
>>|_ bin
>>| |___ runtime1.sh
>>| |___ runtime2.sh
>>| |___ start-all.sh (start all the runtimes except
>> default in separate JVMs)
>>| |___ default.sh (start required runtimes in a
>> single JVM)
>>| |___ jartobundle.sh
>>|
>>|
>>|_ deployment (This will contains custom deployable
>> artifacts)
>>| |___ uuf
>>| |___ microservices
>>|
>>|_ lib
>>|
>>|_ conf
>>|| runtime1
>>|| | deployment.yaml
>>|| | master-keys.yaml
>>|| | secrets.properties
>>|| | log4j2.xml
>>|| | etc
>>|| 

Re: [Architecture] Multiple runtime support for C5 based products

[Thusitha Thilina Dayaratne]

Hi Jayanga,

>From the beginning of C5, we tried to achieve a clear separation between,
> User(Custom) space and Server space.
> IMO, having just a single deployment directory (for both custom and server
> artifacts) won't help to maintain that separation.

We are having 2 deployment directories.

   1. //deployment
   2. /deployment

The issue is in existing API we have a method to deploy/upload the given
artifact to the deployment directory. This was not an issue previously coz
we had only single deployment dir. But since now we have multiple
deployment dirs, where should we deploy the artifact?

Thanks
Thusitha

On Mon, Aug 14, 2017 at 11:15 AM, Jayanga Dissanayake 
wrote:

> Hi Thusitha/Nira,
>
> From the beginning of C5, we tried to achieve a clear separation between,
> User(Custom) space and Server space.
> IMO, having just a single deployment directory (for both custom and server
> artifacts) won't help to maintain that separation.
>
> WDYT?
>
> Thanks,
> Jayanga.
>
> *Jayanga Dissanayake*
> Associate Technical Lead
> WSO2 Inc. - http://wso2.com/
> lean . enterprise . middleware
> email: jaya...@wso2.com
> mobile: +94772207259 <+94%2077%20220%207259>
> 
>
> On Mon, Aug 14, 2017 at 10:53 AM, Niranjan Karunanandham <
> niran...@wso2.com> wrote:
>
>> Hi,
>>
>> On Fri, Aug 11, 2017 at 11:24 AM, Thusitha Thilina Dayaratne <
>> thusit...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> In c5 carbon-deployment we have a method to manually deploy artifacts
>>> where we only provide artifact's path and artifact type. This was no issue
>>> until 5.2.0-m3 since we only had a single deployment directory.
>>> public void deploy(String artifactPath, ArtifactType artifactType)[1]
>>>
>>> But since we have 2 deployment directories with the new
>>> runtime architecture. So how should we handle this deployment?
>>> AFAIU options would be as follows
>>>
>>>1. Add a new API(method) to get the relevant deployment dir and
>>>deploy to that
>>>2. We have to prioritize a deployment directory (Server or runtime)
>>>and deploy only to the prioritized one
>>>3. Deploy to both deployment dirs
>>>
>>>
>>>
>> In the new deployment directory, each runtime will have a deployment
>> directory and there will be on outside. The runtime deployment will be for
>> wso2 artifacts. AFAIU with previous model (C4), the above method is used by
>> when a user uploads the artifact from a UI. Therefore IMO the default
>> method should deploy the artifact to the deployment directory outside the
>> runtime, i.e., /deployment.
>>
>>
>>> [1] - https://github.com/wso2/carbon-deployment/blob/master/comp
>>> onents/org.wso2.carbon.deployment.engine/src/main/java/org/w
>>> so2/carbon/deployment/engine/DeploymentService.java#L43
>>>
>>> Thanks
>>> Thusitha
>>>
>>>
>>> On Fri, Jun 2, 2017 at 10:23 AM, Danesh Kuruppu  wrote:
>>>
 Hi all,

 Correction: Proposed directory structure needed to be change as below.
 instead of having deployment directory per runtime, we will have only
 deployment directory per server distribution. This deployment directory
 contains custom deployable artifacts. So ideally there won't be any
 artifact in default distribution.

 Though we have packaging all runtimes in one distribution. we are not
 encouraging to run all runtime from the single pack. So we are going to
 provide a script to exact runtime from the distribution pack.

 ServerHome
>|_ bin
>| |___ runtime1.sh
>| |___ runtime2.sh
>| |___ start-all.sh (start all the runtimes except
> default in separate JVMs)
>| |___ default.sh (start required runtimes in a
> single JVM)
>| |___ jartobundle.sh
>|
>|
>|_ deployment (This will contains custom deployable
> artifacts)
>| |___ uuf
>| |___ microservices
>|
>|_ lib
>|
>|_ conf
>|| runtime1
>|| | deployment.yaml
>|| | master-keys.yaml
>|| | secrets.properties
>|| | log4j2.xml
>|| | etc
>|| | |__
> pax-logging.properties
>|| | osgi
>||   |__ launch.properties
>||   |__ osgi-debug.options
>|| runtime2
>|  | deployment.yaml
>|  | master-keys.yaml
>|  |