I have been trying to develop a simple distributed web service using .Net. The client calls the web service and the web service calls the database on a different server. Well, guess what? .NET sucks on distributed architecture. .NET won't pass the clients credentials to the database. .NET won't pass its own credentials to the database. .NET sucks. So how do you get this to work (not that I have gotten it to work yet)? You have to build a "ServicedComponent" object which is basically a link to a COM+ dll! Which means that you have to deal with the nightmare of COM's meaningless error codes. This should be the simplest distributed architecture and Microsoft has completely blown it. Microsoft sucks!!!
Thomas, maybe there is another way to do what you want to achieve. Like using ASP.net to act as the web service. I think of a web service as a non-user/password method call, meaning you might need to use a user and password to get to the web server, but once you do and you call the web service, the web service has no more security, and has free access to the database. In that I mean that the webservice object doesn't need a user password from the client to pass to the database. the webservice object already has one user password that it uses for all users, of course this data is encapsulated in the webservice object, so that no one can see it. Now I am not an expert or have really good experience in .net, I have taken a class , but I think the problem is more in the design, or choice of implementation. Hope that helps Mark
I should clarify that this is an intranet application. The idea was that the web service would use the windows credentials of the user that is using the web service. So we couldn't get that to work off the web service server so we went with the idea of passing a user id/password as part of the connection string. Wouldn't work. SQL Server insists on using Windows credentials. Since the web service doesn't have a network id, it uses the anonymous_user id and fails on the security check. The solution from Microsoft was to use COM. Which means that .NET apparently isn't designed for an Enterprise level distributed architecture.
so we went with the idea of passing a user id/password as part of the connection string. Wouldn't work.
Really. Are you sure the connection string was 100% correct? Did it run in a seperate class that is not a web service? Mark
Joined: May 05, 2000
Absolutely. If the database is on the same server as the web service then it runs fine. If the database is on another server then it fails. The web service always tries to log into the SQL Server as anonymous. Here is my exchnage with one of the guys at Microsoft. The ServicedComponent object that he is recommending is a .NET hook into a COM component. This is my favorite quote in poor Andy's response, "I'm not certain of the best solution..." The most basic distributed architecture and Microsoft has no solution. Un-friggin believable.
Interesting. I guess the seams are starting to show eh? I don't doubt MS wants to have a nice seamless architecture for their enterprise space, but it seems clear that .Net is still a mostly marketing facade to their existing toolsets.
Joined: Jan 07, 2002
btw, do you *have* to use NT credentials with MSSql server, or isn't there an option to just use a regular user name and password login and let SQL server authenticate based on it's own list of users?
Take out the nouns of this conversation -- just leave in the verbs and the semantics of problems and responses -- and this topic sounds like every Microsoft technology discussion I've ever been privy too, from Microsoft Windows for Workgoups and Microsoft LAN Manager on up. The more things change, the more they stay the same. [ May 18, 2002: Message edited by: Michael Ernest ]
Make visible what, without you, might perhaps never have been seen. - Robert Bresson
Originally posted by Rob Ross: btw, do you *have* to use NT credentials with MSSql server, or isn't there an option to just use a regular user name and password login and let SQL server authenticate based on it's own list of users?
You can use a regular id and password but MS SQLServer insists that you come in on a "trusted connection". What's a trusted connection, you ask? Why that's a connection with a valid network id! Which means that you are screwed either way. We will be back to the drawing board on Monday trying a few other things. I'll let you know if we make any progress.