Re: [Architecture] Extensions for Siddhi - Math operations

[Seshika Fernando]

Excellent! Some of these will be very useful for the Fraud Detection, and
Forecasting algorithms.

On Wed, Oct 15, 2014 at 5:34 PM, Lahiru Cooray  wrote:

> Hi,
>
> We have implemented below Math operations (all the Math operations available
> in Hive) as extensions to Siddhi engine.
>
> round(DOUBLE a)round(DOUBLE a, INT d)floor(DOUBLE a)ceil(DOUBLE a),
> ceiling(DOUBLE a)rand(), rand(INT seed)exp(DOUBLE a), exp(DECIMAL a)ln(DOUBLE
> a), ln(DECIMAL a)log10(DOUBLE a), log10(DECIMAL a)log2(DOUBLE a),
> log2(DECIMAL a)log(DOUBLE base, DOUBLE a)
> log(DECIMAL base, DECIMAL a)pow(DOUBLE a, DOUBLE p), power(DOUBLE a,
> DOUBLE p)sqrt(DOUBLE a), sqrt(DECIMAL a)bin(BIGINT a)hex(BIGINT a)
> hex(STRING a) hex(BINARY a)unhex(STRING a)conv(BIGINT num, INT from_base,
> INT to_base), conv(STRING num, INT from_base, INT to_base)abs(DOUBLE 
> a)pmod(INT
> a, INT b), pmod(DOUBLE a, DOUBLE b)sin(DOUBLE a), sin(DECIMAL a)asin(DOUBLE
> a), asin(DECIMAL a)cos(DOUBLE a), cos(DECIMAL a)acos(DOUBLE a),
> acos(DECIMAL a)tan(DOUBLE a), tan(DECIMAL a)atan(DOUBLE a), atan(DECIMAL
> a)degrees(DOUBLE a), degrees(DECIMAL a)radians(DOUBLE a), radians(DOUBLE
> a)positive(INT a), positive(DOUBLE a)negative(INT a), negative(DOUBLE 
> a)sign(DOUBLE
> a), sign(DECIMAL a)e()pi()
>
>
> Eg:You can use the operations as below:
>
> *from InStreamSample1*
> *select custom:pi()*
> *insert into OutStreamSample1;*
>
> *from InStreamSample1*
> *select custom:tan(parameter1)*
> *insert into OutStreamSample1;*
>
> *from InStreamSample1*
> *select custom:pmod(parameter1,parameter2)*
> *insert into OutStreamSample1;*
>
>
> We used built-in math operations available in java.lang.Math package and
> we have implemented the operations which are not available in the
> mentioned package (eg: pmod, positive,negative,unhex etc).
> Separate classes were created for each math operation/extension and custom
> function names are as same as the operation names in java.lang.Math.
>
> Appreciate if someone could point out if there are any other
> missing/needed operations or any improvements regarding this..
>
>
> Thanks,
> --
> *Lahiru Cooray*
> Software Engineer
> WSO2, Inc.;http://wso2.com/
> lean.enterprise.middleware
>
> Mobile: +94 715 654154
>
> ___
> 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] [APPFAC] Remote calls for API integration module

[Mahendran Pirinthapan]

Hi,

Currently the API integration module in app factory is a web service module. So 
the jaggery layer uses remote calls to access this module. To reduce these 
remote calls we are planning to register the API integration module as osgi 
service.

Thanks.

Mahendran Pirinthapan
Software Engineer | WSO2 Inc.
Mobile +94772378732.

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

Re: [Architecture] API Manager Authorization Server Decoupling

[Nuwan Dias]

I don't think we should be using the term 'External' or 'Ext' anywhere in
the configuration. It should just be 'KeyManager' (or similar) and default
value should be the implementation class names that are shipped with the
product OOTB.

On Wed, Oct 15, 2014 at 7:36 PM, Amila De Silva  wrote:

> Hi Sanjeewa,
>
> Why do we need an ApplicationClassName? I assume this is to provide an
> Abstraction for different Applications (or clients ) created from an
> External Authorization Server. If this is the case, do we really need to
> Abstract that out ? If I understood it correctly , we discussed about
> having one AppInfo object to represent an Application, which will have one
> or two common fields (like Consumer Key and Key Type) and then a Map to
> hold all the other Authorization Server specific fields .
>
> On Wed, Oct 15, 2014 at 5:57 AM, Sanjeewa Malalgoda 
> wrote:
>
>> Hi All,
>> Here is a brief update on status of External Key Management server -APIM
>> integration implementation.
>> We will move all External Key Management server related implementation
>> classes outside from impl and other API Manager related code. So once this
>> is completed we need to build this jar and put it to dropins directory and
>> restart server. And they need to add required configuration to configs. IMO
>> we need to begin this implementation with clear separation of external jar
>> file and API Manager implementation.
>>
>> For the moment we will use following package name for this newly added
>> package(if need we can change it in future).
>> org.wso2.carbon.apimgt.ext.keymgt
>> There we will have following package hierarchy
>> .
>> └── 1.0.0
>> ├── pom.xml
>> └── src
>> └── main
>> └── java
>> └── org
>> └── wso2
>> └── carbon
>> └── ext.keymgt
>> ├── APIManagerTest.java
>> ├── ExtKeyMgtAppInfoDTO.java
>> ├── ExtKeyMgtAuthenticator.java
>> ├── ExtKeyMgtDao.java
>> └── ExternalKeyManagerImpl.java
>>
>>
>> Here ExternalKeyManagerImpl will be implementation of KeyManager
>> interface.
>> ExtKeyMgtAppInfoDTO will be data level representation of application in
>> External Key Manager side. This should be implemented ApplicationInfo
>> interface.
>> ExtKeyMgtDao will be used to data access required to external key manager.
>> ExtKeyMgtAuthenticator will be used to authenticate requests. And we will
>> use it from authentication handler.
>>
>> Inside API MAnager we need to provide following 3 parameters as full
>> qualified class names. Then we will use that class names to create
>> instances when required. So we will add following configuration to key
>> manager section of api-manager configuration file.
>>
>> 
>>
>> org.wso2.carbon.ext.keymgt.ExtKeyMgtAppInfoDTO
>>
>> org.wso2.carbon.ext.keymgt.ExternalKeyManagerImpl
>>
>> org.wso2.carbon.ext.keymgt.ExtKeyMgtAuthenticator
>> 
>> Value
>> 
>> 
>>
>> If external key management server required additional parameters for
>> their implementation we can define those as properties in above
>> configuration. So we may use that to store external server urls and other
>> required parameters etc.
>> Please let us know your feedback and suggestions on this. Based on that
>> we can move forward and implement other required things.
>>
>>
>> Thanks,
>> Sanjeewa.
>>
>> On Tue, Oct 14, 2014 at 6:14 PM, Nuwan Dias  wrote:
>>
>>> Make sure the class name is OAuthApplication, not oAuthApplication.
>>>
>>> On Tue, Oct 14, 2014 at 6:09 PM, Roshan Wijesena 
>>> wrote:
>>>
 Hi All,

 After having few discussions we have decided to change our earlier
 proposed interface design bit and here I would like to briefly describe
 newly proposed interfaces and their tasks  below.

  Now we have three interfaces.

 1.oAuthApplication

 2.KeyManager.

 3.KeyValidationHandler.

  Third party authorization server implementation can write there own
 custom classes by implementing these interfaces and gain ability to perform
 below tasks.

  1 By implementing oAuthApplication interface Third party
 authorization server can introduce their own  custom attributes when they
 are creating an application via wso2apimanager. Sample custom attributes
 for example, scopes,grant_type, response_type,contacts etc..

  2. By implementing KeyManager interface Third party authorization
 server can create/update/delete/retrieve an oAuthApplication from their
 server. Further KeyManager interface will support to retrieve client meta
 data by reading introspection endpoint. Moreover Third party authorization
 server implementation can hard-code their custom properties/metadata to a
 config file and KeyManager interface will provide a method to re

[Architecture] Functionality of CAppDeployer cleanup operation

[KasunG Gajasinghe]

Hi,

I've been testing the CAppDeployer functionality these days. One thing I
noticed was that the cleanup operation in CappAxis2Deployer is an empty
code block!

Usually, the cleanup operation of an axis2 deployer gets called during the
termination of ConfigurationContext. ie. during a tenant unload for
tenants, and during a server shutdown for super-tenant. Is there any
special reason we have not implemented this method?

I think we have to implement this method, and call the cleanup operation of
the deployers of artifacts packed inside the CApp. Further,
CappAxis2Deployer maintains a list of currently deployed CApps in the
tenant. We have to remove all these references too. Otherwise, this will
cause severe memory leaks, isn't it?

WDYT?

Thanks,
KasunG

-- 

*Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc.
email: kasung AT spamfree wso2.com
linked-in: http://lk.linkedin.com/in/gajasinghe
blog: http://kasunbg.org
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] API Manager Authorization Server Decoupling

[Amila De Silva]

Hi Sanjeewa,

Why do we need an ApplicationClassName? I assume this is to provide an
Abstraction for different Applications (or clients ) created from an
External Authorization Server. If this is the case, do we really need to
Abstract that out ? If I understood it correctly , we discussed about
having one AppInfo object to represent an Application, which will have one
or two common fields (like Consumer Key and Key Type) and then a Map to
hold all the other Authorization Server specific fields .

On Wed, Oct 15, 2014 at 5:57 AM, Sanjeewa Malalgoda 
wrote:

> Hi All,
> Here is a brief update on status of External Key Management server -APIM
> integration implementation.
> We will move all External Key Management server related implementation
> classes outside from impl and other API Manager related code. So once this
> is completed we need to build this jar and put it to dropins directory and
> restart server. And they need to add required configuration to configs. IMO
> we need to begin this implementation with clear separation of external jar
> file and API Manager implementation.
>
> For the moment we will use following package name for this newly added
> package(if need we can change it in future).
> org.wso2.carbon.apimgt.ext.keymgt
> There we will have following package hierarchy
> .
> └── 1.0.0
> ├── pom.xml
> └── src
> └── main
> └── java
> └── org
> └── wso2
> └── carbon
> └── ext.keymgt
> ├── APIManagerTest.java
> ├── ExtKeyMgtAppInfoDTO.java
> ├── ExtKeyMgtAuthenticator.java
> ├── ExtKeyMgtDao.java
> └── ExternalKeyManagerImpl.java
>
>
> Here ExternalKeyManagerImpl will be implementation of KeyManager interface.
> ExtKeyMgtAppInfoDTO will be data level representation of application in
> External Key Manager side. This should be implemented ApplicationInfo
> interface.
> ExtKeyMgtDao will be used to data access required to external key manager.
> ExtKeyMgtAuthenticator will be used to authenticate requests. And we will
> use it from authentication handler.
>
> Inside API MAnager we need to provide following 3 parameters as full
> qualified class names. Then we will use that class names to create
> instances when required. So we will add following configuration to key
> manager section of api-manager configuration file.
>
> 
>
> org.wso2.carbon.ext.keymgt.ExtKeyMgtAppInfoDTO
>
> org.wso2.carbon.ext.keymgt.ExternalKeyManagerImpl
>
> org.wso2.carbon.ext.keymgt.ExtKeyMgtAuthenticator
> 
> Value
> 
> 
>
> If external key management server required additional parameters for their
> implementation we can define those as properties in above configuration. So
> we may use that to store external server urls and other required parameters
> etc.
> Please let us know your feedback and suggestions on this. Based on that we
> can move forward and implement other required things.
>
>
> Thanks,
> Sanjeewa.
>
> On Tue, Oct 14, 2014 at 6:14 PM, Nuwan Dias  wrote:
>
>> Make sure the class name is OAuthApplication, not oAuthApplication.
>>
>> On Tue, Oct 14, 2014 at 6:09 PM, Roshan Wijesena  wrote:
>>
>>> Hi All,
>>>
>>> After having few discussions we have decided to change our earlier
>>> proposed interface design bit and here I would like to briefly describe
>>> newly proposed interfaces and their tasks  below.
>>>
>>>  Now we have three interfaces.
>>>
>>> 1.oAuthApplication
>>>
>>> 2.KeyManager.
>>>
>>> 3.KeyValidationHandler.
>>>
>>>  Third party authorization server implementation can write there own
>>> custom classes by implementing these interfaces and gain ability to perform
>>> below tasks.
>>>
>>>  1 By implementing oAuthApplication interface Third party authorization
>>> server can introduce their own  custom attributes when they are creating an
>>> application via wso2apimanager. Sample custom attributes for example,
>>> scopes,grant_type, response_type,contacts etc..
>>>
>>>  2. By implementing KeyManager interface Third party authorization
>>> server can create/update/delete/retrieve an oAuthApplication from their
>>> server. Further KeyManager interface will support to retrieve client meta
>>> data by reading introspection endpoint. Moreover Third party authorization
>>> server implementation can hard-code their custom properties/metadata to a
>>> config file and KeyManager interface will provide a method to read that
>>> config file and generate corresponding  UIs in API manager store according
>>> to  configurations.
>>>
>>>  3. Finally,Third party authorization server can validate their
>>> tokens/subscriptions/scopes by implementing KeyValidationHandler interface.
>>>
>>> Regards
>>> Roshan.
>>>
>>> On Thu, Sep 4, 2014 at 11:14 PM, Amila De Silva  wrote:
>>>
 Hi,

 *Extension points for token validation*

