I wouldnt disagree with anything Sean is saying. Althought when distilled he is basically saying trust an abstracted API. I kinda tend to like that descrition although I am not sure it helps folks understand the issues. The challenge here was folks disagreeing about the implementation of that API. In the end, Sean is correct. Both implementations hold value. In the majority of cases, Flex is being used in an enterprise distributed paradigm and folks should keep in mind network issues and topology.
Keep up the flow of information. I think its pretty new for most folks here. -- Dave Wolf Cynergy Systems, Inc. Macromedia Flex Alliance Partner http://www.cynergysystems.com Email: [EMAIL PROTECTED] Office: 866-CYNERGY x --- In [email protected], "Matt Chotin" <[EMAIL PROTECTED]> wrote: > > In response to this and the other related thread I just want to post > something that one of our architects, Sean Neville, wrote. You'll get > to see the outcome of the work that Sean alludes to when we start > showing off Flex Enterprise Services in a few months (this is not a > timetable on beta or release). > > > > -- > > There are numerous patterns for dealing with network reliability and > message durability issues across pushed channels, which we are > implementing and which countless others have implemented before us. > These are well-documented and used in critical enterprise apps daily, > particularly in sectors like financial services. > > > > However, there are cases where it is inappropriate, such as the > operational issues of certain deployments reliant on Internet deployment > and web browser clients. In this case polling approaches are > appropriate. > > > > In still other cases, one view of a set of services may be reasonably > accessed via server push, while another view may need to avoid server > push, or at least gracefully switch to a polling technique when push > proves inadequate. This use of the same service(s) across different > network channels by different users should not require API or service > design changes on the part of the developers. > > > > The ideal message bus enables both approaches without requiring changes > in API or service design, and without requiring the network quality of > service issues to affect message choreography. The well-designed message > bus cleanly decouples the administrator's network channel mechanisms > from the app developer's service logic. Both push and polling approaches > have value, though it is quite possible that only one approach or the > other will have value in any one specific scenario or use case - and it > is also quite possible that the specific scenario may change during the > lifetime of an enterprise application and its services, outliving the > attention of its original developers and administrators, so that a > previously horrid approach becomes more desirable or even required. > > > > The logical thing to do is to support both in as clean and extensible > fashion as possible. This also alleviates the need to participate in > push/pull/poll religious debates except for sport. > > -- > > > > See, he's a smart guy. We hope you guys get to benefit from his and > other people's efforts pretty soon :-) > > > > Matt > > > > ________________________________ > > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of Dave Wolf > Sent: Tuesday, October 11, 2005 5:58 PM > To: [email protected] > Subject: [flexcoders] HttpService Push (Re: HTTPService timeout) > > > > There are some things to keep in mind in terms of performance. > Realize that for every client event registration you effectively tie > up a HTTP connection on the server. This means you effectively tie up > a thread on the server. You will want to make sure you server has > enough HTTP threads and descriptors so it can still service normal > HTTP connects. You might also want to see where TCP_KEEPALIVE is set > to prevent the possibility of half dead sockets from dropped clients > getting in the way. > > You might also want to implement a timeout in the servlet. Just drop > idle sockets every N interval. Since the clients should be inside > loops, they will just reconnect if they are still alive. > > As I said, there are some seriously big financial and other > applications that run mission critical systems using just such a design. > > Dave Wolf > Cynergy Systems, Inc. > Macromedia Flex Alliance Partner > http://www.cynergysystems.com > > Email: [EMAIL PROTECTED] > Office: 866-CYNERGY x85 > > > > --- In [email protected], "Eric Raymond" > <[EMAIL PROTECTED]> wrote: > > > > Very clever. > > > > I'm curious if you'd care to share any experiences or gotcha's with > > this approach? > > > > In practice, can you rely upon the HtppService returning or generating > > an error? Or do you need some sort of setInterval function which > > occasionally resets things. > > > > Are there any timeouts accross the entire stack that one would need to > > be aware of. > > > > Are there any issues with the servlet thread poor that arise in > practice? > > > > > > > > > > > > > > > > --- In [email protected], "Dave Wolf" <[EMAIL PROTECTED]> wrote: > > > > > > No not quite. That would be polling. I am *not* suggesting > polling. > > > What I am suggesting is using a "Blocking Registration" pattern to > > > handle this. > > > > > > Basically you get Flex to make an HTTP request to say a servlet in > > > your webserver. That http call will "hang". Since the player makes > > > an http request on its own thread, this hang has no impact on the > UI. > > > > > > Now when the event occurs the servlet releases the hung connection, > > > which returns data and the result handler on the client fires and > > > delivers the event to the UI. Viola. Effectively server-push but > > > without the major issues of server-push or true client-pull. > > > > > > This design has been tested in basically some of the biggest > financial > > > services applications in the world. > > > > > > > > > -- > Flexcoders Mailing List > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > Search Archives: > http://www.mail-archive.com/flexcoders%40yahoogroups.com > > > > > ________________________________ > > YAHOO! GROUPS LINKS > > > > * Visit your group "flexcoders > <http://groups.yahoo.com/group/flexcoders> " on the web. > > * To unsubscribe from this group, send an email to: > [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service <http://docs.yahoo.com/info/terms/> . > > > > ________________________________ > ------------------------ Yahoo! Groups Sponsor --------------------~--> Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM --------------------------------------------------------------------~-> -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
