[Architecture] Refactoring EMM UserModule

2014-05-04 Thread Chan
Hi folks,
I am currently working on the $subject for EMM 1.1.0 release. EMM 1.0.0
used the default jaggery carbon module and internal user and group modules
to solve the UM aspect. Below are some of the issues we have -

   - ​Coupling to the email
   - ​Roles creation is ambiguous (for example not write access to the User
   store)
   - User creation (no write access to User store)
   - Not supporting secondary User store
   - XACML usage

​The new UserModule aims to solve the above problems. There will be a
config file that has configs whether to enable internal role and user
creation. If enabled and write access is not provided - we create users and
roles internally. If disabled we will remove those elements from UI and
disable operations from the API. The new UserModule will always pass the
carbon user object [1]. All the static operations that will be used will be
under the UserModule.

The new UserModule will remove XACML for permission. Even though we used
XACML for permissions on operations in the last version (1.0.0) we didn't
see a real advantage of it for the features we had. For 1.1.0 we discussed
to remove XACML and use a database table to handle permissions for roles.
However -we'll be incorporating XACML in the future releases (1.2.0
perhaps) and will be giving the real advantage of it (eg:- time based
permissions, write your own XACML in EMM UI).

Cheers~

​[1] -
https://github.com/wso2/jaggery-extensions/blob/master/carbon/module/scripts/user/user.js
​

-- 
Chan (Dulitha Wijewantha)
Software Engineer - Mobile Development
WSO2Mobile
Lean.Enterprise.Mobileware
 * ~Email   duli...@wso2.com duli...@wso2mobile.com*
*  ~Mobile +94712112165*
*  ~Website   dulitha.me http://dulitha.me*
*  ~Twitter @dulitharw https://twitter.com/dulitharw*
  *~Github @dulichan https://github.com/dulichan*
  *~SO @chan http://stackoverflow.com/users/813471/chan*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


[Architecture] Writing a generic sql plugin for jaggery-entity

2014-05-04 Thread Chan
Hi folks,
I have started working on the $subject. Jaggery-Entity is a light weight
ORM that can be used to handle models in the business layer. Since we are
using an SQL datasource (H2) - I have started working on the SQL CRUD
plugin [2] for jaggery-entity. It will support

   - Insert
   - Update
   - Select (not implemented yet)
   - Delete (not implemented yet)


​Cheers~​

​[1] - https://github.com/splinter/jaggery-entity​
​[2] -
https://github.com/wso2-dev/product-emm/blob/feature/backend-refactor/modules/apps/emm/modules/sql-crud.js
​

-- 
Chan (Dulitha Wijewantha)
Software Engineer - Mobile Development
WSO2Mobile
Lean.Enterprise.Mobileware
 * ~Email   duli...@wso2.com duli...@wso2mobile.com*
*  ~Mobile +94712112165*
*  ~Website   dulitha.me http://dulitha.me*
*  ~Twitter @dulitharw https://twitter.com/dulitharw*
  *~Github @dulichan https://github.com/dulichan*
  *~SO @chan http://stackoverflow.com/users/813471/chan*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] Refactoring EMM UserModule

2014-05-04 Thread Gayan Gunawardana
Hi Chan,

As I understood situation is like this,

case 01: write access is not provided means read only LDAP or user store
cannot be modified, in that case we will create necessary roles internally
in order to function the system properly and we are not going to create any
users internally[1].

case 02: If write access is provided, we can create both users and roles in
the given user store (typically read/write LDAP)

In case 02 disable internal roles and case 01 only enable internal roles.
(Please correct me if I am wrong)

[1]https://docs.wso2.org/display/IS460/Configuring+Primary+User+Stores


On Sun, May 4, 2014 at 2:58 PM, Chan duli...@wso2.com wrote:

 Hi folks,
 I am currently working on the $subject for EMM 1.1.0 release. EMM 1.0.0
 used the default jaggery carbon module and internal user and group modules
 to solve the UM aspect. Below are some of the issues we have -