>>>

Re: [Architecture] API Manager Authorization Server Decoupling

[Sanjeewa Malalgoda]

On Wed, Oct 15, 2014 at 6:30 PM, Prabath Siriwardena 
wrote:

> Quick feedback - please do not use DTO in the name: ExtKeyMgtAppInfoDTO
>
+1. It was mistake and will remove that.

Thanks,
sanjeewa.

>
> Thanks & regards,
> -Prabath
>
> On Wed, Oct 15, 2014 at 6:27 PM, Sanjeewa Malalgoda 
> wrote:
>
>> Hi All,
>> Here is a brief update on status of External Key Management server -APIM
>> integration implementation.
>> We will move all External Key Management server related implementation
>> classes outside from impl and other API Manager related code. So once this
>> is completed we need to build this jar and put it to dropins directory and
>> restart server. And they need to add required configuration to configs. IMO
>> we need to begin this implementation with clear separation of external jar
>> file and API Manager implementation.
>>
>> For the moment we will use following package name for this newly added
>> package(if need we can change it in future).
>> org.wso2.carbon.apimgt.ext.keymgt
>> There we will have following package hierarchy
>> .
>> └── 1.0.0
>> ├── pom.xml
>> └── src
>> └── main
>> └── java
>> └── org
>> └── wso2
>> └── carbon
>> └── ext.keymgt
>> ├── APIManagerTest.java
>> ├── ExtKeyMgtAppInfoDTO.java
>> ├── ExtKeyMgtAuthenticator.java
>> ├── ExtKeyMgtDao.java
>> └── ExternalKeyManagerImpl.java
>>
>>
>> Here ExternalKeyManagerImpl will be implementation of KeyManager
>> interface.
>> ExtKeyMgtAppInfoDTO will be data level representation of application in
>> External Key Manager side. This should be implemented ApplicationInfo
>> interface.
>> ExtKeyMgtDao will be used to data access required to external key manager.
>> ExtKeyMgtAuthenticator will be used to authenticate requests. And we will
>> use it from authentication handler.
>>
>> Inside API MAnager we need to provide following 3 parameters as full
>> qualified class names. Then we will use that class names to create
>> instances when required. So we will add following configuration to key
>> manager section of api-manager configuration file.
>>
>> 
>>
>> org.wso2.carbon.ext.keymgt.ExtKeyMgtAppInfoDTO
>>
>> org.wso2.carbon.ext.keymgt.ExternalKeyManagerImpl
>>
>> org.wso2.carbon.ext.keymgt.ExtKeyMgtAuthenticator
>> 
>> Value
>> 
>> 
>>
>> If external key management server required additional parameters for
>> their implementation we can define those as properties in above
>> configuration. So we may use that to store external server urls and other
>> required parameters etc.
>> Please let us know your feedback and suggestions on this. Based on that
>> we can move forward and implement other required things.
>>
>>
>> Thanks,
>> Sanjeewa.
>>
>> On Tue, Oct 14, 2014 at 6:14 PM, Nuwan Dias  wrote:
>>
>>> Make sure the class name is OAuthApplication, not oAuthApplication.
>>>
>>> On Tue, Oct 14, 2014 at 6:09 PM, Roshan Wijesena 
>>> wrote:
>>>
 Hi All,

 After having few discussions we have decided to change our earlier
 proposed interface design bit and here I would like to briefly describe
 newly proposed interfaces and their tasks  below.

  Now we have three interfaces.

 1.oAuthApplication

 2.KeyManager.

 3.KeyValidationHandler.

  Third party authorization server implementation can write there own
 custom classes by implementing these interfaces and gain ability to perform
 below tasks.

  1 By implementing oAuthApplication interface Third party
 authorization server can introduce their own  custom attributes when they
 are creating an application via wso2apimanager. Sample custom attributes
 for example, scopes,grant_type, response_type,contacts etc..

  2. By implementing KeyManager interface Third party authorization
 server can create/update/delete/retrieve an oAuthApplication from their
 server. Further KeyManager interface will support to retrieve client meta
 data by reading introspection endpoint. Moreover Third party authorization
 server implementation can hard-code their custom properties/metadata to a
 config file and KeyManager interface will provide a method to read that
 config file and generate corresponding  UIs in API manager store according
 to  configurations.

  3. Finally,Third party authorization server can validate their
 tokens/subscriptions/scopes by implementing KeyValidationHandler interface.

 Regards
 Roshan.

 On Thu, Sep 4, 2014 at 11:14 PM, Amila De Silva 
 wrote:

