Taosheng, In this scenario, it looks like we should use http2 to transport the payload, what do you think?
Thanks, -Ian. On Wed, Jan 23, 2019 at 10:35 PM Taosheng Wei <tswstarpla...@apache.org> wrote: > I think we can find a binary protocol with strong potential to be a public > application protocol like http, and extend it with security function. Or if > there aren't such suitable protocols, we can try to formulate a new > protocol. Then make Dubbo support it. > In my opinion, this way may not only solve the security problems, but also > solve the cross-language RPC with Dubbo. > > zhi_guang_...@163.com <zhi_guang_...@163.com> 于2019年1月23日周三 下午5:47写道: > > > I have a similar Question as this mail: > > Is Dubbo designed for use on internet? > > I have just join a company last year and our business is all around the > > world. > > So we have servers on US and ASIA and EU. > > In this condition we use dubbo on internet and keep security by security > > rules that only allow the servers connect to each other. > > > > I think this is not a pretty useage of dubbo,but I cann't find Strong > > evidences to change the situation. > > > > Can any one help me to answer this questions? Thanks a lot. > > > > > > > > ------------------------------ > > 您的朋友:刘志广 > > > > > > *From:* Yuhao Bi <byh0...@gmail.com> > > *Date:* 2019-01-22 22:55 > > *To:* dev <dev@dubbo.apache.org> > > *Subject:* Re: [DISCUSS]: Some thoughts on What Dubbo 3.0 is, we really > > should start it ASAP > > Hi lan and community, > > > > Although I have already heard "Dubbo" a few years ago, > > but I just started to learn dubbo after the meetup last year in Chengdu > > after it became the Apache Dubbo. > > Maybe I'm not such that familiar with the underlying details, but after > > the continuous participated > > I feel like a part of the community, and free to share my opinion. > > > > So, here is my question and also consider it my suggestion: > > Should we care more about Security? How can we prevent from unauthorized > > remote call? > > - Should we support Authentication and Authorization > > - Should we add Spring Security or Active Directory Service support at > the > > framework level > > > > Thanks, > > Yuhao > > > > > > jun liu <ken.lj...@gmail.com> 于2019年1月22日周二 下午5:50写道: > > > > > > I think the online integration test and performance test environment > > > should > > > > be set up for the new features. > > > > > > Agree! We should start as soon as possible, from 2.7.x. > > > > > > Jun > > > > > > > On Jan 22, 2019, at 5:43 PM, Xin Wang <xin.victorw...@gmail.com> > > wrote: > > > > > > > > I think the online integration test and performance test environment > > > should > > > > be set up for the new features. > > > > > > > > Ian Luo <ian....@gmail.com> 于2019年1月22日周二 下午3:04写道: > > > > > > > >> Yuhao, good idea. > > > >> > > > >> BTW, do you have any thought on what Dubbo 3.0 should be? > > > >> > > > >> Thanks, > > > >> -Ian. > > > >> > > > >> > > > >> On Tue, Jan 22, 2019 at 2:39 PM Yuhao Bi <byh0...@gmail.com> wrote: > > > >> > > > >>> Once we have decided what to do in the next. > > > >>> Should we have a website page to publish it? e.g. [1] > > > >>> > > > >>> [1]. https://phoenix.apache.org/roadmap.html > > > >>> > > > >>> yuneng xie <xieyun...@gmail.com> 于2019年1月22日周二 下午2:25写道: > > > >>> > > > >>>> Hi Ian Luo, > > > >>>> > > > >>>> OK, i'd start to work on it soon. > > > >>>> > > > >>>> Ian Luo <ian....@gmail.com> 于2019年1月17日周四 下午2:01写道: > > > >>>> > > > >>>>> Hi Yuneng, > > > >>>>> > > > >>>>> Sounds interesting. I am especially interested in reactive > > > >> programming > > > >>>>> support. Pls. go ahead to try implement it on 3.x branch. > > > >>>>> > > > >>>>> Thanks, > > > >>>>> -Ian. > > > >>>>> > > > >>>>> On Thu, Jan 17, 2019 at 11:03 AM yuneng xie <xieyun...@gmail.com > > > > > >>> wrote: > > > >>>>> > > > >>>>>> Hi folks, > > > >>>>>> > > > >>>>>> I agreed with Ian Luo on the improvement list. I also got some > > idea > > > >>> in > > > >>>> my > > > >>>>>> mind. I'd just share with you two points below in detail which > > i'm > > > >>>> most > > > >>>>>> interested in right now. > > > >>>>>> > > > >>>>>> 1. Upgrade the core abstraction "Invoker", which works in sync > > > >> mode, > > > >>>> to > > > >>>>> an > > > >>>>>> abstraction works in async mode. then we can construct > > > >>>>>> InvocationChain/FilterChain that works in async mode. A core > > > >>>> abstraction > > > >>>>>> works in async mode would simplify the sync/async logic. We no > > > >>> longer > > > >>>>> need > > > >>>>>> to repeat the logic about sync-mode/async-mode in each > > > >>> ProtocolInvoker. > > > >>>>>> ProtocolInvoker could concentrate on async logic and we could > > > >> handle > > > >>>>>> sync-mode invoke all in once by wrapping the > AsyncInvocationChain > > > >>> into > > > >>>> a > > > >>>>>> SyncInvocationChain. > > > >>>>>> > > > >>>>>> 2. Support using stream-value (Fowable, Flux...) as > > > >>> param/returnType. > > > >>>>>> really a nice feature. > > > >>>>>> > > > >>>>>> Please let me known your opinion on my points. I'm also glad to > > > >> just > > > >>>> give > > > >>>>>> it a try and raise a pr. > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> Ian Luo <ian....@gmail.com> 于2019年1月10日周四 下午6:00写道: > > > >>>>>> > > > >>>>>>> Hi folks, > > > >>>>>>> > > > >>>>>>> Finally we managed to ramp down version 2.7.0 development, and > > > >>>>> hopefully > > > >>>>>> we > > > >>>>>>> can start the vote in the early of the next week. But the main > > > >>>> purpose > > > >>>>> of > > > >>>>>>> this email is not a release announcement. Instead, since we now > > > >>> have > > > >>>>>>> bandwidth, let's consider and discuss what we should focus out > > > >> from > > > >>>>> many > > > >>>>>>> stuff we want to do. For example, we may focus more on issue > and > > > >>> pull > > > >>>>>>> request on GitHub, or we may plan 2.7 minor releases > immediately > > > >>>> after > > > >>>>> we > > > >>>>>>> release 2.7.0. But today I'd like to bring up one longer term > > > >> plan > > > >>>>> which > > > >>>>>>> I'm now caring most, that is, how we define what version 3.0 > is? > > > >>> and > > > >>>>> when > > > >>>>>>> can we get start on it? In my opinion, we need to start it > right > > > >>> from > > > >>>>>> this > > > >>>>>>> moment. > > > >>>>>>> > > > >>>>>>> I recalled Liujie Qin (@liujieqin) initialed the discussion on > > > >> the > > > >>>> same > > > >>>>>>> topic [1] in July this year. I summarize his points here if you > > > >> are > > > >>>> too > > > >>>>>>> impatient to read through the contents of his email :p: > > > >>>>>>> > > > >>>>>>> 1. Need to enhance the current extension mechanism > > > >>>>>>> 2. Need to enhance the code base for better maintenance > > > >>>>>>> 3. Need to support async > > > >>>>>>> 4. Need to decouple registry server and config server > > > >>>>>>> 5. Need to support Java8 and above so that we can use advanced > > > >>>> features > > > >>>>>> in > > > >>>>>>> Dubbo's core > > > >>>>>>> > > > >>>>>>> I agree with most of his points in this good proposal. > > > >>>>>>> > > > >>>>>>> Here I'd like to initial a discussion on how we define Dubbo > 3.0, > > > >>> or > > > >>>> in > > > >>>>>> the > > > >>>>>>> other word, how do the community expect from Dubbo 3.0. In my > > > >>>> opinion, > > > >>>>> I > > > >>>>>>> think we need to answer the following questions in this major > > > >>>> release: > > > >>>>>>> > > > >>>>>>> - Today the boundary between messaging and remoting call gets > > > >> blur. > > > >>>> We > > > >>>>>> may > > > >>>>>>> need to consider to support streaming at the protocol level. > > > >>>>>>> - Reative programming and its fundamental FP start to get > > > >> adopted. > > > >>> We > > > >>>>>>> should consider to support it. > > > >>>>>>> - Dubbo should be redesigned to support async better, and > treats > > > >>>> async > > > >>>>> as > > > >>>>>>> the first class citizen. We do support async feature in 2.7.0 > > > >>> release > > > >>>>> but > > > >>>>>>> it is not so perfect. > > > >>>>>>> - Micro-services has been widely adopted. How Dubbo works > > > >>> seamlessly > > > >>>>> with > > > >>>>>>> micro-services becomes a question mark. We need to look into > the > > > >>>>> inter-op > > > >>>>>>> between Dubbo and micro-services's registry server/config > server. > > > >>> The > > > >>>>>>> support on separating registry server and config server in > 2.7.0 > > > >>>>> release > > > >>>>>> is > > > >>>>>>> a good start, but there are still lots of further works > remaining > > > >>>> with > > > >>>>> no > > > >>>>>>> doubt. > > > >>>>>>> - Once we conquer seamless micro-services support, we still > need > > > >> to > > > >>>>> take > > > >>>>>>> one step further to think about K8S integration. After all, K8S > > > >> and > > > >>>>>> service > > > >>>>>>> mesh built above it are now considered the best way for > > > >>>> micro-services > > > >>>>>>> deployment. > > > >>>>>>> - How we define mini-dubbo, or phrase in another way, what the > > > >>>> minimal > > > >>>>>>> feature set we should define for Dubbo framework. The reason > > > >> behind > > > >>>>> this > > > >>>>>>> is, it is very helpful for developing more language supports > from > > > >>> the > > > >>>>>>> community. This also means, we need to modularize Dubbo > further, > > > >> to > > > >>>>> make > > > >>>>>> it > > > >>>>>>> a reference implementation for other languages. > > > >>>>>>> > > > >>>>>>> In short, I suggest we need to focus on streaming protocol, > > > >> Rx/FP, > > > >>>>> native > > > >>>>>>> async, micro-services support, refactor/modularize areas. Of > > > >>> course, > > > >>>>>> there > > > >>>>>>> are more I don't mention in this email, for examples: how we > make > > > >>>> Dubbo > > > >>>>>>> more resilient? how we support HTTP/2? and more. > > > >>>>>>> > > > >>>>>>> Pls. let me know your opinion on what I and Liujie proposed, > and > > > >>>> share > > > >>>>>> your > > > >>>>>>> thought on what kind of features really matter to you. > > > >>>>>>> > > > >>>>>>> Thanks, > > > >>>>>>> -Ian. > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> 1. Proposal for Dubbo 3.0 from liujie...@apache.org on > > > >>>>>>> dev@dubbo.apache.org > > > >>>>>>> > > > >>>>>> > > > >>>>> > > > >>>> > > > >>> > > > >> > > > > > > > > > > >