- ​Coupling to the email
- ​Roles creation is ambiguous (for example not write access to the
User store)
- User creation (no write access to User store)
- Not supporting secondary User store
- XACML usage

 ​The new UserModule aims to solve the above problems. There will be a
 config file that has configs whether to enable internal role and user
 creation. If enabled and write access is not provided - we create users and
 roles internally. If disabled we will remove those elements from UI and
 disable operations from the API. The new UserModule will always pass the
 carbon user object [1]. All the static operations that will be used will be
 under the UserModule.

 The new UserModule will remove XACML for permission. Even though we used
 XACML for permissions on operations in the last version (1.0.0) we didn't
 see a real advantage of it for the features we had. For 1.1.0 we discussed
 to remove XACML and use a database table to handle permissions for roles.
 However -we'll be incorporating XACML in the future releases (1.2.0
 perhaps) and will be giving the real advantage of it (eg:- time based
 permissions, write your own XACML in EMM UI).

 Cheers~

 ​[1] -
 https://github.com/wso2/jaggery-extensions/blob/master/carbon/module/scripts/user/user.js
 ​

 --
 Chan (Dulitha Wijewantha)
 Software Engineer - Mobile Development
 WSO2Mobile
 Lean.Enterprise.Mobileware
  * ~Email   duli...@wso2.com duli...@wso2mobile.com*
 *  ~Mobile +94712112165 %2B94712112165*
 *  ~Website   dulitha.me http://dulitha.me*
 *  ~Twitter @dulitharw https://twitter.com/dulitharw*
   *~Github @dulichan https://github.com/dulichan*
   *~SO @chan http://stackoverflow.com/users/813471/chan*




-- 
Gayan Gunawardana
Software Engineer; WSO2 Inc.; http://wso2.com/
Email: ga...@wso2.com
Mobile: +94 (71) 8020933
Blog: http://gayanj2ee.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] Refactoring EMM UserModule

2014-05-04 Thread Chan
On Sun, May 4, 2014 at 8:18 PM, Gayan Gunawardana ga...@wso2.com wrote:

 Hi Chan,

 As I understood situation is like this,

 case 01: write access is not provided means read only LDAP or user store
 cannot be modified, in that case we will create necessary roles internally
 in order to function the system properly and we are not going to create any
 users internally[1].


​Is it possible for us to create internal users as well? If so - Admins can
provision to test users within our system safely. ​



 case 02: If write access is provided, we can create both users and roles
 in the given user store (typically read/write LDAP)



 In case 02 disable internal roles and case 01 only enable internal roles.
 (Please correct me if I am wrong)


​In case 02 -we can make it optional to disable internal roles. For example
- if the admin wants to create a group without worrying about user store
roles to dynamically provision a policy. ​If an external user store is
configured -internal roles creation become optional. If not Internal role
creation is enabled. We can have a json config about the preference in case
of external user store. WDYT?




 [1]https://docs.wso2.org/display/IS460/Configuring+Primary+User+Stores


 On Sun, May 4, 2014 at 2:58 PM, Chan duli...@wso2.com wrote:

 Hi folks,
 I am currently working on the $subject for EMM 1.1.0 release. EMM 1.0.0
 used the default jaggery carbon module and internal user and group modules
 to solve the UM aspect. Below are some of the issues we have -

- ​Coupling to the email
- ​Roles creation is ambiguous (for example not write access to the
User store)
- User creation (no write access to User store)
- Not supporting secondary User store
- XACML usage

 ​The new UserModule aims to solve the above problems. There will be a
 config file that has configs whether to enable internal role and user
 creation. If enabled and write access is not provided - we create users and
 roles internally. If disabled we will remove those elements from UI and
 disable operations from the API. The new UserModule will always pass the
 carbon user object [1]. All the static operations that will be used will be
 under the UserModule.

 The new UserModule will remove XACML for permission. Even though we used
 XACML for permissions on operations in the last version (1.0.0) we didn't
 see a real advantage of it for the features we had. For 1.1.0 we discussed
 to remove XACML and use a database table to handle permissions for roles.
 However -we'll be incorporating XACML in the future releases (1.2.0
 perhaps) and will be giving the real advantage of it (eg:- time based
 permissions, write your own XACML in EMM UI).

 Cheers~

 ​[1] -
 https://github.com/wso2/jaggery-extensions/blob/master/carbon/module/scripts/user/user.js
 ​

 --
 Chan (Dulitha Wijewantha)
 Software Engineer - Mobile Development
 WSO2Mobile
 Lean.Enterprise.Mobileware
  * ~Email   duli...@wso2.com duli...@wso2mobile.com*
 *  ~Mobile +94712112165 %2B94712112165*
 *  ~Website   dulitha.me http://dulitha.me*
  *  ~Twitter @dulitharw https://twitter.com/dulitharw*
   *~Github @dulichan https://github.com/dulichan*
   *~SO @chan http://stackoverflow.com/users/813471/chan*




 --
 Gayan Gunawardana
 Software Engineer; WSO2 Inc.; http://wso2.com/
 Email: ga...@wso2.com
 Mobile: +94 (71) 8020933
 Blog: http://gayanj2ee.blogspot.com/