> Hi,
>
> *Extension points for token validation*
>
> These changes are the planned changes.
>
> 1. All the extensions will be done in Key Manager - Earlier it was
> suggeste

Re: [Architecture] API Manager Authorization Server Decoupling

[Prabath Siriwardena]

Quick feedback - please do not use DTO in the name: ExtKeyMgtAppInfoDTO

Thanks & regards,
-Prabath

On Wed, Oct 15, 2014 at 6:27 PM, Sanjeewa Malalgoda 
wrote:

> Hi All,
> Here is a brief update on status of External Key Management server -APIM
> integration implementation.
> We will move all External Key Management server related implementation
> classes outside from impl and other API Manager related code. So once this
> is completed we need to build this jar and put it to dropins directory and
> restart server. And they need to add required configuration to configs. IMO
> we need to begin this implementation with clear separation of external jar
> file and API Manager implementation.
>
> For the moment we will use following package name for this newly added
> package(if need we can change it in future).
> org.wso2.carbon.apimgt.ext.keymgt
> There we will have following package hierarchy
> .
> └── 1.0.0
> ├── pom.xml
> └── src
> └── main
> └── java
> └── org
> └── wso2
> └── carbon
> └── ext.keymgt
> ├── APIManagerTest.java
> ├── ExtKeyMgtAppInfoDTO.java
> ├── ExtKeyMgtAuthenticator.java
> ├── ExtKeyMgtDao.java
> └── ExternalKeyManagerImpl.java
>
>
> Here ExternalKeyManagerImpl will be implementation of KeyManager interface.
> ExtKeyMgtAppInfoDTO will be data level representation of application in
> External Key Manager side. This should be implemented ApplicationInfo
> interface.
> ExtKeyMgtDao will be used to data access required to external key manager.
> ExtKeyMgtAuthenticator will be used to authenticate requests. And we will
> use it from authentication handler.
>
> Inside API MAnager we need to provide following 3 parameters as full
> qualified class names. Then we will use that class names to create
> instances when required. So we will add following configuration to key
> manager section of api-manager configuration file.
>
> 
>
> org.wso2.carbon.ext.keymgt.ExtKeyMgtAppInfoDTO
>
> org.wso2.carbon.ext.keymgt.ExternalKeyManagerImpl
>
> org.wso2.carbon.ext.keymgt.ExtKeyMgtAuthenticator
> 
> Value
> 
> 
>
> If external key management server required additional parameters for their
> implementation we can define those as properties in above configuration. So
> we may use that to store external server urls and other required parameters
> etc.
> Please let us know your feedback and suggestions on this. Based on that we
> can move forward and implement other required things.
>
>
> Thanks,
> Sanjeewa.
>
> On Tue, Oct 14, 2014 at 6:14 PM, Nuwan Dias  wrote:
>
>> Make sure the class name is OAuthApplication, not oAuthApplication.
>>
>> On Tue, Oct 14, 2014 at 6:09 PM, Roshan Wijesena  wrote:
>>
>>> Hi All,
>>>
>>> After having few discussions we have decided to change our earlier
>>> proposed interface design bit and here I would like to briefly describe
>>> newly proposed interfaces and their tasks  below.
>>>
>>>  Now we have three interfaces.
>>>
>>> 1.oAuthApplication
>>>
>>> 2.KeyManager.
>>>
>>> 3.KeyValidationHandler.
>>>
>>>  Third party authorization server implementation can write there own
>>> custom classes by implementing these interfaces and gain ability to perform
>>> below tasks.
>>>
>>>  1 By implementing oAuthApplication interface Third party authorization
>>> server can introduce their own  custom attributes when they are creating an
>>> application via wso2apimanager. Sample custom attributes for example,
>>> scopes,grant_type, response_type,contacts etc..
>>>
>>>  2. By implementing KeyManager interface Third party authorization
>>> server can create/update/delete/retrieve an oAuthApplication from their
>>> server. Further KeyManager interface will support to retrieve client meta
>>> data by reading introspection endpoint. Moreover Third party authorization
>>> server implementation can hard-code their custom properties/metadata to a
>>> config file and KeyManager interface will provide a method to read that
>>> config file and generate corresponding  UIs in API manager store according
>>> to  configurations.
>>>
>>>  3. Finally,Third party authorization server can validate their
>>> tokens/subscriptions/scopes by implementing KeyValidationHandler interface.
>>>
>>> Regards
>>> Roshan.
>>>
>>> On Thu, Sep 4, 2014 at 11:14 PM, Amila De Silva  wrote:
>>>
 Hi,

 *Extension points for token validation*

 These changes are the planned changes.

 1. All the extensions will be done in Key Manager - Earlier it was
 suggested to allow GW to call directly to a different Authorization Server
 and use the result returned by that to validate the subscription. After
 some discussions it seemed that keeping GW intact and changing the validate
 operation in KM would be much simple. GW 

Re: [Architecture] API Manager Authorization Server Decoupling

[Sanjeewa Malalgoda]

Hi All,
Here is a brief update on status of External Key Management server -APIM
integration implementation.
We will move all External Key Management server related implementation
classes outside from impl and other API Manager related code. So once this
is completed we need to build this jar and put it to dropins directory and
restart server. And they need to add required configuration to configs. IMO
we need to begin this implementation with clear separation of external jar
file and API Manager implementation.

