Re: [Architecture] [IAM] Restful API to Evaluate Permission Tree in IS
+1 for REST API. How we secure this REST API. Basic authentication? What are the permissions required for the user to invoke to this REST API? if we use basic authentication, the permissions should be only view the permissions tree. On Thu, Oct 12, 2017 at 5:38 PM, Isuranga Perera wrote: > Hi IAM Team, > > I implemented the $subject feature. Please review and merge PR for the > carbon-identity framework [1] and PR [2] for Product-IS. JIRA for the > feature can be found at [3]. > > [1] https://github.com/wso2/carbon-identity-framework/pull/1122 > [2] https://github.com/wso2/product-is/pull/1406 > [3] https://wso2.org/jira/browse/IDENTITY-6724 > > Best Regards > Isuranga Perera > > > > On Wed, Oct 4, 2017 at 9:32 PM, Isuranga Perera > wrote: > >> Hi IAM Team, >> >> I'm currently working on the solution proposed by Johann. As he suggested >> I just introduced a new function which takes resource-id and subject-id as >> arguments and evaluates the permission tree. >> >> I will submit a PR as soon as possible. >> >> Best Regards >> Isuranga Perera >> >> On Wed, Oct 4, 2017 at 7:56 PM, Asela Pathberiya wrote: >> >>> >>> >>> On Wed, Oct 4, 2017 at 7:14 PM, Johann Nallathamby >>> wrote: >>> >>>> Hi IAM Team, >>>> >>>> Currently we don't have $subject. What we have currently are two APIs. >>>> >>>> 1. RemoteAuthorizationManagerService.isUserAuthorized(user, resource, >>>> action) - a SOAP API that evaluates the permission tree. >>>> >>>> 2. XACML3.0 Rest/JSON API - a Restful API which takes a JSON payload >>>> and evaluates the XACML3.0 policies in the PDP. >>>> >>>> What we need to have is a Restful API to evaluate the permission tree, >>>> so that users can add their application permissions using the Service >>>> Provider UI in IS, and evaluate them by calling the Restful API from their >>>> application. Rather than innovating our own Rest API to do this, the best >>>> way would be using the XACML3.0 Rest API, because it conforms to an >>>> industry standard. >>>> >>>> Therefore what I am proposing is to have XACML3.0 policy shipped with >>>> IS 5.4.0 which will be used to evaluate the permission tree. Some of the >>>> considerations when designing this policy. >>>> >>>> a. A permission is the combination of resource + action. Both resource >>>> and action are defined attribute categories in XACML3.0. Therefore we don't >>>> need to define a new category for this. >>>> >>>> b. If we use the same category "Resource" to identify resources in the >>>> permission tree, as well as any other resources defined in any other >>>> policies, we may not be able to exclusively evaluate permission tree only, >>>> or exclusively evaluate the other policies which don't need permission >>>> tree. The solution for this would be to have a policy target which matches >>>> the action "ui.execute", which is the constant action for all our UI >>>> permissions, or a policy target that checks for resource startwith >>>> "/permission/" because all our UI permissions start with "/permission". >>>> >>>> Attached is the kind of policy I am having in mind. We can define a new >>>> XACML function to evaluate permission tree, that takes two arguments, >>>> subject-id and resource-id. This XACML function will internally invoke the >>>> AuthorizationManager.isUserAuthorized() OSGi service and return the >>>> result. >>>> >>>> Comments and suggestions are welcome. >>>> >>> >>> +1 This look likes a simple approach to support a standard RESTful API >>> for application authorization with our permission tree. >>> >>> Thanks, >>> Asela. >>> >>> >>>> >>>> Thanks & Regards, >>>> Johann. >>>> >>>> -- >>>> >>>> *Johann Dilantha Nallathamby* >>>> Senior Lead Solutions Engineer >>>> WSO2, Inc. >>>> lean.enterprise.middleware >>>> >>>> Mobile - *+9476950* >>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>>> >>> >>> >>> >>> -- >>> Thanks & Regards, >>> Asela >>> >>> ATL >>> Mobile : +94 777 625 933 <+94%2077%20762%205933> >>> +358 449 228 979 >>> >>> http://soasecurity.org/ >>> http://xacmlinfo.org/ >>> >> >> > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- 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
Re: [Architecture] Using Nashorn JavaScript engine in Script Mediator
Nashorn for java 8 users in script mediator. >>>>>>> But in the process we have found some issues and solved them. Such as >>>>>>> when >>>>>>> trying to set Json payload the existing Rhino engine will use its native >>>>>>> objects to pass Json payload so in existing script mediator it use >>>>>>> different serialization techniques for each Rhino native object type. >>>>>>> But >>>>>>> in Nashorn the passed object will be always ScriptObjectMirror type. We >>>>>>> have overcome this issue by serializing these objects using >>>>>>> serialization >>>>>>> functionality of Nashorn native "JSON" object. So when handling the Json >>>>>>> payloads the used engine will not be an issue. But the main issue was >>>>>>> usage >>>>>>> of E4X xml objects when handling xml payloads with Rhino engine. >>>>>>> Because as >>>>>>> stated in[1] E4X is deprecated and it does not supported by Nashorn >>>>>>> engine. >>>>>>> To overcome this when using Nashorn, DOMparser can be used to parse xml >>>>>>> strings rather than using xml objects. But then the users who are using >>>>>>> script mediator with new Nashorn engine will not be able to use xml >>>>>>> objects >>>>>>> in javascript but they will be able to use setPayloadXML and >>>>>>> getPayloadXML >>>>>>> methods in script mediator by using string representations of xml. So >>>>>>> the >>>>>>> decision we need to make is whether to use existing mediator with >>>>>>> Nashorn >>>>>>> engine support but without using E4X(which is deprecated but still using >>>>>>> Rhino engine it will be supported) or writing new mediator separately >>>>>>> for >>>>>>> javascript with Nashorn engine support. >>>>>>> >>>>>>> >>>>>>> [1] https://developer.mozilla.org/en-US/docs/Archive/Web/E4X/Pro >>>>>>> cessing_XML_with_E4X >>>>>>> >>>>>>> Thanks, >>>>>>> -- >>>>>>> Malaka. >>>>>>> -- >>>>>>> Malaka Gangananda - Software Engineer | WSO2 >>>>>>> Email : mala...@wso2.com >>>>>>> Mobile : +94713564340 <+94%2071%20356%204340> >>>>>>> Web : http://wso2.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 >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Isuru Udana* >>>>> Senior Technical Lead >>>>> WSO2 Inc.; http://wso2.com >>>>> email: isu...@wso2.com cell: +94 77 3791887 <077%20379%201887> >>>>> blog: http://mytecheye.blogspot.com/ >>>>> >>>>> ___ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Best Regards, >>>> >>>> Malaka Silva >>>> Associate Director / Architect >>>> M: +94 777 219 791 <+94%2077%20721%209791> >>>> Tel : 94 11 214 5345 >>>> Fax :94 11 2145300 >>>> Skype : malaka.sampath.silva >>>> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 >>>> Blog : http://mrmalakasilva.blogspot.com/ >>>> >>>> WSO2, Inc. >>>> lean . enterprise . middleware >>>> https://wso2.com/signature >>>> http://www.wso2.com/about/team/malaka-silva/ >>>> <http://wso2.com/about/team/malaka-silva/> >>>> https://store.wso2.com/store/ >>>> >>>> Don't make Trees rare, we should keep them with care >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Himasha Guruge >>> *Software Engineer* >>> WS*O2* *Inc.* >>> Mobile: +94 777459299 <+94%2077%20745%209299> >>> himas...@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 >> >> > > > -- > Malaka. > -- > Malaka Gangananda - Software Engineer | WSO2 > Email : mala...@wso2.com > Mobile : +94713564340 > Web : http://wso2.com > <http://wso2.com/signature> > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- 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
Re: [Architecture] [C5] [APIM] Per API Per Gateway with Kubernetes and Openshift
s URL with the >>>> other CMS as Nuwan mentioned. >>>> >>>> >>>> Thanks, >>>> Chamalee >>>> >>>> >>>> -- >>>> Thanks & Regards, >>>> >>>> *Chamalee De Silva* >>>> Software Engineer >>>> *WS**O2* Inc. :http://wso2.com/ >>>> >>>> Office :- *+94 11 2145345 <%2B94%2011%202145345>* >>>> mobile :- *+94 7 <%2B94%2077%202782039>1 4315942* >>>> >>>> >>> >>> >>> -- >>> >>> >>> *Thanks & Regards,* >>> *Nuwan Bandara | Director - **Solutions Architecture, WSO2 Inc.* >>> *+1 646 643 8618 <(646)%20643-8618> | +1 650 745 2169 Ext 4212 >>> <(650)%20745-2169> | http://nuwanbando.com <http://nuwanbando.com> * >>> <http://www.nuwanbando.com/> >>> >> >> >> >> -- >> Lakmal Warusawithana >> Director - Cloud Architecture; WSO2 Inc. >> Mobile : +94714289692 <071%20428%209692> >> Blogs : https://medium.com/@lakwarus/ >> http://lakmalsview.blogspot.com/ >> >> > > > -- > > > *Thanks & Regards,* > *Nuwan Bandara | Director - **Solutions Architecture, WSO2 Inc.* > *+1 646 643 8618 | +1 650 745 2169 Ext 4212 | http://nuwanbando.com > <http://nuwanbando.com> * > <http://www.nuwanbando.com/> > -- 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
Re: [Architecture] How valid is sending TOTP code to email? How about sending it over SMS?
+1 for having both options. When users using from a foreign country, may not receive SMS. On Tue, Jul 18, 2017 at 10:13 AM, Johann Nallathamby wrote: > Hi All, > > Usually we send long lived codes to email and short lived codes to SMS. > Because opening email client and checking the code may take time, depending > on whether user has to log in to his email account, use 2FA for his email, > etc. The TOTP code is short lived (90s). I think it's better to send this > code over SMS or have both functionalities. What do you think? > > Thanks & Regards, > Johann. > > -- > > *Johann Dilantha Nallathamby* > Senior Lead Solutions Engineer > WSO2, Inc. > lean.enterprise.middleware > > Mobile - *+9476950* > Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* > -- 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
Re: [Architecture] File Based Database for Message Broker Store
gt;><https://redis.io/topics/persistence>) >>>>> >>>>> RocksDB >>>>> >>>>> >>>>>- >>>>> >>>>>A simple key value storage (upgrade of LevelDB) >>>>>- >>>>> >>>>> In memory database >>>>> >>>>> >>>>>1. >>>>> >>>>>Fast read,write performances (faster than LevelDB) >>>>>2. >>>>> >>>>>Can implement queue structures (https://github.com/facebook/r >>>>>ocksdb/wiki/Implement-Queue-Service-Using-RocksDB >>>>> >>>>> <https://github.com/facebook/rocksdb/wiki/Implement-Queue-Service-Using-RocksDB> >>>>>) >>>>>3. >>>>> >>>>>Support concurrency >>>>>4. >>>>> >>>>>Highly configurable (Pluggable Architecture) >>>>>5. >>>>> >>>>>Support persistence (memtables and transactional logs manage in >>>>>memory. Memtable is flushed to a sstfile to provide persistence.) >>>>> >>>>> >>>>>1. >>>>> >>>>>Loss of data (in case of power outage etc.) >>>>>2. >>>>> >>>>>No in built transaction support (have to use TansactionDB : >>>>>https://github.com/facebook/rocksdb/wiki/Transactions >>>>><https://github.com/facebook/rocksdb/wiki/Transactions> ) >>>>> >>>>> >>>>> According to this evaluation I suggest Redis as the most suitable >>>>> database for the message broker store. Even though it has an element of >>>>> risk in data loss, the persistence storing is configurable unlike in other >>>>> key-value stores. And it provides fast read and write performances >>>>> compared >>>>> to other databases with basic transaction support. >>>>> >>>>> And this is basically my evaluation and the opinion. It would be great >>>>> to have a feedback on this, specially regarding the additional criteria to >>>>> consider and other suggested databases. >>>>> >>>>> Best Regards >>>>> >>>>> -- >>>>> >>>>> *Wishmitha Mendis* >>>>> >>>>> *Intern - Software Engineering* >>>>> *WSO2* >>>>> >>>>> *Mobile : +94 777577706 <+94%2077%20757%207706>* >>>>> >>>>> >>>>> >>>>> ___ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Indika Sampath >>>> Associate Technical Lead >>>> WSO2 Inc. >>>> http://wso2.com >>>> >>>> Phone: +94 716 424 744 <+94%2071%20642%204744> >>>> Blog: http://indikasampath.blogspot.com/ >>>> >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> >>> *Wishmitha Mendis* >>> >>> *Intern - Software Engineering* >>> *WSO2* >>> >>> *Mobile : +94 777577706 <+94%2077%20757%207706>* >>> >>> >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Kevin Ratnaskera* >> Software Engineer >> WSO2 Inc. - http://wso2.com >> lean . enterprise . middleware >> Mobile - +94774696950 <+94%2077%20469%206950> >> Linkedin - https://www.linkedin.com/in/djkevincr >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > *Wishmitha Mendis* > > *Intern - Software Engineering* > *WSO2* > > *Mobile : +94 777577706* > > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- 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
Re: [Architecture] [APIM][C5] - Handling Broker request failure during Gateway event publishing
+1 for Persist the API with a flag. In the Publisher these apis can be shown as "Publishing in progress". Then how those apis push to broker, when connection alive? Broker is pull apis or APIM is push? +1 Broker checks with intervals and pull form APIM. On Mon, May 8, 2017 at 2:38 PM, Thilini Shanika wrote: > Hi All, > > As per the APIM 3.0.0 architecture, the events such as APIM create, > update, delete, subscription create etc are notified to gateways through > JMS Topic in the broker. Thus, we need to smoothly handle the scenarios > like *broker not available* and *APIM to Broker connection(network) > failure,* since the flow cannot be completed without notifying the > gateway (A blocking call). Ideally, if the API action cannot be completed > due to broker connection failure, the users should be notified about the > failure and the action should be rolled back. > > But, we are facing some difficulties to handle topic publishing failures > and rollback API action(API create, API state change, API update, API > delete, subscription create, subscription block) since the API action is > getting persisted in APIM db layer prior to publishing to Gateway. > > For example, if an API create request is initiated from API core, first, > the API will be persisted in db layer. Then the API create event will be > published to Topic and the registered gateways will be notified. But if the > broker publishing step is failed, the gateways will not be notified on the > newly created API so that the API won't be published to gateway. This might > lead the API to go to an inconsistent/partially created state (API is > successfully created in db, but not pushed to gateway). > > > Currently, we have not implemented any mechanism to > >- Rollback the action, or >- Persist the inconsistent state as a flag in API so that the user is >aware of the inconsistent state > > What would be the best way to handle broker failures? Any suggestions? > > Thanks > -- > Thilini Shanika > Senior Software Engineer > WSO2, Inc.; http://wso2.com > 20, Palmgrove Avenue, Colombo 3 > > E-mail: tgtshan...@gmail.com > > > _______ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- 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
Re: [Architecture] Validate Authorization headers for Oauth endpoints
If permission check not provided, is it allow to all? Any reason for token and user info end points hasn't check permissions? On Tue, May 2, 2017 at 3:02 AM, Farasath Ahamed wrote: > > > > On Tue, May 2, 2017 at 1:48 AM, Manoj Gunawardena wrote: > >> +1 for handle authorization in consistent way for all end points. >> Such as >> "/oauth2/introspect" >> "oauth2/userinfo" >> >> According to IS 5.3 Authentication and Authorization of REST APIS >> mechanism [1], what are the permission strings assign for following end >> points. >> >> "oauth2/token" >> "oauth2/revoke" >> "/oauth2/introspect" >> "oauth2/userinfo" >> > > > Of these, I think only "/oauth2/introspect" is currently protected with > [1]. > > > http-method="all"/> > secured="true" http-method="all"/> > http-method="all"/> > http-method="all"> > /permission/admin/manage/identity/ > applicationmgt/delete > > secured="true" http-method="all"> > /permission/admin/manage/identity/ > applicationmgt/create > > http-method="all"> > > */permission/admin/manage/identity/applicationmgt/view* > > secured="true" http-method="all"> > /permission/admin/manage/identity/pep Permissions> > > > > > Based on [2], AFAIU these are the required permissions, > > "oauth2/token" --> No permission check > > "oauth2/revoke" --> /permission/admin/manage/identity/applicationmgt/view > > "oauth2/userinfo" --> No permission check > > >> [1] https://docs.wso2.com/display/IS530/Authenticating+and+Autho >> rizing+REST+APIs >> > > [2] https://github.com/wso2-extensions/identity-inbound- > auth-oauth/blob/master/components/org.wso2.carbon.identity.oauth/src/main/ > resources/META-INF/services.xml > > >> >> >> On Wed, Apr 26, 2017 at 3:50 PM, Johann Nallathamby >> wrote: >> >>> How about "/oauth2/introspect" endpoint? >>> >>> On Wed, Apr 26, 2017 at 9:25 AM, Harsha Thirimanna >>> wrote: >>> >>>> On Wed, Apr 26, 2017 at 9:07 AM, Asela Pathberiya >>>> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Apr 25, 2017 at 3:34 PM, Harsha Thirimanna >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, Apr 25, 2017 at 3:04 PM, Asela Pathberiya >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Apr 25, 2017 at 2:52 PM, Harsha Thirimanna >>>>>> > wrote: >>>>>>> >>>>>>>> >>>>>>>> On Tue, Apr 25, 2017 at 2:00 PM, Asela Pathberiya >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna < >>>>>>>>> hars...@wso2.com> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Gayan, >>>>>>>>>>> >>>>>>>>>>> What are you trying to achieve by moving the client-secret >>>>>>>>>>> validation logic to the interceptor from the jax-rs layer? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Actually, we have separate layer to pass the secured API in IS >>>>>>>>>> and it is common service that can be used for any product. >>>>>>>>>> AppManager also >>>>>>>>>> using that. >>>>>>>>>> In here also Gayan is trying to get the security check into that >>>>>>>>>> common layer instead of allowing to go into the next level to >>>>>>>>>> validate >>>>>>>>>> headers. >>>>>>>>>> >>>>&
Re: [Architecture] Validate Authorization headers for Oauth endpoints
; >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Since both run on the same JVM, doesn't the overhead of the >>>>>>>>> process remain the same, irrespective of where it runs? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> NuwanD. >>>>>>>>> >>>>>>>>> On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana < >>>>>>>>> ga...@wso2.com> wrote: >>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> In Oauth /token endpoint and /revoke endpoint >>>>>>>>>> >>>>>>>>>> https://localhost:9443/oauth2/token >>>>>>>>>> https://localhost:9443/oauth2/revoke >>>>>>>>>> >>>>>>>>>> required authorization with client key, client secret in basic >>>>>>>>>> auth headers. Currently in implementation we validate those headers >>>>>>>>>> after >>>>>>>>>> serving request to JAX-RS endpoints. Basically /token, /revoke >>>>>>>>>> endpoints >>>>>>>>>> are unsecured. There is significant amount of processing happen even >>>>>>>>>> for >>>>>>>>>> wrong client secret. >>>>>>>>>> >>>>>>>>>> Since we have REST API interceptor layer In IS 5.3.0 can we use >>>>>>>>>> it to validate client credentials ? We may need to plug an additional >>>>>>>>>> authenticator to validate client key, client secret in basic auth >>>>>>>>>> headers. >>>>>>>>>> This authenticator may conflict with basic authenticator because >>>>>>>>>> both authenticators validate basic auth credentials different way. >>>>>>>>>> There >>>>>>>>>> are two approaches to avoid the conflict. >>>>>>>>>> >>>>>>>>>> *#option 01 * >>>>>>>>>> Increase the priority of newly added authenticator and check the >>>>>>>>>> context inside authenticator canHandle. >>>>>>>>>> >>>>>>>>>> *#option 01 * >>>>>>>>>> Increase the priority of newly added authenticator and check >>>>>>>>>> existence of oauth application from client key. >>>>>>>>>> >>>>>>>>>> WDYT? >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Nuwan Dias >>>>>>>>> >>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>> email : nuw...@wso2.com >>>>>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ___ >>>>>>>> Architecture mailing list >>>>>>>> Architecture@wso2.org >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thanks & Regards, >>>>>>> Asela >>>>>>> >>>>>>> ATL >>>>>>> Mobile : +94 777 625 933 <+94%2077%20762%205933> >>>>>>> +358 449 228 979 >>>>>>> >>>>>>> http://soasecurity.org/ >>>>>>> http://xacmlinfo.org/ >>>>>>> >>>>>>> ___ >>>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Thanks & Regards, >>>>> Asela >>>>> >>>>> ATL >>>>> Mobile : +94 777 625 933 <+94%2077%20762%205933> >>>>> +358 449 228 979 >>>>> >>>>> http://soasecurity.org/ >>>>> http://xacmlinfo.org/ >>>>> >>>>> ___ >>>>> 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 >>>> >>>> >>> >>> >>> -- >>> Thanks & Regards, >>> Asela >>> >>> ATL >>> Mobile : +94 777 625 933 <+94%2077%20762%205933> >>> +358 449 228 979 >>> >>> http://soasecurity.org/ >>> http://xacmlinfo.org/ >>> >>> ___ >>> 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 >> >> > > > -- > 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 <http://nallaa.wordpress.com>* > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- 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
Re: [Architecture] [C5][APIM] - Publishing API events to gateway via JMS Topic
This is a suggestion, How about a REST API instead of a JMS service. GW nodes pull changes from APIMCore via REST service in APIMCore with configurable intervals. The GW nodes fetch changes based on a timestamp (last fetch time) and api labels.(apis which hosted in that gw) The REST api will response meta data of changes as JSON payloads. The worry of connectivity breaking between core and GW is not with this mechanism. WDYT? On Fri, Apr 28, 2017 at 1:29 PM, Lakmal Warusawithana wrote: > Hi Kasun, > > On Fri, Apr 28, 2017 at 4:47 AM, Kasun Indrasiri wrote: > >> Hi, >> >> Few questions related to the above design. >> >> >> - Here we are using pub-sub messaging to receive notification of the >> event of different API lifecycle states and use that to apply those changes >> (deploy, redeploy etc.) at the Ballerina service level. This is inherently >> subjective to lost the event notifications in case of a communication >> failure between the broker and GWs. For instance, if there is a >> communication failure, some API may not deploy/update on a given GW node (I >> doubt that we will face the same set of issues as we have in the old >> dep-sync approach). >> I'd rather think a push mechanism from the APIMCore to GW would be more >> solid compared to pub-sub. >> >> WDYT? >> > > Even push model APIMCore to some of gateway communication can be broken. > Then we need to replay that push messages otherwise they will not get them > at all. But why we want to have MB and the pub-sub is for reliable message > delivery. Second, this is very loosely couple and we can scale GWs without > updating the topology in the APIMCore. > > But, yes you have a point. Like NuwanD said, we may need to use durable > topics to handle the communication issues. I think we can have unique > identifiers for GWs and use in durable topic subscriptions. Only catch is > in container scenario, GWs can come and go very frequently and we need to > have some mechanism to clean these dead subscriptions. Hope from MB we may > have some way to clean them up. (or else we may need to have some clean up > process in the core) > > > >> >> From the Ballerina perspective: >> >> - A pre-built JMS service can subscribe to the respective topics (during >> the deployment time) and as the event updates are received it has to deploy >> (create/update new Ballerina service file?) the respective Ballerina >> service. However, I feel we need to clarify the above issues prior to the >> implementation. >> >> On Wed, Apr 26, 2017 at 9:58 PM, Thilini Shanika >> wrote: >> >>> Hi Manoj, >>> >>> Please find my comments inline. >>> >>> Fetching new apis from APIM core do via database call or REST api? >>> >>> We are providing a set of REST apis (in API core) for ballerina gateways >>> to access and fetch API conf, subscription details etc. Following diagram >>> depicts how the communication happens in between the APIM core, the >>> gateway, and the broker. >>> >>> >>> >>> I think, we have to think about time to fetch all apis and starting time >>> of a node. If num of apis increases, the startup time of a node may >>> increase. >>> This may critical for a containerized environments. >>> We found some production instances which has around 1000 apis. >>> >>> Yes. As per the new design, there is a plan of deploying APIs on demand >>> and this will eliminate the overhead of API deployment delays at server >>> startup. >>> >>> On Thu, Apr 27, 2017 at 9:58 AM, Manoj Gunawardena >>> wrote: >>> >>>> Fetching new apis from APIM core do via database call or REST api? >>>> I think, we have to think about time to fetch all apis and starting >>>> time of a node. If num of apis increases, the startup time of a node may >>>> increase. >>>> This may critical for a containerized environments. >>>> We found some production instances which has around 1000 apis. >>>> >>>> On Wed, Apr 26, 2017 at 1:56 PM, Sanjeewa Malalgoda >>>> wrote: >>>> >>>>> In fully automated containerized environment can we assume we can see >>>>> node restarts. As i understood nodes come and go(each time we require we >>>>> start new instance and when its not in use it will terminate). In such >>>>> scenario having durable subscription or persisting data to local node do >>>>> not make much difference. >>>>> >>>
Re: [Architecture] [C5][APIM] - Publishing API events to gateway via JMS Topic
Fetching new apis from APIM core do via database call or REST api? I think, we have to think about time to fetch all apis and starting time of a node. If num of apis increases, the startup time of a node may increase. This may critical for a containerized environments. We found some production instances which has around 1000 apis. On Wed, Apr 26, 2017 at 1:56 PM, Sanjeewa Malalgoda wrote: > In fully automated containerized environment can we assume we can see node > restarts. As i understood nodes come and go(each time we require we start > new instance and when its not in use it will terminate). In such scenario > having durable subscription or persisting data to local node do not make > much difference. > > But if we are thinking of traditional deployment then we may be able to > restart instances and reuse them. > @Lakmal, Pubudu any thoughts? > > Thanks, > sanjeewa. > > On Wed, Apr 26, 2017 at 11:34 AM, Pubudu Gunatilaka > wrote: > >> On Wed, Apr 26, 2017 at 11:02 AM, Lakmal Warusawithana >> wrote: >> >>> >>> >>> On Wed, Apr 26, 2017 at 10:51 AM, Manoj Gunawardena >>> wrote: >>> >>>> Are we going to use durable subscription here? When ever gw node down >>>> and re start, >>>> it should fetch messages which add to the topic during the down time. >>>> In case durable subscription what is the mechanism to create client id >>>> for each gw.Is that discussed and confirm? >>>> >>> >>> No, we are not going to use durable topic. New gateways (scaling) or if >>> we restart a gateway, existing APIs will fetch via API Manager core. Only >>> new API (after boot up) notifications are getting via the topic and actual >>> API will fetch from the core. ( we can try what sanjeewa mention - getting >>> API from the topic - but previous APIs need to fetch from the core) >>> >>> >> >> When we restart a gateway node, it would be better to fetch only the >> updated APIs as well as the new APIs. Restarted gateway has the already >> fetched APIs and it is not worth to fetch all the APIs again. We will have >> to use durable subscription for this. >> >> If we consider the container scenario, are we persisting gateway >> artifacts? If we are not persisting gateway artifacts and restart the >> gateway container, then we need to fetch all the APIs from the core. IMHO >> it would better to persist data and load that data at restart as it would >> take time to fetch all the APIs from the core. >> >> Thank you! >> -- >> *Pubudu Gunatilaka* >> Committer and PMC Member - Apache Stratos >> 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 >> >> > > > -- > > *Sanjeewa Malalgoda* > WSO2 Inc. > Mobile : +94713068779 <+94%2071%20306%208779> > > <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda. > blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/> > > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- 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
Re: [Architecture] [C5][APIM] - Publishing API events to gateway via JMS Topic
Are we going to use durable subscription here? When ever gw node down and re start, it should fetch messages which add to the topic during the down time. In case durable subscription what is the mechanism to create client id for each gw.Is that discussed and confirm? On Tue, Apr 25, 2017 at 2:20 PM, Sanjeewa Malalgoda wrote: > API create/update/delete are similar type of events IMO. After we getting > any event for these what we have to do is redeploy API or discard it. IMO > if possible we should try to avoid web service call based update and send > ballerina file with event itself(if its not heavy object). Other type of > event is subscription change(which originates from API store). And for the > throttling we need another topic. So as i see we can survive with only 3 > topics at the moment. > > Thanks, > sanjeewa. > > On Tue, Apr 25, 2017 at 11:44 AM, Nuwan Dias wrote: > >> The type of events we're talking about here are rare events. API >> creation, subscription, etc won't happen that frequently. So I don't think >> there will be much load on the broker as such. >> >> Architecturally having separate topics will be clean. The code and the >> error handling parameters (dead letter queue) can be defined per event >> type. However I think it'll cause additional burden to the Gateway since >> the Gateway now has to establish and maintain several connections to the >> broker. And since these connections need to happen at startup, each >> connection that needs to be established adds up to the startup time of the >> Gateway. So I would prefer to minimize the number of topics as much as >> possible. >> >> On Tue, Apr 25, 2017 at 11:09 AM, Thilini Shanika >> wrote: >> >>> Hi All, >>> >>> According to APIM C5 architecture, the events like API create, API >>> lifecycle status change, API subscriptions are notified to APIM gateway via >>> JMS topic/topics in the broker. >>> >>> Following diagram depicts how APIM core, broker and gateway components >>> interact when there is an event generated from Core. >>> >>> >>> Following are the two options we came up while implementing above event >>> publishing scenario from APIM Core --> Broker --> Gateways. >>> >>> *1) Publishing all the events to a common topic * >>> >>> A single topic is maintained in broker and all the gateways are >>> subscribed to this common topic. APIM core publishes all the events >>> generated from APIM to this particular topic. After topic subscription, the >>> gateways keep listening to the topic and once a notification is received, >>> it has to be filtered to identify the event type and perform the required >>> action. The events like API create, lifecycle status change, API >>> subscription etc are getting published through this common topic and the >>> event type has to be reflected in the notification itself so that the >>> gateways can identify the notification and decide what has to be performed >>> next. In this case, it has to maintain a single connection to JMS topic >>> from each gateway. >>> >>> >>> >>> >>> *2) Maintaining dedicated topics for each event type* >>> >>> In this option, we can either maintain dedicated topic for each event >>> type (API Create, API publish, API subscription) or maintain dedicated >>> topics for API publisher, API store events. As per this solution, the >>> gateways have to subscribe to all these topics and keep listening to all of >>> them. In that case, gateways have to establish and maintain more >>> connections with the broker, since there are several topic subscriptions. >>> Once a notification is generated from APIM and published to the relevant >>> topic, that particular notification is received by the relevant gateway >>> service and process the message to perform the next action. But, the >>> filtering logic which has to be executed in ballerina gateway side is less >>> complex in this solution. >>> >>> >>> >>> What would be the best option here? Your suggestions and comments are >>> highly appreciated. >>> >>> Thanks >>> Thilini >>> >>> >>> >>> -- >>> Thilini Shanika >>> Senior Software Engineer >>> WSO2, Inc.; http://wso2.com >>> 20, Palmgrove Avenue, Colombo 3 >>> >>> E-mail: tgtshan...@gmail.com >>> >>> >> >> >> -- >> Nuwan Dias >> >&g
Re: [Architecture] Dep sync strategies for Carbon 4 products in Kubernetes
I think we can go with multiple gateway manager nodes with following architecture. This diagrom explains according to mesos environments. 1. For each GW mgr has a script, it connects to mesos dns and get available gw workers. 2. Push new artifacts receive to that particular mgr node to all workers. 3. This script runs as unterminated and with some intervals. 4. Each Mgr node and script deploy in same container using supervisor.D. as multiple processors. I think this will solve restrict to single manager node limitation and issue of re start rsync daemon when network down. Thanks On Wed, Jun 8, 2016 at 6:49 AM, Chamila De Alwis wrote: > Hi Imesh, > > > On Wed, Jun 8, 2016 at 5:32 AM, Imesh Gunaratne wrote: > >> It would be better if we can implement this feature without tightly >> coupling with the K8S API. Therefore I prefer the pull based model than >> this. >> > > I agree. This would require different ways of contacting any platform > specific name resolution service to get the list of target containers. > > >> >> >>> The pull method works the other way, i.e. initiated by the GW worker >>> nodes and has to be run continuously on a loop. >>> >> >> This approach can be applied to API-M on any container cluster manager >> (and also on VMs) with very few changes. AFAIU it's matter of changing how >> SSH server and rsync command processes are run on each GW node. K8S can use >> separate containers for these using pods and Mesos can use supervisord [4]. >> > > I think supervisord would be applicable to any Docker based platform, be > it Kubernetes or Mesos. Is there an additional advantage in going for a > separate container to run sshd with a shared volume? > > One complication we'll come across (regardless of whether rsync pull or > push) that I couldn't further elaborate was the artifact synchronization > *between* GW Manager nodes when manager is in HA. This is when there are > multiple GW Manager nodes, fronted with a load balancer. There will be only > one active pod at a given time, and the request will be directed to the > next available pod when the former goes down. > > For this, if we use a hostPath approach to share data, we'll also need to > specify a node affinity to limit the node that the pod is spawned on. This > way we can make sure the same location is mounted to every pod. The other > option is to use something like Flocker with a Block storage service, > however IMO it is a too complex method to approach a simple problem. > > > > > Regards, > Chamila de Alwis > Committer and PMC Member - Apache Stratos > Software Engineer | WSO2 | +94772207163 > Blog: code.chamiladealwis.com > > > -- 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
[Architecture] WSO2 CDM and MDM 2.0.0 Milestone-1 Released !
Hi All, *WSO2 CDM and MDM 2.0.0 Milestone-1 Released !* This is the first milestone of WSO2 CDM version 2.0.0. You can download the milestone at [1]. Milestone-1 specifically contains following features. New Features - Support pluggable modules corresponding to different device typessupport pluggable modules corresponding to different device types. - Device Enrollment. - Integrate support for "API Everywhere". - JAX-RS services layers for each supported device types which are being invoked by respective agent applications. - License management. - Android plugin implementation. - Basic Operation handling. - UI for Basic functionalities such as add operation, device listing etc. *References* [1] Respective products can be downloaded from, CDM 1.0.0-M1 https://svn.wso2.org/repos/wso2/people/prabatha/CDM-Framework/1.0.0-SNAPSHOT/wso2cdm-1.0.0-SNAPSHOT.zip MDM 2.0.0-M1 https://svn.wso2.org/repos/wso2/people/prabatha/MDM/2.0.0-M1/wso2mdm-2.0.0-SNAPSHOT.zip Thank You, CDM Team -- 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
Re: [Architecture] Invitation: CDM Hackathon @ Mon Dec 1, 2014 1:30pm - 5:30pm (Sameera Perera)
Hi All, Few Corrections. This is December 2nd meeting minutes. Also need to add two things, 12. In the device table: need to change 'byod' field name to 'ownership'. 13. The current policy definition is just a set of actions that do not contain any applicable conditions, it was suggested to rename it as 'profile'. Thanks On Wed, Dec 3, 2014 at 11:06 AM, Manoj Gunawardena wrote: > Hi All, > > *Dec 03rd meeting minutes.* > > *Attendees* : Sameera Perera, Kasun Dananjaya, Prabath Abeysekera, Asok > Perera, Afkham Azeez, Geeth Munasinghe, Inosh Perera, Sumedha Rubasinghe, > Srinath > Perera, Manoj Gunawardena > > > 1. Develop components in a separate repo, But for the movement it's > develop as a module inside CDM. Later move to a separate repo. > > 2.Develop common interface in the core, to cater all core > functionalities. Develop plugins for each device type. > > Ex -: Android, IOS, windows or other device type > > 3. For IOS and android develop a common enrollment data set and common > method. > For windows or other specific devices develop specific services. > > 4. Policy handling discussion - Not completed. Decided to keep existing > functionality for 1st release. > > 5. Policy rename as profile suggested. > > 6. IOT devices enrollment mechanism discussed. The device should develop > It's own agent to communicate with CDM, In such cases authentication > mechanism should be implement using OAUTH custom grant type. > > 7. Sumeda will do a demonstration on IOT devices connectivity with CDM. > > 8. For mobile agents, the existing authentication flow should change. >The authentication mechanism decided to change using service provider. > > 9. The existing agent download mechanism has security falls. Decided to > change and display login page and authenticate user at the downloading. > > 10. The team is working on listing interfaces and creating the repo, > modules and structure > The new CDM repo. > https://github.com/geethkokila/product-cdm/ > > > 11. New concept "event "should add for dynamic policies. > > > Kindly append if I have missed anything here > > Thanks > Manoj > > > > > > On Tue, Dec 2, 2014 at 11:05 AM, Sameera Perera wrote: > >> Appending >> >> Day 1 Notes: >> >> *Goals* >> >>1. Identify a CDM Core that's device/platform agnostic >>2. Properly modularize the product (continuing the discussion in the >>thread [1]) >>3. Evaluate how CDM can able to support Dynamic policies and policy >>merging which are frequently requested features >> >> *Terminology* >> >>- Feature (more accurately Device Management Feature): This is an >>operation that the CDM can instruct the device to perform. A MDM example >> of >>this would be to "Put ringer in silent mode". On a smart thermostat, this >>could be "Reduce Air Conditioning" >>- Policy: A policy is a collection of features. The CDM Core, >>maintains the policy in a canonical format. Platform bundles may translate >>the policy in to a device dependent format. >> >> Both terms (feature and policy) are misnomers and may better termed as >> operations and profiles. However, we decided to stick to the terms as these >> are standard across the MDM industry. >> >> >>- Platform Bundle: Refer [1] >> >> >> *CDM Core* >> >>- Instructs the platform bundle to apply a policy to the device >>- The core determines which policy needs to be applied to the device >>through a "Trigger". EMM 1.0 used 3 types of triggers: Platform, User and >>Role. CDM will introduce Location and Time. >>- When device calls back to the CDM, validates whether the device is >>violating its policy >> >> The Core will contain policy management and policy enforcement components >> as well as a policy editor. >> >> *MDM Module* >> >>- A MDM Module will sit on top of the core to enable feature parity >>with EMM 1.1. It will be written specifically with the knowledge that >>platform bundles for Android, iOS are available. >>- The MDM will define a common set of features that are available >>across all phones. >> >> By introducing this layer of abstraction we are able to keep manage >> mobile devices across mobile platforms as we've done in EMM without >> complicating the device agnostic capabilities of the core. Similar modules >> can be built by 3rd parties to manage other devic
Re: [Architecture] Invitation: CDM Hackathon @ Mon Dec 1, 2014 1:30pm - 5:30pm (Sameera Perera)
Hi All, *Dec 03rd meeting minutes.* *Attendees* : Sameera Perera, Kasun Dananjaya, Prabath Abeysekera, Asok Perera, Afkham Azeez, Geeth Munasinghe, Inosh Perera, Sumedha Rubasinghe, Srinath Perera, Manoj Gunawardena 1. Develop components in a separate repo, But for the movement it's develop as a module inside CDM. Later move to a separate repo. 2.Develop common interface in the core, to cater all core functionalities. Develop plugins for each device type. Ex -: Android, IOS, windows or other device type 3. For IOS and android develop a common enrollment data set and common method. For windows or other specific devices develop specific services. 4. Policy handling discussion - Not completed. Decided to keep existing functionality for 1st release. 5. Policy rename as profile suggested. 6. IOT devices enrollment mechanism discussed. The device should develop It's own agent to communicate with CDM, In such cases authentication mechanism should be implement using OAUTH custom grant type. 7. Sumeda will do a demonstration on IOT devices connectivity with CDM. 8. For mobile agents, the existing authentication flow should change. The authentication mechanism decided to change using service provider. 9. The existing agent download mechanism has security falls. Decided to change and display login page and authenticate user at the downloading. 10. The team is working on listing interfaces and creating the repo, modules and structure The new CDM repo. https://github.com/geethkokila/product-cdm/ 11. New concept "event "should add for dynamic policies. Kindly append if I have missed anything here Thanks Manoj On Tue, Dec 2, 2014 at 11:05 AM, Sameera Perera wrote: > Appending > > Day 1 Notes: > > *Goals* > >1. Identify a CDM Core that's device/platform agnostic >2. Properly modularize the product (continuing the discussion in the >thread [1]) >3. Evaluate how CDM can able to support Dynamic policies and policy >merging which are frequently requested features > > *Terminology* > >- Feature (more accurately Device Management Feature): This is an >operation that the CDM can instruct the device to perform. A MDM example of >this would be to "Put ringer in silent mode". On a smart thermostat, this >could be "Reduce Air Conditioning" >- Policy: A policy is a collection of features. The CDM Core, >maintains the policy in a canonical format. Platform bundles may translate >the policy in to a device dependent format. > > Both terms (feature and policy) are misnomers and may better termed as > operations and profiles. However, we decided to stick to the terms as these > are standard across the MDM industry. > > >- Platform Bundle: Refer [1] > > > *CDM Core* > >- Instructs the platform bundle to apply a policy to the device >- The core determines which policy needs to be applied to the device >through a "Trigger". EMM 1.0 used 3 types of triggers: Platform, User and >Role. CDM will introduce Location and Time. >- When device calls back to the CDM, validates whether the device is >violating its policy > > The Core will contain policy management and policy enforcement components > as well as a policy editor. > > *MDM Module* > >- A MDM Module will sit on top of the core to enable feature parity >with EMM 1.1. It will be written specifically with the knowledge that >platform bundles for Android, iOS are available. >- The MDM will define a common set of features that are available >across all phones. > > By introducing this layer of abstraction we are able to keep manage mobile > devices across mobile platforms as we've done in EMM without complicating > the device agnostic capabilities of the core. Similar modules can be built > by 3rd parties to manage other device categories such as thermostats, smart > TVs etc. from different vendors/platforms. > > *Other notes* > >- We have demoted the following concepts to second class citizens and >pulled them out of the core > 1. OS Platform, version > 2. Device Platform, version > 3. Roles > > 1 and 2 only matter to the extend that they help us define a set of > available features. Bundles will be responsible for managing this set based > on these factors. The core will only be aware of the set. > Roles were used in the EMM only to select the policy to apply on a user's > device. We have moved this responsibility to the Trigger (or handler) > chain. The core will only be aware of the chain, not what logic is applied > to generate the policy. > > *For further discussions:* > >- More discussion around Trigger concept >- Policy mergi
[Architecture] WSO2 Enterprise Store 2.0.0 Milestone-4 Released !
- Document new
extension model for the ES
*References*
[1] Product can be downloaded from
http://dist.wso2.org/milestone/es/2.0.0-M4/wso2es-2.0.0-SNAPSHOT.zip
<http://www.google.com/url?q=http%3A%2F%2Fdist.wso2.org%2Fmilestone%2Fes%2F2.0.0-M4%2Fwso2es-2.0.0-SNAPSHOT.zip&sa=D&sntz=1&usg=AFQjCNH2raQk8mVuschCmhg9gg6lYNIxYw>
[2] Store Front URL : http://{host}:{9763}/store
[3] Store Back-office (Publisher) : http://{host}:{9763}/publisher
[4] Store Roadmap :
https://wso2.org/jira/browse/STORE#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel
[5] JIRA tickets : https://wso2.org/jira/browse/STORE
Thank You,
ES Team
--
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
Re: [Architecture] Geo-Dashboard - Stationery Alert Usecase
gt;> circle but the user should also be able to define a polygon instead. >>>>>>>>> So >>>>>>>>> make it as: >>>>>>>>> >>>>>>>>> An area where the the stationary alert is valid (here we can pass >>>>>>>>> the geo-fence ), and then the time period. >>>>>>>>> >>>>>>>>> Suho >>>>>>>>> >>>>>>>>> On Wed, Oct 22, 2014 at 9:30 AM, Damith Wickramasinghe < >>>>>>>>> dami...@wso2.com> wrote: >>>>>>>>> >>>>>>>>>> Attaching the document. >>>>>>>>>> >>>>>>>>>> On Wed, Oct 22, 2014 at 6:50 PM, Damith Wickramasinghe < >>>>>>>>>> dami...@wso2.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Following is the Architecture for Stationery alert requirement. >>>>>>>>>>> >>>>>>>>>>> Use case: An alert should be generated if an object stays in a >>>>>>>>>>> specific place for some specific time >>>>>>>>>>> >>>>>>>>>>> User will be providing the stationery position, its radius and >>>>>>>>>>> the time. Then an alert will be given if the object satisfies >>>>>>>>>>> following >>>>>>>>>>> two conditions. >>>>>>>>>>> >>>>>>>>>>> 1.Object should come into the stationery circle, which is >>>>>>>>>>> created using the radius user provided. >>>>>>>>>>> 2.Object should be in the circle for a specific time which user >>>>>>>>>>> provided. >>>>>>>>>>> >>>>>>>>>>> Please find below the link for the Architecture. >>>>>>>>>>> >>>>>>>>>>> [1] Architecture >>>>>>>>>>> <https://docs.google.com/a/wso2.com/drawings/d/1X1LE8qjbXCvLmqHVrFoAFkTBdNHxDCiUrQd_FwfEDMA/edit?usp=sharing> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best Regards, >>>>>>>>>>> Damith Wickramasinghe. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Software Engineer >>>>>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>>>>> <http://www.google.com/url?q=http%3A%2F%2Fwso2.com&sa=D&sntz=1&usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg> >>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>> >>>>>>>>>>> mobile: *+94728671315 <%2B94728671315>* >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Software Engineer >>>>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>>>> <http://www.google.com/url?q=http%3A%2F%2Fwso2.com&sa=D&sntz=1&usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg> >>>>>>>>>> lean.enterprise.middleware >>>>>>>>>> >>>>>>>>>> mobile: *+94728671315 <%2B94728671315>* >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> *S. Suhothayan* >>>>>>>>> Technical Lead & Team Lead of WSO2 Complex Event Processor >>>>>>>>> *WSO2 Inc. *http://wso2.com >>>>>>>>> * <http://wso2.com/>* >>>>>>>>> lean . enterprise . middleware >>>>>>>>> >>>>>>>>> >>>>>>>>> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: >>>>>>>>> http://suhothayan.blogspot.com/ >>>>>>>>> <http://suhothayan.blogspot.com/>twitter: >>>>>>>>> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | >>>>>>>>> linked-in: >>>>>>>>> http://lk.linkedin.com/in/suhothayan >>>>>>>>> <http://lk.linkedin.com/in/suhothayan>* >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Software Engineer >>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>> <http://www.google.com/url?q=http%3A%2F%2Fwso2.com&sa=D&sntz=1&usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg> >>>>>>>> lean.enterprise.middleware >>>>>>>> >>>>>>>> mobile: *+94728671315 <%2B94728671315>* >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> *S. Suhothayan* >>>>>>> Technical Lead & Team Lead of WSO2 Complex Event Processor >>>>>>> *WSO2 Inc. *http://wso2.com >>>>>>> * <http://wso2.com/>* >>>>>>> lean . enterprise . middleware >>>>>>> >>>>>>> >>>>>>> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: >>>>>>> http://suhothayan.blogspot.com/ >>>>>>> <http://suhothayan.blogspot.com/>twitter: >>>>>>> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | >>>>>>> linked-in: >>>>>>> http://lk.linkedin.com/in/suhothayan >>>>>>> <http://lk.linkedin.com/in/suhothayan>* >>>>>>> >>>>>>> ___ >>>>>>> Architecture mailing list >>>>>>> Architecture@wso2.org >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Inosh Perera >>>>>> Software Engineer, WSO2 Inc. >>>>>> Tel: 0785293686 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Software Engineer >>>>> WSO2 Inc.; http://wso2.com >>>>> <http://www.google.com/url?q=http%3A%2F%2Fwso2.com&sa=D&sntz=1&usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg> >>>>> lean.enterprise.middleware >>>>> >>>>> mobile: *+94728671315 <%2B94728671315>* >>>>> >>>>> >>>> >>>> >>>> -- >>>> Inosh Perera >>>> Software Engineer, WSO2 Inc. >>>> Tel: 0785293686 >>>> >>> >>> >>> >>> -- >>> Software Engineer >>> WSO2 Inc.; http://wso2.com >>> <http://www.google.com/url?q=http%3A%2F%2Fwso2.com&sa=D&sntz=1&usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg> >>> lean.enterprise.middleware >>> >>> mobile: *+94728671315 <%2B94728671315>* >>> >>> >> >> >> -- >> Inosh Perera >> Software Engineer, WSO2 Inc. >> Tel: 0785293686 >> > > > > -- > Software Engineer > WSO2 Inc.; http://wso2.com > <http://www.google.com/url?q=http%3A%2F%2Fwso2.com&sa=D&sntz=1&usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg> > lean.enterprise.middleware > > mobile: *+94728671315 <%2B94728671315>* > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- 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
Re: [Architecture] What is the best/wso2 way to authenticate REST endpoints.
Hi, +1 for OAuth2. Because publisher APIs can be use in mobile devices. Ex -: customer implements mobile app to publish assets Also need to think about how customer can extend (customize) the security with our extension model. Ex-: Customer writes a extended publisher API and need to give different grant types and roles Also , I think better to maintain one security mechanism, rather than secure some apis with oAuth2 and some apis with Basic Authentication. Thanks On Sun, Oct 19, 2014 at 1:12 PM, Ayesha Dissanayaka wrote: > Thank you everyone for your valuable inputs. > > @Udara, > These API endpoints are used by ES publisher App itself and will be > invoked by authorized third party as well. In that way we have enabled > accessing ES back office via remote clients as well. > > According to suggestions in this thread having aouth is the best way to > secure the endpoints which are exposed to third party. > > We will decide whether to use basic-aouth/aouth or suppot both, and update > the thread on final outcome. > > Thanks! > - Ayesha > > On Sat, Oct 18, 2014 at 10:27 PM, Udara Liyanage wrote: > >> Hi, >> >> Having basic oauth with HTTPS is kind of secured as long as no third >> party is invoking the APIs. >> >> >> >> Touched, not typed. Erroneous words are a feature, not a typo. >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Ayesha Dissanayaka* > Software Engineer, > WSO2, Inc : http://wso2.com > <http://www.google.com/url?q=http%3A%2F%2Fwso2.com&sa=D&sntz=1&usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg> > 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 > > -- 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
Re: [Architecture] Implementing Frequency calculation algorithm in CEP
Hi Seshika, Did u mean, this getFrequencies function, should able to accept another argument, that mean if this apply to a time window if window lenght is 1 day, this function will return last 5 hrs frequency of a day. Is your requirement can fulfill with existing window length or time parameters? ex -: if you need to extract frequency of last 5 hrs , apply this fuction to 5hrs time window Thanks On Fri, Oct 17, 2014 at 5:10 PM, Seshika Fernando wrote: > When considering the usecases for this, getting the frequency during a > particular time period will be very useful. (eg:- trading frequency of a > different stocks/products during the last 5 hours) > Does your custom transformer support this? Or does it always take all > events for the frequency calculations? > > On Fri, Oct 17, 2014 at 4:32 PM, Rajeevan Vimalanathan > wrote: > >> We are planning to integrate Frequency algorithm as a part of training >> project[1] with Siddhi CEP. >> >> Basically this is the algorithm calculates the number of occurrences >> (frequency) of a specified attribute for a given input stream in CEP. >> >> We have selected a Siddhi Transformer to implement this functionality by >> using stream-lib[2] as a third party library which is licensed under Apache >> Software Foundation. >> >> Standard Siddhi query for using this algorithm would look like below, >> >> * from >> inputStream#transform.custom:getFrequencies(desiredAttribute)select >> desiredAttribute, >> frequency* >> *insert into frequencyStream;* >> >> Where, >> >> inputStream : Input Stream to CEP >> >> custom : namespace >> >> getFrequencies : function name >> >> desiredAttribute : Attribute name from input stream for which frequencies >> need to be calculated >> frequencyStream : Output Stream from CEP that contains frequency related >> information >> >> The stream-lib library supports only Top-K and cardinality algorithms >> directly where the Top-K algorithm takes ‘K’ value as an argument from user >> and gives distinct K number of elements which have highest frequency values >> with related frequency values. The library provides no functions for >> getting frequencies of all elements. So what we are planning to do is >> giving a maximum integer value(Integer.MAX_VALUE) as an argument to the >> Top-K algorithm. So obviously, we will be able to get frequencies for all >> distinct event attributes provided that distinct event attribute count does >> not exceed Integer.MAX_VALUE value. >> >> There won’t be any memory issues as giving of Integer.MAX_VALUE for Top-K >> algorithm because it is increasing it’s bucket size dynamically as new >> distinct events come. >> >> We have already implemented the above design and basic testings seem to >> be ok. >> >> Kindly comment on the implementation. >> >> [1] - https://redmine.wso2.com/issues/2884 >> >> [2] - https://github.com/addthis/stream-lib >> >> -- >> Best Regards, >> V.Rajeevan >> Software Engineer, >> WSO2 Inc. :http://wso2.com >> >> Mobile : +94 773090875 >> Email : rajeev...@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 > > -- 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
Re: [Architecture] [Dev] [ES] Workflow extensions support - Approval task pages or app ?
Hi All, +1 for Johan's opinion. My suggstion is develop as Jaggery web app and implement as carbon feature. Publisher ship with this feature and admin pages can navigate through publisher. But this new admin app will be available to integrate with any other app as feature. Thanks On Thu, Oct 16, 2014 at 3:41 PM, Johann Nallathamby wrote: > > > On Wed, Oct 15, 2014 at 1:19 PM, Manoj Gunawardena > wrote: > >> 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. >>>> >>> > Not in all cases can we say the publisher app is admin related. There can > be external facing publisher deployments where users will come and publish > their artifacts (e.g. external users with publisher role come and publish > APIs in API publisher). In that case having workflow integration in > publisher app doesn't seem correct. > > +1 for separate app if you don't have an existing admin related app. > >> >>>> 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 >> >> > > > -- > Thanks & Regards, > > *Johann Dilantha Nallathamby* > Associate Technical Lead & Product Lead of WSO2 Identity Server > Integration Technologies Team > WSO2, Inc. > lean.enterprise.middleware > > Mobile - *+9476950* > Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- 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
Re: [Architecture] [Dev] [ES] Workflow extensions support - Approval task pages or app ?
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
Re: [Architecture] [Siddhi] Extension Support
Hi, This is a suggestion, I think its useful to have a version with the siddhi extension name, The same extension can exists with different versions. Idea is if extension get change and new version arrives, no need to change existing queries. Ex -: currency_1.0.siddhiext In the query should call the extension with the version. Then currency new extension arrives it may be 2.0. Will this be useful? Thanks On Tue, Sep 30, 2014 at 5:52 PM, Sachini Jayasekara wrote: > Hi all, > > New Siddhi implementation supports custom functions and custom output > aggregators. > > Custom functions can be written extending the FunctionExecutor class. > > Custom output aggregators can be written implementing AttributeAggregator > interface. In earlier version, to write a custom output aggregator, user > had to implement both OutputAttributeAggregatorFactory and > OutputAttributeAggregator interfaces. (Now there is no need to implement 2 > interfaces user can simply add the logic to one class which implements > AttributeAggregator interface). > > Then the implemented custom classes has to be compiled and the jar files > should be added to the class path. > User then has to add the custom function name and fully-qualified class > name of the custom extension to a file named "namespace of the > function/aggregator . siddhiext". (eg:- if namespace of a > function/aggregator is "currency" function/aggregator name and > fully-qualified class name should be added to a file named > currency.siddhiext ). For each extension .siddhiext should be created. This > file should also be added to class path. > > In earlier version, jars and siddhiext files have to be added to specific > locations but now user can and those to anywhere in class path. > > Extension loading process of Siddhi will search for files ending with > .siddhiext in class path and add them as extensions. > User can refer to the custom classes giving the namespace and function > name. > > Thanks > > -- > > > > *Thanks & Regards,Sachini JayasekaraSoftware Engineer; **WSO2 Inc. * > > *lean . enterprise . middleware | http://wso2.com <http://wso2.com> * > > _______ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- 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
Re: [Architecture] Sensor data flow from Devices to the Platform
Hi Chan, Clarification, How the device manager generating the token? And what is the logic for validating the token? Thanks On Tue, Sep 30, 2014 at 8:19 PM, Chan wrote: > Hi guys, > Once the devices are enrolled to the Platform - Devices will be publishing > data. For the initial implementation - this will be based on HTTP. We > brainstormed sometime back and found there are 2 types of data - management > data, sensor data, I am proposing the below architecture to publish data > from devices to the platform. > > > > > The Device is first enrolled to the Device Manager and it will be given a > token. The device publishes the data to the Event Receiver. I think we > have to override the Http Event Receiver to perform this token check. After > the token check is done- we need to add the deviceId and tenantId > parameters to the data payload. The Device communication to the Event > Receiver has to be protect through SSL. (Small point here would be about > the long lived access tokens on the device. > > Cheers~ > > -- > Chan (Dulitha Wijewantha) > Software Engineer - Mobile Development > WSO2 Inc > Lean.Enterprise.Mobileware > * ~Email duli...@wso2.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 > > -- 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
Re: [Architecture] ES- Asset publisher to BAM
Hi Suho, noted Thanks On Mon, Sep 29, 2014 at 4:33 PM, Sriskandarajah Suhothayan wrote: > Please use load-balancing data-publisher to publish data to BAM. > > Suho > > On Mon, Sep 29, 2014 at 4:23 PM, Manoj Gunawardena > wrote: > >> Hi Devs, >> >> For ES, I am creating a JAGGERY API to publish ES asset events to BAM. >> The objective is show asset related statistics in BAM dashboard. >> >> >> Inside API, uses Data publisher to send events, related to assets. >> >> When an event occurs in ES, which need to gather statistics, the jaggery >> code will call the API and publish event details to BAM. >> >> >> >> Ex -: Suppose we need to show information of how many downloads per asset. >> The asset download JAG page call the publishEvents API. >> >> >> >> Please go through the diagrom and share your thoughts. >> >> >> >> >> Thanks >> >> >> >> >> BAM Publsiher >> <https://docs.google.com/a/wso2.com/drawings/d/1UpznqPjH2Ohy05OBtiLy1a3tFZIuoYH0NX5u5RIv5E4/edit?usp=drive_web> >> >> >> >> >> -- >> 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 >> >> > > > -- > > *S. Suhothayan* > Technical Lead & Team Lead of WSO2 Complex Event Processor > *WSO2 Inc. *http://wso2.com > * <http://wso2.com/>* > lean . enterprise . middleware > > > *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: > http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter: > http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: > http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>* > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- 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
[Architecture] ES- Asset publisher to BAM
Hi Devs, For ES, I am creating a JAGGERY API to publish ES asset events to BAM. The objective is show asset related statistics in BAM dashboard. Inside API, uses Data publisher to send events, related to assets. When an event occurs in ES, which need to gather statistics, the jaggery code will call the API and publish event details to BAM. Ex -: Suppose we need to show information of how many downloads per asset. The asset download JAG page call the publishEvents API. Please go through the diagrom and share your thoughts. Thanks BAM Publsiher <https://docs.google.com/a/wso2.com/drawings/d/1UpznqPjH2Ohy05OBtiLy1a3tFZIuoYH0NX5u5RIv5E4/edit?usp=drive_web> -- 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
