Serviced Components : Are they still objects ?

15 Jan 2005 1:15 PM

jppop

Hello,

I am considering using Serviced Components to process jobs (file loading
into a Document Management System) asssynchronously.

I have started to write a Serviced Component to handle the job queue using
MS Message Queues. This component reads the queue and calls a method using
events and delegates:

using (JobManager jobQueue = new JobManager) {
    // submit job (testing purpose)
    for ( int i = 0; i< 4; i++ ) {
    jobQueue.SubMit(Â« task Â»);
    }

    // register the delegate
    jobQueue.MessageReceived += new MessageReceiveEvent(ProcessMessage);

    // start job processing
    jobQueue.Start();

    Console.ReadLine();
}

When I run the application, the Start method raises an exception (before
reading a message from the queue, I check if there is at least on registered
event, if not I don't want to read the queue and loose messages).
To figure out what's wrong, I set a break point into the JobManager
constructor (as reminder, it's a Serviced Component): the constructor was
called several times during the using statement. So, the JobManager lost the
delegate registered by the calling application, since new objects are created
before each method calls (I guess).

I guess Serviced Components are designed to run method independtly: each
method runs as a 'service'.

So my question is: Using Serviced Components, don't we loose the benefits of
object programming ?

Jean-Pierre.

17 Jan 2005 10:11 PM

Cowboy (Gregory A. Beamer) - MVP

Apologies if I miss something here, but my brain is pretty much jello after
my day smacking out bug fixes.

Queues listen to a channel and then put message into the queue. You can set
up a listener to listen to the queue. But, you do not have to create queue
objects to add to queue, if that is the gist of the question.

In many ways Queues are similar to the direction MS is taking SOA, except
that the interface is a queue instead of a web service.

Did that hit the right nail?

---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

Show quote

"jppop" wrote:

> Hello,
>
> I am considering using Serviced Components to process jobs (file loading
> into a Document Management System) asssynchronously.
>
> I have started to write a Serviced Component to handle the job queue using
> MS Message Queues. This component reads the queue and calls a method using
> events and delegates:
>
> using (JobManager jobQueue = new JobManager) {
>     // submit job (testing purpose)
>     for ( int i = 0; i< 4; i++ ) {
>     jobQueue.SubMit(Â« task Â»);
>     }
>
>     // register the delegate
>     jobQueue.MessageReceived += new MessageReceiveEvent(ProcessMessage);
>
>     // start job processing
>     jobQueue.Start();
>
>     Console.ReadLine();
> }
>
> When I run the application, the Start method raises an exception (before
> reading a message from the queue, I check if there is at least on registered
> event, if not I don't want to read the queue and loose messages).
> To figure out what's wrong, I set a break point into the JobManager
> constructor (as reminder, it's a Serviced Component): the constructor was
> called several times during the using statement. So, the JobManager lost the
> delegate registered by the calling application, since new objects are created
> before each method calls (I guess).
>
> I guess Serviced Components are designed to run method independtly: each
> method runs as a 'service'.
>
> So my question is: Using Serviced Components, don't we loose the benefits of
> object programming ?
>
> Jean-Pierre.
>