On Thu, Mar 21, 2013 at 10:52 PM, Nuwan Bandara <[email protected]> wrote:
> > On Fri, Mar 22, 2013 at 10:59 AM, Afkham Azeez <[email protected]> wrote: > >> >> >> On Fri, Mar 22, 2013 at 8:38 AM, Sanjiva Weerawarana <[email protected]>wrote: >> >>> I agree with all of this *but*, I still don't get why the workers don't >>> need APIs. How do we: >>> - ask it to update itself for deployment type stuff >>> - ask it to change some config >>> - ask it to send BAM events to a particular place >>> - do JMX to it >>> etc. etc.. >>> >>> All of those require that the OC or the mgmt node or ADC be able to talk >>> to the server. Maybe the communication is cluster-wide (broadcast) or maybe >>> its point-to-point ... depends on the scenario. I am confused why we don't >>> need some way to interact with the worker remotely. >>> >> >> We may require some APIs at the worker level to do certain stuff (we have >> not required this so far) once we have OC, but those APIs will be different >> from the management APIs in the management node/OC. The UI will not talk to >> the worker nodes ever. >> >> I think we need to have a meeting to make some crucial decisions because >> what we build could be used for the next 5 years. The Carbon UI framework >> we built in 2008 is still in use. >> > > Yeah better to have a meeting on the subject > +1. I would like to join as well. Thanks, Sameera. > > >> >> >>> >>> Obviously I'm missing some crucial thought here ... what is it? >>> >>> Sanjiva. >>> >>> >>> On Fri, Mar 22, 2013 at 12:52 AM, Afkham Azeez <[email protected]> wrote: >>> >>>> >>>> >>>> On Fri, Mar 22, 2013 at 12:47 AM, Sagara Gunathunga <[email protected]>wrote: >>>> >>>>> >>>>> >>>>> On Fri, Mar 22, 2013 at 12:36 AM, Sameera Jayasoma >>>>> <[email protected]>wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Mar 21, 2013 at 12:00 PM, Sagara Gunathunga >>>>>> <[email protected]>wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Mar 22, 2013 at 12:12 AM, Afkham Azeez <[email protected]>wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Mar 22, 2013 at 12:05 AM, Sameera Jayasoma < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> See my comments inline. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 21, 2013 at 11:25 AM, Afkham Azeez <[email protected]>wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Mar 21, 2013 at 11:49 PM, Sameera Jayasoma < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Azeez, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Mar 21, 2013 at 5:49 AM, Afkham Azeez <[email protected]>wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Mar 21, 2013 at 6:16 PM, Sanjiva Weerawarana < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Azeez don't we need the management API in worker nodes? I >>>>>>>>>>>>> assume the answer is yes .. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> If you look at the current worker-manager separated setup, we >>>>>>>>>>>> don't have a single instance where the management node BE or FE >>>>>>>>>>>> calls into >>>>>>>>>>>> the worker node BE. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I agree that worker nodes do not require administrative >>>>>>>>>>> services. But for Management node, we need to maintain the BE/FE >>>>>>>>>>> separation. I.e we need to keep the administration services as its. >>>>>>>>>>> This >>>>>>>>>>> would user to write their own UI layer to interact with our server. >>>>>>>>>>> This >>>>>>>>>>> exactly what AppFactory is doing right? In some of the project I've >>>>>>>>>>> worked, >>>>>>>>>>> we developed completely different UI to interact with Mgt nodes. So >>>>>>>>>>> IMV, we >>>>>>>>>>> still need that BE services. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> FE-BE separation means from the UI components we make service >>>>>>>>>> calls to the BE components. What we need is management APIs. Our UI >>>>>>>>>> can >>>>>>>>>> simply use these management APIs. We don't need FE-BE separation. >>>>>>>>>> External >>>>>>>>>> apps can also call these management APIs. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Okay. so anyway we need to expose our management APIs as service >>>>>>>>> right?. >>>>>>>>> >>>>>>>>> I was under the impression that FE-BE separation means a clear >>>>>>>>> separation of UI layer from the BE layer. some how we ended up >>>>>>>>> connecting >>>>>>>>> FE layer to BE layer via web services communication. But we tried to >>>>>>>>> connect FE to BE via Java calls via OSGi services approach. Thats >>>>>>>>> didn't >>>>>>>>> work due to some security issues. >>>>>>>>> >>>>>>>>> Anyway still we need to clearly separate FE components from the >>>>>>>>> management APIs right? But we need to figure out an efficient and >>>>>>>>> secure >>>>>>>>> way to connect the FE to BE. >>>>>>>>> >>>>>>>> >>>>>>>> I guess where I am getting at is, we have RESTful APIs, which will >>>>>>>> be called by code running in the Web Browser. Yes, I am suggesting >>>>>>>> that we >>>>>>>> go back to the old AJAX based UI model we had, but without the pain of >>>>>>>> XSLT >>>>>>>> (in the old model). >>>>>>>> >>>>>>>> FE = jquery + HTML+ (Jaggery?) >>>>>>>> BE= RESTful APIs (Jaggery?) >>>>>>>> >>>>>>>> FE <--- JSON --> BE >>>>>>>> >>>>>>> >>>>>>> One question, what is the transport protocol which carries JSON >>>>>>> messages from FE to BE ? >>>>>>> >>>>>> >>>>>> Obviously HTTPS. :) >>>>>> >>>>> >>>>> Given the fact that both FE and BE run on same JVM do we really need >>>>> to use transport level protocols here ? isn't it make sense to use Java >>>>> call within the JVM ? >>>>> >>>>> >>>> FE (running on Web Browser) <--- JSON/HTTP --> BE (RESTful API running >>>> in JVM) >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Sanjiva Weerawarana, Ph.D. >>> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ >>> email: [email protected]; phone: +94 11 763 9614; cell: +94 77 787 6880| +1 >>> 650 265 8311 >>> blog: http://sanjiva.weerawarana.org/ >>> >>> Lean . Enterprise . Middleware >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> *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 >> 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* >> * >> * >> *Lean . Enterprise . Middleware* >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Thanks & Regards, > > Nuwan Bandara > Associate Technical Lead & Member, MC, Development Technologies > WSO2 Inc. - lean . enterprise . middleware | http://wso2.com > blog : http://nuwanbando.com; email: [email protected]; phone: +94 11 763 > 9629 > * > <http://www.nuwanbando.com/> > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- Sameera Jayasoma Senior Technical Lead WSO2, Inc. (http://wso2.com) email: [email protected] blog: http://sameera.adahas.org Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
