Re: [Architecture] [UUF] Extensible Session Management for UUF

[Dilan Udara Ariyaratne]

Hi Vidura,

+1 for the effort.

In the meantime, could you elaborate on the method level details of the
Session manager interface, too?

Cheers,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Mon, May 1, 2017 at 10:39 PM, Shazni Nazeer  wrote:

> It is beneficial to have this in the UUF.
>
> Many frameworks (in particular web frameworks such as Django, CakePHP and
> Ruby on Rails) support this kind of pluggable Session Management
> capabilities.
>
> On Fri, Apr 28, 2017 at 3:46 PM, Vidura Nanayakkara 
> wrote:
>
>> Hi All,
>>
>> We are in the process of introducing extensible session management
>> mechanism for Carbon UUF.
>>
>> Previously in Carbon UUF, the session management was not extensible and
>> was tightly coupled to the Carbon UUF framework. The purpose of introducing
>> an extensible session management mechanism is to give the ability for the
>> web app developers to plug in any session management implementation of
>> choice. For instance, this can be a JDBC persistent session management or a
>> token based session management implementation.
>>
>> In order to plug in a custom session manager, one need to implement the
>> given `SessionManager` interface. That implementation needs to be specified
>> in the `app.yaml` configuration of the particular UUF app.
>>
>> Example app.yaml configuration:
>>
>> *...*
>>
>> # Session manager for this app
>>
>> sessionManager: *"org.wso2.carbon.uuf.api.auth.InMemorySessionManager"*
>>
>> *...*
>>
>> *WDYT?*
>>
>>
>> Best Regards,
>>
>> *Vidura Nanayakkara*
>> Software Engineer
>>
>> Email : vidu...@wso2.com
>> Mobile : +94 (0) 717 919277 <+94%2071%20791%209277>
>> Web : http://wso2.com
>> Blog : https://medium.com/@viduran 
>> LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara
>> 
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Shazni Nazeer
>
> Mob : +94 37331
> LinkedIn : http://lk.linkedin.com/in/shazninazeer
> Blog : http://shazninazeer.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] [UUF] Extensible Session Management for UUF

[Dilan Udara Ariyaratne]

Hi Imesh and @Vidura,

I wonder if both SessionHandler and SessionManager interfaces could be
merged together to have one interface
that could derive all management level functionalities of a session ?

I think that current SessionManager, i.e.
org.wso2.carbon.uuf.spi.auth.SessionManager
is bit meaningless without capabilities like
createSession(), getSession() and destroySession() that
org.wso2.carbon.uuf.api.auth.SessionHandler provides.

WDYT?

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Tue, May 2, 2017 at 11:02 AM, Imesh Gunaratne  wrote:

> On Tue, May 2, 2017 at 10:44 AM, Dilan Udara Ariyaratne 
> wrote:
>
>>
>> In the meantime, could you elaborate on the method level details of the
>> Session manager interface, too?
>>
>
> ​SessionManager:​
> ​https://github.com/wso2/carbon-uuf/pull/241/files#diff-50f8
> 2419222617b7f14b6d08d45984ac
>
> SessionHandler:
> https://github.com/wso2/carbon-uuf/pull/241/files#diff-39f1b
> 4c291c422e721e8c56d191c75e3​
>
> Thanks
>
>>
>> Cheers,
>> Dilan.
>>
>> *Dilan U. Ariyaratne*
>> Senior Software Engineer
>> WSO2 Inc. <http://wso2.com/>
>> Mobile: +94766405580 <%2B94766405580>
>> lean . enterprise . middleware
>>
>>
>> On Mon, May 1, 2017 at 10:39 PM, Shazni Nazeer  wrote:
>>
>>> It is beneficial to have this in the UUF.
>>>
>>> Many frameworks (in particular web frameworks such as Django, CakePHP
>>> and Ruby on Rails) support this kind of pluggable Session Management
>>> capabilities.
>>>
>>> On Fri, Apr 28, 2017 at 3:46 PM, Vidura Nanayakkara 
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> We are in the process of introducing extensible session management
>>>> mechanism for Carbon UUF.
>>>>
>>>> Previously in Carbon UUF, the session management was not extensible and
>>>> was tightly coupled to the Carbon UUF framework. The purpose of introducing
>>>> an extensible session management mechanism is to give the ability for the
>>>> web app developers to plug in any session management implementation of
>>>> choice. For instance, this can be a JDBC persistent session management or a
>>>> token based session management implementation.
>>>>
>>>> In order to plug in a custom session manager, one need to implement the
>>>> given `SessionManager` interface. That implementation needs to be specified
>>>> in the `app.yaml` configuration of the particular UUF app.
>>>>
>>>> Example app.yaml configuration:
>>>>
>>>> *...*
>>>>
>>>> # Session manager for this app
>>>>
>>>> sessionManager: *"org.wso2.carbon.uuf.api.auth.InMemorySessionManager"*
>>>>
>>>> *...*
>>>>
>>>> *WDYT?*
>>>>
>>>>
>>>> Best Regards,
>>>>
>>>> *Vidura Nanayakkara*
>>>> Software Engineer
>>>>
>>>> Email : vidu...@wso2.com
>>>> Mobile : +94 (0) 717 919277 <+94%2071%20791%209277>
>>>> Web : http://wso2.com
>>>> Blog : https://medium.com/@viduran <http://wso2.com/>
>>>> LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara
>>>> <http://wso2.com/>
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Shazni Nazeer
>>>
>>> Mob : +94 37331
>>> LinkedIn : http://lk.linkedin.com/in/shazninazeer
>>> Blog : http://shazninazeer.blogspot.com
>>>
>>> <http://wso2.com/signature>
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> *Imesh Gunaratne*
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [UUF] Extensible Session Management for UUF

[Dilan Udara Ariyaratne]

Hi Sajith,

My apologies. Did not see the fact that SessionManager is already extending
SessionHandler,
so with your explanation on their difference, it seems fine to me.

Thanks,
Dilan.



*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Tue, May 2, 2017 at 12:18 PM, SajithAR Ariyarathna 
wrote:

> Hi Dilan,
>
> The purpose of the SessionHandler and SessionManager is different.
>
> SessionManager is an extension point (a plugin for UUF) for webapp
> developers. SessionHandler is meant to be passed for other plugins (e.g.
> Authenticator) as a way do session related operations (e.g. create a new
> session when login). If we pass the SessionManager instead, it will over
> expose the session management operations (e.g. close() method). So to
> encapsulate properly we decided to go with two interfaces, SessionHandler
> and SessionManager.
>
> Thanks.
>
> On Tue, May 2, 2017 at 11:49 AM, Dilan Udara Ariyaratne 
> wrote:
>
>> Hi Imesh and @Vidura,
>>
>> I wonder if both SessionHandler and SessionManager interfaces could be
>> merged together to have one interface
>> that could derive all management level functionalities of a session ?
>>
>> I think that current SessionManager, i.e. 
>> org.wso2.carbon.uuf.spi.auth.SessionManager
>> is bit meaningless without capabilities like
>> createSession(), getSession() and destroySession() that
>> org.wso2.carbon.uuf.api.auth.SessionHandler provides.
>>
>> WDYT?
>>
>> Thanks,
>> Dilan.
>>
>> *Dilan U. Ariyaratne*
>> Senior Software Engineer
>> WSO2 Inc. <http://wso2.com/>
>> Mobile: +94766405580 <%2B94766405580>
>> lean . enterprise . middleware
>>
>>
>> On Tue, May 2, 2017 at 11:02 AM, Imesh Gunaratne  wrote:
>>
>>> On Tue, May 2, 2017 at 10:44 AM, Dilan Udara Ariyaratne >> > wrote:
>>>
>>>>
>>>> In the meantime, could you elaborate on the method level details of the
>>>> Session manager interface, too?
>>>>
>>>
>>> ​SessionManager:​
>>> ​https://github.com/wso2/carbon-uuf/pull/241/files#diff-50f8
>>> 2419222617b7f14b6d08d45984ac
>>>
>>> SessionHandler:
>>> https://github.com/wso2/carbon-uuf/pull/241/files#diff-39f1b
>>> 4c291c422e721e8c56d191c75e3​
>>>
>>> Thanks
>>>
>>>>
>>>> Cheers,
>>>> Dilan.
>>>>
>>>> *Dilan U. Ariyaratne*
>>>> Senior Software Engineer
>>>> WSO2 Inc. <http://wso2.com/>
>>>> Mobile: +94766405580 <%2B94766405580>
>>>> lean . enterprise . middleware
>>>>
>>>>
>>>> On Mon, May 1, 2017 at 10:39 PM, Shazni Nazeer  wrote:
>>>>
>>>>> It is beneficial to have this in the UUF.
>>>>>
>>>>> Many frameworks (in particular web frameworks such as Django, CakePHP
>>>>> and Ruby on Rails) support this kind of pluggable Session Management
>>>>> capabilities.
>>>>>
>>>>> On Fri, Apr 28, 2017 at 3:46 PM, Vidura Nanayakkara 
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> We are in the process of introducing extensible session management
>>>>>> mechanism for Carbon UUF.
>>>>>>
>>>>>> Previously in Carbon UUF, the session management was not extensible
>>>>>> and was tightly coupled to the Carbon UUF framework. The purpose of
>>>>>> introducing an extensible session management mechanism is to give the
>>>>>> ability for the web app developers to plug in any session management
>>>>>> implementation of choice. For instance, this can be a JDBC persistent
>>>>>> session management or a token based session management implementation.
>>>>>>
>>>>>> In order to plug in a custom session manager, one need to implement
>>>>>> the given `SessionManager` interface. That implementation needs to be
>>>>>> specified in the `app.yaml` configuration of the particular UUF app.
>>>>>>
>>>>>> Example app.yaml configuration:
>>>>>>
>>>>>> *...*
>>>>>>
>>>>>> # Session manager for this app
>>>>>>
>>>>>> sessionManager: *"org.wso2.carbon.uuf.api.auth.InMemorySessionManager"*
>>

[Architecture] [Kubernetes] Improving Kubernetes Deployment Support for WSO2 Products

[Dilan Udara Ariyaratne]

Hi All,

I am currently working on $subject. Initial idea is to deliver a fully
automated, stable Kubernetes deployment experience for the end users of
both WSO2 EI and APIM products
such that during the process, we can understand how we can improve
Kubernetes-common, the base Kubernetes deployment enabling layer as its
platform.

Earlier with our old product strategy, we did maintain a repository called,
kubernetes-artifacts  where
all the product specific artifacts were also kept.

Now, we have split this out in to two levels, namely
[1] kubernetes-common  - base
Kubernetes deployment enabling layer
[2] kubernetes-, i.e. for example, kubernetes-ei - Product
specific kubernetes artifacts that integrates with kubernetes-common

However, with our new product strategy and architectural changes, most of
the product-specific kubernetes artifacts are not yet done and WSO2 EI,
WSO2 APIM are two such products.

While there is an on-going effort by Isuru (Isuruh) on finalizing
kubernetes-apim related deployment artifacts, I will be working on
kubernetes-ei related artifacts
as an effort to improve Kubernetes Deployment Support for WSO2 Products.

As mentioned above, during this process, we will be also accessing ways of
improving Kubernetes-common layer for a much-developer friendly framework
in building
more customer centric production ready kubernetes deployment artifacts with
very minimum effort.

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Kubernetes] Improving Kubernetes Deployment Support for WSO2 Products

[Dilan Udara Ariyaratne]

Hi Isuru and Imesh,

On Thu, Jul 20, 2017 at 7:20 PM, Imesh Gunaratne  wrote:

>
>
> On Thu, Jul 20, 2017 at 6:06 AM, Isuru Haththotuwa 
> wrote:
>
>> [ += Architecture ]
>>
>> On Thu, Jul 20, 2017 at 2:57 PM, Isuru Haththotuwa 
>> wrote:
>>
>>> Hi Dilan,
>>>
>>> Apologies for the delayed response.
>>>
>>> A couple of changes that I can think of:
>>>
>>>- Rather than using Puppet to build the Docker images, use a simple
>>>copy based approach.
>>>   - IMHO using puppet to build docker images is an overkill. We can
>>>   have one product base images, and build the images relevant to product
>>>   specific deployment patterns extending from the base image.
>>>
>>>
> ​+1 Isuru! We also had an offline discussion on this with Lakmal. Better
> to make usage of Puppet optional for K8S based deployments.
>

I am also +1 to the idea that we should totally decouple Puppet from Docker
as well as K8s and treat each of these separately as they cater different
layers of the deployment spectrum.

When it comes to a "deployment pattern", each product pack participating in
that deployment pattern, has some specific configuration to use.

Configuration can also differ depending on the fact that deployment is
hosted in a container-based environment or not.

We can support automating both these environments either by using
[1] a simple copy based approach, [2] puppet or any other configuration /
artifact update mechanism that we may bring in future.

IMO, we can keep this layer totally decoupled from either the Docker or
Kubernetes layers and what we can expect as the output, would be a fully
configured product pack to cater a specific deployment pattern.

Once the pack is there, we can use it directly at the docker layer to build
an image as the output and that image will then be an input to the K8s
layer to host the specific deployment pattern for which it was built.

WDYT?

Thanks,
Dilan.


> Thanks
> Imesh​
>
>>
>>>-
>>>- Without using an intermediate set of scripts do build docker
>>>images (currently we have our own docker build, run scripts), let the 
>>> user
>>>directly use Docker API for building images, running them, etc.
>>>   - For a Docker user its more natural to use the Docker API.
>>>   Additionally, there would be no need to maintain our own build 
>>> scripts.
>>>
>>> Please share your thoughts.
>>> I have started this effort for APIM the new deployment patterns
>>> discussed in thread [1] in APIM group, and the WIP artifacts can be found
>>> at [2] and [3]. Note that these artifacts are not finalized.
>>>
>>> [1]. API-M perf results to share with a customer
>>> [2]. https://github.com/isurulucky/docker-apim/tree/new-deploymen
>>> t-patterns
>>> [3]. https://github.com/isurulucky/kubernetes-apim/tree/new-deplo
>>> yment-patterns
>>>
>>> On Thu, Jul 13, 2017 at 7:56 PM, Dilan Udara Ariyaratne >> > wrote:
>>>
>>>>
>>>> -- Forwarded message --
>>>> From: Dilan Udara Ariyaratne 
>>>> Date: Thu, Jul 13, 2017 at 7:48 PM
>>>> Subject: [Architecture] [Kubernetes] Improving Kubernetes Deployment
>>>> Support for WSO2 Products
>>>> To: architecture 
>>>>
>>>>
>>>> Hi All,
>>>>
>>>> I am currently working on $subject. Initial idea is to deliver a fully
>>>> automated, stable Kubernetes deployment experience for the end users of
>>>> both WSO2 EI and APIM products
>>>> such that during the process, we can understand how we can improve
>>>> Kubernetes-common, the base Kubernetes deployment enabling layer as its
>>>> platform.
>>>>
>>>> Earlier with our old product strategy, we did maintain a repository
>>>> called, kubernetes-artifacts
>>>> <https://github.com/wso2/kubernetes-artifacts> where all the product
>>>> specific artifacts were also kept.
>>>>
>>>> Now, we have split this out in to two levels, namely
>>>> [1] kubernetes-common <https://github.com/wso2/kubernetes-common> -
>>>> base Kubernetes deployment enabling layer
>>>> [2] kubernetes-, i.e. for example, kubernetes-ei -
>>>> Product specific kubernetes artifacts that integrates with 
>>>> kubernetes-common
>>>>
>>>> However, with our new product strategy and architectural changes, most
>>>> of the product-s

Re: [Architecture] [Kubernetes] Improving Kubernetes Deployment Support for WSO2 Products

[Dilan Udara Ariyaratne]

Hi All,

With respect to "container-based" deployment patterns related to EI,
following were identified as the first set to be supported and are
currently under development.

Pattern 1:  Standalone Integrator Profile with external DB,
   Scalable, But Minimum High Availability Cluster for
Integrator Profile with external DB

Pattern 2:  Standalone MB Profile with external DB,
   Scalable, But Minimum High Availability Cluster for MB
Profile with external DB

Pattern 3:  Standalone BPS Profile with external DB,
   Scalable, But Minimum High Availability Cluster for BPS
Profile with external DB

Pattern 4:  Standalone [ Integrator Profile + EI Analytics Profile ] with
external DB,
   Scalable, But Minimum [ High Availability Cluster for
Integrator Profile + High Availability Cluster for EI Analytics Profile ]
with external DB

Pattern 5:  Standalone [ Integrator Profile + MB Profile ] with external
DB,
   Scalable, But Minimum [ High Availability Cluster for
Integrator Profile + High Availability Cluster for MB Profile ] with
external DB

Pattern 6:  Standalone [ Integrator Profile + EI Analytics Profile + MB
Profile ] with external DB,
   Scalable, But Minimum [ High Availability Cluster for
Integrator Profile + High Availability Cluster for MB Profile + High
Availability Cluster for MB Profile ] with external DB

Please add and correct, if I have missed any.

Thanks,
Dilan.


*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Mon, Jul 24, 2017 at 8:46 AM, Dilan Udara Ariyaratne 
wrote:

>
> Hi Isuru and Imesh,
>
> On Thu, Jul 20, 2017 at 7:20 PM, Imesh Gunaratne  wrote:
>
>>
>>
>> On Thu, Jul 20, 2017 at 6:06 AM, Isuru Haththotuwa 
>> wrote:
>>
>>> [ += Architecture ]
>>>
>>> On Thu, Jul 20, 2017 at 2:57 PM, Isuru Haththotuwa 
>>> wrote:
>>>
>>>> Hi Dilan,
>>>>
>>>> Apologies for the delayed response.
>>>>
>>>> A couple of changes that I can think of:
>>>>
>>>>- Rather than using Puppet to build the Docker images, use a simple
>>>>copy based approach.
>>>>   - IMHO using puppet to build docker images is an overkill. We
>>>>   can have one product base images, and build the images relevant to 
>>>> product
>>>>   specific deployment patterns extending from the base image.
>>>>
>>>>
>> ​+1 Isuru! We also had an offline discussion on this with Lakmal. Better
>> to make usage of Puppet optional for K8S based deployments.
>>
>
> I am also +1 to the idea that we should totally decouple Puppet from
> Docker as well as K8s and treat each of these separately as they cater
> different layers of the deployment spectrum.
>
> When it comes to a "deployment pattern", each product pack participating
> in that deployment pattern, has some specific configuration to use.
>
> Configuration can also differ depending on the fact that deployment is
> hosted in a container-based environment or not.
>
> We can support automating both these environments either by using
> [1] a simple copy based approach, [2] puppet or any other configuration /
> artifact update mechanism that we may bring in future.
>
> IMO, we can keep this layer totally decoupled from either the Docker or
> Kubernetes layers and what we can expect as the output, would be a fully
> configured product pack to cater a specific deployment pattern.
>
> Once the pack is there, we can use it directly at the docker layer to
> build an image as the output and that image will then be an input to the
> K8s layer to host the specific deployment pattern for which it was built.
>
> WDYT?
>
> Thanks,
> Dilan.
>
>
>> Thanks
>> Imesh​
>>
>>>
>>>>-
>>>>- Without using an intermediate set of scripts do build docker
>>>>images (currently we have our own docker build, run scripts), let the 
>>>> user
>>>>directly use Docker API for building images, running them, etc.
>>>>   - For a Docker user its more natural to use the Docker API.
>>>>   Additionally, there would be no need to maintain our own build 
>>>> scripts.
>>>>
>>>> Please share your thoughts.
>>>> I have started this effort for APIM the new deployment patterns
>>>> discussed in thread [1] in APIM group, and the WIP artifacts can be found
>>>> at [2] and [3]. Note that these artifacts are not finalized.
>&

Re: [Architecture] [APIM][C5] Service Discovery at API publisher

[Dilan Udara Ariyaratne]

Hi Koshalya,

Can you explain how the authentication and authorization happens in between
the fabric8 kubernetes-client and any remote kubernetes cluster API Server
that we are hoping to connect ?

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Thu, Jul 27, 2017 at 5:52 PM, Subhashinie Koshalya 
wrote:

> Hi all,
>
> Currently at API publisher, the creator manually enters the backend
> service URI as the endpoint. In addition to the current capability, the
> idea is to let API Manager 3.0.0 support a "global endpoint" field which
> appears in the API Create UI, and be used for an external service discovery
> process to list out the available backend service endpoints within the
> tenant's scope.
>
> With the expectation of expanding the feature to multiple other platforms,
> initial plan is to make this work with Kubernetes.
>
> [image: ServiceD.jpeg]
>
> *As for Kubernetes the criteria would be labels.
>
> [image: servDisc.png]
>
>
>
> After discovery details listed in the UI will be,
>
>-
>
>service name
>-
>
>   (eg: "external-example-service")
>   -
>
>protocol + external IP with port or external name
>-
>
>   (eg: http://146.148.47.155:3306 or https://example.domain.name)
>
>
> For a service endpoint to be discovered by the Publisher,
>
>-
>
>mainly it must have an external IP or external name
>-
>
>can be any of the "types" : ExternalName, LoadBalancer or NodePort
>
>
> Filtering will be possible according to,
>
>-
>
>Namespace
>-
>
>Labels
>
>
> We are hoping to use fabric8 in order to speak to the external Kubernetes
> cluster.
>
> We would like to have your feedback and suggestions in this regard.
>
> Links
>
> Kubernetes Services :
>
> https://kubernetes.io/docs/concepts/services-networking/service/
>
> Thanks and regards,
>
> Subhashinie Koshalya
> Intern | Software Engineering
> WSO2, Inc. : http://wso2.com
>
> Email : subhashi...@wso2.com
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Kubernetes] Improving Kubernetes Deployment Support for WSO2 Products

[Dilan Udara Ariyaratne]

Hi All,

Following up recent discussions that I had with Imesh, Isuru and Indika on
the improvements that we can make
on our container based deployment space, I will be first doing a PoC (Proof
of Concept) on
a little bit, re-structured deployment artifact management hierarchy as
follows.



​
​
Above diagram splits our deployment space into three layers, namely :

[1] Configuration Management Space ( Container-based / Non-container-based
) :
 For a particular product, this layer would support configuring "N"
number of deployment patterns for both container and non-container-based
environments.

 As of now, we are mostly dependent on puppet for building
configurations / distributions for a specific deployment pattern of a
product. But here, in an important note: I am bringing in
 a separate repository as being discussed at [1] to keep directly
deployable configurations + supporting artifacts for each deployment
pattern. We can use this repository, i.e.
 for example [2] as the default entry-point for configuring a
deployment, so that the existing usage of puppet for doing the same becomes
optional.

 Configurations maintained in this repository would either be a direct
input for the container image management space in building product images
or be an input for building product
 distributions that will then be used at the container image management
space for building the images.

[2] Container Image Management Space :
 This layer would support the same "N" number of deployment patterns,
referenced above for container-based environments.

 It would take in configurations or product distributions, specific to
a particular deployment pattern from configuration management space as
input and produce production ready container images
 to be utilized by container-based deployment management space, as
output.

 Docker (Using Dockerfile) is our current implementation of this space,
but in future, we may also have to bring in other technologies ( such as
Rocket ) too in to this space depending on the need.

 As an important note: Currently we are keeping docker-compose related
artifacts too with in this space [3]. But my personal preference would be
to keep it separate and decoupled from the
 docker image management layer, as a separate repository (as positioned
in the above diagram), so that those artifacts would only be downloaded
 by customers who are really in need of them. Please share your
thoughts on this.

[3] Container-based Deployment Management Space :
 This layer would also support the same "N" number of deployment
patterns, referenced above for container-based environments.

 It would take in a set of container images, specific to a particular
deployment pattern from container image management space, as input and
produce a container-based deployment
 as output. Docker-compose, kubernetes and OpenShift are our current
implementations of this space.

 As an important note: Currently, If we refer to the recent
kubernetes-apim 2.1.0 [4] effort, we are keeping all these technologies,
combined and coupled into one repository. But my personal reference would
be to
 keep them separate and decoupled from each other in separate
repositories as visualized in the above diagram, so that we can direct our
customers to the exact technology that they prefer and those
 artifacts would only be downloaded by those who are really in need of
them. Please share your thoughts on this.

A work-in-progress effort, adhering to the above re-structure can be found
at [5] for kubernetes-ei with related configuration artifacts at conf-ei
[6].
To build the required images, currently I am using the existing approach of
docker-ei dockerfiles with default provisioning.

Your feedback is deeply appreciated.

References :
- - - - - - - - - - -
[1] [Strategy] Proposal to create Configuration Repositories for all
products
[2] conf-ei repository: https://github.com/DilanUA/conf-ei/,
wso2-apim-conf: https://github.com/imesh/wso2-apim-conf
[3] docker-ei repository: https://github.com/wso2/docker-ei, docker-apim:
https://github.com/wso2/docker-apim
[4] kubernetes-apim: https://github.com/wso2/kubernetes-apim/tree/2.1.0
[5] kubernetes-ei effort:
https://github.com/DilanUA/kubernetes-ei/tree/master/pattern-2/wso2ei-integrator-ha-analytics-stdln
[6] conf-ei effort:
https://github.com/DilanUA/conf-ei/tree/master/pattern-2/wso2ei-integrator-ha-analytics-stdln
[7] docker-ei dockerfile:
https://github.com/wso2/docker-ei/tree/master/dockerfile

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Wed, Jul 26, 2017 at 8:57 AM, Dilan Udara Ariyaratne 
wrote:

> Hi All,
>
> With respect to "container-based" deployment patterns related to EI,
> following were identified as the first set to be supported a

Re: [Architecture] Same feature with different versions in different runtimes

[Dilan Udara Ariyaratne]

Hi Kasun and All,

Let me raise a different, but fundamental concern to this issue. Please
correct me if I am wrong.

It's perfectly valid to have the same feature on different run-times (or
profiles) of a product, but if that same feature appears in "different
versions",
meaning, with slight or major differences of their implementations, at
different run-times of the product, wouldn't that open up any possibilities
of functional inconsistencies or even failures to the overall system ?

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Thu, Aug 17, 2017 at 8:19 PM, Kasun Siyambalapitiya 
wrote:

> Hi Niranjan,
>
> When generating the p2-repository using `carbon-maven-plugin version 3.x`
> this issue arises due to the fact that it resolves dependencies for each
> given feature with the dependencies we defined in the pom itself (note that
> the effective pom is used for the resolving). Since maven picks only one
> version of a given dependency due the use of `nearest in the dependency
> tree` strategy, a p2-repo with multiple versions of the same feature can
> not be created by using the current `carbon-maven-plugin version 3.1.3`.
>
> But in the case of `carbon-maven-plugin version 1.5.x` this is possible as
> the dependencies of each feature is defined in a string form as below
>
> org.apache.axis2.transport:org.apache.axis2.transport.jms.feature:${axis2-
>> transports.wso2.version.1.1.0.wso2v17}
>
>
> and the version `${axis2-transports.wso2.version.1.1.0.wso2v17}` is
> replaced with the value of the relevant property we defined in the pom.xml.
> Since there are no restrictions like above in defining properties in
> pom.xml this works.
>
> Thanks.
>
> On Thu, Aug 17, 2017 at 10:39 AM, Niranjan Karunanandham <
> niran...@wso2.com> wrote:
>
>> Hi Kasun,
>>
>> On Thu, Aug 17, 2017 at 10:04 AM, Kasun Siyambalapitiya > > wrote:
>>
>>> Hi Niranjan,
>>>
>>> The build fails before successful generation of the p2-repo by giving
>>> the following error
>>>
>>> [ERROR] Failed to execute goal org.wso2.carbon.maven:carbon-f
 eature-plugin:3.1.1:generate-repo (p2-repo-generation) on project
 wso2carbon-kernel: Feature org.wso2.carbon.pax.exam.feature_5.2.0.1
 not found -> [Help 1]
>>>
>>>
>>>
>>> Since in the new C5 model the p2-repo containing all the features
>>> required for all the runtimes of the product, is generated at a single
>>> specified directory(by default the target directory) multiple version of
>>> the same feature cannot be generated as maven build will pick only one
>>> version of the dependency due to the use of "nearest in the dependency
>>> tree" strategy as shown in above mail. As a result although we can have
>>> multiple versions at the p2-repo per feature due to the above nature of
>>> maven, runtimes with different feature versions cannot be created in C5.
>>> This problem was not there in the previous C4 model as the profiles(runtime
>>> in C5 wording) were generated at separate locations and their respective
>>> p2-repos were created at their own locations(where the profile is created)
>>> [1]
>>>
>>> IMO this issue can be avoided by always using the newest feature version
>>> available when creating runtimes in C5 products. WDYT?
>>>
>> The profiles that were used in C4 were used to install features, but only
>> one p2-repo is created. In the case of EI, they have created separate
>> modules (folders for each profile) and then they are handling it. In the
>> case of AS 5.3.0, we had a single pom to create a distribution with
>> multiple profiles. Wilkes p2-repo is generated using the
>> carbon-feature-repository [1], here in the pom, the p2-repo is generated
>> with different versions of the same feature. Similarly for C5, it should
>> follow the same. We need to look into the carbon-maven-plugins version
>> 1.5.x [2] and 3.x [3].
>>
>>
>>>
>>> [1] https://github.com/wso2/product-ei/tree/v6.2.0-m2/p2-profile
>>>
>>> On Wed, Aug 16, 2017 at 3:51 PM, Niranjan Karunanandham <
>>> niran...@wso2.com> wrote:
>>>
 Hi Kasun,

 On Wed, Aug 16, 2017 at 3:30 PM, Kasun Siyambalapitiya <
 kasu...@wso2.com> wrote:

> Hi all,
>
> When I was creating a custom product using carbon-kernel version
> 5.2.0-alpha[1] the following issue aroused.
> In a scenario where a product is build with 2 runtimes called runtimeA
> and runtimeB.
>
> runtimeA contains the below feature among it's other features
>
> pax.exam.feature v5.2.0.0
> sample-bundle2 v5.2.0.0
> log-bundle v1.5.0
>
>
> while runtmeB contains the below feature among it's other features
>
> sample.feature v5.2.0.1
> sample-bundle1 v5.2.0.0
> monitor-bundle v1.5.0
> pax.exam.feature v5.2.0.1
>
>
>
> As shown above since there is a dependency to the
> `pax.exam.feature,v5.2.0.1` from the `sample.feature,v5.2.0.1`,

Re: [Architecture] [C5] Collect config-docs in all featues when packaging product distribution

[Dilan Udara Ariyaratne]

Hi Danesh,

With recent discussions on C5 configuration management, If I understood
correctly, deployment.yaml would not be the only option for a user to
manage configurations, but there will also
be options to directly manipulate configurations via environment variables
and system properties.

Shouldn't we be documenting those options as well ?

For example, if our objective is to change port offset,
[1] If we are going with environment variable approach, Which environment
variable we should use ?
[2] If we are going with system property approach, Which system property we
should use ?
[3] If we are going with deployment.yaml approach, Which key we should use ?

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Thu, Aug 31, 2017 at 1:17 PM, Chamila De Alwis  wrote:

> Hi Danesh,
>
> Thanks for bringing this up! This is a huge improvement and IMO we should
> include the reference YAML file in the product distribution for user
> reference purposes. It's true that hosted documentation would take care of
> most of that story, but there can be situations where the user only has a
> terminal and the product zip file, where a reference text file would come
> in handy.
>
> Just a minor query, what is the purpose of the generated secure-vault.yaml
> file?
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Senior Software Engineer | WSO2
> Blog: https://medium.com/@chamilad
>
>
>
> On Thu, Aug 31, 2017 at 11:37 AM, Danesh Kuruppu  wrote:
>
>> Hi all,
>>
>> With new global configuration model discussed in mail thread[1], we are
>> generating configuration files(for documentation purposes) automatically at
>> compile time by reading annotations and default values in config bean
>> classes. And those configuration files are packed in features under
>> config-docs directory like below(e.g).
>>
>> ├── features
>>> └── org.wso2.carbon.kernel_5.2.0.SNAPSHOT
>>> *   ├── config-docs*
>>> *   └── wso2.carbon.yaml*
>>> └── plugins
>>> └── org.wso2.carbon.core-5.2.0.SNAPSHOT.jar
>>>
>>
>>
>> Since those configuration files are only for documentation purposes, We
>> are not shipping them with product distribution. Currently those
>> configuration files are inside feature jar files and in order to read
>> relevant configuration file, we need to extract the jar file.
>>
>> In order solve this issue, we thought of collecting configuration docs in
>> all features when packaging product distribution using maven plugin. Maven
>> plugin will go through all features inside p2-repo
>> directory(distribution/target/p2-repo/features directory) and copy
>> configuration docs in each feature to one location like below
>> (distribution/target/config-docs)
>>
>> ├── distribution
>>  ├── target
>>
>>
>> * ├── config-docs ├── secure-vault.yaml
>>└── wso2.carbon.yaml*
>>  └── wso2carbon-kernel-5.2.0-SNAPSHOT.zip
>>
>> So when generating product distribution, we automatically get all
>> configuration files used in the product. This will also help when creating
>> product document.
>>
>> Appreciate your input on this.
>>
>> 1. http://wso2-oxygen-tank.10903.n7.nabble.com/Carbon-C5-Server
>> -Configuration-Model-td144549.html
>>
>> Thanks
>> --
>>
>> *Danesh Kuruppu*
>> Senior Software Engineer | WSO2
>>
>> Email: dan...@wso2.com
>> Mobile: +94 (77) 1690552 <+94%2077%20169%200552>
>> Web: WSO2 Inc 
>>
>>
>> ___
>> 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
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Using Kubernetes ConfigMaps for Managing Product Configurations

[Dilan Udara Ariyaratne]

Hi Folks,

As I have experienced so far, using configmaps [1] to do configuration
management of a particular deployment profile is much handy and effective
than
the effort we need to put in doing the same using building per-profile
docker images.

When ever we require a configuration update to be done for a particular
deployment profile, we can easily change the configuration of the specific
file and initiate
a rolling update [2] for that particular deployment as follows. For
example, in the case of wso2/kubernetes-ei [3]

kubectl rolling-update wso2ei-pattern1-integrator-deployment -f
new-integrator-deployment.yaml

No further burden of the need to build docker images again and again
per each change and push them to cluster for a simple configuration
change.

[1] https://kubernetes.io/docs/tasks/configure-pod-container/configmap
[2] 
https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller
[3] https://github.com/wso2/kubernetes-ei

Cheers,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Thu, Sep 7, 2017 at 10:57 AM, Pubudu Gunatilaka  wrote:

> Hi Imesh,
>
> On Thu, Sep 7, 2017 at 10:44 AM, Imesh Gunaratne  wrote:
>
>> Hi Pubudu,
>>
>> On Thu, Sep 7, 2017 at 12:54 AM, Pubudu Gunatilaka 
>> wrote:
>>
>>>
>>> On Wed, Sep 6, 2017 at 11:06 PM, Imesh Gunaratne  wrote:
>>>

 ​Do we really need to parameterize these? Wouldn't it be better to add
 all required folders?​ May be what we need is the bin, conf and deployment
 folders (including sub folders)?

 Without mentioning all the configuration files in the dockerfile[1], we
>>> can copy all the content of wso2ei-integrator-conf to wso2ei product
>>> folder. In this way, users can dynamically add any configuration file
>>> without changing the base docker image.They only need to add a configmap
>>> and mount that to the wso2ei-integrator-conf folder.
>>>
>>
>> Are you suggesting to use a single configmap and mount that to a single
>> conf folder in the pod and then copy file by file to relevant folders?
>>
>>
> As config maps does not support nested folders we have to use multiple
> config maps. Rather than hard coding the folder names in the dockerfile
> [1], using a script we can copy all the files within wso2ei-integrator-conf
> to wso2ei product folder. As I mentioned before, users will be able to add
> any configuration file which resides within the product folder without
> adding that in the dockerfile.
>
> [1] - https://github.com/wso2/kubernetes-ei/blob/master/dockerfi
> les/integrator/Dockerfile#L25
>
> Thank you!
> --
> *Pubudu Gunatilaka*
> Committer and PMC Member - Apache Stratos
> Senior Software Engineer
> WSO2, Inc.: http://wso2.com
> mobile : +94774078049 <%2B94772207163>
>
>
> ___
> 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] Webapp server for React based webapps

[Dilan Udara Ariyaratne]

Hi Sajith,

With respect to the Structure of the web-app, My concern is actually on the
public folder because I do not think that only the stuff that lie under
public folder would be public, please correct
me If I am wrong. IMO, I believe that everything else here is also public
since this doesn't carry any server-side rendering code.

So, may be we need to reconsider restructuring stuff that currently lie
within the public folder. For example, moving everything with in the public
folder into pages, WDYT?

And, also would you explain the purpose of those extensions/device-types
content ?

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Tue, Sep 12, 2017 at 10:59 AM, Joseph Fonseka  wrote:

> Hi Sajith
>
> +1 For the server, would like to propose adding gzip support as well.
>
> Does the web-server enforce the web-app structure ? If so IMHO it would be
> best not to do that.
>
> Thanks & Regards
> Jo
>
>
>
>
>
>
> On Tue, Sep 12, 2017 at 10:13 AM, Chanaka Jayasena 
> wrote:
>
>> Hi Sajith,
>>
>> +1 for the web server. We will be able to replace the MS4J service inside
>> carbon-apimgt with this one when it's available.
>>
>> Following are some of my suggestions and thoughts.
>>
>> Can we put the public/images/logo.png and public/css/styles.css in the
>> default theme ?
>>
>> I believe the extensions are stand alone js files. In APIM case it will
>> be useful to add a new page to the store app. But we will have to write the
>> react app client side routing to pick the extension as a new route.
>>
>>
>> thanks,
>> Chanaka
>>
>> On Mon, Sep 11, 2017 at 3:35 PM, SajithAR Ariyarathna 
>> wrote:
>>
>>> Hi All,
>>>
>>> We are in the process of developing $subject. Tentatively this webapp
>>> server is named as "Carbon UI Server".
>>>
>>> # Major goals of this webapp server are following:
>>>
>>>- Enforcing security measures.
>>>   - Setting proper cache headers
>>>   - Setting recommended security related HTTP headers
>>>   - Protection against file system navigation through URLs
>>>- Defining a structure for webapps.
>>>   - Requirement is to properly define places to put page(s),
>>>   themes, UI extensions, and internalization language files in the 
>>> webapp.
>>>- Proper routeing for SPA apps.
>>>   - For SPA apps, index.html should be served for any request for a
>>>   page.
>>>
>>> # Proposing directory structure:
>>>
>>> - Webapps will be placed in /wso2//d
>>> eployments/reactapps/
>>>
>>> - Structure of a webapp:
>>>
>>> 
>>> ├── configuration.yaml
>>> │
>>> ├── extensions
>>> │   ├── widgets
>>> │   │   ├── line-chart/
>>> │   │   ├── bar-chart/
>>> │   │   └── calendar/
>>> │   │   ├── bundle.js
>>> │   │   ├── styles.css
>>> │   │   └── widget.json
>>> │   │
>>> │   └── device-types
>>> │   ├── andoid/
>>> │   ├── ios/
>>> │   └── ardino/
>>> │   └── ports.json
>>> ├── i18n
>>> │   ├── fr.properties
>>> │   └── en.properties
>>> │
>>> ├── pages
>>> │   └── index.html
>>> │
>>> ├── public
>>> │   ├── images
>>> │   │   └── logo.png
>>> │   ├── css
>>> │   │   └── styles.css
>>> │   └── js
>>> │   └── bundle.js
>>> │
>>> └── themes
>>> ├── dark/
>>> └── light
>>> ├── js
>>> │   └── some.js
>>> └── css
>>> └── styles.css
>>>
>>>
>>> - configuration.yaml will contain configurations of the web app (e.g.
>>> app context path, custom security headers). These configurations should be
>>> able to add/override through the deployment.yaml file.
>>>
>>> - extensions directory contains UI extensions. There can be multiple
>>> types of extensions and they are categorized accordingly into
>>> sub-directories inside the extensions directory. Each extension should
>>> be wrapped with a directory (the name of the directory will be the name of
>>> the extension), and placed inside the relevant type. Thus, the fully
>>> qualified name of an extension will be : (e.g.
>>> widgets:line-chart)
>>>
>>> - i18n directory will bear the internalization language files.
>>>
>>> - public directory contains any client-side resources of the app.
>>>
>>> - themes directory contains the themes of the app. Each theme should be
>>> put inside a sub-directory.
>>>
>>>
>>> # URL patterns:
>>>
>>>- Pages
>>>   - /path/to/page (e.g.
>>>   https://localhost:9292/pets-store/home
>>>   )
>>>- Resources of the app
>>>   - /public/app/
>>>   (e.g. https://localhost:9292/pets-store/public/app/images/logo.png
>>>   )
>>>   - Resources of an extension
>>>   - 
>>> /public/extensions///
>>>   (e.g. https://localhost:9292/pets-store/public/extensions/widgets/
>>>   calendar/styles.cs

Re: [Architecture] [Deployment] [Puppet] Upgrading WSO2 Puppet Modules to Puppet 5.x from 3.x

[Dilan Udara Ariyaratne]

Hi Imesh,

Yes, We should now be able to do a
[1] - Puppet-common release for puppet 5.
   We can also discontinue vagrant test bed and replace it with
docker-compose master - agent test bed for developers testing our modules.
[2] - Puppet-base release for puppet 5.
[3] - Releases of relevant product puppet modules for puppet 5.
   We can first complete migrating APIM puppet module for puppet 5 and
make it a reference guide for other product modules too.

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Sun, Nov 19, 2017 at 4:17 PM, Imesh Gunaratne  wrote:

>
>
> On Fri, Nov 17, 2017 at 5:59 PM, Dilan Udara Ariyaratne 
> wrote:
>
>>
>> It was possible to fix this remaining issue by accessing the manifest
>> variables in .erb files using the scope['variable'] notation [1] instead of
>> the existing @variable local scope notation [2].
>> With this fix [3], we should now be able to successfully run WSO2 puppet
>> modules on top of puppet 5.x with minimal changes [4] that would be
>> compatible until the next puppet major release 6.0.
>>
>> ​Great work Dilan!
> As we discussed offline may be we can now move these changes to WSO2
> Puppet repositories, including the Puppet Docker Compose script in the
> puppet-common repository and replace existing Vagrant script with that.
>
> Thanks
> Imesh
> ​
>
>> [1] - https://puppet.com/docs/puppet/5.3/lang_template_erb.html#sc
>> opevariable-or-scopelookupvarvariable
>> [2] - https://puppet.com/docs/puppet/5.3/lang_template_erb.html#variable
>> [3] - https://github.com/DilanUA/wso2-puppet-modules-5x-upgrade/co
>> mmit/a9b27970d2501d2ceb5cb424a11aa9f6a15966a3
>> [4] - https://github.com/DilanUA/wso2-puppet-modules-5x-upgrade
>>
>> Thanks,
>> Dilan.
>>
>>
>
>
> --
> *Imesh Gunaratne*
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Customizing React based web apps with Carbon UI Server

[Dilan Udara Ariyaratne]

Hi Sajith,

+1 for the effort. Few clarifications, BTW...

[1] Since the purpose of /deployment folder is solely any
customizations, in a developer experience POV, wouldn't it be good to
change the name of the folder to something like "custom-deployment"
 rather than using the same naming convention used to original
deployment folder which might bring any confusions ?
[2] Would there be any chance to have the same web-app inside multiple
run-times ? If that is the case and what if a customer would only need to
customize the web-app of one particular runtime ?

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Wed, Nov 22, 2017 at 12:07 PM, SajithAR Ariyarathna 
wrote:

> Hi All,
>
> We are in the process of implementing the option for customers to
> customize (by overriding or adding new things) React based web apps.
>
> *Overriding:*
>
> Customer can override a file of a web app by putting the custom version of
> that file in the same relative path inside the
> /deployment/web-ui-apps/ directory.
>
> e.g. Consider following web app "pets store" shipped in
> /wso2//deployment/web-ui-apps/pets-store directory.
>
> pets-store
> ├── configuration.yaml
> │
> ├── extensions
> │   ├── widgets
> │   ├── line-chart/
> │   ├── bar-chart/
> │   └── calendar/
> │   ├── bundle.js
> │   ├── styles.css
> │   └── widget.json
> │
> ├── i18n
> │   └── en.json
> │
> ├── pages
> │   └── index.html
> │
> ├── public
> │   ├── images
> │   │   └── logo.png
> │   ├── css
> │   │   └── styles.css
> │   └── js
> │   └── bundle.js
> │
> └── themes
> ├── dark/
> └── light
> ├── js
> │   └── some.js
> └── css
> └── styles.css
>
> # In order to change CSS styles of the "calendar" widget, customer needs
> to put their "styles.css" file in /deployment/web-
> ui-apps/pets-store/extensions/widgets/calendar/styles.css path.
>
> # To change the logo, custom logo image needs to be put in
> /deployment/web-ui-apps/pets-store/public/images/logo.png
> path.
>
> # App's configurations can be overridden by putting a custom
> configuration.yaml file into /deployment/
> web-ui-apps/pets-store/ directory.
>
>
> With above overrides, the  /deployment/
> web-ui-apps/pets-store/ directory looks like following.
>
>
> pets-store
>
> ├── configuration.yaml
>
> │
>
> ├── extensions
>
> │   └── widgets
>
> │   └── calendar
>
> │   └── styles.css
>
> │
>
> └── public
>
> └── images
>
> └── logo.png
>
>
> *Adding:*
>
> Customer can add a new entity (extensions, language files (i18n), themes)
> by putting it to  
> /deployment/web-ui-apps///
> path.
>
> e.g. Consider the same "pets store" web app.
>
> # Customer can add a new widget "pie-chart" by putting it to
> /deployment/web-ui-apps/pets-store/
> extensions/widgets/pie-chart location.
>
> # A new language file can be added by putting it to
> /deployment/web-ui-apps/pets-store/i18n/fr.json .
>
> # New "autum" theme can be added by putting it to
> /deployment/web-ui-apps/pets-store/themes/ directory.
>
>
> With above additions, the  /deployment/web-ui-apps/pets-
> store/ directory looks like following.
>
> pets-store
> │
> ├── extensions
> │   └── widgets
> │   └── pie-chart/
> │   ├── bundle.js
> │   ├── styles.css
> │   └── widget.json
> │
> ├── i18n
> │   └── fr.json
> │
> └── themes
>
> └── autum
>
> ├── js
> │   └── some.js
> └── css
> └── styles.css
>
>
>
> Carbon UI Server will do the app artifact merging (
> /wso2//deployment/web-ui-apps/pets-store/ and
> /deployment/web-ui-apps/pets-store/) at server start-up.
>
>- When serving files, priority is always given to the customers
>version.
>- Customer can revert their customizations by deleting their app
>artifact /deployment/web-ui-apps/ . When this
>happens, the "merged" web app will be undeployed and the "default version"
>(shipped by WSO2 in /wso2//
>deployment/web-ui-apps/) will be redeployed.
>
>
> Your feedback is highly appreciated.
> Thanks.
> --
> Sajith Janaprasad Ariyarathna
> Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
> 
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dockerfiles] Simplified Approach for wso2/dockerfiles

[Dilan Udara Ariyaratne]

Hi Folks,

IMO, docker image size is not a major issue nowadays unless you are
extremely worrying about the image pull time and docker registry disk space
of your deployment.
What matters most here is the amount of ease of docker image build and
customization experience that we are hoping to provide to our customers and
giving priority to that aspect, I am +1 with what Chamila is suggesting
here.

We have already adapted this approach when defining dockerfiles, specific
for K8s/OpenShift deployments and
at the moment, we are in need of adopting the same for purely docker based
container deployments of our products.

Namely, Dockerfiles for :
[1] - Docker compose
[2] - Docker Swarm

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Thu, Nov 23, 2017 at 7:02 PM, Muhammed Shariq  wrote:

> Hi Chamila,
>
> Yes, we would need to make our Docker (and any other) artifacts follow the
> industry accepted standards so that it is easy for users to adopt them.
> More complexity means user probably will be discouraged to use our stuff.
>
> As you mentioned, the --squash option is a good way to reduce the size of
> the resulting images, however do we also need to consider if there are any
> cons in using the --squash approach. According the documentation [1], it
> says;
>
> Note: using this option means the new image will not be able to take
> advantage of layer sharing with other images and may use significantly more
> space.
>
> Note: using this option you may see significantly more space used due to
> storing two copies of the image, one for the build cache with all the cache
> layers in tact, and one for the squashed version.
> It seems with the --squash option, the resulting images could use
> significantly more memory, is this a trade off we are willing to make?
>
> Given that this is an experimental feature, we can hope that this might be
> imrpoved in the future to take advantage of layer sharing as well, however
> better to check on that aspect as well.
>
> [1] - https://docs.docker.com/engine/reference/commandline/build
> /#squash-an-images-layers-squash-experimental-only
>
> On Thu, Nov 9, 2017 at 12:55 PM, Chamila De Alwis 
> wrote:
>
>> Hi,
>>
>> So far, the approach for writing Dockerfiles for WSO2 products has been
>> to write a generic Dockerfile that can be manipulated to build different
>> images with different approaches. For example, to generalize the way in
>> which the product is configured inside the image during build time, a
>> concept called "Provisioning methods" was introduced. This would allow
>> different configuration methods ("default" which is copying a plain old
>> pack into the image, and "puppet" which runs Puppet scripts during the
>> image build) to configure the image.
>>
>> However, the cost of such a generalized approach is the increased
>> complexity of the script layer around the Dockerfile and the necessity of
>> the bootstrap tasks done by the scripts. Because of this,
>>
>> 1. New users have found it hard to quickly start using the Dockerfiles to
>> build the images
>> 2. Users with prior Docker knowledge have struggled to understand the
>> reasoning behind such a thick layer of bootstrapping
>> 3. Customization to existing scripts require a steep learning curve
>> 4. Product teams have found it difficult to commit resources to maintain
>> the scripts+Dockerfiles
>> 5. Dockerfiles cannot be used in pure Docker commands without the complex
>> bootstrapping involved
>>
>> One of the main reasons for following such a complex layer of script
>> based bootstrapping and a somewhat convoluted Dockerfile was to reduce the
>> resulting Docker image size. At the time, Docker's Copy-On-Write strategy
>> was not kind on a number of changes we would be doing for a WSO2 Server.
>> This required "clever" hacks to be performed so that there would be minimal
>> inter-layer changes. One of these hacks was to copy and modify the WSO2
>> server packs and the JDK in the same layer. We were able to reduce the
>> Docker image sizes for a standard ESB image from somewhere around 2GB to
>> 800MB through this approach.
>>
>> However, Docker has now started to address the image size concerns raised
>> by the community. One of the solutions Docker has started to put forward is
>> the --squash flag [1]. This is still an experimental feature but is
>> available with the recent Docker CE releases. With --squash flag, there is
>> no need for Dockerfile instruction manipulation to get a smaller Docker
>> image. It's reasonable to assume that Docker would keep improving this
>> functionality in the future.
>>
>> With this in mind, evolving the current set of Dockerfiles into a simpler
>> set and reducing the bash script based bootstrapping layer to a minimum is
>> IMO the best approach to resolve the above-mentioned issues. In such a
>> simple approach, a Dockerfile would only need the WSO2 Ser

Re: [Architecture] Proposal to Use a Single Set of WSO2 Docker Images for All Container Platforms

[Dilan Udara Ariyaratne]

Hi Imesh,

+1 to this suggestion.

My personal experience is that even our users find it confusing to see
dockerfile definitions for a product or product profile in multiple
repositories.
Thus, it would be quite intuitive to have a single source of truth per each
product or product profile in the relevant docker- repository from
this point onward.
And with the level of generalization that we have reached now in dockerfile
definitions, my gut feeling is that we can use the same definition for any
container platform without any specializations even in future.

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Mon, Jan 29, 2018 at 7:36 AM, Imesh Gunaratne  wrote:

> On Mon, Jan 29, 2018 at 6:58 AM, Muhammed Shariq  wrote:
>
>> Hi Imesh / all,
>>
>> Personally, I think the best option going forward is to maintain a single
>> set of docker image across all platforms. It's true that there is a concern
>> of users having to do more work, but in reality, user's will have do quite
>> a lot of config changes such as copying jdbc drivers, create key stores and
>> update hostnames etc right? As long as we provide a clean option, which is
>> using volume mounts or in k8s case config maps, we should be good.
>>
>> For the evaluation / demo case, users can use the docker-compose
>> artifacts that's already preconfigured and ready to go.
>>
>> While it might seem attractive to maintain images per platform, I think
>> it would be very costly and hard to maintain in the long run. In the
>> future, we would have to do things like running some scans etc on the built
>> images before making it available to pull. Having to identify issues across
>> many different platforms and fixing them one by one would be cumbersome.
>>
>> I would suggest we go with a single set of images for all platforms and
>> then create per platform images if the need arises.
>>
>
> ​I completely agree with Shariq!
>
> The reason for starting this thread was that when we started creating
> DC/OS Docker images we found that we can simply use the Docker images
> created in the product Docker Git repositories (github.com/wso2/docker-
> ) without making any changes except for adding user group id for
> managing volume permissions (which would be common for any container
> platform).
>
> This model will allow us to efficiently manage WSO2 Docker images by only
> creating one image per product version (in EI and SP there will be one per
> profile) and use those on all container platforms by following above best
> practices. Most importantly, it will work well when releasing
> updates/patches.
>
> Regarding the concern of having additional steps for copying files to
> volumes, let's do a quick POC and see whether we can find a better way to
> overcome that problem in each platform for evaluation scenarios.
>
> @Lakmal: Would you mind sharing your thoughts on this?
>
> Thanks
> Imesh
>
>>
>>
>>
>> On Mon, Jan 22, 2018 at 5:30 PM, Imesh Gunaratne  wrote:
>>
>>> On Mon, Jan 22, 2018 at 2:46 PM, Pubudu Gunatilaka 
>>> wrote:
>>>
 Hi Imesh,

 It is very convenient if we can reuse the docker image. AFAIU if we
 follow the above approach we can use a single docker image in all the
 container platforms.

 One of the drawbacks I see with this approach is that the user has to
 update the volume mounts with the necessary jar files, JKS files, etc. If
 any user tries this approach in Kubernetes, he has to add those jar files
 and binary files to the NFS server (To the volume which holds NFS server
 data). This affects the installation experience.

 IMHO, we should minimize the effort in trying out the WSO2 products in
 Kubernetes or any container platform. Based on the user need, he can switch
 to their own deployment approach.

>>>
>>> Thanks for the quick response Pubudu! Yes, that's a valid concern. With
>>> the proposed approach user would need to execute an extra step to copy
>>> required files to a set of volume mounts before executing the deployment.
>>> In a production deployment I think that would be acceptable as there will
>>> be more manual steps involved such as creating databases, setting up CI/CD,
>>> deployment automation, etc. However, in an evaluation scenario when someone
>>> is executing a demo it might become an overhead.
>>>
>>> I also noticed that kubectl cp command can be used to copy files from a
>>> local machine to a container. Let's check whether we can use that approach
>>> to overcome this issue:
>>> https://kubernetes.io/docs/reference/generated/kubectl/kubec
>>> tl-commands#cp
>>>
>>> On Mon, Jan 22, 2018 at 3:03 PM, Isuru Haththotuwa 
>>> wrote:
>>>
 In API Manager K8s artifacts, what we have followed is not having an
 image-per-profile method. With the introduction of Config Maps, it has
 become only two base images - for APIM and Analytics. Its extr

[Architecture] [Puppet] WSO2 Puppet Common v1.1.0 and Puppet Base v1.2.0 Released!

[Dilan Udara Ariyaratne]

Hi Folks,

We are pleased to release WSO2 Puppet Common v1.1.0 and Puppet Base v1.2.0
with following improvements and fixes to the code base.


*WSO2 Puppet Common v1.1.0 Release*
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

This is a minor release of WSO2 Puppet-common

which adds following improvements and fixes to the code base.

   1. Control JDK installation through Facter
   
   2. puppet agent -vt execution fails when executing from a different
   location 
   3. Remove virtualbox group as it fails intermittently
   
   4. Incorrect java version in README.md
   
   5. Vagrant up fails since it cannot find hieradata
   


Link to release: https://github.com/wso2/puppet-common/releases/tag/v1.1.0

*WSO2 Puppet Base v1.2.0 Release*
- - - - - - - - - - - - - - - - - - - - - - - - - - - -

This is a minor release of WSO2 Puppet-base
which adds following improvements and fixes to the code base.

   1. Add unit file support for RHEL 7
   
   2. Syntax error at manifests/system.pp
   


Link to release: https://github.com/wso2/puppet-base/releases/tag/v1.2.0

Thanks.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [Dev] WSO2 Puppet Common v1.1.1 Released!

[Dilan Udara Ariyaratne]

*WSO2 Installation Experience Team* is pleased to announce the release
of *WSO2 Puppet Common v1.1.1
*.

You can download source from following links.

Source code (zip) 
 |Source code (tar.gz)


In this release, changes were made to setup.sh with respect to changed
puppet-is repository structure.

*Issues* - https://github.com/wso2/puppet-common/issues

*How You Can Contribute?*
Join our mailing list and correspond with the developers directly.
Developer List: d...@wso2.org
User List: u...@wso2.org

*Reporting Issues*
We encourage you to report issues or any documentation faults regarding
WSO2 Puppet Common by creating issues at GitHub
.

Thank you!
*WSO2 Installation Experience Team*

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [CDMF] [EMM 2.1.0] Basic Use-cases for Dashboard Analytics Feature

[Dilan Udara Ariyaratne]

Hi Geeth,

Currently there is a plan to show device counts based on user defined
custom groups in EMM snapshot dashboard.
This is in addition to the platform based and ownership based default
grouping of devices.

However, we may have to postpone plans on showing device counts based on
"INACTIVE", "BLOCKED" and "UNREACHABLE" states as
back-end support for maintaining such states are not yet available.

Regards,
Dilan.





*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Fri, Feb 12, 2016 at 10:27 AM, Geeth Munasinghe  wrote:

> Hi Dilan,
>
> We may have to include the following too.
>
>1. Device count by groups,
>2. Device groups
>3. Active/Inactive devices
>4. Blocked/Removed devices
>5. Unreachable devices
>6. Number of enrolled devices within give time frame (new devices
>added)
>
> Thanks
> Geeth
>
>
> *G. K. S. Munasinghe*
> *Senior Software Engineer,*
> *WSO2, Inc. http://wso2.com <http://wso2.com/> *
> *lean.enterprise.middleware.*
>
> email: ge...@wso2.com
> phone:(+94) 777911226
>
> On Fri, Feb 12, 2016 at 10:17 AM, Dilan Udara Ariyaratne 
> wrote:
>
>> Hi All,
>>
>> For the upcoming EMM 2.1.0 release, we have identified following basic
>> use-cases for
>> the Dashboard Analytics Feature with respect to devices.
>>
>> [1] Device count by Platform
>> [2] Device count by Ownership (BYOD, COPE)
>> [3] Device count by Security Concerns
>>  - unmanaged (Meaning no policies currently assigned to the device)
>>  - non-compliant (Meaning a policy has been already assigned, but its
>> rules have been maliciously overridden by some other third party)
>>  - no passcode
>>  - no encryption
>> [4] Last Seen Overview - Devices seen in last 8 hours
>>  Last Seen Breakdown - Devices seen by dates (0-5, 5-15, 15-30, >30)
>> [5] Total enrollments, Re-enrollments & Unenrollments
>> [6] Devices based on location
>>  - Divisional map with Device counts
>>  - ability to zoom in for each division which will show device
>> location with tags
>>  - ability to click on each tag and go to individual device details
>>
>> The dashboard will allow an EMM portal administrator to quickly navigate
>> from the overall view to a device listing view and then
>> zoom into an individual device to view device specific details.
>>
>> WDYT? Any valuable suggestion is highly appreciated.
>>
>> Thanks.
>>
>> *Dilan U. Ariyaratne*
>> Software Engineer
>> WSO2 Inc. <http://wso2.com/>
>> Mobile: +94725197942
>> lean . enterprise . middleware
>>
>> ___
>> 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
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [CDMF] [EMM 2.1.0] Basic Use-cases for Dashboard Analytics Feature

[Dilan Udara Ariyaratne]

Hi Hasunie,

Yes, Most of the use-cases that you have pointed out here are of-course
currently on consideration under
application related analytics. Not only "applications" related, but also
"user" and "policy" related use-cases are currently on review.

I will update the thread ASAP on such requirements once they are sort of
finalyzed.

Thanks,
Dilan.






*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Tue, Mar 29, 2016 at 10:51 PM, Hasunie Adikari  wrote:

> Hi Dilan,
>
> It should be add app related analytics like
>
> 1. Blacklisted app count
> 2. Recently updated app count
> 3. Recommended app count
> 4. Total device count not having latest app version.
> 5. App usage based on the platform, platform version
> 6. Most frequently used applications.
> 7. Application crash scenarios.
>
>
> On Tue, Mar 29, 2016 at 6:47 PM, Dilan Udara Ariyaratne 
> wrote:
>
>> Hi Geeth,
>>
>> Currently there is a plan to show device counts based on user defined
>> custom groups in EMM snapshot dashboard.
>> This is in addition to the platform based and ownership based default
>> grouping of devices.
>>
>> However, we may have to postpone plans on showing device counts based on
>> "INACTIVE", "BLOCKED" and "UNREACHABLE" states as
>> back-end support for maintaining such states are not yet available.
>>
>> Regards,
>> Dilan.
>>
>>
>>
>>
>>
>> *Dilan U. Ariyaratne*
>> Software Engineer
>> WSO2 Inc. <http://wso2.com/>
>> Mobile: +94766405580 <%2B94766405580>
>> lean . enterprise . middleware
>>
>>
>> On Fri, Feb 12, 2016 at 10:27 AM, Geeth Munasinghe 
>> wrote:
>>
>>> Hi Dilan,
>>>
>>> We may have to include the following too.
>>>
>>>1. Device count by groups,
>>>2. Device groups
>>>3. Active/Inactive devices
>>>4. Blocked/Removed devices
>>>5. Unreachable devices
>>>6. Number of enrolled devices within give time frame (new devices
>>>added)
>>>
>>> Thanks
>>> Geeth
>>>
>>>
>>> *G. K. S. Munasinghe*
>>> *Senior Software Engineer,*
>>> *WSO2, Inc. http://wso2.com <http://wso2.com/> *
>>> *lean.enterprise.middleware.*
>>>
>>> email: ge...@wso2.com
>>> phone:(+94) 777911226
>>>
>>> On Fri, Feb 12, 2016 at 10:17 AM, Dilan Udara Ariyaratne <
>>> dil...@wso2.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> For the upcoming EMM 2.1.0 release, we have identified following basic
>>>> use-cases for
>>>> the Dashboard Analytics Feature with respect to devices.
>>>>
>>>> [1] Device count by Platform
>>>> [2] Device count by Ownership (BYOD, COPE)
>>>> [3] Device count by Security Concerns
>>>>  - unmanaged (Meaning no policies currently assigned to the device)
>>>>  - non-compliant (Meaning a policy has been already assigned, but
>>>> its rules have been maliciously overridden by some other third party)
>>>>  - no passcode
>>>>  - no encryption
>>>> [4] Last Seen Overview - Devices seen in last 8 hours
>>>>  Last Seen Breakdown - Devices seen by dates (0-5, 5-15, 15-30, >30)
>>>> [5] Total enrollments, Re-enrollments & Unenrollments
>>>> [6] Devices based on location
>>>>  - Divisional map with Device counts
>>>>  - ability to zoom in for each division which will show device
>>>> location with tags
>>>>  - ability to click on each tag and go to individual device details
>>>>
>>>> The dashboard will allow an EMM portal administrator to quickly
>>>> navigate from the overall view to a device listing view and then
>>>> zoom into an individual device to view device specific details.
>>>>
>>>> WDYT? Any valuable suggestion is highly appreciated.
>>>>
>>>> Thanks.
>>>>
>>>> *Dilan U. Ariyaratne*
>>>> Software Engineer
>>>> WSO2 Inc. <http://wso2.com/>
>>>> Mobile: +94725197942
>>>> lean . enterprise . middleware
>>>>
>>>> ___
>>>> 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
>>>
>>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Hasunie Adikari*
> Software Engineer
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
> blog http://hasuniea.blogspot.com
> Mobile:+94715139495
>
> ___
> 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] [CDMF] [EMM 2.1.0] Basic Use-cases for Dashboard Analytics Feature