-- 
Chan (Dulitha Wijewantha)
Software Engineer - Mobile Development
WSO2Mobile
Lean.Enterprise.Mobileware
 * ~Email   duli...@wso2.com duli...@wso2mobile.com*
*  ~Mobile +94712112165*
*  ~Website   dulitha.me http://dulitha.me*
*  ~Twitter @dulitharw https://twitter.com/dulitharw*
  *~Github @dulichan https://github.com/dulichan*
  *~SO @chan http://stackoverflow.com/users/813471/chan*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] Refactoring EMM UserModule

2014-05-04 Thread Gayan Gunawardana
 ​Is it possible for us to create internal users as well? If so - Admins
 can provision to test users within our system safely. ​


AFAIK there is no internal users concept then we have to point to secondary
user store.



 case 02: If write access is provided, we can create both users and roles
 in the given user store (typically read/write LDAP)



 In case 02 disable internal roles and case 01 only enable internal roles.
 (Please correct me if I am wrong)


 ​In case 02 -we can make it optional to disable internal roles. For
 example - if the admin wants to create a group without worrying about user
 store roles to dynamically provision a policy. ​If an external user store
 is configured -internal roles creation become optional. If not Internal
 role creation is enabled. We can have a json config about the preference in
 case of external user store. WDYT?

This will make system more complex because of some roles are inside the
user store and some other roles are stored internally.



-- 
Gayan Gunawardana
Software Engineer; WSO2 Inc.; http://wso2.com/
Email: ga...@wso2.com
Mobile: +94 (71) 8020933
Blog: http://gayanj2ee.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] Refactoring EMM UserModule

2014-05-04 Thread Chan
On Sun, May 4, 2014 at 8:50 PM, Gayan Gunawardana ga...@wso2.com wrote:


 ​Is it possible for us to create internal users as well? If so - Admins
 can provision to test users within our system safely. ​


 AFAIK there is no internal users concept then we have to point to
 secondary user store.



 case 02: If write access is provided, we can create both users and roles
 in the given user store (typically read/write LDAP)



 In case 02 disable internal roles and case 01 only enable internal
 roles. (Please correct me if I am wrong)


 ​In case 02 -we can make it optional to disable internal roles. For
 example - if the admin wants to create a group without worrying about user
 store roles to dynamically provision a policy. ​If an external user store
 is configured -internal roles creation become optional. If not Internal
 role creation is enabled. We can have a json config about the preference in
 case of external user store. WDYT?

 This will make system more complex because of some roles are inside the
 user store and some other roles are stored internally.


​It does, internally. I think we need this functionality because - for
example sometimes the User Store will not allow us to read the roles or
create roles even if we have write access.

Cheers~​





 --
 Gayan Gunawardana
 Software Engineer; WSO2 Inc.; http://wso2.com/
 Email: ga...@wso2.com
 Mobile: +94 (71) 8020933
 Blog: http://gayanj2ee.blogspot.com/




-- 
Chan (Dulitha Wijewantha)
Software Engineer - Mobile Development
WSO2Mobile
Lean.Enterprise.Mobileware
 * ~Email   duli...@wso2.com duli...@wso2mobile.com*
*  ~Mobile +94712112165*
*  ~Website   dulitha.me http://dulitha.me*
*  ~Twitter @dulitharw https://twitter.com/dulitharw*
  *~Github @dulichan https://github.com/dulichan*
  *~SO @chan http://stackoverflow.com/users/813471/chan*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


[Architecture] Automated test case generation tool

2014-05-04 Thread Rukshan Chathuranga
Hi Malintha,Dharshana,Krishantha,

I followed the resource you provided.So After eclipse and maven
integration, i could implement a solution to test web Service using Robot
keyword driven testing.


   - Project contain the WSDL file and generate the java code
   - Create a Client class to test the web-service methods using generated
   code.
   - Created Client act as Keyword Library to Robot (Client Methods)
   - Project Contain the .txt file with test cases written in natural
   language keywords(Client Methods).
   - that .txt can be run using robot
   - Each of this step can be execute in one eclipse project.



​
 Thanks.


-- 
Department Of Computer Science  Engineering,
Faculty Of Engineering,
University Of Moratuwa.
Sri lanka.
WEB: http://rukspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] Future of Carbon UI Framework - Feedbacks needed !

2014-05-04 Thread Pubudu Dissanayake
Please refer my in-line comment


On Sun, Apr 27, 2014 at 7:37 AM, Joseph Fonseka jos...@wso2.com wrote:

 Hi

 Didn't find tenant management on the list has it been handled separately ?


​It is listed under WSO2 IS configure related UI components. ​



 +1 for moving the UI out of the Kernal but what are the benefits we are
 targeting from this ?





 Thanks
 Jo




-- 
*Pubudu Dissanayake*
 Software Engineer
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware
Mobile: 0775503304
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] Refactoring EMM UserModule

2014-05-04 Thread Ruchira Wageesha
On Sun, May 4, 2014 at 2:58 PM, Chan duli...@wso2.com wrote:

 Hi folks,
 I am currently working on the $subject for EMM 1.1.0 release. EMM 1.0.0
 used the default jaggery carbon module and internal user and group modules
 to solve the UM aspect. Below are some of the issues we have -

- ​Coupling to the email
- ​Roles creation is ambiguous (for example not write access to the
User store)
- User creation (no write access to User store)
- Not supporting secondary User store
- XACML usage

 ​The new UserModule aims to solve the above problems. There will be a
 config file that has configs whether to enable internal role and user
 creation. If enabled and write access is not provided - we create users and
 roles internally. If disabled we will remove those elements from UI and
 disable operations from the API. The new UserModule will always pass the
 carbon user object [1]. All the static operations that will be used will be
 under the UserModule.

Why you need to write a new module, instead of that, can't you improve the
existing one?



 The new UserModule will remove XACML for permission. Even though we used
 XACML for permissions on operations in the last version (1.0.0) we didn't
 see a real advantage of it for the features we had. For 1.1.0 we discussed
 to remove XACML and use a database table to handle permissions for roles.
 However -we'll be incorporating XACML in the future releases (1.2.0
 perhaps) and will be giving the real advantage of it (eg:- time based
 permissions, write your own XACML in EMM UI).

 Cheers~

 ​[1] -
 https://github.com/wso2/jaggery-extensions/blob/master/carbon/module/scripts/user/user.js
 ​

 --
 Chan (Dulitha Wijewantha)
 Software Engineer - Mobile Development
 WSO2Mobile
 Lean.Enterprise.Mobileware
  * ~Email   duli...@wso2.com duli...@wso2mobile.com*
 *  ~Mobile +94712112165 %2B94712112165*
 *  ~Website   dulitha.me http://dulitha.me*
 *  ~Twitter @dulitharw https://twitter.com/dulitharw*
   *~Github @dulichan https://github.com/dulichan*
   *~SO @chan http://stackoverflow.com/users/813471/chan*

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




-- 

*Ruchira Wageesha**Associate Technical Lead*
*WSO2 Inc. - lean . enterprise . middleware |  wso2.com http://wso2.com*

*email: ruch...@wso2.com ruch...@wso2.com,   blog:
ruchirawageesha.blogspot.com http://ruchirawageesha.blogspot.com,
mobile: +94 77 5493444*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] EMM - UI Design

2014-05-04 Thread Pubudu Dissanayake
Please refer my in-line comment.


