Threading issues with COM in Web Service

[A.J.]

I'm writing an application that will run as a Web Service. It will
communicate with some old COM DLLs. These COM objects need to be
called on their own thread. In a regular Web Service I would create a
pool of objects that I call so I don't have to instantiate, log in,
etc, on each Web Service call.

How can I do this? Are there performance issues to keeping an object
on a thread for an extended period of time? Do I have to write
wrappers so that I can pass and retrieve parameters?

Thanks for the advice.

 

[Alvin Bruney]

called on their own thread. In a regular Web Service I would create a

pool of objects that I call so I don't have to instantiate, log in,
etc, on each Web Service call.

I'm not sure what you mean here. Do you mean "In a reguler web page i would
....."
You can implement a singleton pattern which would wrap an object factory so
that specified objects are returned to the caller. This isn't quite
straightforward because webservices are inherently stateless so you would
have to create the statefullness programatically using a durable datastore
or caching.

You can pass parameters as long as they implement ISerializeable (use the
<serialable> attribute) as the component object needs to be pushed across
the wire. There are some gotchas with serializeable objects for webservices
depending on the soap formater (binary or not) which you need to pay
attention to. Serializable custom classes must allow all their members to be
serializeable as well.

Are there performance issues to keeping an object

on a thread for an extended period of time? No not really, performance is

only an issue because of the persistence of the object in server memory or
wherever the durable data store happens to reside. Big objects will take up
lots of memory for extended periods of times

Do I have to write

wrappers so that I can pass and retrieve parameters?

This would all be encapsulated in your singleton pattern. Whatever you are
passing must implement ISerializable if it is not an intrinsic type. So you
would basically build a class which knows how to produce an object and keep
track of it.

You really need a solid resource like 'Distributed Applications' matthew
MacDonald before walking this path. There are a lot of pitfalls with that
approach which can affect scalability and performance if not properly
implemented. Also, have a look at www.prosetech.com they've some
implementations close to what you are looking for.