[Dilan Udara Ariyaratne]

Hi Harshan,

The concern of "Performance" that you have put forward is really good.
We will definitely take this into consideration.

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Wed, Mar 30, 2016 at 9:28 PM, Harshan Liyanage  wrote:

> Hi Dilan,
>
> Should n't we include some performance related dashboard as well? For
> example we can show no of connected devices per second, average response
> times,  logged in user-count etc. I think it may not be feasible at this
> moment. But we can include such a dashboard in the next release. That'll be
> a nice feature to have.
>
> Thanks,
>
> Harshan Liyanage
> Software Engineer
> Mobile: *+94724423048*
> Email: hars...@wso2.com
> Blog : http://harshanliyanage.blogspot.com/
> *WSO2, Inc. :** wso2.com <http://wso2.com/>*
> lean.enterprise.middleware.
>
> On Wed, Mar 30, 2016 at 7:08 AM, Dilan Udara Ariyaratne 
> wrote:
>
>> Hi Hasunie,
>>
>> Yes, Most of the use-cases that you have pointed out here are of-course
>> currently on consideration under
>> application related analytics. Not only "applications" related, but also
>> "user" and "policy" related use-cases are currently on review.
>>
>> I will update the thread ASAP on such requirements once they are sort of
>> finalyzed.
>>
>> Thanks,
>> Dilan.
>>
>>
>>
>>
>>
>>
>> *Dilan U. Ariyaratne*
>> Software Engineer
>> WSO2 Inc. <http://wso2.com/>
>> Mobile: +94766405580 <%2B94766405580>
>> lean . enterprise . middleware
>>
>>
>> On Tue, Mar 29, 2016 at 10:51 PM, Hasunie Adikari 
>> wrote:
>>
>>> Hi Dilan,
>>>
>>> It should be add app related analytics like
>>>
>>> 1. Blacklisted app count
>>> 2. Recently updated app count
>>> 3. Recommended app count
>>> 4. Total device count not having latest app version.
>>> 5. App usage based on the platform, platform version
>>> 6. Most frequently used applications.
>>> 7. Application crash scenarios.
>>>
>>>
>>> On Tue, Mar 29, 2016 at 6:47 PM, Dilan Udara Ariyaratne >> > wrote:
>>>
>>>> Hi Geeth,
>>>>
>>>> Currently there is a plan to show device counts based on user defined
>>>> custom groups in EMM snapshot dashboard.
>>>> This is in addition to the platform based and ownership based default
>>>> grouping of devices.
>>>>
>>>> However, we may have to postpone plans on showing device counts based
>>>> on "INACTIVE", "BLOCKED" and "UNREACHABLE" states as
>>>> back-end support for maintaining such states are not yet available.
>>>>
>>>> Regards,
>>>> Dilan.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *Dilan U. Ariyaratne*
>>>> Software Engineer
>>>> WSO2 Inc. <http://wso2.com/>
>>>> Mobile: +94766405580 <%2B94766405580>
>>>> lean . enterprise . middleware
>>>>
>>>>
>>>> On Fri, Feb 12, 2016 at 10:27 AM, Geeth Munasinghe 
>>>> wrote:
>>>>
>>>>> Hi Dilan,
>>>>>
>>>>> We may have to include the following too.
>>>>>
>>>>>1. Device count by groups,
>>>>>2. Device groups
>>>>>3. Active/Inactive devices
>>>>>4. Blocked/Removed devices
>>>>>5. Unreachable devices
>>>>>6. Number of enrolled devices within give time frame (new devices
>>>>>added)
>>>>>
>>>>> Thanks
>>>>> Geeth
>>>>>
>>>>>
>>>>> *G. K. S. Munasinghe*
>>>>> *Senior Software Engineer,*
>>>>> *WSO2, Inc. http://wso2.com <http://wso2.com/> *
>>>>> *lean.enterprise.middleware.*
>>>>>
>>>>> email: ge...@wso2.com
>>>>> phone:(+94) 777911226
>>>>>
>>>>> On Fri, Feb 12, 2016 at 10:17 AM, Dilan Udara Ariyaratne <
>>>>> dil...@wso2.com> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> For the upcoming EMM 2.1.0 release, we have identified following
>>>>>> basic use-cases for
>>>>>> the Dashboard A

Re: [Architecture] [CDM-F] "Descriptor"-driven plug-ins for CDM-F

[Dilan Udara Ariyaratne]

Hi Prabath,

To me, it seems that your proposal is almost aligned with what we can do
with an OMA DM 
supported device type.

In OMA DM, every property or action related to a device type is a resource
which we can manipulate and how we can do that is well defined in a device
definition file.

Is what you propose, having an idea similar to a device definition file in
OMA DM protocol?

Cheers,
Dilan.

*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Sat, Apr 30, 2016 at 7:11 PM, Prabath Abeysekera 
wrote:

> Hi Everyone,
>
> *Current plug-in architecture of CDM-F*
>
> If we look at the current plug-in model of CDM-F (1.x), it consists of
> three primary components.
>
> 1. A Class that extends "DeviceManager" interface providing information on
> what features/configurations to be managed, what datasources are used for
> persisting plug-in specific information, what push notification mechanism
> has to be configured for a given device type, device type provisioning
> instructions, etc.
>
> 2. A control API in the form of a JAX-RS service that let's us expose
> control operations upon the aforementioned features.
>
> 3. A UI component providing the front-end of the plug-in related
> functionalities
>
> 4. Optionally, analytics scripts, which is to be taken out of the scope of
> a device plug-in. Please refer more info on this in thread "[IoTS] Is it
> the right thing to package "analytics" scripts with a plugin
> implementation?" in architecture@.
>
> *Key characteristics of the current plug-in model*
>
> If we carefully look at the aforementioned model, it has the following
> characteristics.
>
> * A class to "describe" how a plug-in should be modeled and represented to
> the core device management framework together with its list of features.
>
> * A JAX-RS service to expose the features defined by the class above.
>
> * A UI component that talks to the API described in the above step.
>
> *How to make it "descriptor-driven"*
>
> My proposal is that, you can quite easily turn this model into a
> "descriptor-driven" implementation, which will greatly enhance the
> usability of the device management framework, as below.
>
> * We don't necessarily need a "java class" to "describe" a plug-in as it
> can simply be done with a descriptor-file with some sort of a
> framework-provided DSL. The key advantage is that, the whole model is
> "zero-code" so, you don't need to be a java developer to craft a plug-in
> and put it into the framework. If getting used to a DSL is cumbersome, we
> can totally make a Developer Studio plug-in that wraps this DSL and provide
> the user with an easy-to-use UI for plug-in composition.
>
> * The operations that should be exposed as part of the control API can
> easily be extracted out of the list of features given in the plug-in
> descriptor. We should then be able to auto-generate the JAX-RS together
> with the required control-operations during the deployment time of the
> descriptor.
>
> * For the UI too, we should be able to adopt somewhat a combined approach
> comprising both auto-generated + manual composition aspects. However,
> before we do that, we might need to work on a proper UI abstraction for the
> framework, which can then be extended by this sort of a model.
>
> WDYT?
>
> If the aforementioned model sounds like a good alternative to the current
> plug-in model, I'd like to propose adding this to CDM-F 2.0.
>
>
>
> Cheers,
> Prabath
> --
> Prabath Abeysekara
> Technical Lead
> WSO2 Inc.
> Email: praba...@wso2.com
> Mobile: +94774171471
>
> ___
> 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] [CDM-F] Making "Device Management Feature" a top level extensible construct in CDM-F

[Dilan Udara Ariyaratne]

Hi Prabath,

I understand that the same problem could arise when a certain feature of a
device type gets updated to an extent where the same feature level
implementation of the plugin
would work on certain old OS versions, but not work on any newer OS
versions of the same platform.

But what I could not understand is that how making "Device Management
Feature" an extensible construct, could help in solving the issue you
mention?

Can you elaborate more on this?

Cheers,
Dilan.

*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Fri, Apr 29, 2016 at 2:11 PM, Dilshan Edirisuriya 
wrote:

> Sorry about that. I thought this needs to be done after the device
> identity thing which we talked about doing with IS roadmap.
>
> Regards,
>
> Dilshan
>
> On 29 April 2016 at 13:53, Prabath Abeysekera  wrote:
>
>> Well, supporting device identity is indeed something that's there in the
>> product roadmap. However, that I'm afraid is out of the scope of what's
>> proposed and intended to be discussed within this particular thread.
>>
>> That said, if you are willing to contribute to the platform WRT getting
>> device identity implemented, and also have got a design/architecture in
>> mind, please do go ahead and initiate a separate thread in architecture@,
>> so we can discuss it there.
>>
>> Cheers,
>> Prabath
>>
>> On Fri, Apr 29, 2016 at 10:25 AM, Dilshan Edirisuriya <
>> ed.dils...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> What are the plans to support device identity? There are several
>>> situations where you need to consider device as a top level element rather
>>> than associating it with users. Eg; picking the device from authentication
>>> level,  adding throttling policies for device etc.
>>>
>>> Regards,
>>>
>>> Dilshan
>>>
>>> On 28 April 2016 at 17:56, Prabath Abeysekera  wrote:
>>>
 Hi Everyone,

 As all know, CDM-F is a platform that allows folks to easily extend its
 plug-in model and seamlessly add support for new device types. So, ATM,
 "Device Management Plugin" is the primary top level construct that can be
 extended in the framework, to cater the aforementioned requirement.

 I'm proposing "Device Management Feature" too should be treated as a
 similar top-level extensible construct, particularly considering "EMM-like"
 scenarios, in which we ship a standard set of plug-ins, that needs to be
 extended to support a few new features. Here's why.

 Let's assume an organization is planning to deploy EMM to manage their
 devices. The list of "features" that needs to be managed by one
 organization might vary from that of another. Further, support for managing
 some of those might not even be available OOTB as part of EMM. To makes
 things more complicated, in certain cases, shipping all that sort of fancy
 features around OOTB in EMM wouldn't quite make sense as well. However, in
 the context of those adopting organizations, having the ability to control
 such features might be critical. As a result, there is always a possibility
 that these folks get lured into customize the existing functionalities if
 that level of extensibility is not available in the product.

 To cater the aforesaid requirement, the only option available right now
 is extending one of the existing plug-ins (with the new features) and then
 plugging the enhanced plug-in back into the product, which is somewhat a
 tedious task.

 To make things more easier for users, I propose making "Device
 Management Feature" an extensible construct, which can be utilized by the
 folks who want to extend an existing plug-in to seamlessly support new
 features that are not supported OOTB in the product. This can be thought of
 as something similar to the concept of "mediators" in the context of ESB as
 well.

 WDYT?

 Cheers,
 Prabath
 --
 Prabath Abeysekara
 Technical Lead
 WSO2 Inc.
 Email: praba...@wso2.com
 Mobile: +94774171471

 ___
 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
>>>
>>>
>>
>>
>> --
>> Prabath Abeysekara
>> Technical Lead
>> WSO2 Inc.
>> Email: praba...@wso2.com
>> Mobile: +94774171471
>>
>> ___
>> 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] Identity Management Recovery API improvements.

[Dilan Udara Ariyaratne]

Hi Isura,

According to the REST API Guidelines that we have defined across all the
products,
following suggestions can be made regarding the resource paths that you
have proposed.

[1] Base-path "accountrecovery" has two words in it and they can be
separated by a dash, i.e. as "account-recovery".
[2] It seems that path "rest" does not make any sense as a resource, so it
can be removed.
[3] Also, all the underscore signs included in processiong-functions like
"reset_password" and resource-paths like "security_questions_response"
could be replaced with a dash (-).

Regards,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Wed, Jun 8, 2016 at 1:02 PM, Isura Karunaratne  wrote:

> Identity Management Recovery API improvements.
>
> In Identity Server 5.3.0, we are going to implement Identity Management
> recovery APIs as rest resources. In current implementations of IS5.0.0,
> IS5.1.0 we have soap APIs for recovery scenarios. [1].
>
> Captcha validation is coupled with recovery flows in existing soap API
> implementation and we have improved Java API to decouple to the captcha
> validation from recovery flows in new implementations. [4]
> Existing soap APIs.Recover with Notification [2]
>
>-
>
>getCaptcha() -­ Generates a captcha.
>-
>
>verifyUser() -­ Validates the captcha answer and username and returns
>a new key.
>-
>
>sendRecoveryNotification() -­ Send an email notification with a
>confirmation code to the user. Need to provide the key from the previous
>call.
>-
>
>getCaptcha() ­- Generates a captcha when the user clicks on the URL.
>-
>
>verifyConfirmationCode() -­ Validates the captcha answer and
>confirmation code. This returns a key.
>-
>
>updatePassword -­ Updates the password in the system. Need to provide
>the key from the previous call, new password and returns the status of the
>update, true or false.
>
> Recover with Secret Questions[3]
>
>-
>
>getCaptcha() ­- Generates a captcha.
>-
>
>verifyUser() ­- Validates the captcha answer and username and returns
>a new key.
>-
>
>getUserChallengeQuestionIds() ­- Retrieve the claim URI IDs specified
>for the user with the generated key. Need to provide the key from the
>previous call.
>-
>
>getUserChallengeQuestion() ­- Retrieve the user’s challenge question
>for the specified claim URI ID from the previous call. Need to provide the
>key from the previous call.
>-
>
>verifyUserChallengeAnswer() ­- Validates the answer and confirmation
>code for the specified question. Need to provide the key from the previous
>call.
>-
>
>updatePassword() ­- Updates the password in the system. Need to
>provide the key from the previous call, the new password and return the
>status of the update, i.e. true or false.
>
>
>
>
>
> New APIs
> Recover with Notification
>
>-
>
>sendRecoveryNotification() : validate user and returns a new key
>through a notification.
>-
>
>updatePassword() : Updates the password in the system. Need to provide
>the key from notification, new password
>
>
> Recover with Secret Questions
>
>-
>
>intiateUserChallengeQuestion(); ­validate user and returns a question
>to answer with a secret code
>-
>
>verifyUserChallengeAnswer(); validate secret code and answer for the
>question in previous step. Return a new question with new secret until
>minimum number of questions are answered.
>-
>
>updatePassword(); Updates the password in the system. Need to provide
>the key from notification, new password
>
>
>
> New APIs for Multiple Questions at once
>
>-
>
>getAllChallegeQuestions(); validate user and returns all questions to
>answer with a secret code
>-
>
>validateAllChallengeAnswers(); validate code and all answers and
>return a code if success
>-
>
>updatePassword();Updates the password in the system. Need to provide
>the key from notification, new password
>
>
>
>
>
>
>
>
>
>
>
> [1] https://docs.wso2.com/display/IS510/Password+Recovery
>
> [2]
> https://docs.wso2.com/display/IS510/Password+Recovery#PasswordRecovery-Recoveryusingnotifications
>
> [3]
> https://docs.wso2.com/display/IS510/Password+Recovery#PasswordRecovery-Recoveryusingchallengequestions
>
> [4] [Architecture] Decouple capcha validation from Recovery flows
>
>
>
> Sample Requests
> Send Email Notification
>
> POST accountrecovery/rest/notification/notify
> 
>
>
> Request Body
>
>  {
>
> "userName": "testuser",
>
> "tenantDomain": "carbon.super",
>
>  "userStoreDomain": "PRIMARY"
>
> }
>
>
> If notifications are internally managed,
>
> Response Body
>
> HTTP 200
>
>
> If notifications are externally managed,
>
> Response Body
>
> {
>
> "user": {
>
> "

Re: [Architecture] Maintaining analytics related JS libraries outside carbon-dashboards repository

[Dilan Udara Ariyaratne]

Hi All,

Isn't it confusing to maintain two analytics repos with both having common
analytics stuff?

And even if there is a valid reason to do this, still it seems that the
repo names are confusing since both (shared-analytics and
carbon-analytics-common) sound the same. Isn't that so?

@dunith, +1 to your suggestion.

Regards,
Dilan.

On Friday, June 10, 2016, Tharik Kanaka  wrote:

> Hi All,
>
> @Damith
> These are common libs for portal wizard which is common for analytics
> products (analytics-is, analytics-esb, analytics-apim and etc), product-das
> and product-cep. shared-analytics repository was created for analytics
> products, product-das and product-cep does not have dependencies.
>
> @Dunith and others
> On the other hand keeping these in carbon-analytics-common could cause
> maintenance difficulties. For an instance if there is a bug in one of chart
> wizard view, we need to fix it carbon-analytics-common and release that and
> then need to release all the repositories depending on
> carbon-analytics-common. This can be resolved if we keep these in some repo
> like shared-analytics and include those features in the products-cep and
> product-das. Again then we need reconsider about the name
> "shared-analytics" as it has become a common repository for products-cep
> and product-das as well.
>
> Regards,
>
> On Fri, Jun 10, 2016 at 5:13 PM, Damith Wickramasinghe  > wrote:
>
>> Hi Dunith,
>>
>> +1 . isn't these should go shared-analytics repository since we are using
>> it to hold all common artifacts used in analytics effort.
>>
>> Regards,
>> Damith.
>>
>> On Fri, Jun 10, 2016 at 4:55 PM, Dunith Dhanushka > > wrote:
>>
>>> Hi all,
>>>
>>> Gadgets developed for analytics products (E.g ESB, IS,MB, IoTs etc)
>>> depend on JS libraries which are currently been referred from multiple
>>> locations.
>>>
>>> For instance
>>>
>>> 1. JS utilities common to all gadgets like wso2gadgets.js and
>>> chart-utils.js (Currently referred from /portal/libs/common-chart-libs)
>>> 2. JS libraries used by chart template authors (related to gadget
>>> wizard). E.g VizGrammar, Vega etc (Currently referred from gadget level js
>>> folder)
>>>
>>> Since above JS libraries do tasks specific to analytics (E.g mostly for
>>> data visualization), it is better to maintain them in a analytics
>>> repository like
>>> carbon-analytics-common. Advantage is that a simple change in those JS
>>> files will not require a new carbon-dashboards release.
>>>
>>> Another issue is when generating a gadget, libraries like VizGrammar are
>>> packed with each gadget. If there are considerable amount of gadget's
>>> exist, it is quite difficult to propagate a library change across all
>>> gadgets.
>>>
>>> So as a solution, we came up like this.
>>>
>>> 1. There's a feature [1] in carbon-analytics-common to put all analytics
>>> UX related artifcats such as chart templates and data providers. We can
>>> have a room for JS files as well.
>>>
>>> 2. All analytics related JS files will be maintained inside [1] and
>>> analytics folks will have total control over them.
>>>
>>> 3. When building an analytics product, required analytics JS files will
>>> be copied to /portal/libs/analytics-wso2_1.0 folder (Can be instructed in
>>> p2.inf file of feature [1]).
>>>
>>> 4. Gadgets generated using wizard will refer JS files from above
>>> location so that change in one file will be reflected in every generated
>>> gadget.
>>> E.g /portal/libs/analytics-wso2_1.0/VizGrammar.min.js
>>>
>>> By this way, carbon-dashboards repo will no longer needing to maintain
>>> any analytics specific JS files.
>>>
>>> @DS Team, @Dakshika can we have your feedback on this please? Suggest a
>>> naming standard if possible.
>>>
>>> [1]
>>> https://github.com/wso2/carbon-analytics-common/tree/master/features/analytics-gadget-templates
>>>
>>> Regards,
>>>
>>> Dunith Dhanushka,
>>> Associate Technical Lead
>>> WSO2 Inc,
>>>
>>> Mobile - +94 71 8615744
>>> Blog - *https://medium.com/@dunithd *
>>> Twitter - @dunithd 
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> 
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Software Engineer
>> WSO2 Inc.; http://wso2.com
>> 
>> lean.enterprise.middleware
>>
>> mobile: *+94728671315 <%2B94728671315>*
>>
>>
>
>
> --
>
> *Tharik Kanaka*
>
> WSO2, Inc |#20, Palm Grove, Colombo 03, Sri Lanka
>
> Email: tha...@wso2.com  |
>  Web: www.wso2.com
>


-- 
*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Sharing Dashboards that have gadgets with role restriction

[Dilan Udara Ariyaratne]

Hi Megala / Tanya,

It would be useful if you can also explain the practical use-cases behind
implementing this feature;
so that it validates the real necessity of having such feature available on
the product.

IMO, making a dashboard blindly viewable to any user on any other tenant
(who might even not be interested in viewing such dashboard) may not be a
practical use-case.

Please do correct me, if I have misunderstood anything.

Regards,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Fri, Jun 10, 2016 at 9:46 AM, Tanya Madurapperuma  wrote:

> Hi Dilini,
>
> On Fri, Jun 10, 2016 at 9:38 AM, Dilini Gunatilake 
> wrote:
>
>> Hi Tanya/Megala,
>>
>> Can't we share the anonymous view with other tenants as a normal view?
>>
> We have only a dashboard sharing option as per now but not view sharing
> option.
>
>
>> In that case if a particular user gets a waning as you said at the time
>> of sharing, the user can create an anonymous view without those restricted
>> gadgets and share the dashboard with other tenants. Then, those tenant
>> users will be able to view the dashboards as explained in the above doc[1].
>> Just an opinion.
>>
> Also anon view is for any non logged in users and we don't have to
> explicitly share it across tenants.
>
>>
>> Also, I think hiding gadgets won't work because it will introduce
>> unnecessary complications in re-arranging the template. If the restricted
>> gadget is in the middle of the template we can't keep a blank space in the
>> middle rather re-arrange it in a suitable way.
>>
> As I have explained in my previous reply,  actual issue here is we are not
> aware of the existing roles in each tenant to hide a gadget based on gadget
> level permissions.
>
> Thanks,
> Tanya
>
>>
>> Regards,
>> Dilini
>>
>> On Thu, Jun 9, 2016 at 10:27 AM, Tanya Madurapperuma 
>> wrote:
>>
>>> To add into what Megala has explained..
>>>
>>> We decided the above approach due to below reasons.
>>>
>>>1. In the gadget listing page of the designer mode, we list only the
>>>intersection of the gadget that are authorized for the logged in user and
>>>restricted viewers of that particular view. So if we warn the dashboard
>>>creator saying "you have added a restricted gadget, if you share or
>>>planning share this dashboard across tenants, those gadget will be shown 
>>> to
>>>the tenant users" at the time of adding a new gadget to the dashboard, he
>>>will be frustrated if he doesn't want to share this dashboard. So we
>>>skipped that option.
>>>2. We decided* only to warn* the user at the time of sharing the
>>>dashboard rather than hiding those gadgets in tenants view, because say a
>>>particular gadget is restricted only for Role1 in super tenant. There can
>>>be a role with the same name in another tenant which serves a different
>>>purpose. So blindly we can't hide gadgets in tenant mode based on the 
>>> role
>>>specified in the gadget.
>>>
>>> Thanks,
>>> Tanya
>>>
>>> On Thu, Jun 9, 2016 at 10:09 AM, Megala Uthayakumar 
>>> wrote:
>>>
 Hi All,

 We have created a new feature for DS which allows the dashboard
 created from super-tenant to be shared among all the tenants. For more
 information, please refer to documentation at [1]. With the new release we
 are going to introduce fine-grained permission for gadgets. So that,
 gadgets' access can be restricted using roles. In that case, when we share
 the dashboards across tenants the gadgets with role restriction will not be
 shown as roles are limited to each tenant.

 But if we think this from the point-of view of the user, who is willing
 to share the dashboard, he/she will expect tenants to have the same level
 functionality in the view mode.In order to solve this problem, we have
 come up with following option.

 When a super-tenant user tries to share the dashboard, we will give a
 warning saying, this set of gadgets in this dashboard are restricted to
 these roles. If he/she share the dashboard, then it will be shown to all
 other tenant users regardless of role of the user. Then it is user`s
 decision on whether to share/not to share the dashboard.  WDYT ?

 Any comments on this is highly appreciated.

 [1]
 https://docs.google.com/a/wso2.com/document/d/1JjB0Ehf6LzJ13krLwN3vo3fLVU4AHQevBtfzN8XqZ70/edit?usp=sharing

 Thanks.

 Regards,
 Megala
 --
 Megala Uthayakumar

 Software Engineer
 Mobile : 0779967122

>>>
>>>
>>>
>>> --
>>> Tanya Madurapperuma
>>>
>>> Senior Software Engineer,
>>> WSO2 Inc. : wso2.com
>>> Mobile : +94718184439
>>> Blog : http://tanyamadurapperuma.blogspot.com
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman

Re: [Architecture] Access Level Model For WSO2 Dashboard Server

[Dilan Udara Ariyaratne]

Hi All,

IMO, what we require here is a "dynamically-defined,
specific-resource-level-permission" which cannot be achieved by a
"pre-defined, global-permission".

For ex: dasboards/view golbal-permission would allow any user to view any
dashboard in the system.
But if we want to limit specifcally the viewability of, let's say dashboard
"A" to user "X", but not to "Y", we require a dynamically-defined
(defined upon the creation of the dashboard),
specific-resource-level-permission (dasboards/A/view); so that by assigning
that permission to user "X" and not to "Y", we can achieve the required
behavior.

@Nisala,
if I am correct, you are trying to achieve the same here by defining a role
entry that can act as such a permission (i.e. dynamically-defined,
specific-resource-level-permission)
which is exactly the other way of doing this instead of using the
permission based approach.

In this scenario, either if we choose the role option or the permission
option, it seems that
the number of entries to be maintained either at the role level or
permission level to allow these restrictions, are the same.
Therefore, in terms of scalability, both options carry the same burden.

But operational wise, the permission based approach has the following key
advantage over the other.
Take the same example that you have considered.

i.e. lets think that we have to give access to settings page of dashboard X
for all the users who have role A. Then how can we achieve that use-case
here ?

With permission based approach, this can be so easily achieved by adding
the dashboard "X" settings view permission to role "A".
However with role based approach, we will have to assign the dashboard "X"
settings view role to each and every user one by one in order to achieve
the same.
But then again, as sinthuja mentioned, if we have the ability to add
multiple roles to do such operation in addition to the default role, this
won't even be an issue.

Hence, +1 to go with this approach.

In the mean time, one more clarification to make :

i.e on : Another suggestion from me, Shall we create a single role called
'owner' by merging settings role and delete role as manuranga mentioned ?

In here, why are we considering dashboard editing and changing
dashboard settings
as two different operations?
Cannot we merge these two and come up with a role and operation mapping as
follows.

[1] internal/dashboards/{dashboardId}/viewer - can only view the specific
dashboard
[2] internal/dashboards/{dashboardId}/editor - can view, edit and change
any settings of the dashboard
[3] internal/dashboards/{dashboardId}/owner - can view, edit, change any
settings and even delete the dashboard, and also is the original creator of
the dashboard

Regards,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Sat, Jun 11, 2016 at 7:20 PM, Megala Uthayakumar  wrote:

> Hi Nisala,
>
> Shall we create global level permissions for gadget/layout upload and
> delete as they are very sensitive operations which can directly impact on
> dashboard creation?
>
> Note - Gadget/Layout upload and delete are new features that are going to
> be introduced with the new release.
>
> Thanks.
>
> Regards,
> Megala
>
> On Thu, Jun 9, 2016 at 4:32 PM, Nisala Nanayakkara 
> wrote:
>
>> Hi Sinthuja,
>>
>> Thanks for the feedback. I will proceed with implementation.
>>
>> Thanks,
>> Nisala
>>
>> On Thu, Jun 9, 2016 at 4:26 PM, Sinthuja Ragendran 
>> wrote:
>>
>>> Hi Nisala,
>>>
>>> On Thu, Jun 9, 2016 at 8:13 AM, Nisala Nanayakkara 
>>> wrote:
>>>
 Hi Sinthuja,

 This email is to clarify several issues regarding this feature. Up-to
 now I have created a four internal roles as above. All these four roles are
 assigned to the user who created the dashboard initially. If we want to
 give specific permission to another user, we can assign appropriate role to
 that user. As an example if we want to give access to the settings page to
 a user, we can assign appropriate role to that user.

 But lets think that we have to give access to settings page of
 dashboard X for all the users who have role A. Then how can we achieve that
 use-case here ?

>>>
>>> The operations of the dashboard will be assigned initially with the
>>> above mentioned  roles, but you should be able include other roles also for
>>> that operation as same as we have now currently. And hence it's just adding
>>> roleA also along with internal/dashboardA/viewer role for example.
>>>
 Are we going to the add UI configuration in settings page as for editor
 and viewer ?

>>>
>>> Yes, there should be separate options to assign and remove roles per
>>> operations.
>>>
 Otherwise we have to go through all the users who have role A and
 assign them with the dashboard X settings role using carbon management
 console.

 Another suggestion from me, Shall we cr

[Architecture] [CDMF] [IoT] Sensor Management in the CDM Framework

[Dilan Udara Ariyaratne]

Hi Shabir,

IMO, your concern would race mainly in cases where it happens to manage
complex device types. In such scenarios, there could be use-cases in which
we have to maintain multiple instances of the same sensor type to capture
same data, but with varying contexts.

For example, in a refrigerator, we may use two temperature sensors, one to
measure the same inside cooling compartment (context 1) and the other to
measure the same inside freezing compartment (context 2). Even we may use a
group of temperature sensors, in the same context to get an averaged and
more accurate result.

In either case, to correctly classify the data been sent by these sensors,
we need to identify not just the temperature reading and the device, but
also the identity of the sensor and the measuring context.

So the argument that you make seems to be valid and it's applicable not
just to "sensors", but also to "actuators" of a registered device type.

Regards,
Dilan.

On Monday, July 11, 2016, Shabir Mohamed > wrote:

> [+Adding Architecture]
>
> -
> *Shabir Mohamed*
> *Software Engineer*
> WSO2 Inc.; http://wso2.com
> Email: sha...@wso2.com
> Mobile: +94 77 3516019 | +94 71 6583393
>
> On Sun, Jul 10, 2016 at 6:30 PM, Geesara Prathap  wrote:
>
>> Hi Shabir,
>>
>> Is it required at to separately manage generic sensor-types (Temperature,
>> GPS, Distance etc) at the framework level which can be utilised by the
>> device type writers when writing the plugin for their own device-type
>>
>> *or else *
>>
>> Do we not have a separately managed reusable set of sensor-types but only
>> add it as an extension to the existing plugin implementation which enables
>> new device-type plugin writers to DEFINE their own sensor-types at the time
>> of writing the plugin.
>>
>> I think we have to consider both approaches which you are suggesting .
>> Let's say somebody who has a sensor network which needs to be connected
>> with IoTS. Initially,  he will define what are the meta information,
>> payload, stream definition and so on which requires for a given sensor.
>> After initial process is done,  if he needs  to add a sensor which already
>> defined into a new device type he may able to pick existing sensor
>> definition if the framework is supported or else he has to follow the same
>> procedure in order to register a sensor type into a device type.
>>
>> Thanks,
>> Geesara
>>
>> On Sun, Jul 10, 2016 at 3:45 PM, Shabir Mohamed  wrote:
>>
>>> Hi,
>>>
>>> In terms of analytics in the CDM-Framework, we currently contain only
>>> data related to specific device-types. All the streams against which data
>>> is collected is directly bound to a device-type registered to the
>>> framework.
>>>
>>> However, in the build up to the IoT Analytics Framework it was noticed
>>> that there exists a requirement to be able to single out meta information
>>> with regards to the exact origin of the data itself; as in the sensor
>>> information (location, type) from where the data originated.
>>>
>>> For an example if we study a single device-type with TWO different
>>> temperature sensors (mounted on it) pumping data into the IoTServer:
>>>
>>> The current approach persists this data against a single temperature
>>> stream. Whilst it is possible to state that these temperatures came from
>>> "THIS" specific device, it is NOT possible to identify from which sensor
>>> itself (from the 2 that are on the device) that the data came from.
>>>
>>> Hence the need arises to be contain the information with regards to the
>>> sensors/actuators attached to the device-types registered in the
>>> CDM-Framework. That is to be able to manage meta-information of the UNITS
>>> from where data come into the Server or the UNITS to which
>>> commands/controls are sent to from the Server.
>>>
>>> The need for this was initially brought up by Ayyoob in the email thread
>>> with subject:
>>> *"[Architecture] Adding/Managing Sensor information on CDMF"*
>>>
>>> *Having understood the above need, in the discussion to implement it
>>> rises one specific concern to be addressed.*
>>>
>>> Is it required at to separately manage generic sensor-types
>>> (Temperature, GPS, Distance etc) at the framework level which can be
>>> utilised by the device type writers when writing the plugin for their own
>>> device-type
>>>
>>> *or else *
>>>
>>> Do we not have a separately managed reusable set of sensor-types but
>>> only add it as an extension to the existing plugin implementation which
>>> enables new device-type plugin writers to DEFINE their own sensor-types at
>>> the time of writing the plugin.
>>>
>>>
>>> The former case has the advantage of allowing the writers to re-use
>>> already existing sensor-types and to write only new ones as and when
>>> necessary and the latter makes the sensor definition more flexible and
>>> ensures that the CDM-Framework ONLY caters to device management without
>>> complicating with sensors.
>>>
>>> Your thought on this w

Re: [Architecture] [ IoT Analytics] Building a sample analytics story: Smart Home Analytics

[Dilan Udara Ariyaratne]

Hi Geesara,

I would rather argue that the level of information that we are going to
expose here is too low-level in terms of what an end-user would expect
from a so-called "Smart Home Analytics" system.

The type of user stories that you have described here only carries a common
set of analytics requirements that any sort of analytics system would
decide as good-to-have.
But, this is not the higher-level need or end goal of a "Smart Home
Analytics" system should be.

Consider few user-stories as follows.

[1] Depending on the continuous data being pumped by a set of motion
sensors that a user has placed in various locations in his house and
 based on the fact that there is currently no one in the house,
consider how cool it could be if we can detect any suspicious activity by
the exact location and
 alert the user, let's say by SMS and show any necessary information
and possible actions to take on a dashboard.

[2] Depending on the continuous data being pumped by a set of energy usage
meters that a user has placed in all the electric items in his house and
 based on the average energy usage patterns in history for the past few
months, consider how cool it could be if we can predict how his energy
consumption will be
 for the next few days in the month, show corresponding information on
a dashboard and if it's going to be high and costly, suggest any possible
usage plans to minimize it.

[3] Depending on the continuous data being pumped by a set of humidity
sensors, wind speed meters placed in the garden and based on predicted
weather information
 for the day received from weather stations, consider how cool it could
be if we can predict how much water is needed to be applied for plants in
the garden today
 and alert the user of corresponding actions and show any necessary
information in the form of a dashboard gadget.

This is where we should ideally aim when thinking of a sample analytics
story for a Smart Home and make sure that we provide the necessary
development infrastructure
in terms of our middleware stack for any third-party developer to build
such similar end-user experiences on top of our platform.

We already have the key ingredients in terms of this rich middleware stack
that I am talking about.
[1] We do have our Connected Device Management Framework and on top of
that, our IoTServer building up for registering any type of smart device to
the platform and aquire data.
[2] We do have our Data Analytics Server, Complex Event Processor and
Machine Learner building up together in order to perform any sort of
analytics related work.
[3] And finally, we do have our Dashboard Server on top all these to govern
the visualization aspect of captured information.

We just need to find the missing links and connect the dots.

Cheers,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Wed, Jul 13, 2016 at 5:19 PM, Geesara Prathap  wrote:

> Hi All,
>
> Since we do have all the basic components which are required to build a
> fully fledged real world analytics story with IoT Analytics Framework,
> there was a suggestion that we need to build some analytics stories in the
> context of IoT Analytics. So along with that, this is one of the examples
>  we are going to build.
>
> In this use case, we are mainly focusing on analyzing sensor data in a
> timely manner. So when sensors are publishing data it may be required to do
> analytics in real time and do some decision making on a particular event
> stream and so on. Then it goes on with batch processing in order to
> summarize sensor data for later usage. Once raw data is available we will
> be able to do some predefined  machine learning tasks so as to  perform
>  some sort of real work scenarios like model learning, anomaly detection
> and so on.  So this explains how the high-level architecture of this
> project is.
>
>
> [image: homeAutomationSystem.jpg]
>
> Figure 01: High-level architecture
>
> In the initial cut, we are to take a wide variety of dataset which
> contains several types of sensor data from real sensors. This resource[1]
> is provided datasets that have been collected for two successive months. So
> it seems to match our requirement as well.
>
> So these are the selected sample sensor information with some sample
> dataset.
>
>1.
>
>Circuits
>
> CircuitName,CircuitNumber,TimestampUTC,RealPowerWatts,ApparentPowerVAs
>
>  WashingMachine,14,1341047872,1.262,1.963
>
> FridgeRange,15,1341047872,5.196,8.41
>
>  2.  Individual energy meters
>
>
>   MeterName,TimestampUTC,RealPowerWatts,CircuitNumber
>
>   livingroom:subwoofer,1341047975,10,4
>
> basement:washingmachine,1341048003,0,14
>
>3. Dimmable and non-dimmable switches
>
>  
> SwitchName,TimestampUTC,MaxRealPowerWatts,DimProportion,
> CircuitNumber
>

Re: [Architecture] [Dev] EMM 2.1.0 DAS integration and Device Monitoring

[Dilan Udara Ariyaratne]

Hi Chamara,

When it comes to EMM Monitoring Dashboard, we are not retrieving data from
DAS.
Instead, we use the data from our product databases themselves as our
current monitoring use-cases only carry the use of snapshot data and not
historical data.

Regards,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Thu, Jul 21, 2016 at 6:10 PM, Chamara Ariyarathne 
wrote:

>
>
> On Thu, Jul 21, 2016 at 6:05 PM, Hasunie Adikari  wrote:
>
>> Hi Chamara,
>>
>> Publishing events[1] and Device Monitoring [2] are not related each other.
>> Since Android agent is capable of sending out critical events to WSO2 DAS
>> server,
>>
>
> What is the usage of this in  a real world scenario?
>
>
>
>> There are some configurations to enable in EMM server to publish events
>> in DAS Server. Here [1] Managing Event publishing
>> provides those configurations.
>> [1]
>> https://docs.wso2.com/display/EMM210/Managing+Event+Publishing+with+WSO2+Data+Analytics+Server
>> [2]
>> https://docs.wso2.com/display/EMM210/Monitoring+Devices+via+the+Dashboard
>>
>>
>>
>> On Thu, Jul 21, 2016 at 5:25 PM, Chamara Ariyarathne 
>> wrote:
>>
>>> Hi all,
>>>
>>> How does the EMM DAS Integration [1] and Device Monitoring [2] relate to
>>> each other?
>>>
>>> Are we using the Stream definitions defined in DAS in [2] in the EMM
>>> dashboard in [1]. If so I cannot see the exact mapping of what goes into
>>> DAS and what is available in EMM Dashboard side.
>>>
>>> [1]
>>> https://docs.wso2.com/display/EMM210/Managing+Event+Publishing+with+WSO2+Data+Analytics+Server
>>> [2]
>>> https://docs.wso2.com/display/EMM210/Monitoring+Devices+via+the+Dashboard
>>>
>>> --
>>> *Chamara Ariyarathne*
>>> Associate Technical Lead - QA
>>> WSO2 Inc; http://www.wso2.com/
>>> Mobile; *+94772786766 <%2B94772786766>*
>>>
>>> ___
>>> Dev mailing list
>>> d...@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Hasunie Adikari*
>> Software Engineer
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>> blog http://hasuniea.blogspot.com
>> Mobile:+94713350904
>>
>
>
>
> --
> *Chamara Ariyarathne*
> Associate Technical Lead - QA
> WSO2 Inc; http://www.wso2.com/
> Mobile; *+94772786766 <%2B94772786766>*
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [APIM] [EMM] Adding multiple scopes to a single API resource endpoint

[Dilan Udara Ariyaratne]

Adding the thread to architecture, as this proposes an architectural change
to existing OAuth scopes @ APIM level.

Regards,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Tue, Aug 9, 2016 at 6:30 AM, Dilan Udara Ariyaratne 
wrote:

> Hi Sam,
>
> I also think that Chathura is making a valid point here.
>
> For example, let's take the exact problem that EMM APIs do have currently.
>
> I am considering GET /devices API here. For this API, we do have a
> requirement to compile two responses
> based on the type of user accessing the API.
>
> [1] If he is simply a device owner, he would only get the details of his
> own devices.
> [2] If he is an admin user, he would get the facility of retrieving all
> the devices for that particular tenant.
>
> Since we can currently map only one scope with an API endpoint, that can
> only be useful in verifying whether the particular user is capable
> of accessing the API endpoint or not. This one-to-one level of API scoping
> is not enough in identifying to
> which of the above two responses, the user is authorized to access.
>
> If we had one-to-many level of API scoping, the story is different.
> Then we can add two scopes like, get-owning-devices and get-all-devices
> to the API, let a user access the API first by having either of two scopes.
> Next, we can simply decide what response to be authorized based on which
> of the two scopes, user is having.
>
> Since we do not currently have this facility of one-to-many level of API
> scoping, to achieve the same functionality, we have now
> got to think of other alternatives. Two such alternatives are:
>
> [1] Splitting the GET /devices API to two different APIs such that each
> would cater one of the above two responses
> and bring in the mentioned scopes to each of them separately:
>
> Although this is doable, this seems like duplicating
> the same business logic in multiple APIs again and again.
>
> [2] Introducing a predefined role such as get-all-devices and validate
> what response to be compiled based on that.
> If the user accessing the API has this role, in addition to the assigned
> API scope, he would get the facility of retrieving all the devices
> for that particular tenant or otherwise,only get the details of his own
> devices:
>
> Although this also seems doable, now we are simply in a process of
> complicating permission management side of our application.
> Since the capability of retrieving details of all devices is already
> provided by a predefined role, now we do not have the
> luxury of creating one single role having the same capability + another
> set of capabilities simply because of the fact that a role cannot be
> assigned to another role.
> With this limitation, as of now if an administrator wants to assign a user
> the capability of retrieving details of all devices + another set of
> capabilities,
> he cannot simply do that by assigning the user a single role, instead he
> would need to assign at least two roles. This could get even worse
> if we have the same issue for many other APIs as well. All this is because
> we are violating the fundamental principals
> and trying to authorize capabilities of our application directly via roles
> instead of scopes or permissions.
>
> Cheers,
> Dilan.
>
>
>
> *Dilan U. Ariyaratne*
> Senior Software Engineer
> WSO2 Inc. <http://wso2.com/>
> Mobile: +94766405580 <%2B94766405580>
> lean . enterprise . middleware
>
>
> On Mon, Aug 8, 2016 at 2:08 PM, Chathura Dilan  wrote:
>
>> Hi Sam,
>>
>> Sometimes based on the scopes we might need to authorize the APIs to get
>> different responses.
>>
>> Eg: Facebook scopes [1]. At the login we can send multiple scopes,
>> generate the token and authorize an API based on scopes.
>>
>> It is not possible if only one scope is assigned to one API (resource).
>>
>> IMO scopes should be initially designed when the APIs are designed
>> regardless of the roles that they would be attached to.
>>
>> [1] - https://developers.facebook.com/docs/facebook-login/permissions
>>
>>
>>
>> On Thu, Aug 4, 2016 at 1:41 PM, Milan Perera  wrote:
>>
>>> Hi Sam,
>>>
>>> Thanks for the clarification.
>>>
>>> On Thu, Aug 4, 2016 at 12:34 PM, Sam Sivayogam  wrote:
>>>
>>>> Hi Milan,
>>>>
>>>> In APIM scopes are there to give access controls based on user roles. A
>>>> scope can contain multiple user roles so if you want to block multiple
>>>> role

Re: [Architecture] [CDMF] Authorizing users to add device operations

[Dilan Udara Ariyaratne]

Hi Milan and Ayyoob,

Mapping an application capability directly to a role, only complicates the
permission management side of the same.

As this was initially dealt by a permission, ideally now, this should be
dealt by a scope
since we are now moving from carbon permission based approach to OAuth
scope based approach
for backend authorizations.

But we do have concerns here. I will explain this by taking the exact
problem that EMM APIs do have currently.

I am considering GET /devices API here. For this API, we do have a
requirement to compile two responses
based on the type of user accessing the API.

[1] If he is simply a device owner, he would only get the details of his
own devices.
[2] If he is an admin user, he would get the facility of retrieving all the
devices for that particular tenant.

Since we can currently map only one scope with an API endpoint, that can
only be useful in verifying whether the particular user is capable
of accessing the API endpoint or not. This one-to-one level of API scoping
is not enough in identifying to
which of the above two responses, the user is authorized to access.

Ideally, if we had one-to-many level of API scoping, the story is
different.
Then we can add two scopes like, get-owning-devices and get-all-devices to
the API, let a user access the API first by having either of two scopes.
Next, we can simply decide what response to be authorized based on which of
the two scopes, user is having.

Since we do not currently have the facility of one-to-many level of API
scoping, to achieve the same functionality, we have now
got to think of other alternatives. Three of such alternatives are:

[1] Splitting the GET /devices API to two different APIs such that each
would cater one of the above two responses
and bring in the mentioned scopes to each of them separately:

Although this is doable, this seems like duplicating
the same business logic in multiple APIs again and again.

[2] Introducing the missing scope externally to the existing model and
doing the check with in the same API:

This approach is debatable as it violates the current architecture of OAuth
scopes @ APIM level.

[3] Introducing a predefined role such as get-all-devices and validate what
response to be compiled based on that.
If the user accessing the API has this role, in addition to the assigned
API scope, he would get the facility of retrieving all the devices
for that particular tenant or otherwise, only get the details of his own
devices:

Although this also seems doable, now we are simply in a process of
complicating permission management side of our application.
Since the capability of retrieving details of all devices is already
provided by a predefined role, now we do not have the
luxury of creating one single role having the same capability + another set
of capabilities simply because of the fact that a role cannot be assigned
to another role.
With this limitation, as of now if an administrator wants to assign a user
the capability of retrieving details of all devices + another set of
capabilities,
he cannot simply do that by assigning the user a single role, instead he
would need to assign at least two roles. This could get even worse
if we have the same issue for many other APIs as well. All this is because
we are violating the fundamental principals
and trying to authorize capabilities of our application directly via roles
instead of scopes.

Cheers,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Wed, Aug 3, 2016 at 11:50 AM, Ayyoob Hamza  wrote:

> Milan, Please find my comments inline.
>
> *Ayyoob Hamza*
> *Software Engineer*
> WSO2 Inc.; http://wso2.com
> email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495>
>
> On Wed, Aug 3, 2016 at 8:47 AM, Milan Perera  wrote:
>
>> Hi all,
>>
>> In CDMF, we are currently heading towards OAuth2 scope based
>> authorization mechanism by revamping current carbon permission based
>> authorization mechanism in order to support widely accepted standard for
>> API authorization.
>>
>> As a result, we have to find a new way to do the $subject. So the problem
>> is that when a particular role has the permission to invoke an API endpoint
>> which is used to add an operation to a device, an user in that role can add
>> that operation irrespective of his ownership to that device.
>>
>> For an example, lets say user A owns device D1 and he has the permission
>> to invoke operation add APIs. Since he already has the permission to invoke
>> APIs he can add operations by giving another device id like D2 even though
>> it does not belong to that user.
>>
>> So the solution that was there before to overcome is that, we first check
>> whether a particular user who execute this operation holds the ownership of
>> the device or whether he/she is a device-mgt admin. Saying that, this
>> device-mgt admin is just a carbon permission which a role shoul

Re: [Architecture] [APIM] [EMM] Adding multiple scopes to a single API resource endpoint

[Dilan Udara Ariyaratne]

Hi Nuwan,

The responsibility of this authorization check could be assigned to either
one of the layers that you have mentioned.
Currently, we have assigned this responsibility to API layer of the backend
system.

Cheers,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Tue, Aug 9, 2016 at 8:33 AM, Nuwan Dias  wrote:

> Whose responsibility is it to decide what details to return in the
> response based on the user who's requesting it? Is it the fronting API's
> responsibility to decide this or should it be the core back-end of the
> Application who should be deciding who gets what?
>
> On Tue, Aug 9, 2016 at 6:47 AM, Dilan Udara Ariyaratne 
> wrote:
>
>> Adding the thread to architecture, as this proposes an architectural
>> change to existing OAuth scopes @ APIM level.
>>
>> Regards,
>> Dilan.
>>
>> *Dilan U. Ariyaratne*
>> Senior Software Engineer
>> WSO2 Inc. <http://wso2.com/>
>> Mobile: +94766405580 <%2B94766405580>
>> lean . enterprise . middleware
>>
>>
>> On Tue, Aug 9, 2016 at 6:30 AM, Dilan Udara Ariyaratne 
>> wrote:
>>
>>> Hi Sam,
>>>
>>> I also think that Chathura is making a valid point here.
>>>
>>> For example, let's take the exact problem that EMM APIs do have
>>> currently.
>>>
>>> I am considering GET /devices API here. For this API, we do have a
>>> requirement to compile two responses
>>> based on the type of user accessing the API.
>>>
>>> [1] If he is simply a device owner, he would only get the details of his
>>> own devices.
>>> [2] If he is an admin user, he would get the facility of retrieving all
>>> the devices for that particular tenant.
>>>
>>> Since we can currently map only one scope with an API endpoint, that can
>>> only be useful in verifying whether the particular user is capable
>>> of accessing the API endpoint or not. This one-to-one level of API
>>> scoping is not enough in identifying to
>>> which of the above two responses, the user is authorized to access.
>>>
>>> If we had one-to-many level of API scoping, the story is different.
>>> Then we can add two scopes like, get-owning-devices and get-all-devices
>>> to the API, let a user access the API first by having either of two scopes.
>>> Next, we can simply decide what response to be authorized based on which
>>> of the two scopes, user is having.
>>>
>>> Since we do not currently have this facility of one-to-many level of API
>>> scoping, to achieve the same functionality, we have now
>>> got to think of other alternatives. Two such alternatives are:
>>>
>>> [1] Splitting the GET /devices API to two different APIs such that each
>>> would cater one of the above two responses
>>> and bring in the mentioned scopes to each of them separately:
>>>
>>> Although this is doable, this seems like duplicating
>>> the same business logic in multiple APIs again and again.
>>>
>>> [2] Introducing a predefined role such as get-all-devices and validate
>>> what response to be compiled based on that.
>>> If the user accessing the API has this role, in addition to the assigned
>>> API scope, he would get the facility of retrieving all the devices
>>> for that particular tenant or otherwise,only get the details of his own
>>> devices:
>>>
>>> Although this also seems doable, now we are simply in a process of
>>> complicating permission management side of our application.
>>> Since the capability of retrieving details of all devices is already
>>> provided by a predefined role, now we do not have the
>>> luxury of creating one single role having the same capability + another
>>> set of capabilities simply because of the fact that a role cannot be
>>> assigned to another role.
>>> With this limitation, as of now if an administrator wants to assign a
>>> user the capability of retrieving details of all devices + another set
>>> of capabilities,
>>> he cannot simply do that by assigning the user a single role, instead he
>>> would need to assign at least two roles. This could get even worse
>>> if we have the same issue for many other APIs as well. All this is
>>> because we are violating the fundamental principals
>>> and trying to authorize capabilities of our application directly via
>>> roles instead of scop

[Architecture] [EMM] Support For Device Management Policy Merging

[Dilan Udara Ariyaratne]

Hi Supun,

In order to give you an exact picture of what we ideally need to have when
it comes to device policy management, I would like to take
a combined scenario of both your examples mentioned above.

Consider we have three concrete user defined policies readily available to
be applied to enrolled devices as follows.

[1] Policy A :
Assigned Criteria - All android devices
Configured Features - Wifi, Camera disable

[2] Policy B :
Assigned Criteria - All android, BYOD devices
Configured Features - VPN

[3] Policy C :
Assigned Criteria - All android devices used by Managers
Configured Features - Camera enable

Following picture depicts how these three policies would affect four sets
of devices.


​
[1] Android, COPE devices not used by managers - Only policy A would be
applicable.

[2] Android, BYOD devices not used by managers - Both policy A and B would
be applicable.

[3] Android, COPE devices used by managers - Both policy A and C would be
applicable.
​
[4] Android, BYOD devices used by managers - Policies A, B, and C would be
applicable at the same time.
​
In situation [1], we have only one policy applicable; i.e. Policy A which
can be straight away applied to the mentioned set of devices.
In situation [2], since there exist no conflicts in between the set of
configurations of policy A and B, we can either apply two policies
separately
to the mentioned set of devices or think of one merged policy which
combines the configurations of both A and B to be applied.
Considering the fact that maintenance is easy in keeping one effective
policy for a device, policy merging can be understood as the ideal approach
here.
Even in situation [3] and [4], since policy A and C hold feature wise
configuration conflicts, applying the policies separately does not seem to
be practical and
thinking of resolving the prevailing conflicts and merging all resolved
feature configurations into one effective merged policy seems to be the
ideal approach.

Thus, there is no doubt that "Policy Merging" is the way to go forward.

However, in the current implementation of device policy management, we do
not support policy merging.
As a result, when multiple policies become applicable for a set of devices,
we come into situation of considering that
having multiple policies, applicable for a set of devices as the conflict
and resolving it by choosing one effective policy out of them
based on a pre-assigned priority per each policy.

When compared with policy merging, this approach does not carry any
advantage, but only disadvantages.
For example, let's take the same scenario mentioned above.

In situation [2], even if the two policies (A and B) do not carry any
feature wise conflicts, if B has the higher priority, only B would get
apply to
mentioned set of devices and both WIFI and Camera feature wise
configurations from policy A would be disregarded which should not ideally
be the case.
This disadvantage is even visible in situation [3] and [4].

If an administrator still wants to configure those disregarded
configurations to the applicable set of devices, in such a scenario
with no policy merging support, no matter how complex they are, he or she
would have to reconfigure them back
in the policy with highest priority as well, which is the second
disadvantage.

Not to mention how complex this task would be when there are multiple
overlapping situations and multiple applicable policies wth complex feature
configurations.

Thus, I am saying it again, there is no doubt that "policy merging" is the
way to go forward.

But even with "Policy Merging", it is interesting to see how "Conflict
Resolution" should happen.

In here, a conflict means not multiple policies applicable to the same set
of devices, but different configurations of the same feature
in between multiple applicable policies to the same set of devices.

For example, the different camera configurations of policy A (disable
Camera) and policy C (enable Camera), applicable for Android devices used
by managers.

In order to resolve this conflict, we can of course use the existing policy
level priority model as a good starting point.
Priorities are user-defined and If policy C holds a higher priority than
policy A, then we can consider the specific camera configuration
of policy C (enable Camera) as the ultimately effective camera
configuration of recongnized devices.

Let us first focus on policy merging with conflict resolution using the
existing policy level priority model as stated above
and then think of any improvements to this priority model as future work. Few
improvements that I could suggest at this moment
are as follows.

[1] What if policy A and C have not only one conflicting feature, but many?
For example, let's say we have both camera and sound level configurations
in a conflicting state. When it comes to camera, an adminstrator would like
to give policy C a higher priority, but when it comes to sound, the other
way around. We could not support this level of granu

Re: [Architecture] [IOT] Location Based Data Visualization Tool

[Dilan Udara Ariyaratne]

Hi Dimuth,

Regarding the format of data you require,
Any reason to why we are collecting time_stamp information separately out
of location data?

Shouldn't it be one text file and be in the following way?
(sensor_id, x-coordinate , y-coordinate, time_stamp)

Thanks.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Thu, Nov 10, 2016 at 3:45 PM, Dimuth Menikgama  wrote:

> Hi,
> I am an intern currently working on a project to develop a data
> visualization and analyzing tool that can be used to track the motion
> patterns of people inside a building with respect to time.
> As the sample dataset, I use the public dataset released by Mitsubishi
> Electric Research Laboratories mentioned in [1]. Apart from the web
> application I'm currently using WSO2 MS4J framework to get data through
> REST API.
> Tool is capable of taking data as text files. When a dataset is published
> to the tool, it can be used to do things such as
>
> 1. View the locations of triggered sensors in a given time period in the
> building map.
> 2. Play the data in a time range to check movements of people in the
> building map.
> 3. View the relative traffic or busyness of each sensor.
> 4. View the triggering frequencies for a given time range.
> 5. Typical Scenario of a given hour
>
> Moreover this tool can be used to visualize any location based data set
> that provides two files in the format of (sensor_id, time_stamp) and
> (sensor_id,x-coordinate , y-coordinate).
>
> I'm currently studying on how this can be integrated in to WSO2 IOT server
> to visualize location based data.
> [1]https://sites.google.com/a/drwren.com/wmd/
> 
>
> Regards,
> Dimuth Menikgama.
>
> ___
> 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] Implementation of c5 multitenancy

[Dilan Udara Ariyaratne]

Hi Lasantha,

I did go through the list of REST APIs that you have defined in the swagger
doc.
But I have not found any API for doing an update to an existing tenant as
well as deactivation.

Are we skipping those capabilities found in C4 based multi-tenancy, here ?

Regards,
Dilan.


*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Wed, Nov 16, 2016 at 11:12 AM, Imesh Gunaratne  wrote:

> On Tue, Nov 15, 2016 at 5:00 PM, Lasantha Samarakoon 
> wrote:
>
>> Hi all,
>>
>> We are currently working on implementing multitenancy for Carbon-5 based
>> products. In order to implement this we are creating Kubenetes namespaces
>> for each tenant (namespaces provides isolation between tenants and the same
>> approach has been used by WSO2 cloud as well).
>>
>> In most of the customer use cases, the tenants can be defined at the
>> deployment time, but in order to cater SaaS requirements the tenants has to
>> be created dynamically. To achieve this we have built a REST API using
>> Microservices[1] (please find the attached Swaggger definition of the API).
>> This API provides a endpoints for basic CRUD operations on tenants on
>> Kubenetes cluster.
>>
>
> ​Great work Lasantha! Can you please share the API resource/method list in
> text​
>
> ​format?​
>
>>
>> So in order to proceed with this what are the options to integrate this
>> with the platform? Do we need to implement a UUF component and/or a CLI as
>> well?
>>
>
> ​May be we can write a bash script first and later move to a CLI/UI.
>
> ​I think we would also need to expose methods for automating the
> deployment process once tenants/namespaces are created. Each WSO2 product
> would release required K8S defnitions together with the product releases.
>
> ​Thanks​
>
>>
>> [1] https://github.com/lasanthaS/wso2-carbon5-multitenancy-api
>>
>>
>> Regards,
>>
>> *Lasantha Samarakoon* | Software Engineer
>> WSO2, Inc.
>> #20, Palm Grove, Colombo 03, Sri Lanka
>> Mobile: +94 (71) 214 1576
>> Email:  lasant...@wso2.com
>> Web:www.wso2.com
>>
>> lean . enterprise . middleware
>>
>
>
>
> --
> *Imesh Gunaratne*
> Software Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>
> ___
> 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] Carbon C5 - Server Configuration Model

[Dilan Udara Ariyaratne]

Hi Danesh,

Why are we going to duplicate all user-settable, default configuration
values both at yaml level as well as Java bean level ?
Cannot we make the yaml as the one and only reference point ?

Thanks,
Dilan.


*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Tue, Nov 22, 2016 at 10:19 AM, SajithAR Ariyarathna 
wrote:

> Hi Danesh,
>
> Do we really need the @Ignore annotation? IMO, we can ignore frields wich
> are not marked with @Element annotation, thus we don't need a separate
> annotation.
>
> Thanks.
>
> On Mon, Nov 21, 2016 at 11:32 PM, Danesh Kuruppu  wrote:
>
>> Hi all,
>>
>> In Carbon C5, we are going to introduce new global configuration model
>> where we have only one configuration file for all server configurations.
>> So that user have to maintain only one config file for a server.
>>
>> With New Configuration Model,
>>
>>- Global configuration file (deployment.yaml) includes minimal sets
>>of configurations which need to override very often by default (e.g: 
>> server
>>ports etc).
>>- All user settable configurations must have default values and they
>>are burnt into compile codes.
>>- Any default configuration can overridden by adding the particular
>>configuration to the global configuration file(deployment.yaml).
>>- Defining all configurations in the configuration file in not
>>required. add only if we need to override the default value.
>>- If configurations are not specified in the configuration file,
>>values defined in the bean class will apply by default.
>>
>> In global configuration file (deployment.yaml),
>>
>>- Each component will have their own configurations with a unique
>>namespace (e.g: wso2.carbon, wso2.transports.netty etc) and it will be a
>>fragment of deployment.yaml file. Please find the sample file below.
>>- At runtime, the relevant config bean will be generated by
>>overriding the default values specified in bean class with values 
>> mentioned
>>in deployment.yaml file.
>>
>> Sample file looks like,
>>
>>   # Carbon Configuration Parameters
>> wso2.carbon:
>>   id: carbon-kernel
>>   version: 5.2.0-SNAPSHOT
>>   ports:
>> offset: 0
>>   ...
>>
>>   # Netty Transport Configurations
>> wso2.transports.netty:
>>   listeners:
>> - id: msf4j-http
>>   host: 127.0.0.1
>>   port: 8080
>>   bossThreadPoolSize: 2
>>   workerThreadPoolSize: 250
>>   parameters:
>> - name: "executor.workerpool.size"
>>   value: 60
>>
>> ...
>>
>> Along with the above design, we are going to introduce new annotation
>> model to the configuration beans. So each component will have its
>> configuration defined as one or more Java beans annotated with the
>> following annotations
>>
>>- *org.wso2.carbon.kernel.annotations.Configuration* - *Class level
>>annotation, This corresponds to a configuration bean to be used by a
>>component*
>>- *org.wso2.carbon.kernel.annotations.Element* - *Field level
>>annotation, This corresponds to a fields of the class*
>>- *org.wso2.carbon.kernel.annotations.Ignore* - *Field level
>>annotation, This is to specify that field needs to be ignored when the
>>configuration is generated*
>>
>> Sample bean class looks like,
>>
>> @Configuration(namespace = "wso2.carbon", description = "Carbon 
>> Configuration Parameters")
>> public class CarbonConfiguration {
>>
>> @Element(description = "value to uniquely identify a server", required = 
>> true)
>> private String id = "carbon-kernel";
>>
>> @Element(description = "server name")
>> private String name = "WSO2 Carbon Kernel";
>>
>> @Element(description = "server version")
>> private String version = "5.2.0";
>>
>> @Ignore
>> private String tenant = Constants.DEFAULT_TENANT;
>>
>> ...
>>
>> }
>>
>> So we are going to generate the relevant segment of the configuration
>> file(for documentation purposes) automatically at compile time by reading
>> above annotations and default values.
>>
>> If anyone needs to override the default value, He needs to copy the
>> particular segment of the configuration to the deployment.yaml and change
>> the value.
>>
>> Appreciate your input on this.
>>
>> Thanks
>> --
>>
>> *Danesh Kuruppu*
>> Senior Software Engineer | WSO2
>>
>> Email: dan...@wso2.com
>> Mobile: +94 (77) 1690552
>> Web: WSO2 Inc 
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Sajith Janaprasad Ariyarathna
> Software Engineer; WSO2, Inc.;  http://wso2.com/
> 
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>

Re: [Architecture] [IoT] Simplifying IoT device type plugin with a descriptor

[Dilan Udara Ariyaratne]

Hi Ayoob,

Can you elaborate more on this implementation with its internals ?
Does this mean we can basically have a ready-to-use device plug-in
implementation, just by configuring a descriptor file ?

Thanks,
Dilan.


*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Wed, Oct 26, 2016 at 8:11 AM, Sumedha Rubasinghe 
wrote:

> Pretty useful. This also makes the device plugins deployable without
> restarting the server.
>
> I believe we can extend the same to write hot deployable device plugins
> using Java (no OSGi).
>
> On Tue, Oct 25, 2016 at 9:02 PM, Ayyoob Hamza  wrote:
>
>> Hi All,
>>
>> Current structure for device type plugin for WSO2 IoT looks like
>> following:
>>
>> devicetype-plugin
>>  | - device manager extension (An OSGi service )
>>  | - api (jax-rs)
>>  | - UI
>>  | - analytics (descriptors - deployer)
>>
>>
>> However, what goes inside device manager extension component is pretty
>> much a boiler plate code that can be replaced by a descriptor. This is
>> common for all the plugins (eg: Android, Windows, Virtual Firalarm,
>> Raspberypi, Android Sense ...) we have written so far.
>>
>> But the ability to write Java based device manager extension can be
>> useful @ times where custom behaviour is needed.
>>
>> So I have done a PoC that will allow both of these approaches to be
>> supported when writing a device type plugin.
>>
>> This concept is previously discussed in [1] too. A sample descriptor is
>> in [2].
>>
>> [1] [Architecture] [CDM-F] "Descriptor"-driven plug-ins for CDM-F
>> [2] https://github.com/ayyoob/carbon-device-mgt/blob/deploye
>> r/components/device-mgt-extensions/org.wso2.carbon.device.mg
>> t.extensions.device.type.deployer/src/test/resources/sample.xml
>> [3] https://github.com/ayyoob/carbon-device-mgt/tree/deploye
>> r/components/device-mgt-extensions/org.wso2.carbon.device.mg
>> t.extensions.device.type.deployer
>>
>> Thanks,
>> *Ayyoob Hamza*
>> *Software Engineer*
>> WSO2 Inc.; http://wso2.com
>> email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> /sumedha
> m: +94 773017743
> b :  bit.ly/sumedha
>
> ___
> 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] Restructuring Device Type Plugins for IoT

[Dilan Udara Ariyaratne]

Hi Ruwan,

Why would not analytics be inside a particular device type ?, this is in
fact the idea provided in [1].
And also, if these Input/Output transport adapters and extensions for
MB/APP-M are in common to any device type,
cannot we move them down to carbon-device-mgt platform layer ?

References :
[1] [Architecture] [IoT] Simplifying IoT device type plugin with a
descriptor

Thanks,
Dilan.


*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Tue, Nov 22, 2016 at 11:58 AM, Ruwan Yatawara  wrote:

> Hi All,
>
> In line with the changes that have been done to introduce the device-type
> descriptor in [1], I have gone ahead and done some refactoring to the
> existing plugins to standardise + make them self-contained. Following are a
> list of changes introduced.
>
>- Mobile Base plugin is no more :
>   - Earlier windows/ios/android plugins relied on a shared component
>   called the base plugin to include common functionality. This consisted 
> of
>   an OSGi component + a jaggery application. This made the 3 plugins
>   interdependent. With the new structure, all 3 plugins would be
>   self-contained and they would pack all the necessary backend 
> functionality
>   within themselves. The shared jaggery application has been broken down 
> to 3
>   parts android-web-agent, windows-web-agent and ios-web-agent. Each
>   application would get deployed and undeployed with the corresponding 
> device
>   type.
>- Each device type would be injecting the necessary UI units to a
>page/template unit contained inside of a the cdmf framework.
>- Each device type would be declaring its features/sensors and
>relevant tables as per [1]
>- Samples renamed to plugins and samples-deployer.xml renamed to
>plugins-deployer.xml
>- Input/Output transport adapters and extensions for MB/APPM moved to
>a separate section called extensions inside the plugins repo.
>- Analytics scripts moved to analytics section of the plugins repo
>- All the device types have now been moved to the device-types folder,
>as the EMM release is still on going, to make merging of ongoing
>development work easier we have left the mobile plugins as it is. In the
>future, once the EMM release concludes we will be moving the same inside
>the device-types folder.
>
> In summary, as per the changes, the carbon-device-mgt-plugins repo
> structure is as follows. (We may have to break this up in to three
> different repos, in the future if need be)
>
> carbon-device-mgt-plugins
>
> | analytics
>
> | extensions
>
> | device-types
>
> Note that when trying out the IoT distribution, in order to install device
> type plugins, from the server home, run the following command.
>
> *mvn clean install -f plugins/plugins-deployer.xml  *
>
> You may change the plugin-deployer.xml to include/exclude the plugins as
> required.
>
> [1] - [Architecture] [IoT] Simplifying IoT device type plugin with a
> descriptor
>
> Thanks and Regards,
>
> Ruwan Yatawara
>
> Associate Technical Lead,
> WSO2 Inc.
>
> email : ruw...@wso2.com
> mobile : +94 77 9110413
> blog : http://ruwansrants.blogspot.com/
>   https://500px.com/ruwan_ace
> www: :http://wso2.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] Carbon C5 - Server Configuration Model

[Dilan Udara Ariyaratne]

Hi Danesh,

Referring to the following,

@Configuration(namespace = "wso2.carbon", description = "Carbon
Configuration Parameters")
public class CarbonConfiguration {

@Element(description = "value to uniquely identify a server",
required = true)
private String id = "carbon-kernel";

@Element(description = "server name")
private String name = "WSO2 Carbon Kernel";

@Element(description = "server version")
private String version = "5.2.0";

...

}

In a developer's perspective, it would be more meaningful to define any
default value as a separate CONSTANT in the code level and
set any bean property similar to above with such a constant for better
readability.

For ex:

@Configuration(namespace = "wso2.carbon", description = "Carbon
Configuration Parameters")
public class CarbonConfiguration {

@Element(description = "value to uniquely identify a server",
required = true)
private String id = CarbonConfigurationConstants.DEFAULT_ID;
@Element(description = "server name")
private String name = CarbonConfigurationConstants.DEFAULT_NAME;
@Element(description = "server version")
private String version = CarbonConfigurationConstants.DEFAULT_VERSION;
...
}

In the meantime, also have the following question.

If all user-configurable properties are not readily available in the .yaml
file by default, how would a user know which
properties are configurable and which are not ?

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Mon, Nov 28, 2016 at 10:58 AM, Danesh Kuruppu  wrote:

> Hi Rukshan,
>
> No. We are going to include this in next kernel release(5.2.0).
>
> Thanks
> Danesh
>
> On Mon, Nov 28, 2016 at 10:26 AM, Rukshan Premathunga 
> wrote:
>
>> Hi Danesh,
>>
>> Is this feature is available now? if so can you mention the kernel
>> version please?
>>
>> Thanks and Regards
>>
>> On Tue, Nov 22, 2016 at 12:22 PM, Danesh Kuruppu  wrote:
>>
>>> Hi Nuwan,
>>>
>>> Can you also provide an example bean class for the netty listener? That
 would make it clear how the bean class and its nested classes would be
 annotated when array elements come into play.

>>>
>>> Please check TransportsConfiguration sample below. We need to mention
>>> the default values of an array or collection in class constructor as below.
>>>
>>> @Configuration(namespace = "wso2.transports.netty", description = "Netty 
>>> Transport Configurations")
>>> public class TransportsConfiguration {
>>>
>>> //default values of an array or collection need to mention in class 
>>> constructor
>>> public TransportsConfiguration() {
>>> ListenerConfiguration listenerConfiguration = 
>>> ListenerConfiguration();
>>> listenerConfigurations = new HashSet<>();
>>> listenerConfigurations.add(listenerConfiguration);
>>>
>>> SenderConfiguration senderConfiguration = SenderConfiguration();
>>> senderConfigurations = new HashSet<>();
>>> senderConfigurations.add(senderConfiguration);
>>>
>>> transportProperties = new HashSet<>();
>>> }
>>>
>>> @Element(description = "transport properties")
>>> private Set transportProperties = 
>>> Collections.EMPTY_SET;
>>>
>>> @Element(description = "listener configurations")
>>> private Set listenerConfigurations;
>>>
>>> @Element(description = "sender configurations")
>>> private Set senderConfigurations;
>>>
>>>  }
>>>
>>>
 Have we thought about secure vault too?

>>>
>>> Yes, we resolve all secure valut values and system property values in
>>> deployment.yaml before generating bean class.
>>>
>>> Thanks
>>> --
>>>
>>> *Danesh Kuruppu*
>>> Senior Software Engineer | WSO2
>>>
>>> Email: dan...@wso2.com
>>> Mobile: +94 (77) 1690552
>>> Web: WSO2 Inc 
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Rukshan Chathuranga.
>> Software Engineer.
>> WSO2, Inc.
>>
>
>
>
> --
>
> *Danesh Kuruppu*
> Senior Software Engineer | WSO2
>
> Email: dan...@wso2.com
> Mobile: +94 (77) 1690552
> Web: WSO2 Inc 
>
>
> ___
> 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] Carbon C5 - Server Configuration Model

[Dilan Udara Ariyaratne]

Hi Ruwan,

The purpose of suggesting to move these default values to CONSTANTS is as
follows.
Instead of simply setting a raw value to a bean property, by setting it up
via a CONSTANT with a meaningful name like DEFAULT_VERSION brings
the message that unless you set an alternative value via the yaml file, a
default value will be set via this CONSTANT.

It's true that a property like version would change from one release to
another. But it remains as a CONSTANT for a particular release which we
need to understand in my opinion.

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Tue, Nov 29, 2016 at 7:27 AM, Ruwan Abeykoon  wrote:

> Hi Dilan,
> -1 moving the default value in the properties to constants, since they are
> not constants. Most of the values within those defaults will be changed
> over the time, when we learn more about the system behavior, over many
> release cycles.
>
> For the propose of readability and maintainability the original code looks
> better than the suggestion.
>
> i.e
> @Element(description = "server version")
> private String version = "5.2.0";
>
> is better than
> @Element(description = "server version")
> private String version = CarbonConfigurationConstants.DEFAULT_VERSION;
>
> Cheers,
> Ruwan
>
> On Mon, Nov 28, 2016 at 9:08 PM, Dilan Udara Ariyaratne 
> wrote:
>
>> Hi Danesh,
>>
>> Referring to the following,
>>
>> @Configuration(namespace = "wso2.carbon", description = "Carbon 
>> Configuration Parameters")
>> public class CarbonConfiguration {
>>
>> @Element(description = "value to uniquely identify a server", required = 
>> true)
>> private String id = "carbon-kernel";
>>
>> @Element(description = "server name")
>> private String name = "WSO2 Carbon Kernel";
>>
>> @Element(description = "server version")
>> private String version = "5.2.0";
>>
>> ...
>>
>> }
>>
>> In a developer's perspective, it would be more meaningful to define any
>> default value as a separate CONSTANT in the code level and
>> set any bean property similar to above with such a constant for better
>> readability.
>>
>> For ex:
>>
>> @Configuration(namespace = "wso2.carbon", description = "Carbon 
>> Configuration Parameters")
>> public class CarbonConfiguration {
>>
>> @Element(description = "value to uniquely identify a server", required = 
>> true)
>> private String id = CarbonConfigurationConstants.DEFAULT_ID;
>> @Element(description = "server name")
>> private String name = CarbonConfigurationConstants.DEFAULT_NAME;
>> @Element(description = "server version")
>> private String version = CarbonConfigurationConstants.DEFAULT_VERSION;
>> ...
>> }
>>
>> In the meantime, also have the following question.
>>
>> If all user-configurable properties are not readily available in the
>> .yaml file by default, how would a user know which
>> properties are configurable and which are not ?
>>
>> Thanks,
>> Dilan.
>>
>> *Dilan U. Ariyaratne*
>> Senior Software Engineer
>> WSO2 Inc. <http://wso2.com/>
>> Mobile: +94766405580 <%2B94766405580>
>> lean . enterprise . middleware
>>
>>
>> On Mon, Nov 28, 2016 at 10:58 AM, Danesh Kuruppu  wrote:
>>
>>> Hi Rukshan,
>>>
>>> No. We are going to include this in next kernel release(5.2.0).
>>>
>>> Thanks
>>> Danesh
>>>
>>> On Mon, Nov 28, 2016 at 10:26 AM, Rukshan Premathunga 
>>> wrote:
>>>
>>>> Hi Danesh,
>>>>
>>>> Is this feature is available now? if so can you mention the kernel
>>>> version please?
>>>>
>>>> Thanks and Regards
>>>>
>>>> On Tue, Nov 22, 2016 at 12:22 PM, Danesh Kuruppu 
>>>> wrote:
>>>>
>>>>> Hi Nuwan,
>>>>>
>>>>> Can you also provide an example bean class for the netty listener?
>>>>>> That would make it clear how the bean class and its nested classes would 
>>>>>> be
>>>>>> annotated when array elements come into play.
>>>>>>
>>>>>
>>>>> Please check TransportsConfiguration sample below. We need to mention
>

Re: [Architecture] FCM for Android

[Dilan Udara Ariyaratne]

Hi Inosh and All,

Having following questions regarding this feature and the enabling
technology :

[1] Are we bringing FCM as a replacement for GCM or as another Push
Notification Mechanism that can be enabled apart from GCM ?
[2] If as a replacement, what advantages are there with FCM over GCM ?
[3] When it comes to Google-services.json, It seems that it is required to
obtain a separate Google-services.json + FCM server token per each
production deployment and
 compile the agent embedding this file. If that's the case here, cannot
we achieve the same without letting a user to compile the source ? what if
the device could retrieve this file
 at the time of enrollment with the server and we provide this
configuration to the server via platform configurations ?
[4] And at last a general question, architecturally, how FCM differs from
GCM ?

Cheers,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Wed, Nov 30, 2016 at 3:25 PM, Inosh Perera  wrote:

> ​Hi all,
>
> Following is the architecture of FCM implementation of Android agent of
> IoT/EMM. Firebase cloud messaging(FCM) is a push notification mechanism
> introduced by Google for app developers to send notifications to devices.
> Prior to FCM, EMM used Google cloud messaging(GCM) which was the earlier
> standard for sending notifications to devices.
> Coming from GCM to FCM, major changes in architecture are in the Agent
> side implementation compared to server side implementation of EMM. In case
> of EMM, only a wake up call is sent to a device asking the device to
> contact the EMM server to fetch new pending operation. Following is a
> simple illustration of how the mechanism works with FCM.
>
>
>
> --
>
>
> *Prerequisites*
> Using firebase console, a new project needs to be created which will
> provide the user with Google-services.json file and a firebase cloud
> messaging token. Google-services.json contains authentication details
> required  to communicate with the Google FCM server. This file needs to be
> added to Android agent source code's root folder as defined by Google and
> will be later be used to communicate with FCM server. Firebase cloud
> messaging token has to be available to IOT/EMM server and this token acts
> as the API key when sending messages to FCM server.
>
> *Things that happen one time*
> 1. Registration details sending
>
> When the agent starts up for the very first time, since the FCM related
> services are implemented in the agent and the Google-services.json is
> available, FCM services begin an automatic registration process with the
> FCM server. This call is hidden from the developers to avoid the earlier
> GCM complexities of handling the registration with the GCM server manually.
> Device will send the necessery details to FCM server extracted from
> Google-services.json to register it-self with the FCM server.
>
> 2. FCM instance ID token
>
> FCM server will keep a record of the device and issue a token for the
> device, which will be returned and will be automatically persisted by the
> FCM libraries in the Agent.
>
> 3. Send FCM instance ID token to EMM/IoT server
>
> Agent will retrieve the persisted token and send it to EMM/IoT server, so
> that it can send commands to FCM referring the instance ID token of the
> device.
>
> Now the server has all the details that are necessery to send a message to
> the device.
>
> *Sending a wake up call to device*
> 4. Whenever a new operation is added against a specific device, IoT/EMM
> server will send a wake up call to FCM server with the Firebase cloud
> messaging token and FCM instance ID token. Firebase cloud messaging token
> will show that the IoT/EMM server has permission to use FCM services and
> FCM instance ID token specifies to which device the wake up must be sent.
> 5. FCM server send the wake up call to the device and the Android agent
> listens to incoming FCM messages.
> 6. At this point FCM communication is over and as a response to the wake
> up, the Agent will poll the IoT/EMM server to fetch any pending operations
> such as ring and will execute it.
>
> Regards,
> Inosh
>
> Inosh Perera
> Senior Software Engineer, WSO2 Inc.
> Tel: 077813 7285, 0785293686
>
> ___
> 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 WSO2 Enterprise Mobility Manager 2.2.0 RC2

[Dilan Udara Ariyaratne]

Hi All,

Tested overall functionality of device enrollment, assignment of
Operations, Policy enforcement and Device Statistics with both
admin and non-admin users of limited permissions.

Found no bugs.

Hence, I am putting my vote as
[+1] - Stable - go ahead and release.

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Thu, Dec 1, 2016 at 3:14 PM, Geeth Munasinghe  wrote:

> Hi all,
>
> We have received 9 +1s and 0 -1s so far for the EMM 2.2.0-RC2. We are
> closing the vote now and proceed with the release.
>
> Thanks
> Geeth
>
> On Thu, Dec 1, 2016 at 2:52 PM, Megala Uthayakumar 
> wrote:
>
>> Hi All,
>>
>> I tested the SSO scenario in super-tenant mode and tenant mode as admin.
>> Found no any major issues.
>>
>> Hence,
>> [+] - stable - go ahead and release.
>>
>> Thanks.
>>
>> Regards,
>> Megala.
>>
>> On Thu, Dec 1, 2016 at 11:36 AM, Hasunie Adikari 
>> wrote:
>>
>>> Hi All,
>>>
>>> I have tested following scenarios.
>>>
>>> 1. Windows Device enrollment.
>>> 2. Add windows operations
>>> 3. Create windows policy and apply to the device.
>>> 4. Edit Windows policy and done apply changes.
>>> 5. Create more policies and set priority and then apply to the device.
>>> 6. tested notification pane.
>>>
>>> [+] - stable - go ahead and release.
>>>
>>> Thanks
>>> Hasunie
>>>
>>> On Thu, Dec 1, 2016 at 10:41 AM, Geeth Munasinghe 
>>> wrote:
>>>
 Hi all,

 Tested following scenarios.


1. Android device enrollment.
2. User and role creation and assigning permission.
3. Sending email with user invite.
4. Create/Edit policy
5. Applying policy to device.
6. Reapplying changed policy.
7. Add few operations.

 [+] - Stable - go ahead and release.

 Thanks
 Geeth

 On Thu, Dec 1, 2016 at 10:26 AM, Inosh Perera  wrote:

> Hi all,
>
> I have tested FCM together with Android enrollment and operation
> sending, functionality works well.
>
> [+] Stable - go ahead and release
>
> Regards,
> Inosh
>
> On Wed, Nov 30, 2016 at 3:55 PM, Charitha Goonetilleke <
> charit...@wso2.com> wrote:
>
>> Hi All,
>>
>> I have enrolled Android device and tested basic functionality.
>>
>> [+] Stable - go ahead and release
>>
>> Thanks & Regards,
>> /charithag
>>
>> On Tue, Nov 29, 2016 at 9:50 PM, Harshan Liyanage 
>> wrote:
>>
>>> Hi Devs,
>>>
>>> This is the release candidate of WSO2 Enterprise Mobility Manager
>>> 2.2.0.
>>>
>>> Please download EMM 2.2.0 RC2 and test the functionality and vote.
>>> Vote will be open for 72 hours or as needed.
>>> Know issues: https://wso2.org/jira/issues/?filter=13384
>>> Fixes provided : https://wso2.org/jira/issues/?filter=13582
>>> 
>>>
>>> Source & binary distribution files:
>>> https://github.com/wso2/product-emm/releases/tag/v2.2.0-RC2
>>>
>>> The tag to be voted upon:
>>> https://github.com/wso2/product-emm/tree/release-2.2.0-RC2
>>>
>>>
>>> [+] Stable - go ahead and release
>>> [-]  Broken - do not release (explain why)
>>>
>>> Thanks and Regards,
>>>
>>>
>>> Harshan Liyanage
>>> EMM/IoT TG
>>> Mobile: *+94765672894*
>>> Email: hars...@wso2.com
>>> Blog : http://harshanliyanage.blogspot.com/
>>> *WSO2, Inc. :** wso2.com *
>>> lean.enterprise.middleware.
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Charitha Goonetilleke*
>> Software Engineer
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: +94 77 751 3669 <%2B94777513669>
>> Twitter:@CharithaWs , fb: charithag
>> , linkedin: charithag
>> 
>>
>> 
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Inosh Perera
> Senior Software Engineer, WSO2 Inc.
> Tel: 077813 7285, 0785293686
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


 --

 *G. K. S. Munasinghe*
 *Senior Software Engineer,*
 *WSO2, Inc. http://wso2.com  *
 *lean.enterprise.middleware.*

 email: ge...@wso2

Re: [Architecture] Dashboard Component Permission Model

[Dilan Udara Ariyaratne]

Hi Tania,

Are we going to keep one dashboard permission or multiple ? The reason that
I am asking this is if we can allow multiple, we can
separate out access for critical functions like dashboard view, edit and
manage via those permissions.

Also, have you looked into the scenario of restricting access of dashboards
for different users ?
AFAIU, it's only by having multiple permissions, we can do this.

Cheers,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Wed, Jan 4, 2017 at 1:56 PM, Johann Nallathamby  wrote:

>
>
> On Wed, Jan 4, 2017 at 1:04 PM, Nipuna Chandradasa 
> wrote:
>
>> [+adding Sajith]
>> Please find the my questions and suggestions in line
>>
>>>
> Based on the above model we have following questions.
> 1. How can we call the isAuthorized method from dashboard component ?
>

>> Isn't this isAuthorized method should be exposed through UUF as dashboard
>> component is basically a UUF component? It might not be good to expose a
>> such a functionality through a UI framework but it'll be lot cleaner than
>> invoking a OSGI service inside our component.
>>
>
> Once you login using CAAS (carbon authentication and authorization
> service) components you will get a CAAS User object [1]. This User object
> is a proxy object which can be used to call all the underlying identity
> store and authorization store methods. Ideally you will store this User
> object in the user's logged in session and perform those operations when
> necessary.
>
> [1] https://github.com/wso2/carbon-security/blob/release-
> 1.0.0-m2/components/org.wso2.carbon.security.caas/src/main/
> java/org/wso2/carbon/security/caas/user/core/bean/User.java
>
> Regards,
> Johann.
>
>
>
>>
>>
>>> 2. Is there any standard / approval process for permission strings ?
>
 3. How should we register the permissions dynamically at the time of
> creating a dashboard?
>
> Appreciate your insight.
>


>> Thank you,
>>
>> --
>> Nipuna Marcus
>> *Software Engineer*
>> WSO2 Inc.
>> http://wso2.com/ - "lean . enterprise . middleware"
>> Mobile : +94 (0) 713 667906 <+94%2071%20366%207906>
>> nipu...@wso2.com
>>
>
>
>
> --
> Thanks & Regards,
>
> *Johann Dilantha Nallathamby*
> Technical Lead & Product Lead of WSO2 Identity Server
> Governance Technologies Team
> 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
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [C5] [Carbon-Feature-Plugin] Dynamic Creation of carbon.product via a Template

[Dilan Udara Ariyaratne]

Hi Folks,

In the process of building C5, we currently require carbon.product for the
following goals.
[1] publish-product
[2] generate-runtime

This file maintains current version of the carbon kernel to be utilized by
"carbon-feature-plugin" in the build process.
Keeping this value in carbon.product prevents the kernel from been
auto-released as it requires manual intervention to bump
version values as necessary during the release process.

In order to solve this issue, we are currently in the process of improving
Carbon-Feature-Plugin to dynamically create this file during build time
using
a template where the necessary version value information is read from
corresponding distribution pom file.

In order to support backward compatibility, we will still maintain the
original approach of keeping a carbon.product file somewhere appropriate
in the distribution folder and read it accordingly when
 tag is present in the pom file.

In the meantime, as the way to go forward, we will introduce the following.

Carbon-Feature-Plugin will be updated to read version and other optional
values that were originally persisted in the file, from the pom itself.
After reading these values, plugin will dynamically create the
carbon.product which will then be taken into reference by underlying
eclipse.tycho plugin as in the usual way of execution.

WDYT ?

Thank You.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5] [Carbon-Feature-Plugin] Dynamic Creation of carbon.product via a Template

[Dilan Udara Ariyaratne]

Hi Azeez,

Even with the pom based approach (as noted by Kishanthan), we do not have
the luxury of totally getting rid of this file, carbon.product
since both underlying, but external tycho and equinox launcher plug-ins
used by our carbon-feature-plugin require this file as an input.

So IMO, the only improvement that we can introduce here is supporting
templated-dynamic-creation of the file at carbon-feature-plugin level
using the standard carbon kernel version values available in the
distribution pom.

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Mon, Jan 23, 2017 at 7:33 AM, Kishanthan Thangarajah  wrote:

>
>
> On Fri, Jan 20, 2017 at 5:57 PM, Afkham Azeez  wrote:
>
>> I would suggest totally getting rid of it.
>>
>
> To maintain backward compatibility of the plugin, we need to have the file
> based supported. But from next major release of the plugin, we can remove
> the usage of this file and use the pom based approach only.
>
> Thanks,
>
>>
>> On Fri, Jan 20, 2017 at 5:24 PM, KasunG Gajasinghe 
>> wrote:
>>
>>>
>>> +1. carbon.product file hasn't really been used by the products. So, +1
>>> to make it optional.
>>>
>>> On Fri, Jan 20, 2017 at 3:06 PM, Dilan Udara Ariyaratne >> > wrote:
>>>
>>>> Hi Folks,
>>>>
>>>> In the process of building C5, we currently require carbon.product for
>>>> the following goals.
>>>> [1] publish-product
>>>> [2] generate-runtime
>>>>
>>>> This file maintains current version of the carbon kernel to be utilized
>>>> by "carbon-feature-plugin" in the build process.
>>>> Keeping this value in carbon.product prevents the kernel from been
>>>> auto-released as it requires manual intervention to bump
>>>> version values as necessary during the release process.
>>>>
>>>> In order to solve this issue, we are currently in the process of
>>>> improving Carbon-Feature-Plugin to dynamically create this file during
>>>> build time using
>>>> a template where the necessary version value information is read from
>>>> corresponding distribution pom file.
>>>>
>>>> In order to support backward compatibility, we will still maintain the
>>>> original approach of keeping a carbon.product file somewhere appropriate
>>>> in the distribution folder and read it accordingly when
>>>>  tag is present in the pom file.
>>>>
>>>> In the meantime, as the way to go forward, we will introduce the
>>>> following.
>>>>
>>>> Carbon-Feature-Plugin will be updated to read version and other
>>>> optional values that were originally persisted in the file, from the pom
>>>> itself.
>>>> After reading these values, plugin will dynamically create the
>>>> carbon.product which will then be taken into reference by underlying
>>>> eclipse.tycho plugin as in the usual way of execution.
>>>>
>>>> WDYT ?
>>>>
>>>> Thank You.
>>>>
>>>> *Dilan U. Ariyaratne*
>>>> Senior Software Engineer
>>>> WSO2 Inc. <http://wso2.com/>
>>>> Mobile: +94766405580 <%2B94766405580>
>>>> lean . enterprise . middleware
>>>>
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> *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 <+1%20650-745-4499>, 77 678 0813
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Afkham Azeez*
>> Senior Director, Platform Architecture; WSO2, Inc.; http://wso2.com
>> Member; Apache Software Foundation; http://www.apache.org/
>> * <http://www.apache.org/>*
>> *email: **az...@wso2.com* 
>> * cell: +94 77 3320919 <+94%2077%20332%200919>blog: *
>

Re: [Architecture] [IS 6.0.0] Email Management Component Implementation

[Dilan Udara Ariyaratne]

+1 to Sagara's point of view.

It would be ideal if we can have one generic feature across the platform in
sending rich-human-undersdanble messages such as E-mails and SMSs,
so that it would cater any product having associated requirements at a
higher level.

@Lahiru, AFAIR, most recent EMM 2.2.0 and upcoming IoT releases have an
in-built email sending feature at the product level itself to support
associated requirements with device management.
The decision to write an inbuilt email-sending feature with template
support (using Velocity template engine) was made because of the fact that
we never had one generic feature across the platform to achieve the same.

Hope we can avoid any such duplication of the same capability across
multiple products, once this feature is done.

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Mon, Jan 23, 2017 at 8:57 AM, Sagara Gunathunga  wrote:

>
> Sending E-mails is a very generic feature thus we have to make sure
> whatever we do here can be reuse within the platform not just within IS.
> Shall we arrange a discussion with Azeez, Suho and API-M folks before we
> continue to discuss E-Mail specific Implementation details ?
>
> Also E-Mail is just one way of notification, we need some sort of a
> generic framework/abstraction to send any type of  notification such as
> SMS. Once we have such design we can implantation E-Mail support as one
> notification type. I guess we can reuse most of the code/design from C4
> based CEP module.
>
> Thanks !
>
> On Mon, Jan 23, 2017 at 8:29 AM, Johann Nallathamby 
> wrote:
>
>> Hi Isura,
>>
>> On Mon, Jan 23, 2017 at 8:21 AM, Isura Karunaratne 
>> wrote:
>>
>>> Hi Danushka/Kasun,
>>>
>>>
>>>
>>> On Mon, Jan 23, 2017 at 7:00 AM, Kasun Bandara 
>>> wrote:
>>>
 Hi Lahiru,

 Is there any specific reason to populate the email configurations under
 'config' directory ? . IMO these email template configurations must reside
 under 'Identity' directory structure.

>>>
>>> Email templates are not identity specific data. IMO email configurations
>>> should be in the conf directory, but not in Identity directory.
>>>
>>
>> Why we have email templates under identity directory in 5.3.0 is because
>> we made a decision to contain all identity server features under one root
>> directory, hence /identity. Not based on whether they are really a identity
>> related feature or not. Same applies to event-mgt.properties file.
>> Otherwise there can be naming conflicts coming from other repos. I also
>> think all identity server features must go under one directory.
>>
>> Regards,
>> Johann.
>>
>>
>>> Thanks
>>> Isura.
>>>

 Thanks,
 Kasun.

 Kasun Gayan Bandara
 PhD Research Student
 Machine Learning Group

 Faculty of Information Technology, Clayton
 Monash University
 25 Exhibition Walk, Clayton Campus
 Wellington Road
 Clayton VIC 3800
 Australia.

 E: herath.band...@monash.edu
 M (+61) 43 491 6476

 



 On Sun, Jan 22, 2017 at 10:10 PM, Lahiru Manohara 
 wrote:

> Hi,
>
> We are implementing email management component for IS 6.0.0. The
> following properties will be included in the email template.
>
> configuration:
>  -
>   subject:
>   body:
>   footer:
>   type:
>   display:
>   locale:
>   emailContentType:
>
> The following directory structure will be used to keep the template
> based on the locale.
>
> config/
> └── email/
> ├── en_US
> │└── email-admin-config.yaml
> └── en_GB
> └── email-admin-config.yaml
>
> Appreciate your suggestions on above design.
>
> Best Regards,
> --
> *Lahiru Manohara*
> *Software Engineer*
> Mobile: +94716561576
> WSO2 Inc. | http://wso2.com
> lean.enterprise.middleware
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>

>>>
>>
>>
>> --
>> Thanks & Regards,
>>
>> *Johann Dilantha Nallathamby*
>> Technical Lead & Product Lead of WSO2 Identity Server
>> Governance Technologies Team
>> 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
>>
>>
>
>
> --
> Sagara Gunathunga
>
> Associate Director / Architect; WSO2, Inc.;  http://wso2.com
> V.P Apache Web Services;http://ws.apache.org/
> Linkedin; http://www.linkedin.com/in/ssagara
> Blog ;  http://ssagara.blogspot.com
>
>
> _

Re: [Architecture] [C5] [Carbon-Feature-Plugin] Dynamic Creation of carbon.product via a Template

[Dilan Udara Ariyaratne]

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Thu, Jan 26, 2017 at 10:06 AM, Kishanthan Thangarajah <
kishant...@wso2.com> wrote:

>
>
> On Mon, Jan 23, 2017 at 11:49 AM, Dilan Udara Ariyaratne 
> wrote:
>
>> Hi Azeez,
>>
>> Even with the pom based approach (as noted by Kishanthan), we do not have
>> the luxury of totally getting rid of this file, carbon.product
>>
>
> I believe this is only needed at product build time, so we do not need to
> keep a file in the repo but only create the file during build time and then
> delete it (or may be use the target directory so that it will be anyway
> removed).
>
+1 to create the file at target directory during build time, I just tested
the implementation and it works fine. So, in going forward, we can
deprecate the static carbon.product file that exists in distribution folder
of the repo.

>
> since both underlying, but external tycho and equinox launcher plug-ins
>> used by our carbon-feature-plugin require this file as an input.
>>
>> So IMO, the only improvement that we can introduce here is supporting
>> templated-dynamic-creation of the file at carbon-feature-plugin level
>> using the standard carbon kernel version values available in the
>> distribution pom.
>>
>> Thanks,
>> Dilan.
>>
>> *Dilan U. Ariyaratne*
>> Senior Software Engineer
>> WSO2 Inc. <http://wso2.com/>
>> Mobile: +94766405580 <%2B94766405580>
>> lean . enterprise . middleware
>>
>>
>> On Mon, Jan 23, 2017 at 7:33 AM, Kishanthan Thangarajah <
>> kishant...@wso2.com> wrote:
>>
>>>
>>>
>>> On Fri, Jan 20, 2017 at 5:57 PM, Afkham Azeez  wrote:
>>>
>>>> I would suggest totally getting rid of it.
>>>>
>>>
>>> To maintain backward compatibility of the plugin, we need to have the
>>> file based supported. But from next major release of the plugin, we can
>>> remove the usage of this file and use the pom based approach only.
>>>
>>> Thanks,
>>>
>>>>
>>>> On Fri, Jan 20, 2017 at 5:24 PM, KasunG Gajasinghe 
>>>> wrote:
>>>>
>>>>>
>>>>> +1. carbon.product file hasn't really been used by the products. So,
>>>>> +1 to make it optional.
>>>>>
>>>>> On Fri, Jan 20, 2017 at 3:06 PM, Dilan Udara Ariyaratne <
>>>>> dil...@wso2.com> wrote:
>>>>>
>>>>>> Hi Folks,
>>>>>>
>>>>>> In the process of building C5, we currently require carbon.product
>>>>>> for the following goals.
>>>>>> [1] publish-product
>>>>>> [2] generate-runtime
>>>>>>
>>>>>> This file maintains current version of the carbon kernel to be
>>>>>> utilized by "carbon-feature-plugin" in the build process.
>>>>>> Keeping this value in carbon.product prevents the kernel from been
>>>>>> auto-released as it requires manual intervention to bump
>>>>>> version values as necessary during the release process.
>>>>>>
>>>>>> In order to solve this issue, we are currently in the process of
>>>>>> improving Carbon-Feature-Plugin to dynamically create this file during
>>>>>> build time using
>>>>>> a template where the necessary version value information is read from
>>>>>> corresponding distribution pom file.
>>>>>>
>>>>>> In order to support backward compatibility, we will still maintain
>>>>>> the original approach of keeping a carbon.product file somewhere
>>>>>> appropriate
>>>>>> in the distribution folder and read it accordingly when
>>>>>>  tag is present in the pom file.
>>>>>>
>>>>>> In the meantime, as the way to go forward, we will introduce the
>>>>>> following.
>>>>>>
>>>>>> Carbon-Feature-Plugin will be updated to read version and other
>>>>>> optional values that were originally persisted in the file, from the pom
>>>>>> itself.
>>>>>> After reading these values, plugin will dynamically create the
>>>>>> carbon.product which will then be taken into reference by underlying
>>>>>> eclipse.tycho plugin as in the usual way of execu

Re: [Architecture] [C5] [Carbon-Feature-Plugin] Dynamic Creation of carbon.product via a Template

[Dilan Udara Ariyaratne]

Hi All,

Here, I would be discussing the tentatively proposed pom element structure
in carbon-feature-plugin to
support dynamic creation of carbon.product file at build time.

As mentioned in the original post, carbon.product file will be used by
carbon-feature-plugin to achieve two build-time goals, namely
"publish-product" and "generate-runtime".

[1] Proposed pom element structure for Goal "publish-product"
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - -
Old :
This will be kept until next major release for supporting backward
compatibility.

  ${basedir}/carbon.product


New :

  3.5
  
Carbon Product
carbon.product.id
carbon.product
carbon.application
${carbon.kernel.version}
true
true

  default



  eclipse



  
org.wso2.carbon.runtime

${carbon.kernel.version}
  
 
 
   
 org.eclipse.core.runtime
 true
 4
   
   
 org.eclipse.equinox.common
 true
 2
. . .
  
  
   

org.eclipse.update.reconcile
 false
   
   

org.eclipse.equinox.simpleconfigurator.useReference
 true
. . .
   
  
  
${basedir}/target
  



[2] Proposed pom element structure for Goal "generate-runtime"
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - -
Old :
This will be kept until next major release for supporting backward
compatibility.

  ${basedir}/carbon.product


New :

  ${basedir}/target


As discussed for the new approach, dynamically created carbon.product file
path will be the target directory of distribution folder.
Product version value will be captured using the existing pom property,
${carbon.kernel.version}.

WDYT ? Much appreciate your feedback.

Thank you,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Fri, Jan 27, 2017 at 9:47 PM, Afkham Azeez  wrote:

> Yeah that approach sounds good
>
> On Jan 27, 2017 4:30 PM, "Dilan Udara Ariyaratne"  wrote:
>
>>
>>
>> *Dilan U. Ariyaratne*
>> Senior Software Engineer
>> WSO2 Inc. <http://wso2.com/>
>> Mobile: +94766405580 <%2B94766405580>
>> lean . enterprise . middleware
>>
>>
>> On Thu, Jan 26, 2017 at 10:06 AM, Kishanthan Thangarajah <
>> kishant...@wso2.com> wrote:
>>
>>>
>>>
>>> On Mon, Jan 23, 2017 at 11:49 AM, Dilan Udara Ariyaratne <
>>> dil...@wso2.com> wrote:
>>>
>>>> Hi Azeez,
>>>>
>>>> Even with the pom based approach (as noted by Kishanthan), we do not
>>>> have the luxury of totally getting rid of this file, carbon.product
>>>>
>>>
>>> I believe this is only needed at product build time, so we do not need
>>> to keep a file in the repo but only create the file during build time and
>>> then delete it (or may be use the target directory so that it will be
>>> anyway removed).
>>>
>> +1 to create the file at target directory during build time, I just
>> tested the implementation and it works fine. So, in going forward, we can
>> deprecate the static carbon.product file that exists in distribution folder
>> of the repo.
>>
>>>
>>> since both underlying, but external tycho and equinox launcher plug-ins
>>>> used by our carbon-feature-plugin require this file as an input.
>>>>
>>>> So IMO, the only improvement that we can introduce here is supporting
>>>> templated-dynamic-creation of the file at carbon-feature-plugin level
>>>> using the standard carbon kernel version values available i

Re: [Architecture] [C5] [Carbon-Feature-Plugin] Dynamic Creation of carbon.product via a Template

[Dilan Udara Ariyaratne]

Hi All,

Here follows an update to the current state of this implementation.

Carbon-feature-plugin has been updated to get use of one-of-two
configuration options in carbon-kernel distribution pom
in accessing the product file for achieving goals "publish-product" and
"generate-runtime".

[1] One configuration requires following in distribution pom
to access a product file that would be always present physically inside
carbon-kernel source repository.


   publishing products
   package
   
  publish-product
   
   
  
  ${basedir}/carbon.product
  
  
${basedir}/target/org.eclipse.equinox.executable_3.5.0.v20110530-7P7NFUFFLWUl76mart
  file:${basedir}/target/p2-repo
   
   materialize-product
   package
   
  generate-runtime
   
   
  
   ${basedir}/carbon.product
  
  file:${basedir}/target/p2-repo
  file:${basedir}/target/WSO2Carbon/wso2
  default
   
 

Since C4, we have been using this approach to configure product file
location and
will be further continuing to support this until next major release of
C5 for backward compatibility.

[2] Second configuration option will be the new addition of the
mentioned one-of-two configuration options
which will not require the presence of a static product file, instead
it will require the presence of a pom based product file configuration
to
dynamically generate the file at build-time.

[a] Minimum required configuration :


   publishing products
   package
   
  publish-product
   
   
  
 
${carbon.kernel.version}
 
 
${basedir}/target
 
  
  
${basedir}/target/org.eclipse.equinox.executable_3.5.0.v20110530-7P7NFUFFLWUl76mart
  file:${basedir}/target/p2-repo
   

   materialize-product
   package
   
  generate-runtime
   
   
  ${basedir}/target
  file:${basedir}/target/p2-repo
  file:${basedir}/target/WSO2Carbon/wso2
  default
   

[b] A complete configuration with other optional elements :


   publishing products
   package
   
  publish-product
   
   
  
 
 
 

${carbon.kernel.version}












 
 
 ${basedir}/target
  
  
${basedir}/target/org.eclipse.equinox.executable_3.5.0.v20110530-7P7NFUFFLWUl76mart
  file:${basedir}/target/p2-repo


   materialize-product
   package
   
  generate-runtime
   
   
  
  ${basedir}/target
  file:${basedir}/target/p2-repo
  file:${basedir}/target/WSO2Carbon/wso2
  default


Please refer to following PR in Carbon-maven-plugins for more details.
[1] https://github.com/wso2/carbon-maven-plugins/pull/59

Thanks,
Dilan.


*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Mon, Jan 30, 2017 at 12:14 PM, Dilan Udara Ariyaratne 
wrote:

> Hi All,
>
> Here, I would be discussing the tentatively proposed pom element structure
> in carbon-feature-plugin to
> support dynamic creation of carbon.product file at build time.
>
> As mentioned in the original post, carbon.product file will be used by
> carbon-feature-plugin to achieve two build-time goals, namely
> "publish-product" and "generate-runtime".
>
> [1] Proposed pom element structure for Goal "publish-product"
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - -
> Old :
> This will be kept until next major release for supporting backward
> compatibility.
> 
>   ${basedir}/carbon.product
> 
>
> New :
> 
>   3.5
>   
> Carbon Product
> carbon.product.id
> carbon.product
> carbon.application
> ${carbon.kernel.version}
> true
> true
> 
>   default
> 
> 
> 
>   eclipse
> 
> 
> 
>   
> org.wso2.carbon.runtime
> ${carbon.kernel.
> version}
>   
>  
>  
>
>  org.eclipse.core.runtime
>  true
> 

Re: [Architecture] [C5] [Carbon-Feature-Plugin] Dynamic Creation of carbon.product via a Template

[Dilan Udara Ariyaratne]

Hi Kasun,

Yes, it seems that you are correct.
+1 for your suggestion. We can access both version and distribution/target
directory path values from the following property of any existing mojo.

@Parameter(defaultValue = "${project}")
protected MavenProject project;

This means we can either keep version and target elements as optional or
even get rid of them totally.

If we can understand target directory of the distribution folder as the
standard location for a dynamically created product file at build-time, then
we can anyway get rid of the productFilePath element.

In similar, since the product version is always equal to
carbon.kernel.version which is also accessible via the MavenProject
instance, we can also get rid of the version element.

This means in a default setting, we can even totally get rid of the
buildTimeProductFileConfig
element.

If both productConfigurationFile and buildTimeProductFileConfig is not
present, we can take that as a build-time product file configuring
situation and
proceed with default settings.

@Kishanthan, WDYT ?

Thanks,
Dilan.




*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Wed, Feb 8, 2017 at 12:31 PM, KasunG Gajasinghe  wrote:

> Hi Dilan,
>
> This introduces new configuration changes. IMO, we should not introduce
> new configurations that is unnecessary for a user. Here, can we make
> the productConfig/version and productFilePath optional as well?
>
> productFilePath/version is not really the product version, it is the
> kernel's version. We can derive the kernel version by looking at the
> core.runtime maven dependency's version. In all our products, the
> productFilePath is the ${project.build.dir}. So, can we make that the
> default? This will make all the configs transparent to the user.
>
> Thanks,
> KasunG
>
> On Tue, Feb 7, 2017 at 6:47 PM, Dilan Udara Ariyaratne 
> wrote:
>
>> Hi All,
>>
>> Here follows an update to the current state of this implementation.
>>
>> Carbon-feature-plugin has been updated to get use of one-of-two
>> configuration options in carbon-kernel distribution pom
>> in accessing the product file for achieving goals "publish-product" and
>> "generate-runtime".
>>
>> [1] One configuration requires following in distribution pom
>> to access a product file that would be always present physically inside
>> carbon-kernel source repository.
>>
>> 
>>publishing products
>>package
>>
>>   publish-product
>>
>>
>>   
>>   ${basedir}/carbon.product
>>   
>>   
>> ${basedir}/target/org.eclipse.equinox.executable_3.5.0.v20110530-7P7NFUFFLWUl76mart
>>   file:${basedir}/target/p2-repo
>>
>>materialize-product
>>package
>>
>>   generate-runtime
>>
>>
>>   
>>${basedir}/carbon.product
>>   
>>   file:${basedir}/target/p2-repo
>>   file:${basedir}/target/WSO2Carbon/wso2
>>   default
>>
>>  
>>
>> Since C4, we have been using this approach to configure product file 
>> location and
>> will be further continuing to support this until next major release of C5 
>> for backward compatibility.
>>
>> [2] Second configuration option will be the new addition of the mentioned 
>> one-of-two configuration options
>> which will not require the presence of a static product file, instead it 
>> will require the presence of a pom based product file configuration to
>> dynamically generate the file at build-time.
>>
>> [a] Minimum required configuration :
>>
>> 
>>publishing products
>>package
>>
>>   publish-product
>>
>>
>>   
>>  
>> ${carbon.kernel.version}
>>  
>>  
>> ${basedir}/target
>>  
>>   
>>   
>> ${basedir}/target/org.eclipse.equinox.executable_3.5.0.v20110530-7P7NFUFFLWUl76mart
>>   file:${basedir}/target/p2-repo
>>
>> 
>>materialize-product
>>package
>>
>>   generate-runtime
>>
>>
>>   ${basedir}/target
>>   file:${basedir}/target/p2-repo
>>   file:${basedir}/target/WSO2Carbon/wso2
>>   default
>>
>>
>> [b] A complete configuration with other optional elements :
>>
>> 
>>publishing products
>>package
>>
>>   publish-produc

Re: [Architecture] [IoT] Load Distribution for Device + Server Communication.

[Dilan Udara Ariyaratne]

Hi Geeth,

IMO, all the current information retrieval and monitoring operations could
run in parallel from device to device.
In that case, cannot we maintain a task pool at server side where we would
allocate some defined set of operations to each task and dynamically expand
the pool based on demand.
It's more of a divide-and-concur approach that I am suggesting here.

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Mon, Feb 27, 2017 at 11:09 PM, Geeth Munasinghe  wrote:

> Hi all,
>
> We have encountered an issue with balancing load distribution of device +
> server communication. Device and server communication happens through
> following ways.
>
>1. Polling - Device keeps polling the server
>2. Push notification - Server sends a notification to device to come
>retrieve the operation. (wake up call)
>3. Push message - Whole message is pushed to device as notification.
>
> In 1 and 2 ways, device always comes to server to pick up the operation.
> (In MDM scenarios, we use only 1 and 2) We have found few scenarios where
> this would lead to a request overload to the server.
>
>1. Device information retrieval
>2. Device application list retrieval
>3. Device location retrieval
>4. Policy monitoring
>5. Installing/Uninstalling application (Role based)
>
> First four scenarios are handled by background tasks. These tasks are
> responsible for adding an operation against each of the device. This
> process would notify the device regarding operation or device will come to
> server at a pre-configured time to retrieve the operation. Specially with
> the notification process, when an operation is added to all the device,
> notification is send to all of them. In iOS, we send to the notification to
> APNS, for android - GCM/FCM and for Windows - WNS. These notification
> services normally deliver the messages to devices quickly. Therefore as
> soon as device receives the notification, it starts to contact the server.
> If this happens with a server which has 1,000s of devices enrolled, most of
> devices start retrieving the operation from the server which leads to a
> request a burst. 5th scenario happens when we install an application to a
> role which has 1,000s of users. This also starts sending notifications to
> all the devices of those users, which would result in a request burst.
>
> As a solution, we can limit the number of devices notified at given
> moment. Only set of devices will receive the notification at first, then
> after some time interval second set of devices will receive the
> notification and continue until all the devices are notified. This way, we
> can make sure only chunk of devices receives the notification, hence reduce
> the server load.
>
> Please give your feedbacks and suggestions.
>
> Thanks
> Geeth
>
> --
>
> *G. K. S. Munasinghe*
> *Senior Software Engineer,*
> *WSO2, Inc. http://wso2.com  *
> *lean.enterprise.middleware.*
>
> email: ge...@wso2.com
> phone:(+94) 777911226 <+94%2077%20791%201226>
>
> 
>
> ___
> 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] IdentityStore APIs in C5

[Dilan Udara Ariyaratne]

Hi Gayan and All,

+1 for having a well-defined exception hierarchy over having a set of error
code returns in describing specific errors.

Although error codes are light-weight, they can easily go unnoticed and
ignored by callers of the functions. So they provide the potential for
error-prone code which should be avoided.

On the other hand, exceptions, although heavy-weight, force the callers of
the functions to deal with errors in some way which is far more safer in
IMO.

So, in this case, it is preferable to extend identity server and specially,
the identity client exceptions to whatever the much important
decision-making oriented errors that we want to expose to clients.

Thanks,
Dilan.


*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Tue, Feb 28, 2017 at 10:37 AM, Gayan Gunawardana  wrote:

>
>
> On Mon, Feb 27, 2017 at 6:52 PM, Omindu Rathnaweera 
> wrote:
>
>> We already have a JIRA[1] and a redmine for this.
>>
>> One requirement I came across was to identify when we are adding a
>> duplicate user. ATM we don't have a method to identify without checking
>> 'isUserExist'. It's better if we can at least introduce an error code for
>> this.
>>
>> @Gayan might have come across similar requirements while developing the
>> SCIM component.
>>
> Yes.
>
>>
>> [1] - https://wso2.org/jira/browse/IDENTITY-5768
>>
>> On Mon, Feb 27, 2017 at 6:31 PM, Thanuja Jayasinghe 
>> wrote:
>>
>>> Hi Gayan,
>>>
>>> We have already defined an exception hierarchy for identity components.
>>>
>>> IdentityException[1]
>>> ├── IdentityServerException[2]
>>> └── IdentityClientException[3]
>>>
>>>  All exceptions classes defined for identity components extend either 
>>> IdentityServerException
>>> or IdentityClientException.
>>>
>>> So any client can catch the exception as follows,
>>>
>>> catch (IdentityClientException ex) {
>>> // Can return the same error message and code to the client
>>> } catch (IdentityException ex) {
>>> // Need to log and return a generic message to the client
>>> }
>>>
>> This is fine when we propagate exception to out side. IdentityStore APIs
> are extensively used by other identity components where they want to take
> decisions based on exceptions provided by IdentityStore APIs. Just by
> having IdentityServerException, IdentityClientException does not provide
> exact idea to API consumer.
>
> I guess answer to above question is having error codes. As I mentioned in
> the initial mail, isn't it better to have exception hierarchy than error
> codes ?
>
>
>>> Since we add these exception classes recently, we need to
>>> update carbon-identity-mgt repo.
>>>
>>> [1] - https://github.com/wso2/carbon-identity-commons/blob/maste
>>> r/components/org.wso2.carbon.identity.common/src/main/java/o
>>> rg/wso2/carbon/identity/common/base/exception/IdentityException.java
>>> [2] - https://github.com/wso2/carbon-identity-commons/blob/maste
>>> r/components/org.wso2.carbon.identity.common/src/main/java/o
>>> rg/wso2/carbon/identity/common/base/exception/IdentityServer
>>> Exception.java
>>> [3] - https://github.com/wso2/carbon-identity-commons/blob/maste
>>> r/components/org.wso2.carbon.identity.common/src/main/java/o
>>> rg/wso2/carbon/identity/common/base/exception/IdentityClient
>>> Exception.java
>>>
>>> Thanks,
>>> Thanuja
>>>
>>> On Mon, Feb 27, 2017 at 10:06 AM, Ruwan Abeykoon 
>>> wrote:
>>>
 Hi All,
 +1 to have an exception hierarchy, which carries information for
 specific errors.

 I think we should follow the way Java IO exceptions are done.

 Cheers,
 Ruwan


 On Mon, Feb 27, 2017 at 9:58 AM, Gayan Gunawardana 
 wrote:

> Hi All,
>
> Shall we revisit IdentityStore APIs? For an example addUser method[1]
> throws IdentityStoreClientException and IdentityStoreServerException
> in many cases where client cannot differentiate the reason. There will be
> relevant error message but client cannot rely on error message to take
> decisions.
> IMO we should have proper exception hierarchy or error codes. I'm +1
> to have
> exception hierarchy.
>
> WDYT ?
>
> [1] https://github.com/wso2/carbon-identity-mgt/blob/master/comp
> onents/org.wso2.carbon.identity.mgt/src/main/java/org/wso2/c
> arbon/identity/mgt/impl/IdentityStoreImpl.java#L985
>
> Thanks,
> Gayan
> --
> Gayan Gunawardana
> Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>



 --

 *Ruwan Abeykoon*
 *Associate Director/Architect**,*
 *WSO2, Inc. http://wso2.com  *
 *lean.enterprise.middleware.*


>>>
>>>
>>> --
>>> *Thanuja Lakmal*
>>> Senior Software Engineer
>>> WSO2 Inc. http://wso2.com/
>>> *lean.enterprise.middleware*
>>> Mobile: +94715979891 +94758009992
>>>
>>
>>
>>
>> --
>> Om

Re: [Architecture] Retrieving Rating value of API in the GET_API resource API

[Dilan Udara Ariyaratne]

Hi Chamalee,

I think that the 1st option would be the slowest in performance as it
requires two network calls to APIs + two separate DB Calls to get all
information related to an API.

So, IMO, we should rather focus on other two options which only require one
network call, instead of the first.

>From that, 2nd option only involves 1 network call + 1 database call where
as
3rd involves 1 network call + 2 database calls.

So, IMO, what's left here to compare is if one join is better than
performing multiple queries to achieve the same.

Since you are performing simply an inner join here and not any outer join
which can result in any redundant rows, I guess that 2nd option would be
much better.

WDYT?

Thanks.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Fri, Mar 3, 2017 at 10:37 AM, Chamalee De Silva 
wrote:

> Thanks all for the responses.
>
> I will go ahead with option 1.
>
> So with that,
>
>
>- The rating value of the API *will not be returned* in the response
>of the getAPI  resource API.
>- Separate resource APIs will be implemented to do the following.
>
>  -  add rating value by an API
>  -  get the overall rating of an API
> -  to get rating given by a particular
> subscriber for an API
>
>
> Thanks,
> Chamalee.
>
> On Thu, Mar 2, 2017 at 10:01 AM, Vidura Nanayakkara 
> wrote:
>
>> Hi Chamalee,
>>
>> The response in [1]
>> 
>>  suggests
>> option 1 in general. It explains few good points that are worth looking at.
>>
>> Furthermore, in addition to Chamin's response, getAPI call looks to me
>> is common HTTP call in the application. Therefore we do not need to include
>> additional information in the response. (You only need to proceed with
>> option 2 if you need to always get the API rating along with the API (a
>> single request is much more scalable than multiple requests in this case))
>>
>> So IMO we should proceed with option 1
>>
>> [1] Many asynchronous calls vs single call to the API
>> 
>>
>>
>> On Wed, Mar 1, 2017 at 6:09 PM, Malintha Amarasinghe 
>> wrote:
>>
>>>
>>>
>>> On Wed, Mar 1, 2017 at 1:45 PM, Chamalee De Silva 
>>> wrote:
>>>
 Hi all,

 I am working on adding REST APIs for the following operations.

 1. Rate an API (add rating)
 2. Get rating of an API (given the UUID of the API)


 A separate table is going to be added to store for API_RATINGS like
 what we had in APIM 2.1.0
 where it has 1:m mapping with AM_API table.

 AM_API_RATINGS

 ID

 API_ID

 SUBSCRIBER_ID

 RATING





 In current implementation or in the previous version of the API there
 is no implementation to get the API rating when retrieving the API in Store
 REST API.

 We need to get the rating of the API at the same time we do the GET_API
 call when thinking of the UI perspective to display the API in Store.

 So there are two options available to get the rating of the API.


 *Option 1 : *
 Do the *getAPIRating *call (/apis/{apiId}/rating) right after the
 getAPI call.

 If we do this there will be t*wo REST calls* one after the
 other. But the query execution will be less expensive and less complex.

>>> +1. Better to keep this outside of the API since this is not really a
>>> part of the API resource. Adding to Chamin's and Harsha's comments; If we
>>> make this as part of the API resource, we will always have to change the
>>> ETag of the API once a user changes the rating of the API (which can happen
>>> frequently compared to a change that happens to the actual API). This is an
>>> unnecessary change that would affect client side caching. I think we need
>>> to be bit careful about this when doing changes to any exising resource in
>>> general.
>>>
>>> Thanks!
>>> Malintha
>>>




 *Option 2 : *
  Get the rating value of the particular API inside the same
 query for  get_API , add it to the API object as a property and retrieve
 the rating with *getAPI* call.

  This will reduce it to one REST call to the server, but in
 DB level, we are doing a bit complex query

  e.g. Then the getAPI query will be like this with an inner
 join operation.

   *select   *
   *a.id , a.name
 , a.context, . , avg(r.rating)*
   *from*
   

Re: [Architecture] [C5] [Carbon-Feature-Plugin] Dynamic Creation of carbon.product via a Template

[Dilan Udara Ariyaratne]

Hi Imesh,

Will check IS 6.0.0-SNAPSHOT with updated carbon-feature-plugin
(3.0.1-SNAPSHOT) configurations.

Thanks.
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Thu, Mar 9, 2017 at 11:37 AM, Imesh Gunaratne  wrote:

> Overall great effort Dilan! The new PR [1] was merged to the master branch
> after reviewing.
> Maybe we can try this out with IS 6.0.x [2] WDYT?
>
> [1] https://github.com/wso2/carbon-maven-plugins/pull/61
> [2] https://github.com/wso2/product-is
>
> Thanks
> Imesh
>
> --
> *Imesh Gunaratne*
> Software Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][IS 6.0.0] Password History Validation

[Dilan Udara Ariyaratne]

On Mon, Mar 13, 2017 at 5:00 PM, Omindu Rathnaweera  wrote:

> Hi,
>
> On Sun, Mar 12, 2017 at 7:59 AM, Ruwan Abeykoon  wrote:
>
>> Hi All,
>> Can the hash algorithm change over the time?
>> If so we need to record the hash algorithm used to do hashing along with
>> the particular password history record. We need to use the particular
>> algorithm to do the comparison, not the system configured one.
>>
>
> In addition to the hashing algo, we should store the key length and the
> iteration count. We have given the option to configure these properties for
> the credential stores and we should do the same for password history
> management. Since we are storing the current password in the history table,
> the hashing mechanism should be similar to that of the credential stores.
>

Will the hashing mechanism (i.e. algorithm, key length, iteration count) be
same for all hashing algorithms ?
In that case, How do we handle such a scenario in storing hashing mechanism
related data in database ? When hashing mechanisms differ from one another,
we will definitely not be able to have a fixed column structure in the
table.

>
> Regards,
> Omindu.
>
>
>>
>> Cheers,
>> Ruwan
>>
>>
>> On Sun, Mar 12, 2017 at 7:44 AM, Gayan Gunawardana 
>> wrote:
>>
>>> Hi All,
>>>
>>> We are in the process of implementing password history validation
>>> feature for IS 6.0.0. Architecture of this feature was previously discussed
>>> in [1] by Isura for IS 5.3.0. We plan to follow same architecture with
>>> minor changes.
>>>
>>> Previously history validation has been done by checking only last 'n'
>>> number of attempts. Ex. you cannot use a password which is inside last 5
>>> attempts. This time we additionally validate time factor as well Ex. you
>>> cannot use a password, if there is a similar password with created date
>>> inside last 7days.
>>>
>>> Table structure will be changed as below since we have unique user ID in
>>> C5.
>>>
>>> *Previous *
>>>
>>> CREATE TABLE IF NOT EXISTS IDN_PASSWORD_HISTORY_DATA (
>>>   ID INTEGER NOT NULL AUTO_INCREMENT,
>>>   USER_NAME   VARCHAR(255) NOT NULL,
>>>   USER_DOMAIN VARCHAR(127) NOT NULL,
>>>   TENANT_ID   INTEGER DEFAULT -1,
>>>   SALT_VALUE  VARCHAR(255),
>>>   HASHVARCHAR(255) NOT NULL,
>>>   TIME_CREATED TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
>>>   PRIMARY KEY(ID),
>>>   UNIQUE (USER_NAME,USER_DOMAIN,TENANT_ID,SALT_VALUE,HASH)
>>> )ENGINE INNODB;
>>>
>>>
>>> *New *
>>> CREATE TABLE IF NOT EXISTS IDN_PASSWORD_HISTORY_DATA (
>>>   ID INTEGER NOT NULL AUTO_INCREMENT,
>>>   USER_UNIQUE_ID   VARCHAR(255) NOT NULL,
>>>   SALT_VALUE  VARCHAR(255),
>>>   HASHVARCHAR(255) NOT NULL,
>>>   TIME_CREATED TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
>>>   PRIMARY KEY(ID),
>>>   UNIQUE (USER_NAME,USER_DOMAIN,TENANT_ID,SALT_VALUE,HASH)
>>> )ENGINE INNODB;
>>>
>>> Password Hashing algorithm will be a configurable property.
>>>
>>> [1] [Architecture] Force Password Reset and Password History validation
>>>
>>> Thanks,
>>> Gayan
>>>
>>> --
>>> Gayan Gunawardana
>>> Software Engineer; WSO2 Inc.; http://wso2.com/
>>> Email: ga...@wso2.com
>>> Mobile: +94 (71) 8020933
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>>
>> *Ruwan Abeykoon*
>> *Associate Director/Architect**,*
>> *WSO2, Inc. http://wso2.com  *
>> *lean.enterprise.middleware.*
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Omindu Rathnaweera
> Software Engineer, WSO2 Inc.
> Mobile: +94 771 197 211 <+94%2077%20119%207211>
>
> ___
> 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] [C5][IS 6.0.0]Admin Forced Password Reset Via Offline for Existing Users

[Dilan Udara Ariyaratne]

On Tue, Mar 14, 2017 at 11:08 AM, Gayan Gunawardana  wrote:

>
>
> On Tue, Mar 14, 2017 at 10:58 AM, Hasanthi Purnima Dissanayake <
> hasan...@wso2.com> wrote:
>
>> Hi all,
>>
>> We are in the process of implementing Admin Forced Password Reset via
>> Offline for existing users in Admin Portal for the new IS 6.0.0 release.
>> The wireframe design for the UI is found at [1].
>>
>> Admin can select a user and generate a password for the selected user.
>> This generated password is an OTP.
>>
>> This OTP is:
>> 1. Not adhere to any password policy.
>> 2. There is no validity period
>> 3. Once this OTP is used it expires.
>> 4. Not considered like a normal password and we are going to store it in
>> IDN_RECOVERY_DATA table.
>>
> If admin generates two or more OTPs, what is the behavior ?
> All valid or last one valid ?
> Suppose there is two and we consume only first one, in that case does it
> invalidate second one ?
>

Why should we allow multiple OTPs for a particular user at a given time ?
Cannot we keep only one valid OTP for a user at a given time and override
it at the point of creating a new one ?

>
>> [1] https://github.com/wso2-dev-ux/product-is/blob/master/Wirefr
>> ames/admin-portal/v3/3.32%20%20Reset%20password%20with%
>> 20offline%20OTP%20-%20password%20generated.png
>>
>> Thanks,
>>
>> Hasanthi Dissanayake
>>
>> Software Engineer | WSO2
>>
>> E: hasan...@wso2.com
>> M :0718407133| http://wso2.com 
>>
>
>
>
> --
> Gayan Gunawardana
> Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>
> ___
> 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] [C5][IS 6.0.0] User List UI for IS 6.0.0

[Dilan Udara Ariyaratne]

On Tue, Mar 14, 2017 at 10:28 AM, Nuwandi Wickramasinghe 
wrote:

> Hi all,
>
> We are in the process of implementing User List view in the Admin Portal
> for the new IS 6.0.0 release. The wireframe design for the UI is found at
> [1].
>
> Admin can view a list of users and perform actions such as Delete, Edit
> and request to Reset Password. Also admin can select multiple users and
> chose to Delete, Disable or Activate. There will be an option to filter the
> list according to the user attributes.
>
> I am planning to add an admin profile in profile-mapping.yaml file where
> an admin can define what user attributes to be shown in the list.
>
> According to the wireframe ([1]), we have to give the flexibility to show
> Groups and Roles of the users. ATM we do not have claim definitions for
> Groups and Roles. Therefore we won't be able to handle them with an
> attribute profile. As per the offline chat with Johann we might define
> Claim URIs for Groups and Roles in future since there will be other use
> cases where we need to treat them as user attributes (eg. SAML attribute
> profile). Also loading all the Roles and Groups for each user in the list
> will highly effect the initial loading time. May be we can filter out to
> maximum number (say 3) of records and request all if one wants to see more
> roles/groups.
>

For a list view, we can always limit what we are showing per row to the
most essential. It's not required to fetch and show all the data, for ex:
in here, we can omit showing roles / groups and focus on other primary data
suitable for an overview of the user. And from the list view, when someone
wants to get into a more detailed look of a user, we can always direct him
for that using a link to a separate, detailed page view of a user.

>
> However for the immediate release (m5) I guess it is ok not to have Roles
> and Groups in the User List view. We did not have that in IS 5.3.0 as well
> so I hope this is not a critical requirement. We will keep the wireframe as
> it is since we are planning to improve things in the future.
>
> [1] https://github.com/wso2-dev-ux/product-is/blob/master/
> Wireframes/admin-portal/v3/3.19%20User%20Listing.png
>
> thanks
> Nuwandi
> --
>
> Best Regards,
>
> Nuwandi Wickramasinghe
>
> Software Engineer
>
> WSO2 Inc.
>
> Web : http://wso2.com
>
> Mobile : 0719214873
>
> ___
> 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] [C5][IS 6.0.0] Add and Update Group UI for IS 6.0.0

[Dilan Udara Ariyaratne]

Hi Folks,

When you have both users and roles tabs under either "Add Group" or "Edit
Group", it may seem to someone that adding a user or role is
part of adding a group / editing a user or role is part of editing a group
which might not be the idea that we are trying to give.

WDYT ? We might have to revisit on that aspect here.

Regards,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Sun, Mar 19, 2017 at 3:08 PM, Gayan Gunawardana  wrote:

> When we say Add/Edit group showing 'General' tab and 'Users' tab some what
> acceptable because obviously they belong to Group entity. Having  'Roles'
> tab under Add/Edit group may confuse end users, if they do not know C5
> permission model.
> IMO it should reflect the idea of permission than just saying Roles.
>
> On Fri, Mar 17, 2017 at 9:19 AM, Minoli Perera  wrote:
>
>> Hi Kasun,
>>
>> On Thu, Mar 16, 2017 at 1:55 PM, KasunG Gajasinghe 
>> wrote:
>>
>>>
>>>
>>> On Thu, Mar 16, 2017 at 8:50 AM, Pushpalanka Jayawardhana <
>>> la...@wso2.com> wrote:
>>>


 On Thu, Mar 16, 2017 at 8:46 AM, Pushpalanka Jayawardhana <
 la...@wso2.com> wrote:

> Hi All,
>
> I am working on implementing 'add group' and 'update group' UIs for IS
> 6.0.0 as per the wire-frames [1] and [2].
>
> In group addition, user experience will be as, in the 'General' tab
> user provides name and description of the role.
> User can either conclude the group addition flow here or go to 'Users'
> tab to select users who will be in this group.
> User can either conclude the flow here or go to 'Roles' tab to select
> the roles to be assigned to all the users in the newly added group.
>

>>> What this means is this the 'General', 'Users', 'Roles' tabs are part of
>>> a wizard. Further, users don't need to complete all the pages in wizard;
>>> they can finish at any step.
>>>
>>> I think the current UI fails to capture that each of them are part of a
>>> wizard. It looks quite ambiguous to me. @Dakshika, Minoli, can you guys
>>> review this again to see what we can do? It may be as simple as adding a
>>> 'Next' button, or a complete overhaul.
>>>
>>> We apply wizards when there is a step by step mandatory process we want
>> the user to go through. But in this scenario adding users and roles are
>> optional. So IMO we cannot apply a wizard for this scenario. But we will
>> further review this and will update.
>>
>>>
>>>
>>> --
>>>
>>> *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,
>> --
>> Minoli Perera,
>> Software Engineer, WSO2, Inc.
>> E-mail : mino...@wso2.com
>> Mobile : +94771567527 <+94%2077%20156%207527>
>> 
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Gayan Gunawardana
> Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>
> ___
> 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] C5 Fixing the StartupOrderResolver race condition

[Dilan Udara Ariyaratne]

Hi Jayanga,

Can you describe a little bit on how this StartupServiceCache is working,
for ex: How it is updated, with what data and so on.

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Wed, Mar 22, 2017 at 7:23 PM, Kishanthan Thangarajah  wrote:

> Hi Jayanga,
>
> As we spoke offline, did we check on the possibility of using service
> EvenHook instead of the above "cache" ? Also how the internals work when
> events are delivered in an order (trackers vs service component
> references)?
>
> Thanks,
>
> On Wed, Mar 22, 2017 at 6:37 PM, Jayanga Dissanayake 
> wrote:
>
>> Hi All,
>>
>> In the C5 Carbon Kernel, we introduced a new feature call
>> StartupOrderResolver. The main idea is to overcome some of the limitation
>> we have in the cardinality of OSGi Service Components and to have implicit
>> dependencies among the components. You can find more information on the
>> design/implementation in [1] and [2].
>>
>> In the recent testing, we came across a very rare race condition in this
>> implementation which is explained below.
>>
>>
>> ​
>> ​
>> Let's assume there is Component (DeploymentMgtComponent) that is using
>> StartupOrderResolver, needs to wait until all the Deployment services are
>> available.
>>
>> 1) The Happy Path
>> i) A deployment service registers with the OSGi registry (1)
>> ii) OSGi Registry notifies the ServiceComponent (2a)
>> iii) OSGi Registry notifies the ServiceTracker of StartupOrderResolver
>> (2b)
>> iv) StartupOrderResolverUpdates its ServiceMetadata
>> (v) The timer triggers, if all the required capabilities are ready,
>> notify the component (3)
>>
>> 2) Problematic Path
>> i) A deployment service registers with the OSGi registry (1)
>> ii) OSGi Registry notifies the ServiceTracker of StartupOrderResolver (2b)
>> iii) StartupOrderResolverUpdates its ServiceMetadata
>> iv) The timer triggers, if all the required capabilities are ready,
>> notify the component (3)
>> v) OSGi Registry notifies the ServiceComponent (2a)
>>
>> In the problematic path, onAllRequiredCapabilitiesAvailable() method is
>> called before a reference to the Deployment service is received via the
>> OSGi registry.
>>
>> The fix is to delay the method call onAllRequiredCapabilitiesAvailable()
>> until all the service references are received by the ServiceComponet. But
>> there is no OOB way of detecting from the outside, whether a particular
>> component has received a service reference or not.
>>
>> Hence I came up with the below-mentioned solution, In which I added a new
>> "StartupServiceCache" and changed the StartupOrder pending capability
>> detecting logic to use the StartupServiceCache to identify the services
>> that are already known by the Component.
>>
>> With this approach, if a ServiceComponent developer wants to rely on
>> StartupOrderResolver, he will have to follow the same old way and have an
>> additional entry in the @Reference method in the service component
>>
>> e.g:
>> StartupServiceUtils.updateServiceCache("carbon-deployment-mgt",
>> Deployment.class, deployment);
>>
>>
>>
>> ​
>>
>> The proposed solution fixes the issue. With this solution, the developer
>> will have to add another one entry in the ServiceComponent, which I believe
>> ok as the developer anyway be putting additional entries in the Components
>> and Services to make it incorporate with old StartupOrderResolver.
>>
>>  Anyway, I am looking into other possibilities whether we could get rid
>> of this additional entry.
>>
>> Any idea/suggestion on this regard is highly appreciated.
>>
>> [1] https://medium.com/@sameera.jayasoma/startup-order-resol
>> ving-mechanisms-in-osgi-48aecde06389#.vn6p146ts
>> [2] https://medium.com/@sameera.jayasoma/resolving-startup-o
>> rder-of-carbon-components-in-wso2-carbon-5-0-0-497fe3287e67#.drybgj29a
>>
>> Thanks,
>> *Jayanga Dissanayake*
>> Associate Technical Lead
>> WSO2 Inc. - http://wso2.com/
>> lean . enterprise . middleware
>> email: jaya...@wso2.com
>> mobile: +94772207259 <+94%2077%20220%207259>
>> 
>>
>
>
>
> --
> *Kishanthan Thangarajah*
> Technical Lead,
> Platform Technologies Team,
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - +94773426635 <+94%2077%20342%206635>
> Blog - *http://kishanthan.wordpress.com *
> Twitter - *http://twitter.com/kishanthan *
>
> ___
> 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] [C5][IS 6.0.0] Admin Initiated Password Reset by Reset Link

[Dilan Udara Ariyaratne]

Hi Hasanthi,

I guess with this option, we are forcing a user to reset his password
before the next login.

In that case, it's actually not an administrator, but a particular user who
would reset his password upon on retrieval of a reset link.

So, can we term the title of the provided wire-frame as "Reset Password"
and action button name as "Reset", because this UI is supposed to be used
by an administrator
to actually force a password reset action by some other user and not to
reset his password ?

WDYT?

Thanks,
Dilan.

*Dilan U. Ariyaratne*
Senior Software Engineer
WSO2 Inc. 
Mobile: +94766405580 <%2B94766405580>
lean . enterprise . middleware


On Thu, Mar 23, 2017 at 9:34 AM, Hasanthi Purnima Dissanayake <
hasan...@wso2.com> wrote:

> Hi all,
>
> We are in the process of implementing $subject in Admin portal for IS
> 6.0.0 release. The wire frame design for the UI is found at [1].
>
> In this user story the admin can initiate password reset for a user with
> reset link which will trigger an email containing password reset link to
> the registered email address of the account. This option is only available
> if an email is given in the user profile.  Once a password reset link has
> sent to a selected user , the user will not be allowed to login with the
> old password.
>
> [1] https://github.com/wso2-dev-ux/product-is/blob/master/Wi
> reframes/admin-portal/v3/3.35%20%20Reset%20password%20with%
> 20reset%20link.png
>
> Thanks,
>
> Hasanthi Dissanayake
>
> Software Engineer | WSO2
>
> E: hasan...@wso2.com
> M :0718407133| http://wso2.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] Proposed Device Operations Flow of CDM

[Dilan Udara Ariyaratne]

Hi Harshan,

This is with reference to the two merging options that you have mentioned
in your previous reply to the thread.

As I understood, with the 1st Option:

You suggest to

[1] convert platform-independent-payload to platform-specific-payload, save
it and when another request comes in,
[2] convert the platform-specific-payload back into its
platform-independent-form and merge it with the
platform-independent-payload for the new request and
[3] convert that back to a platform-specific-payload. (Please correct me if
I am wrong)

So with this option, you suggest not to save a platform-independent-payload
for the pending requests and deal with it only at run-time.

As I understood, with the 2nd Option:

You suggest to

[1] Keep the platform-independent-payload saved along with its
platform-specific-payload and when ever another request comes in,
[2] Get the existing platform-independent-payload and merge it with new
platform-independent-payload of the incoming request, save it and
[3] Convert that to a new platform-specific-payload and overwrite the
existing platform-specific-payload with the new one. (Please correct me if
I am wrong)

Thanks.







*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94775149066
lean . enterprise . middleware

On Mon, Nov 17, 2014 at 8:16 AM, Harshan Liyanage  wrote:

> Hi,
>
> *Platform-specific payload *is the actual payload which will be delivered
> to the device when the device contacts the server for pending-operations. 
> *Platform-independent
> *form is used to construct the *Platform-specific payload *& communicate
> device operations internally within CDM. For example when an user sends a
> device operation using CDM web-console, *platform-independent *message
> will be sent from the console -> CDM API -> CDM Core -> Device-platform
> bundle. Then the *device-platform bundle *will use it to construct the 
> *platform-specific
> payload.*
> But there might be situation where some device operation payloads might
> not delivered to the device when another operation for that device comes-in.
>  IMO in such cases its not good to have many pending *platform-specific
> payloads *for a single device. If we are to deliver multiple payloads
> that might introduce an additional overhead in network. In such situations
> what I suggest is to merge the new payload with the existing payload. To do
> that we have two options.
>
> 1. Use the existing *platform-specific payload *& merge it with the new
> operation request
> 2. Use the *platform-independent *form & merge it with new operation
> request (platform-independent form) & construct a new payload
>
> Going through the 1st approach will be harder because then the
> device-platform bundle will have to have the all the conversion logic need
> to convert payloads ( *platform-independent -> platform-specific *& 
> *platform-specific
> -> platform-independent). *In some platforms converting back the 
> *platform-specific
> payload* might not be possible because the device-platform bundle might
> use a 3rd party library to do the conversion. So we had to opt out 1st
> approach.
> If we follow the 2nd approach, CDM server itself can do the merging of the
> operation requests because it does not need any platform-specific knowledge
> to do so. Then the merged *platform-independent payload *can be send to
> the device-platform bundle to get the corresponding *platform-specific
> payload.* For do that we need to save the *platform-independent payload *along
> with the *platform-specific payload.*
> This approach will reduce the workload of device-platform implementer,
> which will make easier integration of new platforms.
>
> Regards,
>
> Lakshitha Harshan
> Software Engineer
> Mobile: *+94724423048*
> Email: hars...@wso2.com
> Blog : http://harshanliyanage.blogspot.com/
> *WSO2, Inc. :** wso2.com <http://wso2.com/>*
> lean.enterprise.middleware.
>
> On Mon, Nov 17, 2014 at 5:59 AM, Dilan Udara Ariyaratne 
> wrote:
>
>> Hi All,
>>
>> This is just to clarify things.
>>
>> With reference to defining pending-operations-per-device, why do we need
>> to have a
>> *platform-specific payload *and its *platform-independent* *form*?
>>
>> What is the expected use-case of this?
>>
>> Regards,
>>
>> Dilan.
>>
>>
>>
>>
>> *Dilan U. Ariyaratne*
>> Software Engineer
>> WSO2 Inc. <http://wso2.com/>
>> Mobile: +94775149066
>> lean . enterprise . middleware
>>
>> On Mon, Nov 3, 2014 at 5:36 PM, Harshan Liyanage 
>> wrote:
>>
>>> Hi InoshP,
>>>
>>> Before explaining the above scenario I'll explain the process o

Re: [Architecture] Proposed Device Operations Flow of CDM

[Dilan Udara Ariyaratne]

Hi All,

Why do we need to construct a "Platform-specific-payload" at the server
level?

Cannot we just send the "Platform-independent-payload" to the device agent
and invoke the corresponding feature operation at the client side?

I might not be right because I am not exactly aware of all the use-cases.

Appreciate if some valid use-cases can be provided on this regard.

Thanks.



*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94775149066
lean . enterprise . middleware

On Tue, Nov 18, 2014 at 8:32 AM, Harshan Liyanage  wrote:

> Hi Dilan,
>
> Yes. you are correct.
>
> Thanks,
>
> Lakshitha Harshan
> Software Engineer
> Mobile: *+94724423048*
> Email: hars...@wso2.com
> Blog : http://harshanliyanage.blogspot.com/
> *WSO2, Inc. :** wso2.com <http://wso2.com/>*
> lean.enterprise.middleware.
>
> On Tue, Nov 18, 2014 at 7:20 AM, Dilan Udara Ariyaratne 
> wrote:
>
>> Hi Harshan,
>>
>> This is with reference to the two merging options that you have mentioned
>> in your previous reply to the thread.
>>
>> As I understood, with the 1st Option:
>>
>> You suggest to
>>
>> [1] convert platform-independent-payload to platform-specific-payload,
>> save it and when another request comes in,
>> [2] convert the platform-specific-payload back into its
>> platform-independent-form and merge it with the
>> platform-independent-payload for the new request and
>> [3] convert that back to a platform-specific-payload. (Please correct me
>> if I am wrong)
>>
>> So with this option, you suggest not to save a
>> platform-independent-payload for the pending requests and deal with it only
>> at run-time.
>>
>> As I understood, with the 2nd Option:
>>
>> You suggest to
>>
>> [1] Keep the platform-independent-payload saved along with its
>> platform-specific-payload and when ever another request comes in,
>> [2] Get the existing platform-independent-payload and merge it with new
>> platform-independent-payload of the incoming request, save it and
>> [3] Convert that to a new platform-specific-payload and overwrite the
>> existing platform-specific-payload with the new one. (Please correct me if
>> I am wrong)
>>
>> Thanks.
>>
>>
>>
>>
>>
>>
>>
>> *Dilan U. Ariyaratne*
>> Software Engineer
>> WSO2 Inc. <http://wso2.com/>
>> Mobile: +94775149066
>> lean . enterprise . middleware
>>
>> On Mon, Nov 17, 2014 at 8:16 AM, Harshan Liyanage 
>> wrote:
>>
>>> Hi,
>>>
>>> *Platform-specific payload *is the actual payload which will be
>>> delivered to the device when the device contacts the server for
>>> pending-operations. *Platform-independent *form is used to construct
>>> the *Platform-specific payload *& communicate device operations
>>> internally within CDM. For example when an user sends a device operation
>>> using CDM web-console, *platform-independent *message will be sent from
>>> the console -> CDM API -> CDM Core -> Device-platform bundle. Then the 
>>> *device-platform
>>> bundle *will use it to construct the *platform-specific payload.*
>>> But there might be situation where some device operation payloads might
>>> not delivered to the device when another operation for that device comes-in.
>>>  IMO in such cases its not good to have many pending *platform-specific
>>> payloads *for a single device. If we are to deliver multiple payloads
>>> that might introduce an additional overhead in network. In such situations
>>> what I suggest is to merge the new payload with the existing payload. To do
>>> that we have two options.
>>>
>>> 1. Use the existing *platform-specific payload *& merge it with the new
>>> operation request
>>> 2. Use the *platform-independent *form & merge it with new operation
>>> request (platform-independent form) & construct a new payload
>>>
>>> Going through the 1st approach will be harder because then the
>>> device-platform bundle will have to have the all the conversion logic need
>>> to convert payloads ( *platform-independent -> platform-specific *& 
>>> *platform-specific
>>> -> platform-independent). *In some platforms converting back the 
>>> *platform-specific
>>> payload* might not be possible because the device-platform bundle might
>>> use a 3rd party library to do the conversion. So we had to opt out 1st
>>> approach.
>>> If we follow the 2nd

Re: [Architecture] Proposed Device Operations Flow of CDM

[Dilan Udara Ariyaratne]

Hi Sameera,

I am not exactly getting the point.

It should be because I am not exactly aware of the actual use case of
Windows and iOS.

Do you mean that they are using different transport (or connectivity)
protocols?

Regards.




*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94775149066
lean . enterprise . middleware

On Sat, Nov 22, 2014 at 9:29 PM, Sameera Perera  wrote:

> Hi Dilan
> On Windows and iOS we need to use the specific protocols and rely on the
> OS to execute the command. This is why we have to use this approach.
>
> (Sent from a mobile device)
> On 22 Nov 2014 19:29, "Dilan Udara Ariyaratne"  wrote:
>
>> Hi All,
>>
>> Why do we need to construct a "Platform-specific-payload" at the server
>> level?
>>
>> Cannot we just send the "Platform-independent-payload" to the device
>> agent and invoke the corresponding feature operation at the client side?
>>
>> I might not be right because I am not exactly aware of all the use-cases.
>>
>> Appreciate if some valid use-cases can be provided on this regard.
>>
>> Thanks.
>>
>>
>>
>> *Dilan U. Ariyaratne*
>> Software Engineer
>> WSO2 Inc. <http://wso2.com/>
>> Mobile: +94775149066
>> lean . enterprise . middleware
>>
>> On Tue, Nov 18, 2014 at 8:32 AM, Harshan Liyanage 
>> wrote:
>>
>>> Hi Dilan,
>>>
>>> Yes. you are correct.
>>>
>>> Thanks,
>>>
>>> Lakshitha Harshan
>>> Software Engineer
>>> Mobile: *+94724423048*
>>> Email: hars...@wso2.com
>>> Blog : http://harshanliyanage.blogspot.com/
>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>*
>>> lean.enterprise.middleware.
>>>
>>> On Tue, Nov 18, 2014 at 7:20 AM, Dilan Udara Ariyaratne >> > wrote:
>>>
>>>> Hi Harshan,
>>>>
>>>> This is with reference to the two merging options that you have
>>>> mentioned in your previous reply to the thread.
>>>>
>>>> As I understood, with the 1st Option:
>>>>
>>>> You suggest to
>>>>
>>>> [1] convert platform-independent-payload to platform-specific-payload,
>>>> save it and when another request comes in,
>>>> [2] convert the platform-specific-payload back into its
>>>> platform-independent-form and merge it with the
>>>> platform-independent-payload for the new request and
>>>> [3] convert that back to a platform-specific-payload. (Please correct
>>>> me if I am wrong)
>>>>
>>>> So with this option, you suggest not to save a
>>>> platform-independent-payload for the pending requests and deal with it only
>>>> at run-time.
>>>>
>>>> As I understood, with the 2nd Option:
>>>>
>>>> You suggest to
>>>>
>>>> [1] Keep the platform-independent-payload saved along with its
>>>> platform-specific-payload and when ever another request comes in,
>>>> [2] Get the existing platform-independent-payload and merge it with new
>>>> platform-independent-payload of the incoming request, save it and
>>>> [3] Convert that to a new platform-specific-payload and overwrite the
>>>> existing platform-specific-payload with the new one. (Please correct me if
>>>> I am wrong)
>>>>
>>>> Thanks.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *Dilan U. Ariyaratne*
>>>> Software Engineer
>>>> WSO2 Inc. <http://wso2.com/>
>>>> Mobile: +94775149066
>>>> lean . enterprise . middleware
>>>>
>>>> On Mon, Nov 17, 2014 at 8:16 AM, Harshan Liyanage 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> *Platform-specific payload *is the actual payload which will be
>>>>> delivered to the device when the device contacts the server for
>>>>> pending-operations. *Platform-independent *form is used to construct
>>>>> the *Platform-specific payload *& communicate device operations
>>>>> internally within CDM. For example when an user sends a device operation
>>>>> using CDM web-console, *platform-independent *message will be sent
>>>>> from the console -> CDM API -> CDM Core -> Device-platform bundle. Then 
>>>>> the *device-platform
>>>>> bundle *will use it to cons

Re: [Architecture] Proposed Architecture of CDM

[Dilan Udara Ariyaratne]

Hi All,

I am having this little doubt about the use and the purpose of having a
device-specific OSGI Bundle at the server side.

By doing that, aren't we taking up the burden of handling all the
complexities/incompatibilities of the device side to the server side.

Isn't that possible to move this burden to the Device-side-agent, so that
the actual platform-specific-logic will be handled by the Device-side-agent
and
the CDM-server-side implementation will be much more generic, light-weight
and faster in execution, from the other end.

If the communication protocol is the problem from device to device, we can
just have the connector to bridge the gap.

I may not be right, so please excuse. This is just to clarify things.

Regards,

Dilan.



*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. 
Mobile: +94775149066
lean . enterprise . middleware

On Fri, Oct 31, 2014 at 9:57 AM, Harshan Liyanage  wrote:

> Actually the connector will only act as an interface to communicate with
> the device. Actual platform-specific logic & the payload to be sent to the
> device (for executing an operation) will be constructed by the
> platform-specific OSGi bundle.
>
> There won't be any connection between CDM-Console & platform-specific
> bundle or connector. When a new platform added, there will be a
> configuration which included the operations supported by the platform (it
> will depend on the platform version). The configuration will be something
> like belows (not-finalized). This configuration can be done through the
> CDM-console & it will be saved to the Registry or database. Initially we
> thought of saving it to the registry. But Inosh has pointed out that there
> might be situation where we'll have to join the information in this config
> with the data in database. In such cases we'll have to programatically join
> the results from db queries with the config (which would affect the
> performance). So we have not yet finalized where to save this
> configuration.
>
>  - Individual platform config
>
>  platformId - unique platform id
>
> name - platform name
>
> minOSVersion - minimum OS version supported
>
> maxOSVersion - maximum OS version supported
>
> description - A short description about the platform
>
> transports - Transport mechanisms / protocols supported
>
> payloadConfig - Payload configuration
>
> header - Payload header configuration
>
>  template - Header template
>
>  alwaysAppend (True/False) - Whether to append header for all
> communications
>
>  - Operation configuration
>
>  - Individual operation config
>
> operationId - Unique ID for operation
>
> code - Operation code
>
> name - Operation name
>
> description - Description
>
> type - One way / Two way
>
> payloadConfig - Payload configuration for the operation
>
>  appendHeader - Whether to append header or not
>
>  template - Payload template for the operation
>
>  parent - Parent element of this payload. This will be used for creating
> policies & sequence of operations.
>
>  - Optional parameter configuration. These parameters will be
> sent as data in the payload. This will be required when implementing
> dynamic policies/ rules. For example “Set device volume to 30%”
>
>  
>
> name - Param name
>
>  type - Param type (integer/ boolean/ float etc)
>
>  defaultValue - Default value sent if not specified
>
> minValue - Minimum permitted value
>
> maxValue - Max permitted value
>
> 
>
> 
>
> 
>
> 
>
> 
>
> But there may be cases like some devices may not support all the
> operations supported by the platform. So when invoking operations on a
> device we'll have to filter out the operations those are not supported. As
> Inosh has mentioned our agent app has to be modified to send the operations
> supported by the device to the CDM. Then CDM will know what are the
> operation supported by the device platform and by devices.
>
> Hope this clarifies your questions. I'll update the thread with proposed
> operation flow ASAP.
>
> Best Regards,
>
> Lakshitha Harshan
> Software Engineer
> Mobile: *+94724423048*
> Email: hars...@wso2.com
> Blog : http://harshanliyanage.blogspot.com/
> *WSO2, Inc. :** wso2.com *
> lean.enterprise.middleware.
>
> On Fri, Oct 31, 2014 at 9:09 AM, Sameera Perera  wrote:
>
>>
>> On Fri, Oct 31, 2014 at 9:04 AM, Dilshan Edirisuriya 
>> wrote:
>>
>>> Please see the comments for the question.
>>>
>>> 3) Does this APIs get exposed through API manager? If so how does the
>>> same API differentiate in multiple platforms? Does this have multiple APIs
>>> based on the platform?
>>> >>> Every device platform will have their own APIs. For example
>>> registration for iOS would be something like HOST/ios/register whereas for
>>> Android it would be something like HOST/android/register
>>>
>>
>> ​Correct: The purpose of the connector is to unify them in to a common
>> API that the console is aware of. Each connector will talk to the
>> platform's native API.​
>>
>>
>>
>> --
>>
>> 

Re: [Architecture] [Dev] [EMM] Policy Management Approach Used by Version 1.1.0

[Dilan Udara Ariyaratne]

Hi Dilshan,

Thanks for the feedback.

It is true that we need to go for some algorithm of doing the necessary
intersection + union calculations when resources from multiple resource
levels are attached.

But the key point that I am trying to figure out is that when we are
assigning resources from multiple resource levels to the same policy, it is
not any more possible to name that policy as
either a user level policy, platform level policy or a role level policy.

In that case, when multiple such policies are assigned to the same user, it
would no longer be possible to select an effective policy to be applied for
a device based on the priority.

Hence, my argument will be that the assignment of resources from multiple
resource levels to the same policy should not be possible from the UI.

Regards,
Dilan.



*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94775149066
lean . enterprise . middleware

On Thu, Jan 22, 2015 at 3:33 PM, Dilshan Edirisuriya 
wrote:

> Hi Dilan,
>
> Ideally if there are policies in all the assign resources such as users,
> roles and platforms intersection or union needs to be calculated based on
> the policy. Lets say for an example admin might have blocked camera for a
> role but specifically enable it for a certain set of users. In that case
> the most appropriate would be the user level policy and hence it needs more
> weight in that scenario. When it comes to other operations like VPN, LDAP,
> APN settings we could consider the union hence it represent the entire
> operation stack that the user needs to focus.
>
> Hence conceptually I would say that the current functionality to have
> multiple policies based on the assign resources could be present in normal
> usecases but the way we need to handle the compliance/monitoring needs to
> be defined based on the corresponding operation/policy.
>
> Regards,
>
> Dilshan
>
> On Thu, Jan 22, 2015 at 12:05 PM, Dilan Udara Ariyaratne 
> wrote:
>
>> Hi All,
>>
>> While going through the following documentation
>> https://docs.wso2.com/display/EMM110/Working+with+Policies
>> on managing policies, I came across the idea that a policy can be defined
>> on various levels.
>>
>> Namely user level (L1), platform level (L2) and role level (L3). L3
>> policies have the lowest priority. L2 policies override L3 policies, while
>> L1 policies override both L2 and L3 policies.
>>
>> Although it is not clearly defined, I guess that
>> [1] a user level policy is a policy to have only a set of users attached,
>> [2] a role level policy is a policy to have only a set of roles attached
>> and
>> [3] a platform level policy is a policy to have only a set of platforms
>> attached.
>>
>> However the question is that if we look into the EMM Web Console Admin UI
>> web page
>> on assigning resources, (i.e. users/roles/platforms) to a policy (see the
>> image attached), it is possible to
>> assign more than one resource type in a mix for a policy which is totally
>> against the documented way of defining policies.
>>
>> Is this a problem in the UI or have I misunderstood this concept totally?
>>
>> Appreciate your feedback on this.
>>
>> Thanks.
>>
>> *Dilan U. Ariyaratne*
>> Software Engineer
>> WSO2 Inc. <http://wso2.com/>
>> Mobile: +94775149066
>> lean . enterprise . middleware
>>
>
>
>
> --
> Dilshan Edirisuriya
> Senior Software Engineer - WSO2
> Mob: + 94 777878905
> http://wso2.com/
> https://www.linkedin.com/profile/view?id=50486426
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] CDM Policy Management Approach

[Dilan Udara Ariyaratne]

Hi All,

We are currently working on defining the most effective policy management
approach
to be used by the 1st release of CDM (or as of now, CDMF - Connected Device
Management Framework).

We have first analyzed the approach used by last version of EMM and found
out the use of following conventions with several concerns.

[1] A policy - Is a list of device-specific settings combined with some
predefined action upon non-compliance.
[2] A resource - Can be a user, a role or a platform.
[3] User level, Platform level and Role level - Are three types of resource
levels under which a resource was assigned to a policy.
[4] User level policy - Is a policy assigned to a set of users.
 (Current concerns: The existence of a separate user level policy is
questionable.
 Reason: A similar policy with the same output can be defined by
assigning some role to those users and creating a role level policy.)
[5] Platform level policy - Is a policy assigned to a set of platforms.
 (Current concerns: The existence of a separate platform level policy
is also questionable.
 Reason: According to the above definition of a policy, the policy
itself already implies a platform.)
[6] Role level policy - Is a policy assigned to a set of roles.
 (Current concerns: Since the existence of both user level and platform
level policies seems to be questionable,
 only the existence of a role level policy seems to be valid in this
context.)
[7] A priority for each resource level - Role level policies have the
lowest priority. Platform level policies override role level policies
 while user level policies override both platform level and role level
policies.
 (Current concerns: Since the existence of only a role level policy
seems to be valid, resource level priorities as mentioned above are no
longer useful.)
[8] Policy enforcement criteria -
 Criteria 1 - If a user with multiple policies of same
level enrolled, the last assigned policy was enforced on the user's device.
 Criteria 2 - If a user with multiple policies of different policy
levels enrolled, the policy with highest priority was enforced on the
user's device.
 Criteria 3 - If the administrator edited a policy that was attached to
a user, and if the newly edited policy and the assigned policy to the
device at that time belonged to the same level,
 then the newly edited policy was enforced on the user's device.
 Criteria 4 - If the administrator edited a policy that was assigned to
a user, and if the newly edited policy had a lower priority than the
assigned policy to the device at that time,
 then the newly edited policy was not enforced on the user's device.
 (Current concerns: Criteria 2 and 4 are no longer useful since the
existence of only a role level policy seems to be valid.)
[9] Compliance monitoring - Monitoring compliance of a device configuration
with settings assigned by the server, was carried out at the lapse
 of a certain time period. When a device was found to be non-compliant,
actions performed - Acknowledging the server, Warning the user and
Re-enforcing the Policy.

After considering the above concerns and industry standards used by other
competitive products in market place, it has been noticed that
the establishment of following conventions would be much more appropriate
in the context of both CDM and MDM.

[1] A device profile - Is a list of device-specific settings.
[2] A generic policy - Is a profile combined with some applicable set of
conditions.
[2] A compliance policy - Is a generic policy combined with some predefined
action upon non-compliance.
[3] Assigned roles, Excluded roles, Device ownership type, Time schedule,
Additionally Geo-fencing for mobile devices - Are applicable set conditions
of a policy.
[4] Policy enforcement criteria and the mode of compliance monitoring - Are
topics that are yet to be analyzed.

IoT use-cases are also to be discussed and mapped accordingly.
There will be frequent updates on this thread as things get discussed and
finalized.
Appreciate your valuable feedback on the material discussed during the
process.

Thank you.

*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. 
Mobile: +94775149066
lean . enterprise . middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] CDM Policy Management Approach

[Dilan Udara Ariyaratne]

Hi All,

Based on initial discussions, here follows (see the attachment) the basic
scope of work on
CDM Policy Management in the form of a use-case diagram.

Appreciate your valuable feedback on things that get discussed during the
process and
specially if some important part is missing on this initial sketch.

Thank you.
​​​
 cdm-policy-mgt-use-case.png
<https://docs.google.com/a/wso2.com/file/d/0B8AvZOQGEpMiOEtPN0R3ME8tLU0/edit?usp=drive_web>
​


*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94775149066
lean . enterprise . middleware

On Mon, Feb 2, 2015 at 7:53 PM, Dilan Udara Ariyaratne 
wrote:

> Hi All,
>
> We are currently working on defining the most effective policy management
> approach
> to be used by the 1st release of CDM (or as of now, CDMF - Connected
> Device Management Framework).
>
> We have first analyzed the approach used by last version of EMM and found
> out the use of following conventions with several concerns.
>
> [1] A policy - Is a list of device-specific settings combined with some
> predefined action upon non-compliance.
> [2] A resource - Can be a user, a role or a platform.
> [3] User level, Platform level and Role level - Are three types of
> resource levels under which a resource was assigned to a policy.
> [4] User level policy - Is a policy assigned to a set of users.
>  (Current concerns: The existence of a separate user level policy is
> questionable.
>  Reason: A similar policy with the same output can be defined by
> assigning some role to those users and creating a role level policy.)
> [5] Platform level policy - Is a policy assigned to a set of platforms.
>  (Current concerns: The existence of a separate platform level policy
> is also questionable.
>  Reason: According to the above definition of a policy, the policy
> itself already implies a platform.)
> [6] Role level policy - Is a policy assigned to a set of roles.
>  (Current concerns: Since the existence of both user level and platform
> level policies seems to be questionable,
>  only the existence of a role level policy seems to be valid in this
> context.)
> [7] A priority for each resource level - Role level policies have the
> lowest priority. Platform level policies override role level policies
>  while user level policies override both platform level and role level
> policies.
>  (Current concerns: Since the existence of only a role level policy
> seems to be valid, resource level priorities as mentioned above are no
> longer useful.)
> [8] Policy enforcement criteria -
>  Criteria 1 - If a user with multiple policies of same
> level enrolled, the last assigned policy was enforced on the user's device.
>  Criteria 2 - If a user with multiple policies of different policy
> levels enrolled, the policy with highest priority was enforced on the
> user's device.
>  Criteria 3 - If the administrator edited a policy that was attached
> to a user, and if the newly edited policy and the assigned policy to the
> device at that time belonged to the same level,
>  then the newly edited policy was enforced on the user's device.
>  Criteria 4 - If the administrator edited a policy that was assigned
> to a user, and if the newly edited policy had a lower priority than the
> assigned policy to the device at that time,
>  then the newly edited policy was not enforced on the user's device.
>  (Current concerns: Criteria 2 and 4 are no longer useful since the
> existence of only a role level policy seems to be valid.)
> [9] Compliance monitoring - Monitoring compliance of a device
> configuration with settings assigned by the server, was carried out at the
> lapse
>  of a certain time period. When a device was found to be
> non-compliant, actions performed - Acknowledging the server, Warning the
> user and Re-enforcing the Policy.
>
> After considering the above concerns and industry standards used by other
> competitive products in market place, it has been noticed that
> the establishment of following conventions would be much more appropriate
> in the context of both CDM and MDM.
>
> [1] A device profile - Is a list of device-specific settings.
> [2] A generic policy - Is a profile combined with some applicable set of
> conditions.
> [2] A compliance policy - Is a generic policy combined with some
> predefined action upon non-compliance.
> [3] Assigned roles, Excluded roles, Device ownership type, Time schedule,
> Additionally Geo-fencing for mobile devices - Are applicable set
> conditions of a policy.
> [4] Policy enforcement criteria and the mode of compliance monitoring -
> Are topics that are yet to be analyzed.
>
> IoT use-cases are also to be discussed and m

Re: [Architecture] CDM Policy Management Approach

[Dilan Udara Ariyaratne]

Hi Prabath,

Thanks for the feedback.

Anyway, the three types of policies mentioned in the post are actually the
existing policy levels in EMM 1.1.0.

Our idea on CDM is that having a separate definition for a platform level
policy and a user level policy
is not really necessary simply due to the following reasons.
[1] A platform is already implied once some device profile is configured to
a device.
[2] A set of users can anyway be represented by defining some role to
include them.

As a result, it is reasonable to argue that having a role level policy is
more than enough to do the job.

And when it comes to roles, your suggestion to have "groups" is indeed
correct and we are happy to consider that suggestion to our design
since it generalizes the criteria of grouping policies at CDM level for any
situation.

So, if I am to put your suggestion into a statement once again (Please
correct me if I am wrong),
"

*For profiles that we define for some specific device type, there would be
1-to-many grouping attributes that will define an applicable context to
each profile*".

Ex:
Consider a set of profiles that we define for some Android powered
smart-phones. Grouping-attributes can be
[1] Device-Ownership-Type,
[2] Assigned-Role
[3] Excluded-Role
[4] Time &
[5] Location

These attributes may drastically change for another set of profiles
that we define for some air-conditioners in a building.

Regards.

*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94775149066
lean . enterprise . middleware


On Thu, Feb 5, 2015 at 12:34 AM, Prabath Ariyarathna 
wrote:

> Hi Dilan
>
> I have a small suggestion on your proposal about the  policy levels. You
> have proposed three policy(User, Platform and Role) levels here and each
> policy level has predefined priority which cannot be changed accordingly.
> According to your mail, you are going to apply the  same approach to the
> IOT scenarios. I think, if we are going to the IOT arena, we need to
> facilitate the capabilities to define dynamic policy levels. I don’t like
> to name these as policy levels, these are actually groups based on some
> criteria's (Eg:- geographical,  Device Type, User Roles). We can apply
> different predefined priority levels to each of these groups. Then we can
> process these policy groups base on your proposed approach.
>
> Thanks
>
> On Mon, Feb 2, 2015 at 8:00 PM, Dilan Udara Ariyaratne 
> wrote:
>
>> Hi All,
>>
>> Based on initial discussions, here follows (see the attachment) the basic
>> scope of work on
>> CDM Policy Management in the form of a use-case diagram.
>>
>> Appreciate your valuable feedback on things that get discussed during the
>> process and
>> specially if some important part is missing on this initial sketch.
>>
>> Thank you.
>> ​​​
>>  cdm-policy-mgt-use-case.png
>> <https://docs.google.com/a/wso2.com/file/d/0B8AvZOQGEpMiOEtPN0R3ME8tLU0/edit?usp=drive_web>
>>
>>
>> *Dilan U. Ariyaratne*
>> Software Engineer
>> WSO2 Inc. <http://wso2.com/>
>> Mobile: +94775149066
>> lean . enterprise . middleware
>>
>> On Mon, Feb 2, 2015 at 7:53 PM, Dilan Udara Ariyaratne 
>> wrote:
>>
>>> Hi All,
>>>
>>> We are currently working on defining the most effective policy
>>> management approach
>>> to be used by the 1st release of CDM (or as of now, CDMF - Connected
>>> Device Management Framework).
>>>
>>> We have first analyzed the approach used by last version of EMM and
>>> found out the use of following conventions with several concerns.
>>>
>>> [1] A policy - Is a list of device-specific settings combined with some
>>> predefined action upon non-compliance.
>>> [2] A resource - Can be a user, a role or a platform.
>>> [3] User level, Platform level and Role level - Are three types of
>>> resource levels under which a resource was assigned to a policy.
>>> [4] User level policy - Is a policy assigned to a set of users.
>>>  (Current concerns: The existence of a separate user level policy
>>> is questionable.
>>>  Reason: A similar policy with the same output can be defined by
>>> assigning some role to those users and creating a role level policy.)
>>> [5] Platform level policy - Is a policy assigned to a set of platforms.
>>>  (Current concerns: The existence of a separate platform level
>>> policy is also questionable.
>>>  Reason: According to the above definition of a policy, the policy
>>> itself already implies a platform.)
>>> [6] Role level policy - Is a policy assigned to a set of roles.
>>>  (

[Architecture] [EMM] Common UI Template for Viewing All Resource Types in EMM

[Dilan Udara Ariyaratne]

Hi All,

Considering the lesser amount of time and effort that needs to be put
forward
and much more extendable + mobile friendly view that it would provide,
we have thought of coming up with a common UI Template for viewing all
resource types in EMM.
i.e. [1] Device, [2] Policy, [3] User

Using this template, following is how the device / Policy / User View would
look like.
(Attaching links to mock-ups)
​
 emm-device-view-ui-1.png

​​
 emm-policy-view-ui-1.png

​​
 emm-user-view-ui-1.png

​
Note: This was actually the template used also for the Policy-Creation-UI
of EMM.
(Attaching links to policy-creation-uis)
​
 emm-policy-create-ui-desktop.png

​​
 emm-policy-create-ui-mobile.png

​
WDYT?

Thanks.

*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. 
Mobile: +94775149066
lean . enterprise . middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [EMM] EMM 2.0.0 Dashboard Use-cases

[Dilan Udara Ariyaratne]

Hi All,

Following are some obvious use-cases for the dashboard view of EMM 2.0.0.
(Also considering our previous release of EMM 1.1.0 - see below)

​
​
Captured Use-cases :

[1] Stats on Devices
 Total Count
 Count By Platform (Android / iOS / Windows)
 Count By Ownership Type (COPE / BYOD)
 Count By Policy Compliance (Compliant / Violated)
 Device Location Feed - This would show frequently updated location
information on selected devices (By Platform / Ownership Type / Compliance
/ All)

[2] Stats on Users
 Total Count
 Count of Registered Users with Devices
  - Complaint User Count
  - Non-compliant User Count

[3] Stats on Policies
 Total Count
 Count By Platform (Android / iOS / Windows)
 Count By Ownership Type (COPE / BYOD)
 Count By Policy Compliance (Compliant / Violated)

[4] Device Enrollment Status
 Current :
 Active Devices Count
 Inactive Devices Count (Due to device unreachability for a long time)
 Blocked (or Suspended) Device Count (Due to being inactive for a long
time or Often Policy Violation)
 Overall History :
 Total Enrollments
 - Enrollment Count for Past Month
 - Enrollment Count for Past Week
 - Enrollment Count for Past Day
 Total Unenrollments

[5] Stats on Apps
 Most Installed Apps - Showing Top 5 Apps installed on devices with
each Platform
 Devices without Latest App Version - Showing (Device Count + App +
Platform) separation

Please provide your feedback if anything is missing ...

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - -

Also worked on a Dashboard UI Template for showing above use-cases at EMM
Front-end.
(Attaching links to Design Templates)
​
 admin-dashboard-view-3.png

​​
 user-dashboard-view-3.png


WDYT?

Cheers,
Dilan.

*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. 
Mobile: +94775149066
lean . enterprise . middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [EMM] EMM 2.0.0 Dashboard Use-cases

[Dilan Udara Ariyaratne]

Hi Yvonne,

When it comes to 'Count by policy compliance (Compliant/Violated), is it
possible to drill down to the policy level depiction?
Yes, it's possible to drill down to the detailed-policy-level depiction of
compliant & violated devices using following path.

Dashboard View of Complaint or Violated Devices ---}  Detailed List view of
Complaint or Violated Devices ---} Detailed Resource View of a Complaint or
Violated Device with currently effective policy information.

How about enabling to search figures bound to time (e.g. Total Enrolments)
within a custom time period?
Essentially, even if we compare other products like Airwatch, what they
have provided are static views as I described.
But your suggestion is indeed nice to have as an extended approach.

Regarding the 'Devices without Latest App Version - Showing (Device Count +
App + Platform) separation", can we give a picture of all the app versions
(up to date or not) of a given device?
Yes, this is possible by having a look at the "Installed Apps" section of
Device View.

Thanks.
Dilan.



*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. <http://wso2.com/>
Mobile: +94775149066
lean . enterprise . middleware

On Tue, Aug 4, 2015 at 3:51 PM, Yvonne Wickramasinghe 
wrote:

> Hi Dilan,
>
> When it comes to 'Count by policy compliance (Compliant/Violated), is it
> possible to drill down to the policy level depiction? For example, if there
> are three policies named ABC, PQR and XYZ, we may depict the total number
> of policy compliant and policy violated devices. Is there a way to depict
> the underlying policy compliance figures as below:
>
>- No of Policy Compliant Devices = x = (x1+x2+x3)
>   - No of ABC Policy Compliant Devices = x1
>   - No of PQR Policy Compliant Devices = x2
>   - No of XYZ Policy Compliant Devices = x3
>
>
>- No of Policy Violated Devices = y = (y1+y2+y3)
>   - No of ABC Policy Violated Devices = y1
>   - No of PQR Policy Violated Devices = y2
>   - No of XYZ Policy Violated Devices = y3
>
>
> How about enabling to search figures bound to time (e.g. Total Enrolments)
> within a custom time period? WDYT?
>
> Regarding the 'Devices without Latest App Version - Showing (Device Count
> + App + Platform) separation", can we give a picture of all the app
> versions (up to date or not) of a given device?
>
> Regards,
>
> On Mon, Aug 3, 2015 at 8:22 PM, Dilan Udara Ariyaratne 
> wrote:
>
>> Hi All,
>>
>> Following are some obvious use-cases for the dashboard view of EMM 2.0.0.
>> (Also considering our previous release of EMM 1.1.0 - see below)
>>
>> ​
>> ​
>> Captured Use-cases :
>>
>> [1] Stats on Devices
>>  Total Count
>>  Count By Platform (Android / iOS / Windows)
>>  Count By Ownership Type (COPE / BYOD)
>>  Count By Policy Compliance (Compliant / Violated)
>>  Device Location Feed - This would show frequently updated location
>> information on selected devices (By Platform / Ownership Type / Compliance
>> / All)
>>
>> [2] Stats on Users
>>  Total Count
>>  Count of Registered Users with Devices
>>   - Complaint User Count
>>   - Non-compliant User Count
>>
>> [3] Stats on Policies
>>  Total Count
>>  Count By Platform (Android / iOS / Windows)
>>  Count By Ownership Type (COPE / BYOD)
>>  Count By Policy Compliance (Compliant / Violated)
>>
>> [4] Device Enrollment Status
>>  Current :
>>  Active Devices Count
>>  Inactive Devices Count (Due to device unreachability for a long time)
>>  Blocked (or Suspended) Device Count (Due to being inactive for a
>> long time or Often Policy Violation)
>>  Overall History :
>>  Total Enrollments
>>  - Enrollment Count for Past Month
>>  - Enrollment Count for Past Week
>>  - Enrollment Count for Past Day
>>  Total Unenrollments
>>
>> [5] Stats on Apps
>>  Most Installed Apps - Showing Top 5 Apps installed on devices with
>> each Platform
>>  Devices without Latest App Version - Showing (Device Count + App +
>> Platform) separation
>>
>> Please provide your feedback if anything is missing ...
>>
>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>> - - - - - - -
>>
>> Also worked on a Dashboard UI Template for showing above use-cases at EMM
>> Front-end.
>> (Attaching links to Design Templates)
>> ​
>>  admin-dashboard-view-3.png
>> <https://drive.google.com/a/wso2.com/file/d/0B8AvZOQGEpM

[Architecture] Common UI Template for Listing All Resource Types in EMM 2.0.0

[Dilan Udara Ariyaratne]

Hi All,

Currently we are working on updating the existing List View UIs
with one common UI template that would cater all list-view-requirements in
EMM.

Earlier what we had were separate, custom design layouts for each list view
that did not fulfill following essential requirements.
[1] Basic Search
[2] Easily Customizable Advanced Data Filtering Support
[3] Pagination
[4] Un-disconnected end-user experience common to any resource list view.

As, Jquery Data-tables [1] already support these features, current plan is
on using data-tables to achieve $subject
with some level of customization and Jerad from UX team is currently
working on that aspect.

Following are the initial "data-table" inspired design wire-frames,
capturing all business-level use-cases for existing list views.
i.e. Device list view / Policy list view / User list view and Role list
view.
​
 device-list-view.png

​​
 policy-list-view.png

​​
 user-list-view.png

​​
 role-list-view.png


References:
https://www.datatables.net

Thanks.

*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. 
Mobile: +94725197942
lean . enterprise . middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [EMM] Android agent auto enrollment

[Dilan Udara Ariyaratne]

Hi Inosh,

Please find my questions regarding this process as follows.

[1] How are we planning to get an OOT for each serial and in-case of an
unenrollment, what is the process of getting a new OOT?
[2] Here, are plainning to do an enrollment without associating a user? if
not, how will be other management functionalities carried out upon
post-enrollment?

Thanks.



*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. 
Mobile: +94725197942
lean . enterprise . middleware

On Mon, Feb 1, 2016 at 3:49 PM, Inosh Perera  wrote:

> Hi Harshan/Chathura,
>
> @Harshan - As Ayyoob mentioned, we can use a custom grant type
> handler for retrieving tokens.
> @Chathura - The technician will login to the command line tool and carry
> out operations, this avoids the need to type credentials to the device each
> time we need to enroll.
> Since after more analysis, we realized, that even in this method, there
> can be issues such as the time it takes to install drivers when connecting
> a device to the PC/ driver unavailability that can be an issue. Therefore,
> I have  simplified the architecture as bellow.
>
>
> ​
> ​
> Regards,
> Inosh
>
>
> On Fri, Jan 29, 2016 at 12:41 AM, Ayyoob Hamza  wrote:
>
>> Hi Harshan
>>
>>>
>>> In the step 11, you have mentioned that the device sends authentication
>>> request, generate access and refresh tokens and send it to device. However
>>> you need client credentials (client key, secret) in-order to generate
>>> access tokens. How are you planing to get these client credentials prior to
>>> generating access tokens? In the existing EMM implementation we use
>>> Dynamic-client-registration to do that. I think we can use the same here.
>>> However we need to modify the flow diagram to reflect that.
>>>
>>
>> For bulk installation use case how about creating a custom grant type
>> handler which takes the OTT and validate and then provide an access token
>> as a response. Therefore in current flow we can replace the password grant
>> type handler with a custom grant type handler.
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Inosh Perera
> Software Engineer, WSO2 Inc.
> Tel: 077813 7285, 0785293686
>
> ___
> 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] [EMM] Enabling application white listing and application blacklisting support

[Dilan Udara Ariyaratne]

Hi Lakshman,

With respect to EMM space, I think that this requirement should be handled
from device policy level.

FYI, a device policy is a set of configurations that we set to be published
for a number of devices based on Roles and Users.
If we think about this requirement too in the same way, it is a application
level configuration that we publish for a set of devices based on Roles and
Users.

Therefore, It seems that you can integrate this use case with the existing
device policy UI [1] as two more feature additions to the "Configure
Profile" section.
i.e. One feature for White Listed Apps and the other for Black Listed Apps.

Thanks,
Dilan.


*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. 
Mobile: +94725197942
lean . enterprise . middleware

On Tue, Feb 2, 2016 at 5:47 PM, Lakshman Udayakantha 
wrote:

> [adding Dakshika]
>
> On Tue, Feb 2, 2016 at 5:45 PM, Lakshman Udayakantha 
> wrote:
>
>> Hi All,
>>
>> @KasunD/PrabathA: Thanks for your suggestions. I will check for methods
>> to block application installations for lower api level than 23 also.
>> I have created mockup UIs to create, edit , view lists which should be
>> added to app publisher UI and attached mockup UIs to this mail.
>> @UX team: Could you do a quick review and make suggestions to make them
>> better.
>>
>>
>> Thanks​​​
>>
>> On Tue, Feb 2, 2016 at 9:54 AM, Harshan Liyanage 
>> wrote:
>>
>>> Hi Inosh,
>>>
>>> There may be some cases where enterprises need to have application
>>> policies for individual users. But I think that scenario is very unlikely.
>>> If we take an organization, every user will map to one or more user-roles.
>>> There might be situations where a role has only one user (i.e like CEO,
>>> MD).  But still we can achieve it via the application policies for
>>> user-roles.
>>>
>>> Thanks,
>>>
>>> Harshan Liyanage
>>> Software Engineer
>>> Mobile: *+94724423048*
>>> Email: hars...@wso2.com
>>> Blog : http://harshanliyanage.blogspot.com/
>>> *WSO2, Inc. :** wso2.com *
>>> lean.enterprise.middleware.
>>>
>>> On Tue, Feb 2, 2016 at 9:37 AM, Inosh Perera  wrote:
>>>
 Hi all,

 Role based application restriction will be provided. Administrator will
 define a list of applications as a black list and a set of roles which is
 to be restricted to the application, along with the applications.
 Is there any particular reason for not having application policies for
 individual users?

 Regards,
 Inosh

 On Mon, Feb 1, 2016 at 11:05 PM, Prabath Abeysekera 
 wrote:

>
> On Mon, Feb 1, 2016 at 6:14 PM, Kasun Dananjaya Delgolla <
> kas...@wso2.com> wrote:
>
>> Hi Lakshman,
>>
>> In terms of Android you can use blocking APIs[1] in Marshmallow SDK
>> (SDK 23) to achieve this. We already use DevicePolicyManager API so you 
>> can
>> straightaway add these new stuff into the same android agent API layer.
>> Also for older API levels ( < 23) earlier we used a mechanism just to 
>> warn
>> the user if a blacklisted app is installed on the device since blocking 
>> of
>> apps is not supported in those API levels.
>>
>
> We might need to dig slightly deep into some of the APIs around and
> see if we've already got anything to mimic what's done in
> DevicePolicyManager, which is part of Marshmallow SDK; in previous 
> versions
> of Android SDK. So, please check if there's any mechanism that'd
> potentially allow us to go beyond merely warning the user when a
> blacklisted application is installed and then block the installation
> completely particularly targeting SDKs < 23.
>
> Cheers,
> Prabath
>
>
>>
>> One more thing, we can add this to the system app which I'm in the
>> process of building. Then we can enable COPE (rooted/system access 
>> granted)
>> devices to blacklist/whitelist apps even though the API level is < 23.
>>
>> [1] -
>> http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
>>
>> Thanks
>>
>> On Mon, Feb 1, 2016 at 5:50 PM, Lakshman Udayakantha <
>> lakshm...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>> There is a requirement to implement application white listing and
>>> application black listing support in Enterprise Mobility Manager.
>>> Application white listing means creating a list of applications which 
>>> are
>>> only allowed to run on mobile devices which are connected to EMM.
>>> Application blacklisting is the opposite meaning in which there is a 
>>> list
>>> of applications which are only not allowed to run on mobile devices 
>>> which
>>> connected to EMM.
>>> As a solution for this we thought to introduce a configuration to
>>> identify black listing, white listing enabled or not and exactly which
>>> listing is enabled and If each configuration enabled sepa

Re: [Architecture] iOS supervision mode enrollment Architecture

[Dilan Udara Ariyaratne]

Hi Tharindha,

With current implementation of iOS enrollment to EMM server, the mentioned
profile in step 9 is created on the fly by EMM server when
a device enrollment happens with the system.

If I assume that "Assign devices in step 6" means an enrollment of the
devices, shouldn't this "Request Profile in step 11"
happen as a sub-action of step 6 since it's a pre-requirement for the
enrollment?

Also as a side note, for improved clarity of this activity diagram, it is
better to introduce another swim lane for actor "EMM-admin" and initiate
all relevant requests
from there. Also, the arrow head of step 4 should be the other way around.

Thanks,
Dilan.



*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. 
Mobile: +94725197942
lean . enterprise . middleware

On Mon, Feb 8, 2016 at 11:50 AM, Tharinda Ehelepola 
wrote:

> Hi All,
>
> *Supervision was introduced by Apple in iOS 5 to differentiate
> institutionally-owned iPhones and iPads from personally-owned devices.
> Supervision is enabled using Apple Configurator
> , Device Enrollment
> Program  if
> purchased directly from Apple.*
>
>
>
> *Requirements - WSO2 should be registered in deploy.apple.com
>  as a organization- A device is needed which is
> directly purchased from apple *
> I have design below architecture for the iOS supervision mode enrollment.
>
>
> ​
> Regrads,
> Tharinda.
> --
>
> *Tharinda Ehelepola*
>
> *Software Engineering Intern*
> LinkedIn 
> TP :  94711834769
> Email: tharin...@wso2.com
> Web: tharinda.tk
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [CDMF] [EMM 2.1.0] Basic Use-cases for Dashboard Analytics Feature

[Dilan Udara Ariyaratne]

Hi All,

For the upcoming EMM 2.1.0 release, we have identified following basic
use-cases for
the Dashboard Analytics Feature with respect to devices.

[1] Device count by Platform
[2] Device count by Ownership (BYOD, COPE)
[3] Device count by Security Concerns
 - unmanaged (Meaning no policies currently assigned to the device)
 - non-compliant (Meaning a policy has been already assigned, but its
rules have been maliciously overridden by some other third party)
 - no passcode
 - no encryption
[4] Last Seen Overview - Devices seen in last 8 hours
 Last Seen Breakdown - Devices seen by dates (0-5, 5-15, 15-30, >30)
[5] Total enrollments, Re-enrollments & Unenrollments
[6] Devices based on location
 - Divisional map with Device counts
 - ability to zoom in for each division which will show device location
with tags
 - ability to click on each tag and go to individual device details

The dashboard will allow an EMM portal administrator to quickly navigate
from the overall view to a device listing view and then
zoom into an individual device to view device specific details.

WDYT? Any valuable suggestion is highly appreciated.

Thanks.

*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. 
Mobile: +94725197942
lean . enterprise . middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [CDMF] [EMM 2.1.0] Basic Use-cases for Reporting Feature

[Dilan Udara Ariyaratne]

Hi All,

For the upcoming EMM 2.1.0 release, we have identified following basic
use-cases
for the pre-defined reports of Reporting Feature with respect to devices,
policies and users.

[1] All MDM portal users, their privileges and last login time during a
given interval

[2] All devices grouped by their groups or subgroups

[3] Security policy report - policy configuration information, devices and
current security policy applied

[4] Audit trails
 - actions performed on specific device or group of devices
 - actions performed by specific user
 - changes made to a specific security profile

All reports will be viewable on the Web portal, and exportable to PDF.

WDYT? Any valuable suggestion is highly appreciated.

Thanks.

*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. 
Mobile: +94725197942
lean . enterprise . middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM][Analytics] Health monitor for APIM as a separate Java client

[Dilan Udara Ariyaratne]

Hi Maheshakya,

Can you also briefly explain how is this client going to monitor the health
of an API and
what considerations are being made to check the health?

Thanks.


*Dilan U. Ariyaratne*
Software Engineer
WSO2 Inc. 
Mobile: +94725197942
lean . enterprise . middleware

On Mon, Feb 15, 2016 at 12:34 PM, Lahiru Sandaruwan 
wrote:

> Hi Maheshakya,
>
>
> On Mon, Feb 15, 2016 at 11:59 AM, Maheshakya Wijewardena <
> mahesha...@wso2.com> wrote:
>
>> Hi,
>>
>> After discussing with API analytics team, the health monitor component
>> for API analytics has been decided to be implemented as a separate java
>> client.
>>
>
> What is the reason for this decision? The load on the APIM server if a
> stat publishing agent is run?
>
> Thanks.
>
>> This is essentially a scheduled program which pings the APIs to check
>> their statuses.
>> The conventional way of implementing this is by adding it as a scheduled
>> task in the ESB. But in the point view of deployment, this adds the
>> complexity of having an ESB just to host the health monitor for APIM.
>>
>> What would be the most appropriate solution to implement this health
>> monitor, considering both the intricacy of deployment and the standards.
>>
>> Best regards.
>> --
>> Pruthuvi Maheshakya Wijewardena
>> mahesha...@wso2.com
>> +94711228855
>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> --
> Lahiru Sandaruwan
> Committer and PMC member, Apache Stratos,
> Senior Software Engineer,
> WSO2 Inc., http://wso2.com
> lean.enterprise.middleware
>
> phone: +94773325954
> email: lahi...@wso2.com blog: http://lahiruwrites.blogspot.com/
> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>
>
> ___
> 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