This may not be new, but I hope some one can put me on right track as its bit confusing during azure deployment. I'm in the process of planning for deployment on Azure. This is what I have
A Public facing ASP.Net MVC app (web-role) + WCF Service (web-role) to be accessible only to this asp.net app + WCF Service (worker-role) again accessible to 1. over message-queue
An Custom STS i.e. ASP.NET MVC app (web-role) acting as Id-Provider (for 1. which is a Relying Party) + WCF Service (web-role) to expose some of STS funcionality to RP's such as 1.
SQL Azure: accessed by 1 and 2
Note: 1. will eventually grow to be come a portal, with multiple wcf-services hosted on web and worker roles for both internal and external access.
My question is if 1. is going to be the app exposed to public, and 2. is for 1. to Federate the security (internal), how should I plan my deployment on azure keeping in mind 1. will require scale-out sometime later along with the two wcf services? Do I publish to one cloud service or how?.
My understanding is that A Cloud Service is a Logical Container for n-web/worker roles.
But when yu have 2 web soles like in this case both asp.net apps, which one becomes the default one?
Best Regards
Satish
By default all web roles in the solution are public. You can change this by going into the service definition and remove HTTP endpoints, if you wish; you can also define internal HTTP endpoints that will only be available to cloud services, nothing will be exposed to the load balancer. The advantage to having all web roles in the same project is that it's easy to dynamically inspect the RoleEnvironment and each web role -- in other words, all roles in a solution are "aware" of other roles and their available ports. It's also easy to deploy one package.
All roles share the same DNS name (.cloudapp.net) (however you could use host headers to differentiate), but they are typically exposed by using different ports via the load balancer on your .cloudapp.net service. You can see this when the service is running in the cloud, there are links in the portal that point to each role that has a public HTTP endpoint that specifies the port. The one that is port 80 (as defined by the external HTTP endpoint) is the "default" site.
You could also create multiple cloud projects, and deploy them separately. In this case, each would have its own DNS name, and each is managed separately. Whether this is a good thing or not depends on how tightly coupled the applications are, and if you will typically be deploying the entire solution, or just updating individual roles within that solution. But there's no cost or scalability difference.
If you are going to frequently redeploy only one of the roles, I'd favor breaking them out.
To deploy multiple Web Roles under the same cloud instance have a look at this:
Best practice for Deployment of Web site into a cloud service
Multiple worker roles will be trickier to implement:
Run multiple WorkerRoles per instance
Is it better to have lots of small deployments with a few web services per war, or to have one big deployment with lots of web services per war?
In this case, assume that all of the web services share a common backend and will benefit from code-sharing. For small wars shared code would have to be put into a jar project and included from all the smaller deployments. Now each war can be tested/deployed separately, but if the backend changes they all need to be updated rather than only one.
The backend in this case is yet another web service provided by a vendor. Updates to it are usually backwards compatible but not always.
I know there is no clear-cut answer but any experience shared will be helpful.
As a rule you'd want one war per service. The point is that a service does not have to be a single web-service (in fact some of the endpoint can be other technologies not just web-services). A service can expose multiple endpoints and contracts.
You'd group together related contracts e.g a service that handles user management can have APIs for both users and groups. However APIs related to Orders probably belong in a different service (and thus war).
If you slice the services pieces that are too small you can get what I call the nano-service antipattern where the overhead of a service is more than the utility you get from it
I have a SQL Server database which serves multiple ASP.NET web applications. They each have their own SiteID to distinguish the data.
I recently realised that it isn't good practice to have multiple applications accessing one database directly and decided I would implement a service to handle all database connections.
All the web applications and database sit on the same windows 2008 server.
I want to know what kind of service is best for this functionality. web service or windows service? In a previous job they seemed to have a windows service that ran on the server, what are the advantages of this over a web service?
While it's certainly ok to have multiple applications accessing one database, I think what you mean is you are trying to avoid duplicating all your data access and business logic in multiple web sites. In other words, you would rather have a centralized service where you can update all the applications at once.
It sounds like you want a WCF service, which will let you run either as a web application under IIS -OR- as a self-hosted Windows service. There is a bit of a learning curve if you've never done WCF, but it is well worth learning.
WCF under IIS, you get the same benefits as you get with running any web site. Application lifecycle management, maintenance using the IIS mms plug-in, running under a specific pool identity, etc.
As a Windows Service, you manage through the Services mms, and you have to manually write a little more code (just a little) to handle the service startup and shutdown, and of course you don't get the application lifecycle management that you do with IIS.
Which you choose may depend on how much security access you have to the server, and which tools you are allowed to run. If you have full access to the server, I prefer the IIS way, but that's totally subjective.
Windows Service vs Web Service is apples vs oranges... A windows service doesn't serve up data on its own...
So here are some options:
Data Access in traditional Code
It sounds like this is what you have. As long as this is a logically separate layer, this probably isn't too bad.
Services
Using services has a lot of advantages such true separation of concerns / implementation. You can even have your service implemented in a different language / platform than your client app. A downside might be performance. You're likely going to have to serialize / deserialize data and that takes cpu cycles any way you slice it.
Interface Driven Approach
This is nice because you can write your data access in your application against an interface. That interface can be implemented by "traditional" ADO / ORM code. Or you can consume a web service. This has the distinct advantage of separating the UI from data and making automated unit testing much easier.
I have an existing set of singleton WCF services. They are long-running processes that do a lot of work on an ongoing basis and expose themselves with WCF service contracts for communication with other processes.
When the WCF Web API was being developed I was excited because it was looking like I'd finally be able to do away with all of the annoying contract stuff and simply provide a platform-agnostic REST API for each service and have the processes communicate via HTTP requests and JSON responses.
Now it looks like the Web API has become an IIS-hosted ASP.Net feature, leaving me trying to figure out if I'm just missing something or if my WCF services will no longer have the opportunity to provide a REST interface.
If the Web API is no longer really targeted at my scenario, what has the ASP.Net team envisioned with respect to non-terminating singleton processes that wish to provide an HTTP/JSON-based API to other consuming processes?
You do not have to host ASP.NET Web API services in IIS. There is an option called "Self Hosting" that will allow you to host your API services in another process (such as a Windows Service) if you would like. I imagine that your current architecture would work just fine as a self-hosted app.
You can self-host using ServiceHost as in this MSDN example. See related SO post. Essentially - IIS is not a requirement for WCF hosting.
If you are using webHttpBinding - you just need to create the WebServiceHost which extends from ServiceHost to support REST.
I'm new to .Net and do not understand the difference. Can someone point me in the right direction?
ASP.NET Web services was developed for building applications that send and receive messages by using the Simple Object Access Protocol (SOAP) over HTTP.
WCF is for enabling .NET Framework applications to exchange messages with other software entities. SOAP is used by default, but the messages can be in any format, and conveyed by using any transport protocol.
You can view ASP.NET web services as a subset of WCF services.
Here is a link comparing the two frameworks.
it is quite easy to know the differences.
ASP.NET Web Method is called ASMX [because of the file extension] (check 4GuysFromRolla about this, they have a good tutorial)
That technology makes you expose functions as a Web Service so you can connect it from everywhere and use it. But... you can't protect the data between server and client, you can send big files clear and know what happend, etc...
[Note] you can protect the access to the web service using certificates, but it is complicated but normally, in ASMX we use username / passsword.
in WCF, you are in the different world about Web Services,and this s the best technology in .NET to expose Services (can you see the difference... Services! not Web Services), WCF does not need IIS to run, it can run as a System Service on the server, using a console ambient (like command line), etc, so we say that WCF is a Service not Web Service. Remember ASMX need IIS to run.
with WCF you can use SSL to encrypt the communication (to do that in ASMX you need to use WSE - Web Services Enhancements), you can send big files and securely (to do that in ASMX you need to use MTOM - Message Transmission Optimization Mechanism).
you can set the transmission preferences just changing one line of code, the security is much higher, etc, etc :)
hope you get a better general overview with this, but there is much more.
bottom line: to expose Web Services that you do not need to protect, you can use ASMX, no problem at all, but if you need to protect the communication somehow, do it in WCF!
link: you can read here some performance comparative between the 2 services
They are two different frameworks for writing services. WCF is generally more flexible and provides configurable options for what protocols are used, how the service is hosted and a variety of security options. ASMX offers SOAP based services. Generally WCF is also more performant. In general ASMX is easier to use and generally has less of a learning curve.
Here is a MSDN forum discussion on the topic.
Here are the getting started pages for ASMX and WCF.
In addition to the above responses, WCF was created to replace .NET Remoting in .NET 3.0 and beyond. In addition to SOAP, REST, POX, etc. web services in various formats (e.g. XML and JSON), WCF also offers MSMQ and Named Pipes. ASMX, as mentioned above, provides only SOAP-based XML web services.
You would need to delve into .NET Remoting for other types of communication protocols. For additional information, you should check out Pro C# 2008 and the .NET 3.5 Framework. It's a great resource, and you can get the chapters from the previous books that cover .NET Remoting, and other replaced features.
Here's a new, big, difference: Microsoft now considers ASMX web services to be "legacy" technology. See "XML Web Services Created Using ASP.NET and XML Web Service Clients".
Web Services
It Can be accessed only over HTTP
It works in stateless environment
WCF
WCF is flexible because its services can be hosted in different types of applications. The following lists several common scenarios for hosting WCF services:
IIS
WAS
Self-hosting
Managed Windows Service
They are two different things all together. WCF is a more generic framework through which you can write one service type component and deploy it in many ways (even as an Asp.Net Web Service).
Here's a brief thread about this http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/2d6a7ff2-f15c-4599-a389-a81cfffcc852/
I had the same problem.
I found the book Microsoft Windows Communication Foundation Step by Step to be really good.
If you just want to do the traditional webservice thing using WCF, then Chapter 1 of that book will show you exactly how to do that (write service, test, deploy, use service).
Its written for VS2005, but I'm using vs2008 and found it even easier.
There's a lot more to WCF, but that book is a good start.
Main Differences between Web service and WCF are listed below.
Web Service : Web Service is an application that is designed to interact directly with other applications over the internet.
1) [WebService] and [WebMethod] attributes defines a web service and methods.
2) It Can be accessed only over HTTP.
3) Hosted in IIS.
4) Support security services.
5) Can not be multithreaded.
6) Only Used Soap or XML.
7) System.Xml.serialization name space is used for serialization
WCF :Windows Communication Foundation (Code named Indigo) is a programming platform and runtime system for building, configuring and deploying network-distributed services.
1) [ServiceContract] and [OperationContract] attributes defines a web service and methods.
2) Accessed through HTTP, TCP, MSMQ, P2P, Named pipes
3) Hosted in IIS, Self-Hosting ,WAS and Windows Service.
4) Can be multithreaded via service behavior class.
5) System.Runtime.Serialization namespace is used for serialization
6) Supports different type of bindings like BasicHttpBinding, WSHttpBinding,WSDualHttpBinding etc.
7) Support security services, reliable messaging, transactions, AJAX and REST Support