Queued Components Questions...

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Alfredo - 27 Jan 2006 14:36 GMT

Hi,

I have several questions about Queued Components in .Net.

1. What are the differences between the checkbox "Queued" and the
checkbox "Listen"? They appear Queue Tab in component properties.

2. When should i use message queued? I mean, pls give me somesome
useful scenarios

3. Why do we have to use Interfaces to implement Queued Components? I
really dont understand why in some cases we have to implement
interfaces.

4. Is there any relationship between the QueueName parameter and the
Private Queues that appear in "Message Queuing" in "Services and
Applications" in "Computer Management".

queue:ComputerName=<ServerName,
Queuename=<QueueName>/new:QueuedComponents.QueuedObject"),
IQueuedObject)

5. Why do i see six (6) queues for each queued component that i
registered? I would like to know how it works.

Please help me!!

Thanks,

Alfredo Barrientos

Reply to this Message

Tomas Restrepo (MVP) - 27 Jan 2006 17:37 GMT

Alfredo,

> I have several questions about Queued Components in .Net.
>
> 1. What are the differences between the checkbox "Queued" and the
> checkbox "Listen"? They appear Queue Tab in component properties.

> 2. When should i use message queued? I mean, pls give me somesome
> useful scenarios

Queued components are useful when you need to do asynchronous processing.
For example, you might take an order and submit it for processing, but you
don't care to wait until processing is done. In that case, you can delegate
the processing to a queued component that gets invoked in an async fashion.
Also, they are useful because they can help reliability somewhat, since the
messages can be locally queued for processing even if the machine running
the actual queued component is down.

> 3. Why do we have to use Interfaces to implement Queued Components? I
> really dont understand why in some cases we have to implement
> interfaces.

All COM+ components have one or more interfaces, and creating explicit
interfaces is the recommended best practice. However, if you don't define
one, when you register your ServicedComponent .NET will synthetize an
interface definition based on your class' public members for you.
Now, a queued component can be queued on one interface, but also implement
other interfaces made for synchronous calls, you need to tell COM+
explicitly which interface is available for queued calls. Another reason is
that COM+ needs to make sure that an interface used for queued calls only
contains methods with [in] parameters as well as no return value, since this
is required because of the one-way, async nature of queued component calls.

> 4. Is there any relationship between the QueueName parameter and the
> Private Queues that appear in "Message Queuing" in "Services and
> Applications" in "Computer Management".

> queue:ComputerName=<ServerName,
> Queuename=<QueueName>/new:QueuedComponents.QueuedObject"),
> IQueuedObject)

Yes, there is.

> 5. Why do i see six (6) queues for each queued component that i
> registered? I would like to know how it works.

Because COM+ implements a staged processing for messages sent to queued
components. Basically, COM+ will retry the call if the component fails (i.e.
throws an exception or returns a failure HRESULT code) a fixed number of
times, with some fixed time between retries, and it does this by moving the
messages through those queues it creates. This is particularly useful for
transactional components, as it allows you to be sure that even if the
component fails when it receives the call, COM+ will take care of calling it
again after a while to retry the transaction, so it really minimizes the
ammount of work you need to do to ensure some reliability.

Signature

Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/

Reply to this Message

Alfredo - 27 Jan 2006 19:30 GMT

Tomas, Thank you very much!!

Pls, question number one is very important to me... do you have any
idea about that checkboxs??

Thanks,

Alfredo Barrientos

Tomas Restrepo (MVP) ha escrito:

> Alfredo,
>
[quoted text clipped - 51 lines]
> again after a while to retry the transaction, so it really minimizes the
> ammount of work you need to do to ensure some reliability.

Reply to this Message

Tomas Restrepo (MVP) - 28 Jan 2006 02:32 GMT

Hi Alfredo,

> Tomas, Thank you very much!!
>
> Pls, question number one is very important to me... do you have any
> idea about that checkboxs??

Oops, sorry, forgot about that.

Well, it's not that they are different, it's just that they do two separate
things required to run queued components. IOW, both are required. One just
enables the capabilities needed to support queued components and creates the
necessary MSMQ queues, but doesn't actually make COM+ actively listen to
those queues for messages. The second option is what actually achieves the
latter. That means that, for example, you can temporarily configure COM+ to
leave the queues alone but not process messages on them, without completely
shutting down the COM+ application, for example.

Signature

Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/

Reply to this Message

Alfredo - 01 Feb 2006 15:38 GMT

Thank you very much Tomas!!

Alfredo Barrientos

Reply to this Message

Rate this thread:

Queued Components Questions...

Free Magazines