I have an asp.net 3.5 site and I've just written some wcf services. It is ok to just drop the .svc file right alongside my .aspx files or should I move my .svc files onto a separate virtual directory and IP and call it something like services.mydomain.com.
Just wondering what best practices are. Maybe it doesn't make any difference? I have a client app that will update the database that my web site uses. It updates through an IIS hosted wcf service.
IMHO it would be better to isolate the web service into a separate virtual directory and application pool. In this case the client application and the web service don't share the same AppDomain and if one fails the other will continue serving requests.
In our project we tend to keep them in separate virtual directories. I like to regard the service as something that can be used by more than one client, and so I like the deployment and hosting of it separate from the client. Of course, if you just stick it in a separate virtual directory you can argue to what extent the hosting is separated, but at least it is separate on a logical level, and easily moved to separate physical hosting if necessary.
You definitely don't want to have them in the same place - not least because it makes it hard to configure the appropriate level of security. It also makes configuration simpler as they won't share a web.config.
Related
I need advise on the architecture of my new application. In the environment I work in, we normally create Win based apps and these compose a UI layer, Business Layer, WCF Service Layer, and Data Access Layer. These are on a 3 tier architecture with Services Server, Database Server and clients machines accessing the application via Citrix on an Application Server. I just created a web aplpication and my admin has suggested this should be hosted on a separate web server, my question is, is there a need for my web application to use a WCF Service Layer, since it can be hosted on the same application server? Basically, do websites need to use wcf/service layers and what are the benefits?
1.
Read this:
http://www.codeproject.com/Articles/10746/Dude-where-s-my-business-logic
My advice:
At the least, you should use WCF, and use "named pipes". You can deploy both the Host (WCF) and the Client (Asp.Net website) on the same machine.
The Asp.Net website will be the "client" and access the service.
Then, if you ever want to horizontally scale, all you have to do is change the .config settings to use a different protocol besides named-pipes.
Aka, you'll have the "logical separation", even if you deploy both on the same physical machine(s).
They (websites, any project) don't "need" to do anything.
You can write inline sql code behind buttons on webforms if you want.
But its not maintainable. And its not scalable. And it is probably foolish.
But putting in the time to SOA a mid to large sized application is worth the effort in the beginning, IMHO.
This is a question without a concrete possible answer, do you need a wcf? well that depends on the requirements and the architecture you want to put in place.
based on the small context you provide maybe you can get some the following benefits
WCF Provide state for operations
Fast processing (binary serialization)
WCF are more likely 'to be testable' than legacy asmx web services
You can access the same backend you built for your desktop applications
regarding if than can be accessed from the same server, the short answer is yes (obviously you need to measure your server capabilities)
I've done some app's that doesn't use a wcf at all, and other that use it for certain operations you can take a look to this SO answer to get a good example where a wcf could be a good candidate in an app.
Say I make a web app for my main page and publish it to wwwroot (assuming this is the default website). Do I publish other web apps by nesting them within wwwroot. Something like wwwroot/webapp1 for example? This seems somewhat messy to me, so I'm not quite sure if it's the correct way of doing it. Therefore, I'm wondering how the rest of you would organize this?
I generally do not put applications inside of other applications when using IIS. This is because I do MVC applications that can take over all the routing and it'd be really annoying to host applications in the folders inside. Even if you are not doing MVC applications, I would still avoid doing it, and instead make multiple websites that listen on different host headers or ports. If you need to have applications nested like that I would use a reverse proxy like HAProxy and setup routing there instead.
I have web application that are using multiple clients.
I should create one copy of application for all clients or every client should have its own copy.
I am using Asp.net MVC and SQLServer.
What you suggest.
Creating seperate projects per client will be troublesome to maintain while a single project for all clients could be difficult to customize. It is a fine line and your needs will dictate how you build your solution.
One of my more recent projects where we do SAS (Software as a Service) we were able to build our MVC application using a plugin architecture so that each client COULD have their own DLL deployed to the BIN that would enable customizations for just that client (to the Views, Assets or even the Controllers). We are able to leverage a single code base and have many clients, most without customizations and some with minor to heavy customizations.
Every client has a unique URL for their "portal" and most often they have private domains, so http://app.mycompany.com or http://mycompanyapp.com and some are even hosted on our own site, http://hostingcompany.com/client/.
By building an application that can determine what client it is based on the URL we were able to handle all of these cases with ease. When we deploy we have a single code base (deployed just ONCE to a single folder) and all of the sites use that same code deployment.
We run a web farm where we have many .NET Web Servers and have load balancing setup and the sites all have ping pages that our load balancers interact with to determine their health.
Like I said, your needs will determine what the best solution for you is.
Nick , what about database should we use one database every client or should have separate database for each client in my scenario our application is more database centric so there are lot of changes done for each client as per there business roles .
What way makes the most sense? I have a ASP.NET app... and maybe a Silverlight app in the future.. I want both to talk to web services..
At first, I like have the WCF project be by it self for the seperation..
But then I thought.. What is the point since I can just as easily have a 'WEBSERVICES' folder that contains all the .svc files and code in the EXISTING website project. ... Atleast that way.. deploying to a remote host will be a little easier since everything is in one project..
any other considerations ?
Why not have:
your WCF service and data contracts in a Contracts assembly
your WCF service implementations in a Services assembly
reference those two assemblies from your web site or web app
put the *.svc files into a WebServices directory
That way, you have
clean and nicely organized separation of concerns
the deployment files (*.svc) are in your web site / web app as you want
you can still extend / use your WCF code in other ways (e.g. self-hosting) later on without much fuss
Two things to consider:
Security - are your services only going to be used by your application, or do they have the potential to be used anywhere else (after all they are services). If so, you will be granting access to your application in order to grant access to your web services, or at least tweaking the access to that specific folder, which might lead to security breaches.
Deployment - If you do changes on your service that doesn't break the contract, in order to deploy the changes you will have to deploy the whole application.
I would prefer to go with the approach that Marc suggested (e.g. have an assembly for contracts, one for the service implementation) and have the webservice hosted as its own application and reference it from the ASP.NET app. This way, you have proper separation of concerns and can maintain both separately.
I have a Visual Studio solution containing a web site project plus a bunch of supporting projects (domain model, data access, etc).
I want to expose an API to the same underlying data, via urls under the same domain, so I developed a WCF/REST project to do this (which has dependencies on the same set of domain/data access projects).
Now I'm wondering what the pros and cons are of having the WCF service in a separate solution, deployed under a virtual IIS path, compared with just putting the WCF project into the original website solution.
Are there good reasons why I would want to go one way or the other? I'm not too experienced with IIS deployments.
IF you ever want to self-host the service instead of hosting it inside IIS, or if you ever want to share the service interface as an assembly for some reason, it will probably be easier to have it in a separate assembly.
I would recommend one assembly for the service interface(s) (including data contracts and such), one for the service implementation, and another (if needed) for a self-host (e.g. Windows NT service or command-line app). That's the cleanest separation and there's no real reason not to go that way, IMHO.
Marc