Hi guys, I want to share with you a discussion that I’ve participated recently.
Consider this: you are a a host provider and your company will offer Sharepoint support to the public so they can pay you a monthly fee and then they setup a Sharepoint site with you.
You go for a simplistic and cheap design. You have IIS, Sharepoint installed, and you create a web application on the port 80. Within this web app you create multiple site collections. They are the sites your clients will have control for their own setups.
And how do you host multiple websites on the port 80 with a single IP address? Easy. I will use host headers – you say.
And you think: I should be fine. I will setup in away so each client will have their own separate database, they will redirect to the given URL I will provide them and according to the hosting plan I enable disk quotas for each case. For instance, if my client pays me some little money and he is a ’silver client’ I offer them 10MB; if they are ‘platinum client’ and pay me some more I give them 50MB.
All goes fine and well. You see everybody joining your company, the clients keep coming and your setup is totally independent.
so, what’s the problem here?
You are unable to offer HTTPS in that setup. If one of your clients wants to add a shopping cart area and want it to be secure, you can’t help them with that model.
The thing is, IIS can not resolve an incoming HTTPS request like that. ISS will hold the request and it is going to ask himself: ok, to which website should I give this request? Unfortunately IIS as of now can not address this question following that setup. Everybody is under the same IP.
To fix that one of the recommended approaches is to follow the diagram below:
On your IIS you will create multiple web applications, then for each web application you will want to give separate IPs and then host sites on these IPs, and then these web applications are the ones you will offer to your clients.
That’s a little bit more elaborated solution, a little bit more expensive but the gains in scalability will overcome the headaches you might have in the future with an atomic structure that at some point needs to be flexible.
And on that model IIS can finally then fix the SSL dilemma. Because then you will assign the applications to independent IP addresses on the ISS Manager.
Sometimes it takes more than a quick and simplistic approach to design a solution if you only know partially the products involved. Once you have the proposed design please be aware of the issues that are basic in the parts involved. In our case, a knowledge of IIS would have avoided a big trouble in the beginning.
See you later.
Hi guys,
Let's talk architecture again, reference architecture, more
specifically SOA, and how can we map the available products and resources available from Microsoft given a SOA project?
Before I start, let me make a statement here: I will talk this from the Microsoft's point of view, since this is a blog about Microsoft technologies.
In any case, it doesn't matter what's your preferred provider as long as you are able to correctly do the mapping of functionalities to better fit your business' plans, budget and SLA. And just to revisit: SOA is an architecture where the functionalities of existing business applications are exposed and published as services.
And what would be a service? Services are software components that expose application functionalities in a given SOA architecture and they are:
- self-manageable;
- message-based oriented;
- can handle and support many protocols;
- can be published on a myriad of hosts;
- implement operational contracts, interfaces and message types;
Of course you can design some service that doesn't follow these rules, but let me tell you: Rules are made with a purpose and in our case the purpose is to design a solution where clients and services are highly decoupled, thus paving the way for the reuse of functionalities. One of the goals is to maximize the resource utilization in our project.
I won't talk here about governance, granularity, message routing, service level control etc. I won't go there for it is a much larger topic, so this post is about the technical view. Now, let's make our first diagram given what we've seen so far:
As we can see, we have here the common services of a SOA architecture such as the presentation services, collaboration, systems integration, orchestration services etc.
Looking at this diagram we can identify the aspects that we really want to map in our solution to be successful. Note that in some scenarios sometimes the security is critical, sometimes the orchestration is paramount, sometimes the platform integration is more important.
Now, visualize this filling the gaps with the products that Microsoft has to offer.
An interesting conclusion we can take at first sight is that some products can cross domain frontiers and can handle various capacities at once, such as the Windows Workflow Foundation, which can be used for interoperability services and orchestration at the same time with BizTalk Server.
What's the best option to choose? Well, to be able to see this big picture and to choose the best piece in the puzzle is your job as architect. Unfortunately many architects fall in the problem to overkill the solution.
Also important is to choose not to overkill the solution. Sometimes a simple custom application can fill the gap enough to not require a bigger solution like Windows Workflow Foundation, for example. Otherwise the whole project just becomes harder to handle and to maintain...thus increasing the ROI overtime...and the developers patience.
The message to keep in mind: any good architecture is composed by many capacities. To identify these capacities and which one of them are important for our solution is as critical as choosing the technology provider.
See you later.