We have three "types" applications:
MainSite (MVC Web Role, 6 instances)
CoreServices (TCP-based WCF Worker Role, 20 instances)
NewFeaturesPreviewSiteOne (MVC Web Role, 3 instances)
NewFeaturesPreviewSiteTwo
... 14. NewFeaturesPreviewSiteTwelve
Both MainSite and CoreServices are bundled up as two roles in one deployment. This is updated ~once every 2 months. MainSite accesses CoreServices via an InternalEndpoint on CoreServices. This works great!
We now want to add NewFeaturesPreviewSite (in reality, we have 12 totally different/unrelated apps that you can think of like this). NewFeaturesPreviewSite is updated every couple days and is its own deployment. However, we REALLY want this to consume the already-deployed CoreServices app.
What is the best (or a good) way to accomplish this while considering the following?
Load-balancing is a must-have (20+ CoreServices instances handling requests from three NewFeaturesPreviewSite instances).
We do NOT want CoreServices being publicly exposed to the internet or to anything outside of our applications we're deploying to Azure.
I'd really like to have a solution that leverages Azure's PaaS platform rather than its IaaS platform.
Ultimately, I suspect there's something with Azure's Local Network or Virtual Private Network features that might help me here but I'm not sure - there's something about those that I don't quite get yet.
From the public documents from Microsoft you might not be able to communicate through internal endpoints from another deployment (cloud service). This means you have to open an input endpoint on your core service for your new feature services. But I have the impression that Steve Marx had had a blog post said if you somehow know the internal endpoint, you can just connect to it from another cloud service role if both of them are located in the same data center.
Related
I cannot understand the difference between WCF (service oriented) , and Azure Function or AWS lambda ( FaaS). It seems to me both are invoking remote functions, while WCF has a host. but what is the technical difference between them?
WCF or the Windows Communication Foundation, is another framework, this time for writing and consuming services. These are either web services, or other, e.g. TCP based services, even MSMQ based services. This is, in my opinion, what you should be looking at for exposing your back-end. WCF provides you the ability to easily specify a contract and implementation, while leaving the hosting of the service and the instantiation to IIS (IIS being Microsoft's web server, which is also running under the covers on Azure).
Azure, towards you, is a hosting provider. It helps you scale your application servers based on demand (e.g. number of mobile clients downloading & installing your application).
A little marketing speak: Azure lowers your cost of ownership for your own solutions because it takes away the initial investment in firstly figuring out (guessing) the amount of hardware you need and then building/renting a data center and/or hardware. It also provides some form of middleware for your applications, like AppFabric, so that they can communicate in the "cloud" a bit better. You also get load balancing on Azure, distributed hosting (e.g. Europe datacenters, USA datacenters...), fail safe mechanism already in place (automatic instance instantiation if one were to fail) and obviously, pay as you go & what you use benefits.
Here is the reference: Introduction to Azure Functions, Azure and WCF
I cannot seem to find any combination of tutorials or information online to set me in the right direction, so I'm hoping the community can help me out!
I have some experience with WCF in the past (mostly simple/default http implementations), but nothing to the level I am attempting with my current architecture. Unfortunately 99% of the info I'm finding for WCF is a couple of years old, and most of it does not address Azure specific details. Most books are published back in 2007, and do not address the newer IDE/Tooling or WCF updates since that time. Needless to say I have a few open questions, and would love to get pointed in the right direction after exhausting Google, Stack Overflow, MSDN & YouTube!
In a nutshell:
I want to centralize all business logic behind a single WCF service
on Azure (it will be load balanced on a Cloud Service).
I have a number of web clients that will be consuming this service.
All the clients are C#/.NET MVC projects that I control (I do not need or want the
WCF endpoints to be publicly available)
I would prefer to whitelist access to the endpoints, rather than
implement authentication (for performance & simplicity)
Hear are my questions and potential speed bumps:
Is WCF the right solution? Is there a newer better technology I should be using?
If I use a Cloud Service for my WCF solution, is WebRole or WorkerRole my best option and why? Are hosting the service as a Website an option? (It would save cost)
In my research I've landed on the fact that using NetTCP binding is faster than using the default Http bindings. But I can't find a simple example of how to set this up using VS 2013/.Net 4.5/Azure Cloud Service. Is there a good tutorial for this? Also, I'm assuming NamedPipes are not on option for me?
Since all the consumers of the WCF service will be running on Azure Websites, is NetTCP still possible? How do I create service references? I'm assuming I just use the NetTCP endpoint address, but what about whitelisting for security within the Azure infrastructure?
How can my Azure Website clients connect to TCP within Azure the fastest? Affinity groups don't seem to be an option for Websites, should I abandon this and deploy all my clients as WebRoles so they can share Affinity with my WCF Service? Is Azure smart enough to know that the website is calling a machine within the same region and keep the connection within the region? How is this ensured?
I will have a debug, stage and production environment for my WCF service. What is the best way to switch between the various endpoints on my azurewebsite client(s)? I'd prefer to do it during startup in my global.asax file using C#, rather than in my web.config. I only intend to keep one setting in my Web.Config for "Environment". Ideally I will have a Switch() statement in my startup file that will determine with WCF environment endpoint to use for my Service References.
My apologies for the array of questions. I was thinking about breaking this out into multiple posts, but keeping them in the same context seemed to be the only way to ensure that I am communicating the scope of my inquiry.
Thank you.
I found a great series of videos on Microsoft Virtual Academy that answers all of my questions:
Azure & Services
The key videos in this series are: 1,2 & 7. Here is a direct link to each one:
Intro to WCF
WCF on Azure
Advanced Topics
My management is evaluating non-Azure Microsoft Windows Service Bus (Azure is out of consideration for security reasons). It will be used to setup topic/subscription model with a number of WCF services with netMessagingBinding that we building, so I just have a few basic questions about that.
Are there any specific hardware requirements like dedicated server, dedicated database etc. for WSB to run in production environment?
It's easy to configure WCF service to listen on a specific topic subscription. Is there any way for WCF service to listen to multiple subscriptions?
Appreciate the answers.
You can install the service components and the databases all on one server (that is the default). However, for a number of reasons, we installed the services on a dedicated app server and then created the Service bus databases on an existing database server. The install package allows you to specify a different db server. Check this article for the minimum server requirements
Yes you can get one WCF service to listen to multiple subscriptions. You would need to create two (or more) System.ServiceModel.ServiceHost instances and then run them inside one process. For example we had one windows service running two ServiceHost's. Each host listened at a different queue and therefore implemented a different contract. This meant where queues were logically grouped we didn't need a new windows service per queue. You could do the same with subscriptions.
For question one, you will have to go through the exercise of hardware sizing. the good news is that WCF services can scale vertically, so you can add up servers if there were issues in handling client load.
To do hardware sizing you will have to make an estimate the expected load and then do performance/scalablity testing to figure the load bearing capacity of your serviceBus/services .
you could find a lot of resources for load testing like this one http://seroter.wordpress.com/2011/10/27/testing-out-the-new-appfabric-service-bus-relay-load-balancing/
once you do load testing and come up with the numbers, you can then do sizing using references like this one http://msdn.microsoft.com/en-us/library/bb310550.aspx
I am working with silverlight project that is consuming domain services. Actually i find that quite messy as one domain service class and metadata. I have already worked with Wcf services and found them very easy to update and handle. But domain service's modification (as new field or tables are added) is really a pain.
I want to know why people prefer domain services over silverlight enabled Wcf services? I mean advantages or disadvantages of both and performance implication
After goggling i found this are things you should see :
To authenticate users faster in the domain
To authenticate resources(gps etc) faster for the users
Utilization of resources
Utilization of network and descreasing the overall traffic in the
network.
The main benefit is that of the users and passwords management, which
could grow to be massive amount of work having to manage them
individually on each independent servers. The proposed changes of
migrating the whole platform to Active Directory environment will
assist in propagating the changes (such as new users, password
changes, new security requirements via GPO, etc) on to the servers
(which will run as domain clients, only 1 or 2 will run Primary and
Secondary ADC. Not all these servers are going to run host AD or be
an ADC, server OS is used due to it's robustness and reliability).
disadvantage
cost of infrastructure
good planning is must
Complex structure for user
I understand to an extent that it helps applications communicate regardless of their location. Why is it important and what is an example of a real-world use of WCF?
WCF is a generic communication mechanism that allows you to setup generic client/host communication between two parties. The neat thing about WCF is that is allows you to configure service properties such as transport (http/pipes/tcp/Tibco EMS), security models (any of the W3C standards), compression, encoding, timeouts, etc, without changing ANY code. That is powerful. Best of all, you can configure it so that you can have a service in C# and a client in Java (or any other language or the other way around), as long as they both talk using the same mechanisms.
You can create a standard HTTP SOAP web service using WCF and one day decide to switch it to use the faster named pipes for local communication. You can create web services that talk over TibcoEMS and have easy failover on the queue level. You can create a file streaming web service that distributes all kinds of images/videos to your application.
Here Are some brain dump i think might be useful to understand the whole scenario.
Reason of Creating WCF : Background
Modern Application[Distributed Application] development we use different architechtures and technologies for communication
i.e:
COM+
.NET Enterprise Services
MSMQ
.NET Remoting
Web Services
As there are various technologies. they all have different architechtures. so learning all them are tricky and tedious.
one need to focus on each technologies to develop rather than the application business logic
so microsoft unifies the capabilities into single, common, general service oriented programming model for Communication. WCF provides a common approach using a common API which developers can focus on their application rather than on communication protocol.
Now-a-days we call it WCF.
N.B: image collected from - http://www.codeproject.com/Articles/255114/Windows-Communication-Foundation-Basics
What Exactly WCF Service Stands For?
WCF lets you asynchronus messages transform one service endpoint to another.
The Message Can be simple as
A Single Character
A word
sent as XML
complex data structure as a stream of binary data
Windows Communication Foundation(WCF) supports multiple language & platforms.
WCF Provides you a runtime environment for your services enabling you to expose CLR types as Services and to consume other Services as CLR Types.
A few sample scenarios include:
A secure service to process business transactions.
A service that supplies current data to others, such as a traffic report or other monitoring service.
A chat service that allows two people to communicate or exchange data in real time.
A dashboard application that polls one or more services for data and presents it in a logical presentation.
Exposing a workflow implemented using Windows Workflow Foundation as a WCF service.
A Silverlight application to poll a service for the latest data feeds.
Why on Earth We Should Use WCF?
from a Code Project Article, thanks to #Mehta Priya I found the following Scenarios to illustrate the concept. Let us consider two Scenario:
The first client is using java App to interact with our Service. So for interoperability this client wants the messages in XML format and the Protocol to be HTTP.
The Second client uses .NET so far better performance this clients wants messages in binary format and the protocol to be TCP.
Without WCF Services
now for the stated scenarios if we don't use WCF then what will happen let's see with the following images:
Scenario 1 :
Scenario 2:
These are two different technologies and have completely differently programming models. So the developers have to learn different technologies
so to unify & bring all technologies under one roof. Microsoft has come with a new programming model called WCF.
How WCF Make things easy ?
one implement a service and he/she can configure as many end points as it required to support all the client needs .
To support the above 2 client requirements
-we would configure 2 end points
-we can specify the protocols and message formats that we want to use in the end point of configuration
References:
WCF : What , Why and When https://vishalnayan.wordpress.com/2010/12/31/wcf-what-why-when/
Why we use WCF Service? http://www.codeproject.com/Tips/815742/Why-We-Use-WCF-Service-and-Sample-of-WCF-Service
What Is Windows Communication Foundation https://msdn.microsoft.com/en-us/library/ms731082(v=vs.110).aspx
Windows Communication Foundation Basics http://www.codeproject.com/Articles/255114/Windows-Communication-Foundation-Basics
There's little to add to the responses so far, especially the one from "siz".
One thing to add is that WCF is the current way to do web services on the .NET platform. It's not the "new" way, it's the current way. ASMX web services are the old and just barely maintained way. One Microsoft employee has publicly stated that only critical security fixes will be made to the ASMX platform, so if you intend for your services to be useful more than a year from now, don't use ASMX.
In addition to the typical "web service" use cases, WCF handles atypical cases, like binary communication over named pipes, message queues, etc. To a very large extent, the service you write to support something simple like SOAP over SSL can also support these other protocols, with no changes to the code.
To answer the "real world" bit, I'm just finishing up a dispatch system by which a Visual Basic 6.0/access alarm receiver, a WPF/SQL ERP system and an iPhone application all share information to schedule and execute jobs.
Essentially the use case is where you want two separate applications to talk to each other somehow and their locations are unknown (could be same machine (but different application domain), same network or on the other side of the internets)
You can easily embed it into a Windows Forms application. That was a nice thing to discover. It is so much easier than .NET Remoting too.
There are a number of reasons why it is advantageous over classic ASP.NET web services (.asmx).
A couple of these off the top of my head are:
The ability to have multiple bindings for the same service call means the message doesn't have to serialise into XML and back if you simply want to communicate inside a web farm.
The way contracts are defined is much more forgiving when it comes to multiple versions of the same contract.