For the moment we will use following package name for this newly added
package(if need we can change it in future).
org.wso2.carbon.apimgt.ext.keymgt
There we will have following package hierarchy
.
└── 1.0.0
├── pom.xml
└── src
└── main
└── java
└── org
└── wso2
└── carbon
└── ext.keymgt
├── APIManagerTest.java
├── ExtKeyMgtAppInfoDTO.java
├── ExtKeyMgtAuthenticator.java
├── ExtKeyMgtDao.java
└── ExternalKeyManagerImpl.java


Here ExternalKeyManagerImpl will be implementation of KeyManager interface.
ExtKeyMgtAppInfoDTO will be data level representation of application in
External Key Manager side. This should be implemented ApplicationInfo
interface.
ExtKeyMgtDao will be used to data access required to external key manager.
ExtKeyMgtAuthenticator will be used to authenticate requests. And we will
use it from authentication handler.

Inside API MAnager we need to provide following 3 parameters as full
qualified class names. Then we will use that class names to create
instances when required. So we will add following configuration to key
manager section of api-manager configuration file.


org.wso2.carbon.ext.keymgt.ExtKeyMgtAppInfoDTO
org.wso2.carbon.ext.keymgt.ExternalKeyManagerImpl
org.wso2.carbon.ext.keymgt.ExtKeyMgtAuthenticator

Value



If external key management server required additional parameters for their
implementation we can define those as properties in above configuration. So
we may use that to store external server urls and other required parameters
etc.
Please let us know your feedback and suggestions on this. Based on that we
can move forward and implement other required things.


Thanks,
Sanjeewa.

On Tue, Oct 14, 2014 at 6:14 PM, Nuwan Dias  wrote:

> Make sure the class name is OAuthApplication, not oAuthApplication.
>
> On Tue, Oct 14, 2014 at 6:09 PM, Roshan Wijesena  wrote:
>
>> Hi All,
>>
>> After having few discussions we have decided to change our earlier
>> proposed interface design bit and here I would like to briefly describe
>> newly proposed interfaces and their tasks  below.
>>
>>  Now we have three interfaces.
>>
>> 1.oAuthApplication
>>
>> 2.KeyManager.
>>
>> 3.KeyValidationHandler.
>>
>>  Third party authorization server implementation can write there own
>> custom classes by implementing these interfaces and gain ability to perform
>> below tasks.
>>
>>  1 By implementing oAuthApplication interface Third party authorization
>> server can introduce their own  custom attributes when they are creating an
>> application via wso2apimanager. Sample custom attributes for example,
>> scopes,grant_type, response_type,contacts etc..
>>
>>  2. By implementing KeyManager interface Third party authorization
>> server can create/update/delete/retrieve an oAuthApplication from their
>> server. Further KeyManager interface will support to retrieve client meta
>> data by reading introspection endpoint. Moreover Third party authorization
>> server implementation can hard-code their custom properties/metadata to a
>> config file and KeyManager interface will provide a method to read that
>> config file and generate corresponding  UIs in API manager store according
>> to  configurations.
>>
>>  3. Finally,Third party authorization server can validate their
>> tokens/subscriptions/scopes by implementing KeyValidationHandler interface.
>>
>> Regards
>> Roshan.
>>
>> On Thu, Sep 4, 2014 at 11:14 PM, Amila De Silva  wrote:
>>
>>> Hi,
>>>
>>> *Extension points for token validation*
>>>
>>> These changes are the planned changes.
>>>
>>> 1. All the extensions will be done in Key Manager - Earlier it was
>>> suggested to allow GW to call directly to a different Authorization Server
>>> and use the result returned by that to validate the subscription. After
>>> some discussions it seemed that keeping GW intact and changing the validate
>>> operation in KM would be much simple. GW will always receive a uniform
>>> response irrespective of the Authorization Server used behind.
>>>
>>>
>>> 2 Use validate operation in OAuth2TokenValidationService instead of
>>> using APIKeyValidationService. - Behaviour of the validate operation of can
>>> be changed by providing a custom handler. We can put the current validate
>>> method

[Architecture] Extensions for Siddhi - Math operations

[Lahiru Cooray]

Hi,

We have implemented below Math operations (all the Math operations available
in Hive) as extensions to Siddhi engine.

round(DOUBLE a)round(DOUBLE a, INT d)floor(DOUBLE a)ceil(DOUBLE a),
ceiling(DOUBLE a)rand(), rand(INT seed)exp(DOUBLE a), exp(DECIMAL a)ln(DOUBLE
a), ln(DECIMAL a)log10(DOUBLE a), log10(DECIMAL a)log2(DOUBLE a),
log2(DECIMAL a)log(DOUBLE base, DOUBLE a)
log(DECIMAL base, DECIMAL a)pow(DOUBLE a, DOUBLE p), power(DOUBLE a, DOUBLE
p)sqrt(DOUBLE a), sqrt(DECIMAL a)bin(BIGINT a)hex(BIGINT a) hex(STRING a)
hex(BINARY a)unhex(STRING a)conv(BIGINT num, INT from_base, INT to_base),
conv(STRING num, INT from_base, INT to_base)abs(DOUBLE a)pmod(INT a, INT
b), pmod(DOUBLE a, DOUBLE b)sin(DOUBLE a), sin(DECIMAL a)asin(DOUBLE a),
asin(DECIMAL a)cos(DOUBLE a), cos(DECIMAL a)acos(DOUBLE a),
acos(DECIMAL a)tan(DOUBLE
a), tan(DECIMAL a)atan(DOUBLE a), atan(DECIMAL a)degrees(DOUBLE a),
degrees(DECIMAL a)radians(DOUBLE a), radians(DOUBLE a)positive(INT a),
positive(DOUBLE a)negative(INT a), negative(DOUBLE a)sign(DOUBLE a),
sign(DECIMAL a)e()pi()


Eg:You can use the operations as below:

*from InStreamSample1*
*select custom:pi()*
*insert into OutStreamSample1;*

*from InStreamSample1*
*select custom:tan(parameter1)*
*insert into OutStreamSample1;*

*from InStreamSample1*
*select custom:pmod(parameter1,parameter2)*
*insert into OutStreamSample1;*


We used built-in math operations available in java.lang.Math package and we
have implemented the operations which are not available in the mentioned
package (eg: pmod, positive,negative,unhex etc).
Separate classes were created for each math operation/extension and custom
function names are as same as the operation names in java.lang.Math.

Appreciate if someone could point out if there are any other missing/needed
operations or any improvements regarding this..


Thanks,
-- 
*Lahiru Cooray*
Software Engineer
WSO2, Inc.;http://wso2.com/
lean.enterprise.middleware

Mobile: +94 715 654154


Hive Math Operations (1).rtf
Description: RTF file
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [App-Fac] Deployment URL for Single Tenant Cartridges in App-Factory

[Roshan Deniyage]

Hi all,

In single tenant cartridges, in order to show the deployed url to the user,
there are two requirements to be satisfied.

(1) generate the url with newly spawned cartridge public IP (this is done)
(2) last deployed status of the application need to be success in
app-factory side runtime database. (this is the issue)


In multi-tenant case, it uses listeners with extension in wso2-as, but, in
single tenant case, there is no such extension points as per my
understanding.

we need to have a mechanism to update the last deployed status of the
application in app-factory side. one option is to introduce a related event
in stratos side.

any suggestion or comment would be appreciated on this issue.


Thanks,

Roshan Deniyage
Associate Technical Lead
WSO2, Inc: http://wso2.com

Mobile:  +94 777636406
Twitter:  *https://twitter.com/roshku *
LinkedIn :  https://www.linkedin.com/in/roshandeniyage
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [App-Fac] Approach to Generate Application URL of Application Types which uses Single Tenant Cartridges in App-Factory

[Roshan Deniyage]

Hi all,
I'm working on the feature and testing for php app types. Based on the
current approach of listening to stratos mb (active mq) and generating the
url is done. Currently in the process of persisting data to registry
component.

Thanks,

Roshan Deniyage
Associate Technical Lead
WSO2, Inc: http://wso2.com

Mobile:  +94 777636406
Twitter:  *https://twitter.com/roshku *
LinkedIn :  https://www.linkedin.com/in/roshandeniyage


On Wed, Oct 15, 2014 at 10:00 AM, Roshan Deniyage  wrote:

> Hi all,
>Thanks for the feedback. I'm working on the the topic subscription
> method and seems working fine.
>
> Thanks,
>
> Roshan Deniyage
> Associate Technical Lead
> WSO2, Inc: http://wso2.com
>
> Mobile:  +94 777636406
> Twitter:  *https://twitter.com/roshku *
> LinkedIn :  https://www.linkedin.com/in/roshandeniyage
>
>
> On Sun, Oct 12, 2014 at 6:39 PM, Lakmal Warusawithana 
> wrote:
>
>> Hi DImuthu,
>>
>> On Sat, Oct 11, 2014 at 9:56 PM, Dimuthu Leelarathne 
>> wrote:
>>
>>> Hi Lakmal,
>>>
>>> Why is polling better than having a Topology listener?
>>>
>>
>> Ok, I did not notice its polling. But what I thought is getting it from
>> rest API is better than custom extending, but if it required then its ok.
>>
>>
>>>
>>> thanks,
>>> dimuthu
>>>
>>> On Fri, Oct 10, 2014 at 10:18 AM, Lakmal Warusawithana 
>>> wrote:
>>>
 Hi Roshan,

 On Thu, Oct 9, 2014 at 10:12 PM, Roshan Deniyage 
 wrote:

> * Adding the missing images.*
>
> Hi All,
>
> Currently I’m working with php application type support for wso2
> appfactory product. The scenario is as follows,
>
> Multi-Tenant Cartridge Case
>
> The existing supported application types (ex: java web application)
> work with in-container multi-tenancy support which means those 
> applications
> run inside wso2 application server, deployed inside one cartridge instance
> of stratos (of course with many for clustering).
>
> Based on the current “dev setup” and “production deployment”, when new
> tenant is created with app factory, relevant tenant is created in the
> wso2-as of the shared cartridge instance illustrated as follows.
>
> The sample is for dev cloud without LB. (same as dev setup). The
> cartridge instance could be spawned before tenant is created. Hence, the
> “Public IP address” or the “DNS name” is know.
> [image: Inline image 1]
>
> ​
>
>
> Single Tenant Cartridge Case
>
> But, in the “php application type” case, no multi-tenant cartridges
> are there, we have to use single tenant cartridges with “apache http
> server”. In this case, Need to spawn a new instance when a new tenant is
> created. The workflow would be as follows.
>
> ​[image: Inline image 2]
>
>
>
> Generating Application URL of Single Tenant Application Types
>
> But the problem in single-tenant case is, the Public IP or the DNS
> name of the newly spawned cartridge is unknow. Or in case of clustering,
> the Public IP or the DNS name of the LB is unknow. Hence, In order to get
> the Public IP of entry point, I propose the following workflow.
> ​
> [image: Inline image 3]​
>
>
> The purpose of this design is to get the “Public IP of DNS Name” of
> the newly spawned cartridge or the LB of the cartridge cluster (If cluster
> is present). The logic is as follows,
>
>1.
>
>When server is started App-Fac’s “StratosMemberActivated Listener”
>is subscribed to topic in active mq.
>2.
>
>Tenant user create new single tenant type application.
>3.
>
>App-Fac do the necessary logic and then, subscribed to new
>cartridge via stratos controller.
>4.
>
>When cartridge is spawning it sends events to topic in active mq
>and when cartridge is activated, it send the “MemberActivated Event” 
> to the
>topic.
>5.
>
>App-Fac receives the “MemberActivated Event” and get the “Public
>IP” of the cartridge or the LB.
>6.
>
>App-Fac generates the “Application URL” using received public IP
>and store in the registry.
>7.
>
>When user request the “Application URL” of the newly created
>application, App-Fac get the url from registry.
>
>
>
> In this feature, upto figure :02 is already done and the application
> url generation has designed based on the figure: 03.
>
> NOTE : In order to get the cartridge’s Public IP or DNS name (or LB
> Public IP if clustering is present), there are 3 options.
>
>
>1.
>
>Subscribe to topic in stratos and get the relevant information.
>2.
>
>Stratos can provide a REST API and app-fac can pool to get the
>information.
>>>

