If we only support MQTT only in light weight one, that should be possible. On Thu, Jul 9, 2015 at 10:38 AM, Afkham Azeez <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> >>> 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 >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Ramith Jayasinghe >> Technical Lead >> WSO2 Inc., http://wso2.com >> lean.enterprise.middleware >> >> E: [email protected] >> P: +94 777542851 >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> 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: **[email protected]* <[email protected]> > * 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 [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
