Greetings!

This message is a variation on my recent "Connecting to a Windows
service" post. In that post, I asked if a client on a PocketPC can use
remoting to connect to a Windows service on a server. It was pointed
out that the Compact Framework does not support remoting, which
effectively ended that line of thought.

Now I am considering using a Web service to receive commands from the
hand-held PC and relay them to the Windows service. A user would issue
a command on the hand-held PC, the GUI app on the hand-held would call
a method on the Web service, the Web service would begin running on the
server, the Web service would connect to the Windows service, and the
command would be relayed to the Windows service. Sounds like a lot of
steps, but it's all straightforward except for the second-last one.
How does a program (the Web service) that is just starting talk to one
(the Windows service) that is already running? Can remoting do this?
What about methods of the AppDomain object? AppDomain.CreateInstance()
seems to be analogous to the old CreateObject() call in COM. COM had
GetObject(), IIRC, to get a reference to an object that already existed
in memory, like a previously running instance of MS Word. Is there an
analogous method in the AppDomain class?

The commands that will need to be sent are very simple. There's only
about ten of them, and more than half will have no arguments. Text
strings will suffice for all arguments.

Thanks again!

Rob

Remoting is probably your best bet for communicating between the web service
and the Windows service. In your web.config you would put the proper
remoting config entries to declare a wellknown (or client-activated) object
that exists in your Windows service. Then, in your web service method
implementations, you would simply instantiate the proper remote object and
invoke the corresponding method. If you need to return data from the call,
you would just pass that along as well.

One question though: will all of the clients who access this service be
doing so through the web service? If so, I'd eliminate the windows service
altogether unless it serves a specific purpose for you.

Ken


"Rob Richardson" <rrichardson (AT) primepro (DOT) com> wrote

Ken,

Thanks for your thoughts. I'll see if I can figure out the details.

The Web service is only needed intermittently, while the Windows service is
needed constantly. The application prints labels for cases of meat. The
operator would enter the product number on the hand-held PC. The PC would
call a method on the Web service, passing the product number. The Web
service would wake up, receive the product number, and send it to the
Windows service. The Windows service would read the SQL Server database for
the name of the label format file, and then would load that file. It would
send an "OK" message back to the Web service, which would relay it to the
hand-held PC, which would then go back to sleep. In the meantime, the
Windows service is waiting to receive package weights over TCP/IP. When a
weight comes in, the weight is added to the label and the label is printed.
That will happen every few seconds. Commands may be issued once a shift or
even less frequently.

Rob

In that case, using the web service as a proxy for the Windows Service
sounds reasonable.

Good luck -
Ken


"Rob Richardson" <notreally (AT) n2net (DOT) net> wrote

I'll just give the stamp of approval on Ken's advice ;-). My first thought
was also why involve a windows service at all, but I guess you have
justified it's existence. Check out this article:

How to Host A Remote Object in a Windows Service
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secmod/html/secmod29.asp

Thanks,

Sam

--
_______________________________
Sam Santiago
ssantiago (AT) n0spam-SoftiTechture (DOT) com
http://www.SoftiTechture.com
_______________________________
"Ken Kolda" <ken.kolda (AT) elliemae-nospamplease (DOT) com> wrote