On Sun, May 4, 2014 at 9:29 AM, Chanaka Jayasena chan...@wso2.com wrote:

 I agree that we need to unify the look and feel of these UIs. When working
 with WSO2 Cloud the importance of unified look and feel is more visible.
 Considering the top and left menus usability wise both have pros and cons.
 Generally it's good to have a left side menu when there are growing number
 of options for it. In the Cloud UI it's better to have the menu at the top,
 since we have to inject the same menu to the App Factory UI and API
 Store/Publisher UIs.

 @Dilshan, API Store, API Publisher, and App Factory is done with an older
 version of Caramel. This is why there is a significant difference in the
 coding pattern. I don't think Caramel existed when the API Store/Manger
 applications were started developing. The latest version of Caremel we use
 for Stratos Web Console is way better than the older versions. It pushes
 front end developers to write clean code without messing with complex
 jQuery Dom manipulation to present data to the UI. We have handlebars.js
 with Caramel. Even though handebars.js ( Template Engine)  and AngularJS (
 HTML Compiler and data binder )  is completely different things, using them
 together doesn't make sense IMO. Chthura please do a research and find out
 that his need for AngularJS is filled by handebars.js or not.

 To have a consistent look and feel in Carbon products, the way Carbon UI
 initially developed helped. If we can have a similar patten where there is
 a core component with default styles, layout and let each product override
 these styles with there own, it will drive every product to have a common
 look and feel.

 ​Indeed, ​Having unified UI framework is a must and let products to build
their own UI is a bad idea. We should come up with a proper structure (
previous carbon releases has this component.xml based approach ) therefore
we can build on top of it (hence can re-use it for future carbon UI
framework) . IMO consistency has to be there.


 thanks,
 Chanaka

 --
*Pubudu Dissanayake*
 Software Engineer
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware
Mobile: 0775503304
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] EMM - UI Design

2014-05-04 Thread Harshan Liyanage
Hi,

It's true that we should have unified UI's for all the applications. But
reinventing the front-end MVC frameworks won't be a good idea (agree with
Chan's idea). IMO we should look deeper into this and find a proper way to
do the front-ends of our application (at least selecting the technologies 
setting-up guidelines for UI design will be helpful).

Thanks,

Best 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, May 5, 2014 at 9:44 AM, Pubudu Dissanayake pubu...@wso2.com wrote:

 Please refer my in-line comment.


 On Sun, May 4, 2014 at 9:29 AM, Chanaka Jayasena chan...@wso2.com wrote:

 I agree that we need to unify the look and feel of these UIs. When
 working with WSO2 Cloud the importance of unified look and feel is more
 visible. Considering the top and left menus usability wise both have pros
 and cons. Generally it's good to have a left side menu when there are
 growing number of options for it. In the Cloud UI it's better to have the
 menu at the top, since we have to inject the same menu to the App Factory
 UI and API Store/Publisher UIs.

 @Dilshan, API Store, API Publisher, and App Factory is done with an older
 version of Caramel. This is why there is a significant difference in the
 coding pattern. I don't think Caramel existed when the API Store/Manger
 applications were started developing. The latest version of Caremel we use
 for Stratos Web Console is way better than the older versions. It pushes
 front end developers to write clean code without messing with complex
 jQuery Dom manipulation to present data to the UI. We have handlebars.js
 with Caramel. Even though handebars.js ( Template Engine)  and AngularJS (
 HTML Compiler and data binder )  is completely different things, using them
 together doesn't make sense IMO. Chthura please do a research and find out
 that his need for AngularJS is filled by handebars.js or not.

 To have a consistent look and feel in Carbon products, the way Carbon UI
 initially developed helped. If we can have a similar patten where there is
 a core component with default styles, layout and let each product override
 these styles with there own, it will drive every product to have a common
 look and feel.

 ​Indeed, ​Having unified UI framework is a must and let products to build
 their own UI is a bad idea. We should come up with a proper structure (
 previous carbon releases has this component.xml based approach ) therefore
 we can build on top of it (hence can re-use it for future carbon UI
 framework) . IMO consistency has to be there.


 thanks,
 Chanaka

 --
 *Pubudu Dissanayake*
  Software Engineer
 WSO2 Inc.; http://wso2.com
 lean.enterprise.middleware
 Mobile: 0775503304

 ___
 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] WSO2 Con back-end application move to WSO2 cloud

2014-05-04 Thread Amila Maha Arachchi
SumedhaS,

Can you deploy the above mentioned jaggery modules to dev,test and prod AS
instances in cloud preview and reply to this thread.


On Sat, May 3, 2014 at 8:51 AM, Amila Maha Arachchi ami...@wso2.com wrote:

 AFAIR we have some of the mentioned modules in the AS at the moment. We'll
 check what is missing and add them. Thanks for letting us know about this.


 On Saturday, May 3, 2014, Indika Sampath indi...@wso2.com wrote:

 Hi Amila,

 I created my own tenant and deploy the con_api jaggery app in the App
 Cloud. Build and Deployment succeeded but I got an issue when I going to
 test it. The reason was this application used number of modules. Those are
 as below.

- caramel
- markdown
- handlebars
- pipe

 Above modules must reside in the *modules* folder of the WSO2
 Application Server (wso2as-5.2.0/modules) or any other WSO2 server which
 support artifact deployment. Is there a way to add this external modules to
 the App cloud ? I think Application server has to be restarted once we add
 these modules.

 Cheers!



 On Fri, May 2, 2014 at 12:31 PM, Amila Maha Arachchi ami...@wso2.comwrote:

 Hi Indika,

 You can deploy the con_api, wso2_con_api (DB) and con_front in the app
 cloud (try with your own tenant). Then I believe you need to go the API
 Cloud and create and publish the API.




 On Fri, May 2, 2014 at 12:18 PM, Indika Sampath indi...@wso2.com wrote:

 Hi All,

 We are planing to move the WSO2 Con application back-end application to
 the WSO2 cloud as we had a discussion with Sanjiva. Following are the
 artifacts which needs to moved to the WSO2 cloud.

- con_api - Jaggery application written using Jaggery pipe
- wso2_con_api - MySQL database to store the con related data
- con_front - Static HTML application which provide admin console to
feed data


 The current deployment done in the WSO2 API-M. Also MySQL database
 installed in the same server. Herewith I have attached the high level
 diagram of the current deployment. Sajiva showed us number of issues in
 this deployment and suggested to move everything to the WSO2 cloud.

 Following are the facts we need to consider when move to the WSO2 cloud.

- Currently All GET endpoints are not secured. POST/PUT/DELETE
endpoints are secured with OAuth. We need to secure all the endpoints
regardless of the GET/POST/PUT/DELETE.
- The two mobile apps (android and iOS) are consume GET endpoints.
After we secured the all endpoints there will be refactoring to the both
mobile application.
- In the same way con_front application has to do the modification in
the GET endpoints.
- We are currently use the password grant type for generate the token.


 We appreciate if there is any suggestions.

 Cheers!


 --
 Indika Sampath
 Software Engineer
 WSO2 Inc.
 http://wso2.com

 Phone: +94 716 424 744
 Blog: http://indikasampath.blogspot.com/




 --
 *Amila Maharachchi*
 Senior Technical Lead
 WSO2, Inc.; http://wso2.com

 Blog: http://maharachchi.blogspot.com
 Mobile: +94719371446




 --
 Indika Sampath
 Software Engineer
 WSO2 Inc.
 http://wso2.com

 Phone: +94 716 424 744
 Blog: http://indikasampath.blogspot.com/



 --
 *Amila Maharachchi*
 Senior Technical Lead
 WSO2, Inc.; http://wso2.com

 Blog: http://maharachchi.blogspot.com
 Mobile: +94719371446





-- 
*Amila Maharachchi*
Senior Technical Lead
WSO2, Inc.; http://wso2.com

Blog: http://maharachchi.blogspot.com
Mobile: +94719371446
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] WSO2 Con back-end application move to WSO2 cloud

2014-05-04 Thread Sumedha Kodithuwakku
Hi Amila,

Sure. Will do

Thanks
SumedhaS


On Mon, May 5, 2014 at 10:21 AM, Amila Maha Arachchi ami...@wso2.comwrote:

 SumedhaS,

 Can you deploy the above mentioned jaggery modules to dev,test and prod AS
 instances in cloud preview and reply to this thread.


 On Sat, May 3, 2014 at 8:51 AM, Amila Maha Arachchi ami...@wso2.comwrote:

 AFAIR we have some of the mentioned modules in the AS at the moment.
 We'll check what is missing and add them. Thanks for letting us know about
 this.


 On Saturday, May 3, 2014, Indika Sampath indi...@wso2.com wrote:

 Hi Amila,

 I created my own tenant and deploy the con_api jaggery app in the App
 Cloud. Build and Deployment succeeded but I got an issue when I going to
 test it. The reason was this application used number of modules. Those are
 as below.

- caramel
- markdown
- handlebars
- pipe

 Above modules must reside in the *modules* folder of the WSO2
 Application Server (wso2as-5.2.0/modules) or any other WSO2 server which
 support artifact deployment. Is there a way to add this external modules to
 the App cloud ? I think Application server has to be restarted once we add
 these modules.

 Cheers!



 On Fri, May 2, 2014 at 12:31 PM, Amila Maha Arachchi ami...@wso2.comwrote:

 Hi Indika,

 You can deploy the con_api, wso2_con_api (DB) and con_front in the app
 cloud (try with your own tenant). Then I believe you need to go the API
 Cloud and create and publish the API.




 On Fri, May 2, 2014 at 12:18 PM, Indika Sampath indi...@wso2.comwrote:

 Hi All,

 We are planing to move the WSO2 Con application back-end application to
 the WSO2 cloud as we had a discussion with Sanjiva. Following are the
 artifacts which needs to moved to the WSO2 cloud.

- con_api - Jaggery application written using Jaggery pipe
- wso2_con_api - MySQL database to store the con related data
- con_front - Static HTML application which provide admin console to
feed data


 The current deployment done in the WSO2 API-M. Also MySQL database
 installed in the same server. Herewith I have attached the high level
 diagram of the current deployment. Sajiva showed us number of issues in
 this deployment and suggested to move everything to the WSO2 cloud.

 Following are the facts we need to consider when move to the WSO2 cloud.

- Currently All GET endpoints are not secured. POST/PUT/DELETE
endpoints are secured with OAuth. We need to secure all the endpoints
regardless of the GET/POST/PUT/DELETE.
- The two mobile apps (android and iOS) are consume GET endpoints.
After we secured the all endpoints there will be refactoring to the both
mobile application.
- In the same way con_front application has to do the modification
in the GET endpoints.
- We are currently use the password grant type for generate the
token.


 We appreciate if there is any suggestions.

 Cheers!


 --
 Indika Sampath
 Software Engineer
 WSO2 Inc.
 http://wso2.com

 Phone: +94 716 424 744
 Blog: http://indikasampath.blogspot.com/




 --
 *Amila Maharachchi*
 Senior Technical Lead
 WSO2, Inc.; http://wso2.com

 Blog: http://maharachchi.blogspot.com
 Mobile: +94719371446




 --
 Indika Sampath
 Software Engineer
 WSO2 Inc.
 http://wso2.com

 Phone: +94 716 424 744
 Blog: http://indikasampath.blogspot.com/



 --
 *Amila Maharachchi*
 Senior Technical Lead
 WSO2, Inc.; http://wso2.com

 Blog: http://maharachchi.blogspot.com
 Mobile: +94719371446





 --
 *Amila Maharachchi*
 Senior Technical Lead
 WSO2, Inc.; http://wso2.com

 Blog: http://maharachchi.blogspot.com
 Mobile: +94719371446




-- 
*Sumedha Kodithuwakku*
Software Engineer
WSO2 Inc. : wso2.com
lean . enterprise . middleware

Email: sumed...@wso2.com;  Mobile: +94 71 808 1124
Blog: http://sumedhask.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


[Architecture] EMM devices - Different types for unique fields

2014-05-04 Thread Niranjan Karunanandham
Hi all,

When refracting the code that there are three types of unique fields
[1https://github.com/wso2-dev/product-emm/commit/8396f05c8f82587f6e9eb1c6382138d6cf065381],
namely

   1. Generated by EMM server
   2. Generated by the Device
   3. Generated by the GCM / APNS

The token generated by the GCM / APNS should not be used for communication
between the device and the EMM server because it is generated by  third
party. We need to use either the generated by EMM server or by the device.
Currently in android un-registration, we are using the GCM registration ID
to communicate. This needs to be changed.


[1] -
https://github.com/wso2-dev/product-emm/commit/8396f05c8f82587f6e9eb1c6382138d6cf065381


Regards,
Nira

-- 

*Niranjan Karunanandham*
Senior Software Engineer - WSO2 Inc.
WSO2 Inc.: http://www.wso2.com
M: +94 777 749 661 http:///
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] WSO2 Con back-end application move to WSO2 cloud

2014-05-04 Thread Sumedha Kodithuwakku
Hi Amila,

I have deployed the above modules for the three environments.

@Indika,
Please check whether these are working as expected.

Thanks
SumedhaS


