Hi Dinusha, Why do we think it is the responsibility of the CEP to pull poilcies from the APIM? Just forgetting the APIM case, if we think this as a general feature of CEP, here the CEP is periodically pulling artifacts from a given set of APIs. There are 2 drawbacks I see in this approach.
1. Updating the CEP with latest artifacts is restricted by the given polling time interval. (realtime CEP artifact updates are not possible from an external party which is important as CEP is dealing with realtime requirements) 2. Dynamically adding unplanned artifacts to a running CEP server is not possible as the polling APIs has to be pre configured. For example this can happen when the existing APIM server is stopped and a different APIM server is started with a different host address. In that case the CEP also has to be restarted to update the policy API location, which would lose some data in the running CEP. Correct me if I am wrong. Therefore I think the current policy push based approach is correct. We should be able to correct the syncing policies across the CEP nodes with a different approach like deploment synchronizing, registry based approach, with a shared database based approach or with a clustering solution like Hazelcast. Thanks. *Maninda Edirisooriya* Senior Software Engineer *WSO2, Inc.*lean.enterprise.middleware. *Blog* : http://maninda.blogspot.com/ *E-mail* : [email protected] *Skype* : @manindae *Twitter* : @maninda On Thu, Jun 29, 2017 at 5:10 PM, Dinusha Dissanayake <[email protected]> wrote: > +Adding architecture > > On Thu, Jun 29, 2017 at 5:05 PM, Nuwan Dias <[email protected]> wrote: > >> Let's discuss publicly please, this thread is internal only. >> >> On Thu, Jun 29, 2017 at 5:01 PM, Dinusha Dissanayake <[email protected]> >> wrote: >> >>> Hi All, >>> >>> In earlier versions of APIM, throttle policy deployment for CEP was >>> handled using push mechanism meaning APIM itself had to deploy throttle >>> policies in CEP. If there are multiple CEP nodes, then the Siddhi >>> apps/execution plans syncing would be an issue here. >>> >>> We were thinking of pull based mechanism from CEP side to overcome this. >>> To do that, from APIM side we need to add an API to the core which allows >>> CEP to get all Siddhi apps for existing throttle policies. Then every CEP >>> node will call APIM (once or periodically) and then it will check the DB >>> and generate a zip containing all the Siddhi Apps for existing throttle >>> policies. >>> >>> >>> This API will only need GET resource. The resource path for this API >>> would be *"export/policies/throttle"*. As mentioned above, this will >>> return a zip. Mutual SSL would be used to secure the API since if we use >>> OAuth2, then the token may expire in a while. >>> >>> Exported zip can be manually deployed in the CEP or deployment can be >>> done using e a curl command. If this needs to be happened periodically, >>> then a cron job can be written. >>> >>> Please provide suggestions for improvements. >>> >>> Thanks & Regards. >>> -- >>> Dinusha Dissanayake >>> Software Engineer >>> WSO2 Inc >>> Mobile: +94712939439 <+94%2071%20293%209439> >>> <https://wso2.com/signature> >>> >> >> >> >> -- >> Nuwan Dias >> >> Software Architect - WSO2, Inc. http://wso2.com >> email : [email protected] >> Phone : +94 777 775 729 <+94%2077%20777%205729> >> > > > > -- > Dinusha Dissanayake > Software Engineer > WSO2 Inc > Mobile: +94712939439 <+94%2071%20293%209439> > <https://wso2.com/signature> >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
