Thanks, Ivan - that does make the situation clearer. We're obviously not alone in wondering where this web services road is taking us ... ;-)
-randy At 10:27 AM 5/5/2004, Ivan R. Judson wrote: >Hey Randy, > >I'll address this as two separate points, first multicast and second the >services issue. > >With respect to multicast, we're planning on building a pretty simple set of >services that should alleviate this problem two ways; the current bridge >model will remain as a "service provider" model so that institutions with >large bandwidth and computer resources can offer services to those less >fortunate. However, to enable the more down to earth use we want to see, >we'll also be building a set of peer-to-peer services that can provide >dynamic multicast bridging. This will still be constrained by the firewall >solution, discussed next. > >The firewall issue has various parts, first, we're continuing to minimize >the number of open connections required to run a full venue client -- >perhaps in the future we'll have some sort of connection concentrator and >it'll only be one hole in/out to do the client -- that's not in the near >term, that's a dream/vision :-). On the server side, we'll continue to >reduce the number of holes needed to run services, however, quite honestly >this isn't a top priority for various reasons. First, the feedback we've >received is "as long as we know _what_ we need, we can put holes in", >second, sites providing services are used to this problem, and finally, the >ratio of service providers to users favors us fixing the client situation >first. That being said, someone writing a AG enabled proxy for folks who >don't have holes in place for the two holes that I can think of for the >venue client would be great, I'd love it if someone did that. > >The proliferation of services and firewalls and general web services >problems are just that general web services problems. We'll have to wait and >see what the effect is and adapt to the best solution for the users. I don't >see us steering oasis, ibm, or microsoft in terms of what we want. We'll be >responsible to our user community and continue to try and insulate the users >from changes in the underlying infrastructure, while given them more and >more functionality. > >I hope that helps, > >--Ivan > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Randy Groves > > Sent: Wednesday, May 05, 2004 9:20 AM > > To: [email protected] > > Subject: RE: [AG-TECH] 'Bridge' for venue services, etc.? > > > > The message may not have been as clear as I would have liked > > (an aside - what is the contraction for 'I would have'? > > I'd've? I'dve?) - written in pieces amidst many other things > > going on. And yes, I think that the appropriate > > interpretation is not bridge but proxy. There are really two > > separate concerns. The multicast issue will be with us as > > long as the commodity Internet doesn't supply this as a > > matter of course. So making sure, as much as possible, that > > the aspects of the AG that are truly multicast (and I'm > > showing my ignorance here, but I'm assuming that this is > > mainly the audio and video, right?) can be used over some > > sort of unicast/multicast bridge. > > > > The other issue is the addition of services. With our > > security conscious world, and especially behind corporate > > firewalls, there is a definite problem with additional ports. > > And there is even a growing concern with the overloading of > > port 80, and the possiblility of problems with web services. > > In one document, I think the AGEP about firewalls, there is a > > statement that the venue client need not accept incoming > > packets on the > > 8000/2/4/6 ports, but there will be a loss of some of the > > collaborative richness. I guess my concern is that there not > > be a proliferation of ports that fit into this category. I > > haven't even started the process of discussing breaching our > > official corporate firewall to allow AG sessions between > > external and internal sites. I will have a significant > > problem convincing the powers that be that the 8000/2/4/6 > > regime is acceptable, let alone the fact that we will also > > have to bridge. (If this becomes an acceptable tool, then it > > is feasible that Boeing might create its own external bridge). > > > > That is why the idea of a proxy for the potentially many ports. > > > > Hope that clears up my previous note. > > > > -randy > > > > At 06:31 AM 5/5/2004, Ivan R. Judson wrote: > > > > >There are multiple facets needed to answer your question; > > let me try to > > >catch as many as I can. First let me try to break apart what you're > > >asking about to see if I can capture it correctly. You're mentioning > > >multicast and firewalls, and concerned about users who need to work > > >around issues related to them. Additionally the use of > > 'Bridge' in your > > >subject line is not a like we've ever used the word before, > > it's really a proxy, right? > > > > > >If these assumptions are correct, I can answer your > > questions pretty easily. > > > > > >--Ivan > > > > > > > -----Original Message----- > > > > From: [email protected] > > > > [mailto:[email protected]] On Behalf Of Randy Groves > > > > Sent: Wednesday, May 05, 2004 8:25 AM > > > > To: [email protected] > > > > Subject: [AG-TECH] 'Bridge' for venue services, etc.? > > > > > > > > I'm looking into the future here, and wondering how many > > of the new > > > > services that might be coming down the pike are going to fit into > > > > the > > > > 8000,2,4,6 port scheme of the Venue Server/Client as it > > is presently > > > > designed. I know that on the top end of all this, the fact that > > > > some of the participants are multicast-challenged will mean that > > > > they just lose out on some of the newest features. If the > > > > participants are multicast-challenged and firewall-challenged > > > > (behind a restrictive firewall, with a long process to go through > > > > before changes can be made, long security justifications for just > > > > opening up any port in the first place, etc.), I see them > > > > potentially falling further and further behind. > > > > > > > > What is the priority, when design decisions are made, as to what > > > > emphasis is placed on making sure that these situations are dealt > > > > with? > > > > > > > > Is there a possibility of a venue service proxy in the future? > > > > > > > > -randy > > > > > > > > > > > > > > > > > > > >