On Mon, May 5, 2014 at 10:24 AM, Sumedha Kodithuwakku sumed...@wso2.comwrote:

 Hi Amila,

 Sure. Will do

 Thanks
 SumedhaS


 On Mon, May 5, 2014 at 10:21 AM, Amila Maha Arachchi ami...@wso2.comwrote:

 SumedhaS,

 Can you deploy the above mentioned jaggery modules to dev,test and prod
 AS instances in cloud preview and reply to this thread.


 On Sat, May 3, 2014 at 8:51 AM, Amila Maha Arachchi ami...@wso2.comwrote:

 AFAIR we have some of the mentioned modules in the AS at the moment.
 We'll check what is missing and add them. Thanks for letting us know about
 this.


 On Saturday, May 3, 2014, Indika Sampath indi...@wso2.com wrote:

 Hi Amila,

 I created my own tenant and deploy the con_api jaggery app in the App
 Cloud. Build and Deployment succeeded but I got an issue when I going to
 test it. The reason was this application used number of modules. Those are
 as below.

- caramel
- markdown
- handlebars
- pipe

 Above modules must reside in the *modules* folder of the WSO2
 Application Server (wso2as-5.2.0/modules) or any other WSO2 server which
 support artifact deployment. Is there a way to add this external modules to
 the App cloud ? I think Application server has to be restarted once we add
 these modules.

 Cheers!



 On Fri, May 2, 2014 at 12:31 PM, Amila Maha Arachchi 
 ami...@wso2.comwrote:

 Hi Indika,

 You can deploy the con_api, wso2_con_api (DB) and con_front in the app
 cloud (try with your own tenant). Then I believe you need to go the API
 Cloud and create and publish the API.




 On Fri, May 2, 2014 at 12:18 PM, Indika Sampath indi...@wso2.comwrote:

 Hi All,

 We are planing to move the WSO2 Con application back-end application to
 the WSO2 cloud as we had a discussion with Sanjiva. Following are the
 artifacts which needs to moved to the WSO2 cloud.

- con_api - Jaggery application written using Jaggery pipe
- wso2_con_api - MySQL database to store the con related data
- con_front - Static HTML application which provide admin console
to feed data


 The current deployment done in the WSO2 API-M. Also MySQL database
 installed in the same server. Herewith I have attached the high level
 diagram of the current deployment. Sajiva showed us number of issues in
 this deployment and suggested to move everything to the WSO2 cloud.

 Following are the facts we need to consider when move to the WSO2 cloud.

- Currently All GET endpoints are not secured. POST/PUT/DELETE
endpoints are secured with OAuth. We need to secure all the endpoints
regardless of the GET/POST/PUT/DELETE.
- The two mobile apps (android and iOS) are consume GET endpoints.
After we secured the all endpoints there will be refactoring to the both
mobile application.
- In the same way con_front application has to do the modification
in the GET endpoints.
- We are currently use the password grant type for generate the
token.


 We appreciate if there is any suggestions.

 Cheers!


 --
 Indika Sampath
 Software Engineer
 WSO2 Inc.
 http://wso2.com

 Phone: +94 716 424 744
 Blog: http://indikasampath.blogspot.com/




 --
 *Amila Maharachchi*
 Senior Technical Lead
 WSO2, Inc.; http://wso2.com

 Blog: http://maharachchi.blogspot.com
 Mobile: +94719371446




 --
 Indika Sampath
 Software Engineer
 WSO2 Inc.
 http://wso2.com

 Phone: +94 716 424 744
 Blog: http://indikasampath.blogspot.com/



 --
 *Amila Maharachchi*
 Senior Technical Lead
 WSO2, Inc.; http://wso2.com

 Blog: http://maharachchi.blogspot.com
 Mobile: +94719371446





 --
 *Amila Maharachchi*
 Senior Technical Lead
 WSO2, Inc.; http://wso2.com

 Blog: http://maharachchi.blogspot.com
 Mobile: +94719371446




 --
 *Sumedha Kodithuwakku*
 Software Engineer
 WSO2 Inc. : wso2.com
 lean . enterprise . middleware

 Email: sumed...@wso2.com;  Mobile: +94 71 808 1124
 Blog: http://sumedhask.blogspot.com/




-- 
*Sumedha Kodithuwakku*
Software Engineer
WSO2 Inc. : wso2.com
lean . enterprise . middleware

Email: sumed...@wso2.com;  Mobile: +94 71 808 1124
Blog: http://sumedhask.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture