Makes perfect sense, seems like a lot of work though. You say "insist on using rsb..." - what does this imply?
On Mon, Apr 19, 2010 at 4:18 PM, nightwatch77 <[email protected]>wrote: > Jan, to efficiently receive messages by polling you have to store them > at the server and get them all in a batch. So, if you insist on using > RSB, you'll have to implement a buffering consumer that will sit on > the server and collect messages directed to it and allow you to > retrieve them all by a WCF call. Something like a 'gateway' between > synchronous WCF and asynchronous RSB. I'm thinking about something > like an additional RSB endpoint that would forward your WCF messages > to RSB infrastructure (but substituting its own endpoint name as a > reply address - like in NAT) and keep all incoming replies in a buffer > so your client app could get them by polling. Does it make any sense? > > > > On 19 Kwi, 18:37, Jan Limpens <[email protected]> wrote: > > From what I can see a (occasional) consumer is just registered to the > > container by its name, right? > > Probably there is some facility somewhere, that inspects these components > > and finds out who subscribed to what. > > > > So, if my sl control wants to 'subscribe' to a reply, it has to tell its > > service instance about that. Do you have any idea, of how I could make > such > > a service instance make either > > a) subscribe to the reply without it implementing the interface and being > > installed in the container? or > > b) use dynproxy and some kind of factory to generate the consumer on the > > fly? This instance could the be registered to the container and disposed > of > > after use. > > > > Or any other better idea? Is my idea feasible at all? > > > > > > > > > > > > On Mon, Apr 19, 2010 at 1:16 PM, Ayende Rahien <[email protected]> > wrote: > > > Jan, > > > Reply is always async with RSB > > > > > On Mon, Apr 19, 2010 at 6:29 PM, Jan Limpens <[email protected] > >wrote: > > > > >> Ah, while *subscribe *is fine, my above post talks of the *reply > *case... > > >> need to read some code, it seems :) > > > > >> On Mon, Apr 19, 2010 at 11:50 AM, Jan Limpens <[email protected] > >wrote: > > > > >>> While it is dead simple to publish/send messages to a bus exposed via > > >>> wcf, has anyone ever tried to subscribe to it? > > > > >>> while this makes the kinda-stateful comet connection between client > and > > >>> server > > > > >>> protected override void InitializeRuntime() > > > > >>> { > > >>> this.AddServiceEndpoint( > > > > >>> typeof(IStockService), > > >>> new PollingDuplexHttpBinding(), > > > > >>> new Uri(_serviceBusUri)); > > >>> base.InitializeRuntime(); > > >>> } > > > > >>> Then I'd could expose the bus like that: > > > > >>> [ServiceContract] > > >>> public interface IServiceBusService > > >>> { > > >>> [OperationContract] > > >>> void Publish<T>(T message); > > > > >>> [OperationContract] > > >>> void Subscribe<T>(Action<T> callback); // don't like that > this callback goes across the wire, while all i want is the type. this > should star at the client... > > > > >>> } > > > > >>> I wonder how to go on after that. How does the message find it's > > >>> subscriber? For instance if I > > > > >>> _busSrv.Subscribe<GetSearchResultMessage>((e)=> > > >>> MessageBox.Show(string.Join(e.Result, ", "))) > > >>> _busSrv.Send(send a new SearchMessage(searchTerm: "rhino")) > > > > >>> How would _busSrv be able to tell if a certain GetSearchResultMessage > is > > >>> for a certain client? > > > > >>> How could _busSrv add itself to the dictionary of > GetSearchResultMessage > > >>> consumers, without implementing the interface > > >>> ConsumerOf<GetSearchResultMessage>? There are _many_ types of > messages, and > > >>> I would want to avoid to have to write and maintain all that > boilerplate > > >>> code... > > > > >>> -- > > >>> Jan > > > > >> -- > > >> Jan > > > > >> -- > > >> You received this message because you are subscribed to the Google > Groups > > >> "Rhino Tools Dev" group. > > >> To post to this group, send email to [email protected] > . > > >> To unsubscribe from this group, send email to > > >> [email protected]<rhino-tools-dev%[email protected]> > <rhino-tools-dev%2Bunsubscribe@ googlegroups.com> > > >> . > > >> For more options, visit this group at > > >>http://groups.google.com/group/rhino-tools-dev?hl=en. > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Rhino Tools Dev" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<rhino-tools-dev%[email protected]> > <rhino-tools-dev%2Bunsubscribe@ googlegroups.com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/rhino-tools-dev?hl=en. > > > > -- > > Jan > > > > -- > > You received this message because you are subscribed to the Google Groups > "Rhino Tools Dev" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > [email protected]<rhino-tools-dev%[email protected]> > . > > For more options, visit this group athttp:// > groups.google.com/group/rhino-tools-dev?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Rhino Tools Dev" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<rhino-tools-dev%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/rhino-tools-dev?hl=en. > > -- Jan -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
