On Thu, Jul 9, 2015 at 10:41 AM, Srinath Perera <srin...@wso2.com> wrote:
> If we only support MQTT only in light weight one, that should be possible. > > +1, MQTT is enough for our communications. > On Thu, Jul 9, 2015 at 10:38 AM, Afkham Azeez <az...@wso2.com> wrote: > >> Ramith what would involve making a really lightweight MB? It would have a >> lot of benefits. Like the lightweight Netty based JAXRS engine which is >> performing a whole lot better than stock JAXRS as well as consuming less >> memory, it would be very useful to have a lightweight MB which can run on >> C5. >> >> >> On Thu, Jul 9, 2015 at 10:16 AM, Ramith Jayasinghe <ram...@wso2.com> >> wrote: >> >>> can't we make the single node work without having to go through topics >>> etc? >>> and topic based artifact distribution mechanism get enabled only if >>> clustering is enabled? >>> >>> On Thu, Jul 9, 2015 at 8:40 AM, Srinath Perera <srin...@wso2.com> wrote: >>> >>>> Overall look good. >>>> >>>> How would the single node version work? Does it embed MB? >>>> >>>> Kernel, are we using JMS as message interface or wrap it in our own >>>> interface? >>>> >>>> --Srinath >>>> >>>> >>>> >>>> On Thu, Jul 2, 2015 at 3:49 PM, Lakmal Warusawithana <lak...@wso2.com> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> Had initial discussion with Azeez and Carbon team about $subject. >>>>> Please find the details. >>>>> >>>>> *Are we embedding MB into kernel?* >>>>> >>>>> We though of not to embed MB into kernel, rather runs it on top or >>>>> separate. Kernel APIs are expect topology and ADC topic (MB end point) for >>>>> the artifact distribution and the topology management. Will bungle light >>>>> weight MB features with products which can runs in management node to >>>>> cover >>>>> requirement. But importantly kernel APIs are not depend on any specific >>>>> MB, >>>>> rather only need MB end point. >>>>> >>>>> *Important of the topology topic* >>>>> >>>>> Topology topic contain cluster detail of the all members, artifacts >>>>> etc. When ever new member created (statically or dynamically) kernel will >>>>> update the topology with member details like cluster, IP, ports etc. >>>>> >>>>> With the effect of topology introduce, Load Balancers get all member >>>>> information dynamically which eliminate static member configuration. With >>>>> the load balancer extension, capable of working with ANY load balancers >>>>> without coupling to one. >>>>> >>>>> With the topology based LB support, we can achieved partition based >>>>> artifact update without major effect. e.g. Say we are having 5 nodes on a >>>>> cluster and want to update 3 node with artifact V1 and other two with >>>>> artifact V2. ADC can instruct (will explain topic based ADC next section) >>>>> second 2 nodes to take new version V2 and update the topology with >>>>> relevant >>>>> artifact version, then LBs can dynamically configure to route V1 to first >>>>> 3 >>>>> nodes and V2 to second 2 nodes etc. >>>>> >>>>> Topology also help to provide better solution to WKA member discovery >>>>> in current hazelcast implementation. Simply we can get all members >>>>> information for a cluster and update hazelcast member list. See same >>>>> mechanism used in Kubernetes to member discovery on hazelcast based >>>>> containers [1]. With the effect on that all members will be WKA and we >>>>> also no need to go specific implementation AWS member discovery etc. This >>>>> can be used in any cloud with out specific to a provider. Also this can >>>>> used with any clustering implementation. (not specific to hazelcast) >>>>> >>>>> [1] >>>>> https://github.com/pires/hazelcast-kubernetes-bootstrapper/blob/master/src/main/java/com/github/pires/hazelcast/HazelcastDiscoveryController.java >>>>> >>>>> *Topic based artifact synchronizer* >>>>> >>>>> This will replace hazelcast/SVN based artifact synchronizer. Instead >>>>> sending cluster messages, artifact updates are notify via pub/sub >>>>> communication which give more scalability and capable of multi region >>>>> deployment support. >>>>> >>>>> Also new artifact update should have two phases. >>>>> >>>>> 1. Upload artifact to management node >>>>> 2. Notify the members of the cluster >>>>> >>>>> Two phase model bring following benefits. >>>>> >>>>> - Artifact versioning support. >>>>> - with the versioning effect, capable of artifact rollback >>>>> - composite application artifact support - IMO individual products >>>>> should not aware of the deployment logic of the composite apps >>>>> artifacts, >>>>> rather centralize ADC should handle the decompose logic and notify >>>>> relevant >>>>> products to get relevant artifact update. >>>>> - Artifact update message should provide protocol and artifact end >>>>> point ( IMO by default we should support HTTP based artifact end >>>>> points), >>>>> kernel will get and deploy the artifacts. >>>>> - By default HTTP based artifact server will host in the >>>>> management node, but if a cluster having larger size artifacts and >>>>> frequent >>>>> updates recommended to having separate file server. But either way >>>>> artifact update APIs are not changed. >>>>> >>>>> >>>>> These are some key points, can discussed details when having the >>>>> review session. @Azeez is anything I missed? >>>>> >>>>> Welcome your thoughts :) >>>>> >>>>> PS: Also we have discussed MT model effect with containers and >>>>> microservice based product deployment. Need separate thread I guess :) >>>>> >>>>> -- >>>>> Lakmal Warusawithana >>>>> Vice President, Apache Stratos >>>>> Director - Cloud Architecture; WSO2 Inc. >>>>> Mobile : +94714289692 >>>>> Blog : http://lakmalsview.blogspot.com/ >>>>> >>>>> >>>> >>>> >>>> -- >>>> ============================ >>>> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera >>>> Site: http://people.apache.org/~hemapani/ >>>> Photos: http://www.flickr.com/photos/hemapani/ >>>> Phone: 0772360902 >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Ramith Jayasinghe >>> Technical Lead >>> WSO2 Inc., http://wso2.com >>> lean.enterprise.middleware >>> >>> E: ram...@wso2.com >>> P: +94 777542851 >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Afkham Azeez* >> Director of Architecture; WSO2, Inc.; http://wso2.com >> Member; Apache Software Foundation; http://www.apache.org/ >> * <http://www.apache.org/>* >> *email: **az...@wso2.com* <az...@wso2.com> >> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >> *http://blog.afkham.org* <http://blog.afkham.org> >> *twitter: **http://twitter.com/afkham_azeez* >> <http://twitter.com/afkham_azeez> >> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >> <http://lk.linkedin.com/in/afkhamazeez>* >> >> *Lean . Enterprise . Middleware* >> > > > > -- > ============================ > Blog: http://srinathsview.blogspot.com twitter:@srinath_perera > Site: http://people.apache.org/~hemapani/ > Photos: http://www.flickr.com/photos/hemapani/ > Phone: 0772360902 > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Lakmal Warusawithana Vice President, Apache Stratos Director - Cloud Architecture; WSO2 Inc. Mobile : +94714289692 Blog : http://lakmalsview.blogspot.com/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
