>Perhaps the problem is that I've always developed LAN systems and I'm really a newbie in .NET and Web Services.
>I try to be more specific: Let's say that I create a class (VFP 8 SP1) named USER that has 2 properties ID and NAME and a method LOGIN. With this scenario I'm able to instantiate an object and work with it during the session started in the system.
>In the other hand I can create a Web Service named USER that exposes to web consumers the service named LOGIN, then I'm able to "call some distributed functions" and not deal with real objects.
>I apologize for my very basic way of thinking but definitely I don't understand how to handle objects through Web Services.
>Many thanks from "the end of the world" (Ushuaia is the southernmost city in the world)

LOGIN is probably a method, the one you are referring to.

If USER is your Web Service, then, once uploaded to the server, it will have an extension of User.asmx.

Web Service so are Internet Web site applications are stateless. So, at every hit, you need to do what is appropriate to identify your user. It's not like a VFP application where you can have a login at once and then you know who is working on your application no matter what operations are being executed.

As for your design, yes, it is a good approach to isolate the login process in a class and instantiate that class in your Web Service. By that, you can have the class also available for other purposes, if you develop more .NET applications other than your Web Service.

Basically, you may define your login class in a desktop application and test it for. Once workable, you can add that class as a reference in your Web Service project and simply call it when desired to identify the user.

For your Login() method, as soon as the user would be identified, you will have to establish some kind of mechanisms to recognize that user on upcoming hits. Some will use cookies, some will use application session and others will use something else. It's up to you to decide what approach to use.