On Fri, Jun 30, 2017 at 2:47 PM, Lakmal Warusawithana <[email protected]> wrote:
> Hi Maninda, > > On Fri, Jun 30, 2017 at 12:02 PM, Maninda Edirisooriya <[email protected]> > wrote: > >> 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. >> > > This is exactly what we want to avoid. :) > > #1 is not an valid concern. We are not going to solve generic case here. > In the APIM, throttling policy update not a frequent thing. Sometimes it > only doing one time for a deployment. > Yeah if we just want to fix the APIM requirement that would be enough. But realtime policy updating would certainly be an valid scenario in the CEP user's point of view. Suppose a customer system (or an ESB) wants to update the execution plans right away. Then it would be useful. > > I can't understand #2 concern. No need CEP to restart anytime. > I may be wrong. As I understand the CEP should be given the API location of policies URL in somewhere in configuration. If the host address is changed in that URL, the CEP should be restarted. Isn't it? may be we can give the URL in a registry location and each time the cron job is running, the URL can be obtained from the registry. > > >> >> 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> >>> >> >> > > > -- > Lakmal Warusawithana > Director - Cloud Architecture; WSO2 Inc. > Mobile : +94714289692 <071%20428%209692> > Blogs : https://medium.com/@lakwarus/ > http://lakmalsview.blogspot.com/ > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