Re: [Architecture] [APPFAC] .NET Apptype Support

[Kasun De Silva]

Hi All,
​​
Feature highlights are,

Archetype - Needs modifications. (Current archetype is more complex. IMO
archetype needs to be dynamic, as we have some hard coded configurations to
be dynamic and some files should be named in the app name but currently
doesn't because of the complexity of the archetype. Better if we have a
more simple archetype`WDYT? )

App Creation - Done

Building - Done

Deployment - Done

Promoting in to stages - Need more Testing

Retrieving deployment url - waiting on member activation listener

Docs - In Progress


AMIs

Jenkins windows slave  -  ami-263e1874
Windows-cartridge  -  ami-2e4c6a7c


Currently these AMI s are private but we can make them public when shipping
this feature.

This feature has been currently tested on M5, needs to be tested in M6
since we have done some big changes in app deployment.

IMO we should ship this as plug and play feature, since this has some
manual configurations as to set up the build server and so on, we can
provide the apptype.xml and instructions on how to plug it inside APPFAC
with the doc so anyone wants to play with it can use it WDYT ?

Please find the attached screen cast and the documentation below.

​
 Screencast dotnet apptype.mp4

​​
 .NET Support in WSO2AppFactory

​

Thanks,
Kasun


*Kasun de Silva*
Software Engineer | *WSO2 Inc.*; http://wso2.com
lean.enterprise.middleware

email   : kas...@wso2.com
mobile : +94 77 794 4260


On Mon, Sep 29, 2014 at 10:18 AM, Kasun De Silva  wrote:

> Hi Manula,
>
> Thanks a lot, I'm working on this now.
>
> Kasun
>
> *Kasun de Silva*
> Software Engineer | *WSO2 Inc.*; http://wso2.com
> lean.enterprise.middleware
>
> email   : kas...@wso2.com
> mobile : +94 77 794 4260
>
>
> On Mon, Sep 29, 2014 at 10:12 AM, Manula Chathurika Thantriwatte <
> manu...@wso2.com> wrote:
>
>> Hi Kasun,
>>
>> I have make that AMI as public. Windows cartridge AMI ID is : ami-f47d23a6
>>
>> Thanks !
>>
>> On Sun, Sep 28, 2014 at 12:52 PM, Kasun De Silva  wrote:
>>
>>> Hi Manula,
>>>
>>> Thanks for the response, it would be great if u can make it public since
>>> currently we don't have an windows image with IIS in openStack, so that, I
>>> can proceed with AMI for .NET support in AF. Currently I'm working on
>>> evaluating how solid using AMI and OpenStack for this matter, I'll let you
>>> know.
>>>
>>> Thanks,
>>> kasun
>>>
>>>
>>> *Kasun de Silva*
>>> Software Engineer | *WSO2 Inc.*; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> email   : kas...@wso2.com
>>> mobile : +94 77 794 4260
>>>
>>>
>>> On Sat, Sep 27, 2014 at 1:12 PM, Manula Chathurika Thantriwatte <
>>> manu...@wso2.com> wrote:
>>>
 Hi Kasun,

 We have already create an EC2 AMI for windows cartridge. All the
 configurations such as IIS, agent, start up scrips, etc... configured in
 this AMI. We have used EC2 because windows server 2012 is already available
 as EC2 AMI. If you have windows image in OpenStack you can proceed with
 that also. Currently the AMI we have created is visible only for private.
 If you want we can make it to public as well.

 Thanks !


 On Sat, Sep 27, 2014 at 12:50 PM, Kasun De Silva 
 wrote:

> Hi,
>
> I'm working on .NET AppType support in AF. Currently phase 1 and phase
> 2 are almost complete, as now AF it self can create and build .NET web
> apps. The next phase is deploying .NET web apps inside IIS cartridge.
>
> Currently private pass team has been experimented on an IIS cartridge
> which can be found in [1]. This approach has been tested with Ec2. we can
> also use openstack for this.
>
> I'm looking forward to use the cartridge stated on [1] with AF for
> this feature with EC2 or OpenStack.
>
> What would be more solid when using [1] with AF using ec2 or
> openstack, WDYT?
>
> [1]
> http://wso2.com/library/webinars/2014/07/saas-app-development-with-windows-cartridge/
>
>
> Thanks,
> Kasun
>
> *Kasun de Silva*
> Software Engineer | *WSO2 Inc.*; http://wso2.com
> lean.enterprise.middleware
>
> email   : kas...@wso2.com
> mobile : +94 77 794 4260
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


 --
 Regards,
 Manula Chathurika Thantriwatte
 Software Engineer
 WSO2 Inc. : http://wso2.com
 lean . enterprise . middleware

 email : manu...@wso2.com / man...@apache.org
 phone : +94 772492511
 blog : http://manulachathurika.blogspot.com/




 ___
 Architecture mailing list
 Arch

Re: [Architecture] What is the best/wso2 way to authenticate REST endpoints.

[Ayesha Dissanayaka]

Hi Ruchira,

Yes, I need recommendation on how to secure all the REST API endpoints.
Currently publisher app use both HTTP and HTTPS. Since, publisher should be
secured I think we need to disable serving pages/apis in HTTP. In that way
these REST endpoints also will be only HTTPS enabled as they are served in
'{context}/publisher/apis/*.
WDYT?

Roshan,
Thank you for your suggestions.
We don't maintain two REST APIs, this is the same REST API we use
internally in ES client side and we expose to external clients (third party
developers).

Thanks!
- Ayesha

On Wed, Oct 15, 2014 at 12:00 PM, Roshan Wijesena  wrote:

> Hi Ayesha,
>
> IMO,if you have an intention to expose your API to third party developers
> best way to secure is using oAuth2 where third party developer can generate
> his consumer id/secret and generate an API token and use that token to
>  access APIs. Wso2APIM is using that protocol.If you wish can use wso2IS as
> a token-provider, but I believe in your case  basic-oAuth [1] over SSL
> would be sufficient enough.
>
> And why we need two REST apis here? we can validate user directly in your
> CURD rest api?
>
> [1] http://tools.ietf.org/html/rfc2617
>
> On Wed, Oct 15, 2014 at 11:27 AM, Ruchira Wageesha 
> wrote:
>
>>
>>
>> On Wed, Oct 15, 2014 at 11:18 AM, Ayesha Dissanayaka 
>> wrote:
>>
>>> Hi all,
>>>
>>> I have implemented ES Publisher REST API in order to access and perform
>>> CRUD operations on ES -BackOffice.
>>>
>>> Each endpoint is authenticated by a valid Session-ID, passed to the
>>> endpoint in request header.
>>>
>>> In-order to obtain a session-ID we have implemented a separate
>>> authenticate REST endpoint. A user can send username and password in the
>>> POST request to this endpoint and if credentials are valid a session-id
>>> will be returned.
>>>
>>> Currently, no encryption or other (basic-aouth/aouth) authorization
>>> mechanism is yet implemented.
>>>
>>> What would be the lightweight and best way to secure this
>>> 'authentication' endpoint? Is there a particular wso2 way of doing this?
>>>
>> I assume you need to get a recommendation for securing all the REST APIs,
>> whether to use OAuth, Basic Auth etc. as you have secured it based on the
>> cookie, right??
>>
>> Anyway, in order to secure the auth endpoint, you will have to at least
>> use HTTPS.
>>
>>>
>>> Thanks!
>>> - Ayesha
>>>
>>> --
>>> *Ayesha Dissanayaka*
>>> Software Engineer,
>>> WSO2, Inc : http://wso2.com
>>> 
>>> 20, Palmgrove Avenue, Colombo 3
>>> E-Mail: aye...@wso2.com 
>>>
>>
>>
>>
>> --
>>
>> *Ruchira Wageesha**Associate Technical Lead*
>> *WSO2 Inc. - lean . enterprise . middleware |  wso2.com *
>>
>> *email: ruch...@wso2.com ,   blog:
>> ruchirawageesha.blogspot.com ,
>> mobile: +94 77 5493444 <%2B94%2077%205493444>*
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Roshan Wijesena.
> Senior Software Engineer-WSO2 Inc.
> Mobile: *+94752126789*
> Email: ros...@wso2.com
> *WSO2, Inc. :** wso2.com *
> lean.enterprise.middleware.
>



-- 
*Ayesha Dissanayaka*
Software Engineer,
WSO2, Inc : http://wso2.com

20, Palmgrove Avenue, Colombo 3
E-Mail: aye...@wso2.com 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [ES] Workflow extensions support - Approval task pages or app ?

[Manoj Gunawardena]

Hi,

+1 for develop as separate app and more clean and logical way . But I think
user point of view, its more applicable to view and function with in
publisher. Cant we implement as separate Jaggery app and included to
publisher as a carbon feature.  Then this workflow support app is available
as a feature to distribute with any other app.


Thanks

On Wed, Oct 15, 2014 at 9:47 AM, Nuwan Dias  wrote:

> There can be workflows for both the Publisher and the Store. Therefore
> having a single place to administer both sounds appropriate and easy to
> manage.
>
> At least in the context of API Manager, having a page on the Publisher to
> administer operations occurring on the Store doesn't seem right.
>
> IMO having an app for administrative purposes seems logical/clean and more
> secure (you can take it off completely from public facing interfaces and
> deploy internally if required). Even in the case of ES, you can use it for
> workflow administration, theming, doing import/export asset kind of stuff,
> etc.
>
> Thanks,
> NuwanD.
>
> On Wed, Oct 15, 2014 at 9:28 AM, Tanya Madurapperuma 
> wrote:
>
>> Hi,
>>
>> *Overview*
>> We are currently working on initial design to support workflow extensions
>> in Enterprise Store as in APIM. Both global workflow extensions (Ex : Self
>> signup ) and asset level extensions (Ex : Application creation for an API
>> store ) will be supported.
>>
>> *Concern*
>> Once the workflow support is enabled, there should be a place where
>> different types of tasks will be  listed for an admin user approval. In
>> APIM, a seperate admin-dashboard app is used for this
>> purpose.(admin-dashboard app in APIM serves some other tasks such as theme
>> uploading etc as well. )
>>
>> Does it require to use a seperate app for this in ES as well? Isn't it
>> relevant to add these as pages in ES Publisher with appropriate
>> permissions.Because basically publisher app acts as a store-admin which is
>> used to perform store releated admin tasks such as publishing assets to
>> store, viewing statistics etc.
>>
>> WDYT?
>>
>> Thanks,
>> Tanya
>> --
>> Tanya Madurapperuma
>>
>> Software Engineer,
>> WSO2 Inc. : wso2.com
>> Mobile : +94718184439
>> Blog : http://tanyamadurapperuma.blogspot.com
>>
>
>
>
> --
> Nuwan Dias
>
> Associate Tech Lead - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Manoj Gunawardena
Tech Lead
WSO2, Inc.: http://wso2.com
lean.enterprise.middleware
Mobile : +94 77 2291643
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture