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 J
Matt
From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Dave Wolf
Sent: Tuesday, October 11, 2005
5:58 PM
To: flexcoders@yahoogroups.com
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 flexcoders@yahoogroups.com,
"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 flexcoders@yahoogroups.com,
"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
