I thougth about letting the Web Service do all the work prior to sending the
'success'. But I have seen and tested another web service that did just that
very thing and as long as no more than 5-10 transactions per minute were sent
every thing worked great (a lot of behind the scenes processing).
This Web service can receive strings from @ 10 characters to @ 100 k
characters. It has to search the string and react to what it finds. It
needs to be able to handle incomming messages of 1 per hour up to 100 per
second.
I thought that if I dumped the string into a text or xml file in a direcory,
that would solve my acceptance speed problem and then I could process the
files at the programs lesure.
[quoted text, click to view] "Bob Grommes" wrote:
> Why would that take a lot of resources?
>
> I'd just create a console app that you leave running which does a
> Thread.Sleep() for some seconds and then scans for new files. I would use a
> time interval that's no more frequent than necessary. Once it's debugged,
> I'd turn it into a Windows Service.
>
> Alternately, you could create a Windows Service that sits idle waiting for
> your Web Service to notify it that it has received something to process.
> Then you wouldn't have to scan for anything. Indeed, your web service could
> simply avoid writing to a file at all, and pass the string it receives along
> to this other process, if the string isn't too big.
>
> --Bob
>
> "hourlie" <hourlie@discussions.microsoft.com> wrote in message
> news:D48BD15B-235C-41D7-BB5C-C8B02649189C@microsoft.com...
> >I wrote a simple Web Service. It Consumes a single String, writes it to a
> > text file on the hard drive, and returns a success. Now I need a trigger
> > that will start the program that processes the file.
> >
> > I could make a routine that checks for new files every so many seconds,
> > but
> > that uses too much of the machines resources. Any ideas?
>
>
Well I agree, you should decouple the receipt of the data from the
processing of the data. You could dump them into a folder or into MSMQ and
process them "at leisure", as you suggest. You could also pass them to some
kind of Remoting server that would manage threads and/or still other servers
to do the work while continuing to listen for more "incoming" from the Web
Service.
Done properly, none of these solutions should be inherently slow.
--Bob
[quoted text, click to view] "hourlie" <hourlie@discussions.microsoft.com> wrote in message
news:3A28EF95-13EC-4058-8AF0-3101FA6239D9@microsoft.com...
>I thougth about letting the Web Service do all the work prior to sending
>the
> 'success'. But I have seen and tested another web service that did just
> that
> very thing and as long as no more than 5-10 transactions per minute were
> sent
> every thing worked great (a lot of behind the scenes processing).
>
> This Web service can receive strings from @ 10 characters to @ 100 k
> characters. It has to search the string and react to what it finds. It
> needs to be able to handle incomming messages of 1 per hour up to 100 per
> second.
>
> I thought that if I dumped the string into a text or xml file in a
> direcory,
> that would solve my acceptance speed problem and then I could process the
> files at the programs lesure.
FileSystemWatcher is a good idea, in fact I went to MSDN and printed the
instructions for FileSystemWatcher.Created Event. Now all I have to do is
figure it out. As you may have guessed, C# is not my primary language. But
it is fun to write.
John
[quoted text, click to view] "Moty Michaely" wrote:
> Hey,
>
> Why not using FileSystemWatcher in a windows service?
>
> - Moty -
>
> "Bob Grommes" <bob@bobgrommes.com> wrote in message
> news:OxlSLEllFHA.3300@TK2MSFTNGP15.phx.gbl...
> > Why would that take a lot of resources?
> >
> > I'd just create a console app that you leave running which does a
> > Thread.Sleep() for some seconds and then scans for new files. I would use
> > a time interval that's no more frequent than necessary. Once it's
> > debugged, I'd turn it into a Windows Service.
> >
> > Alternately, you could create a Windows Service that sits idle waiting for
> > your Web Service to notify it that it has received something to process.
> > Then you wouldn't have to scan for anything. Indeed, your web service
> > could simply avoid writing to a file at all, and pass the string it
> > receives along to this other process, if the string isn't too big.
> >
> > --Bob
> >
> > "hourlie" <hourlie@discussions.microsoft.com> wrote in message
> > news:D48BD15B-235C-41D7-BB5C-C8B02649189C@microsoft.com...
> >>I wrote a simple Web Service. It Consumes a single String, writes it to a
> >> text file on the hard drive, and returns a success. Now I need a trigger
> >> that will start the program that processes the file.
> >>
> >> I could make a routine that checks for new files every so many seconds,
> >> but
> >> that uses too much of the machines resources. Any ideas?
> >
> >
>
>
Don't see what you're looking for? Try a search.
