Hello,

I'm building up a new application framework that consists of multiple
components that communicate through events. These components publish their
events as they do work and consume events through what I'm calling the Event
Service Controller (ESC).

The purpose of the ESC is to receive events from the individual components
and then publish events through multicast to each component that has
subscribed to the events it is interested in. You might think of this as a
traffic control system in that all communication goes to the ESC and then it
is broadcast again.

All of these components, and the ESC use a set of interfaces that define
what events they publish.

The problem that I'm running into is that when the ESC starts a component,
how can it determine which interface(s) that component is using to publish
events? I have many different components that (obviously) do not need to know
anything about other components and I want all communication (through events)
to go through the ESC to facilitate an elegant design. For example, I might
later code a component to log specific events received by the ESC, regardless
of where they came from and whatnot.

The crux of the problem is that a specific component may raise only a few
events defined in its interface, of which the ESC has a reference to, but the
ESC has no way of knowing at runtime which interface(s) that component is
going to use and therefore I cannot figure out a way to bind the event
handlers in the ESC to the component.

Ideas? I appreciate any help you can provide... I know that I can use
reflection to get the publically exposed events from the components but that
still leaves me trying to figure out the logic to bind those events to the
corresponding handlers in the ESC.

Thanks in advance!

Chris

Re: Dynamic Event Binding & Interfaces (Complex Questions) by Paul

Paul
Fri Mar 25 23:52:58 CST 2005

Not sure I entirely understand, as I would have thought your ESC would need
to bind to every components events, and only the subscribers would choose
what they wanted to listen to when the subscribed.

At any rate, perhaps some custom attibutes may do what you rquire and enable
you to ascertain at runtime, which components intend to utilise which
interfaces/events.

Might be totally off track here though.

--

- Paul Glavich
ASP.NET MVP
ASPInsider (www.aspinsiders.com)


"Chris Keller" <ChrisKeller@discussions.microsoft.com> wrote in message
news:E9E3A135-AFAE-4BD3-86A8-6BE80638C623@microsoft.com...
> Hello,
>
> I'm building up a new application framework that consists of multiple
> components that communicate through events. These components publish their
> events as they do work and consume events through what I'm calling the
Event
> Service Controller (ESC).
>
> The purpose of the ESC is to receive events from the individual components
> and then publish events through multicast to each component that has
> subscribed to the events it is interested in. You might think of this as a
> traffic control system in that all communication goes to the ESC and then
it
> is broadcast again.
>
> All of these components, and the ESC use a set of interfaces that define
> what events they publish.
>
> The problem that I'm running into is that when the ESC starts a component,
> how can it determine which interface(s) that component is using to publish
> events? I have many different components that (obviously) do not need to
know
> anything about other components and I want all communication (through
events)
> to go through the ESC to facilitate an elegant design. For example, I
might
> later code a component to log specific events received by the ESC,
regardless
> of where they came from and whatnot.
>
> The crux of the problem is that a specific component may raise only a few
> events defined in its interface, of which the ESC has a reference to, but
the
> ESC has no way of knowing at runtime which interface(s) that component is
> going to use and therefore I cannot figure out a way to bind the event
> handlers in the ESC to the component.
>
> Ideas? I appreciate any help you can provide... I know that I can use
> reflection to get the publically exposed events from the components but
that
> still leaves me trying to figure out the logic to bind those events to the
> corresponding handlers in the ESC.
>
> Thanks in advance!
>
> Chris
>
>
>



Re: Dynamic Event Binding & Interfaces (Complex Questions) by ChrisKeller

ChrisKeller
Mon Mar 28 02:19:02 CST 2005

Thanks for the reply Paul.

Your logic is correct, the ESC (in my example) does need to bind to every
event that a component has - but the trick is that not every component has
the same events.

For example, every component has a 'standard' interface that everyone uses -
it is easy enough to bind to those events because I know about them. The
trick with all of this is that there are many different interfaces, the ESC
knows about all of them, but a component may only be implementing a specific
set of interfaces. How can I tell which interfaces (from the known interfaces
mentioned above) are implemented?

I'll be honest, I'd not thought of attributes, so I'll play with that in the
morning and see how that falls into place.

As I mentioned, I can use reflection to see the implemented interfaces on
the component, but I'm not seeing how to write the code to bind to those
events without some kind of convoluted kludge feeling code... I guess what
I'm asking for is opinions on a 'elegant' solution for this type of
infrastructure.

Thank you very much for your valuable time.

Chris


"Paul Glavich [MVP ASP.NET]" wrote:

> Not sure I entirely understand, as I would have thought your ESC would need
> to bind to every components events, and only the subscribers would choose
> what they wanted to listen to when the subscribed.
>
> At any rate, perhaps some custom attibutes may do what you rquire and enable
> you to ascertain at runtime, which components intend to utilise which
> interfaces/events.
>
> Might be totally off track here though.
>
> --
>
> - Paul Glavich
> ASP.NET MVP
> ASPInsider (www.aspinsiders.com)
>
>
> "Chris Keller" <ChrisKeller@discussions.microsoft.com> wrote in message
> news:E9E3A135-AFAE-4BD3-86A8-6BE80638C623@microsoft.com...
> > Hello,
> >
> > I'm building up a new application framework that consists of multiple
> > components that communicate through events. These components publish their
> > events as they do work and consume events through what I'm calling the
> Event
> > Service Controller (ESC).
> >
> > The purpose of the ESC is to receive events from the individual components
> > and then publish events through multicast to each component that has
> > subscribed to the events it is interested in. You might think of this as a
> > traffic control system in that all communication goes to the ESC and then
> it
> > is broadcast again.
> >
> > All of these components, and the ESC use a set of interfaces that define
> > what events they publish.
> >
> > The problem that I'm running into is that when the ESC starts a component,
> > how can it determine which interface(s) that component is using to publish
> > events? I have many different components that (obviously) do not need to
> know
> > anything about other components and I want all communication (through
> events)
> > to go through the ESC to facilitate an elegant design. For example, I
> might
> > later code a component to log specific events received by the ESC,
> regardless
> > of where they came from and whatnot.
> >
> > The crux of the problem is that a specific component may raise only a few
> > events defined in its interface, of which the ESC has a reference to, but
> the
> > ESC has no way of knowing at runtime which interface(s) that component is
> > going to use and therefore I cannot figure out a way to bind the event
> > handlers in the ESC to the component.
> >
> > Ideas? I appreciate any help you can provide... I know that I can use
> > reflection to get the publically exposed events from the components but
> that
> > still leaves me trying to figure out the logic to bind those events to the
> > corresponding handlers in the ESC.
> >
> > Thanks in advance!
> >
> > Chris
> >
> >
> >
>
>
>