«

Hi guys,

I'm building a Web Service application to be run as an engine for some
client web applications.
The client application will be used as a shell to update and maintain a
customer database where the Web Service acts as the engine containing all
functions to interact with the SQL Server. One can see each client
application as a terminal to the main Web Service application.

Since all communication to the Web Service needs authentication, this
information has to be sent to the Web Service each time it's called to be
checked against the SQL Server. Will this slow down the process a lot?

Example:
Client updates info --> Call Web Service --> Authentication --> Update
info --> Return results to client

Does someone recommend a better solution to this? Or can I optimize the
process?

Thanks for any kind of help.

Regards,
Jonah Olsson
Generation Software

It's possible to use Sessions to keep track of state (including
authentication info) on the server side.

In this case, the client would open a conversation (eg, session) with the
server, passing the authentication info when the session is started. At
that point the server would retain the authentication info on the server, in
the session object. When the client connected again (a new request for a
webmethod), then the server can examine the session and use the stored
authentication info.

example:
http://samples.gotdotnet.com/quickst...esandobjs.aspx

This will not scale as well as a stateless model, where you authenticate
with each webmethod request. But if you do not have extreme perf
requirements, it may work just fine for you.

The client needs to be aware of the session, and needs to use cookies.

-Dino


"Jonah Olsson" <> wrote in message
news:%...
> Hi guys,
>
> I'm building a Web Service application to be run as an engine for some
> client web applications.
> The client application will be used as a shell to update and maintain a
> customer database where the Web Service acts as the engine containing all
> functions to interact with the SQL Server. One can see each client
> application as a terminal to the main Web Service application.
>
> Since all communication to the Web Service needs authentication, this
> information has to be sent to the Web Service each time it's called to be
> checked against the SQL Server. Will this slow down the process a lot?
>
> Example:
> Client updates info --> Call Web Service --> Authentication --> Update
> info --> Return results to client
>
> Does someone recommend a better solution to this? Or can I optimize the
> process?
>
> Thanks for any kind of help.
>
> Regards,
> Jonah Olsson
> Generation Software
>
>

You may want to look at Remoting, it is better suited for this application,
as you can make the service a singleton and thus eliminate the issue (Still
will scale within the limits of the server memory etc)

Tom
--
==========================================
= Tom Vande Stouwe MCSD.net, MCAD.net, MCP
= 45Wallstreet.com (www.45wallstreet.com)
= (803)-345-5001
==========================================
= If you are not making any mistakes
..= ..you are not trying hard enough.
==========================================
"Dino Chiesa [MSFT]" <> wrote in message
news:...
> It's possible to use Sessions to keep track of state (including
> authentication info) on the server side.
>
> In this case, the client would open a conversation (eg, session) with the
> server, passing the authentication info when the session is started. At
> that point the server would retain the authentication info on the server,
in
> the session object. When the client connected again (a new request for a
> webmethod), then the server can examine the session and use the stored
> authentication info.
>
> example:
> http://samples.gotdotnet.com/quickst...esandobjs.aspx
>
> This will not scale as well as a stateless model, where you authenticate
> with each webmethod request. But if you do not have extreme perf
> requirements, it may work just fine for you.
>
> The client needs to be aware of the session, and needs to use cookies.
>
> -Dino
>
>
> "Jonah Olsson" <> wrote in message
> news:%...
> > Hi guys,
> >
> > I'm building a Web Service application to be run as an engine for some
> > client web applications.
> > The client application will be used as a shell to update and maintain a
> > customer database where the Web Service acts as the engine containing
all
> > functions to interact with the SQL Server. One can see each client
> > application as a terminal to the main Web Service application.
> >
> > Since all communication to the Web Service needs authentication, this
> > information has to be sent to the Web Service each time it's called to
be
> > checked against the SQL Server. Will this slow down the process a lot?
> >
> > Example:
> > Client updates info --> Call Web Service --> Authentication --> Update
> > info --> Return results to client
> >
> > Does someone recommend a better solution to this? Or can I optimize the
> > process?
> >
> > Thanks for any kind of help.
> >
> > Regards,
> > Jonah Olsson
> > Generation Software
> >
> >
>
>

Hi Dino,

Thanks for your reply and help.
I'll take a look at sessions, it sounds like a way to do it. I suppose
handling sessions takes both less cpu and bandwidth than checking
authorization against the SQL Server.

Jonah

"Dino Chiesa [MSFT]" <> skrev i meddelandet
news:...
> It's possible to use Sessions to keep track of state (including
> authentication info) on the server side.
>
> In this case, the client would open a conversation (eg, session) with the
> server, passing the authentication info when the session is started. At
> that point the server would retain the authentication info on the server,
in
> the session object. When the client connected again (a new request for a
> webmethod), then the server can examine the session and use the stored
> authentication info.
>
> example:
> http://samples.gotdotnet.com/quickst...esandobjs.aspx
>
> This will not scale as well as a stateless model, where you authenticate
> with each webmethod request. But if you do not have extreme perf
> requirements, it may work just fine for you.
>
> The client needs to be aware of the session, and needs to use cookies.
>
> -Dino
>
>
> "Jonah Olsson" <> wrote in message
> news:%...
> > Hi guys,
> >
> > I'm building a Web Service application to be run as an engine for some
> > client web applications.
> > The client application will be used as a shell to update and maintain a
> > customer database where the Web Service acts as the engine containing
all
> > functions to interact with the SQL Server. One can see each client
> > application as a terminal to the main Web Service application.
> >
> > Since all communication to the Web Service needs authentication, this
> > information has to be sent to the Web Service each time it's called to
be
> > checked against the SQL Server. Will this slow down the process a lot?
> >
> > Example:
> > Client updates info --> Call Web Service --> Authentication --> Update
> > info --> Return results to client
> >
> > Does someone recommend a better solution to this? Or can I optimize the
> > process?
> >
> > Thanks for any kind of help.
> >
> > Regards,
> > Jonah Olsson
> > Generation Software
> >
> >
>
>

Tom,

Doesn't Remoting require something installed on the server? I'm on shared
hosting regarding the Web Service..

Thanks.
Jonah


"Tom Vande Stouwe MCSD.net" <> skrev i meddelandet
news:%...
> You may want to look at Remoting, it is better suited for this
application,
> as you can make the service a singleton and thus eliminate the issue
(Still
> will scale within the limits of the server memory etc)