I recently installed Windows Server Service Bus 1.0 (on a Windows Server 2008 R2 machine).
That also installs "Windows Fabric" (not AppFabric).
Could not find much information on it, and googleing it I stumbled on a Lync server post (Windows Fabric is also installed by Lync Server 2013).
Definition:
"Windows Fabric is a Microsoft technology used for creating highly reliable, distributable, and scalable applications."
From the Service Bus architecture intro,it looks like Fabric is what allows for services replication, high availabilty, and fault tolerance.
Anyone knows if that can be used to host custom .NET services? Or any kind of direction would be greatly appreciated.
Thanks in advance.
Cos
I went to a talk by Mark Eisenberg on May 28th at the Microsoft NERD Center near MIT in Boston MA. The talk was mostly about the Azure Service Fabric. General consensus was that if you're using Azure from the infrastructure as a service perspective you aren't really using it.
The next step up is to use Azure naively as a platform meaning that rather than create VMs and hosting them there you're creating cloud services and web jobs and web apps and using the new Logic Api's etc...
But if you really want to build a stateful, resilient service enterprise class you'll want to go underneath the PaaS and write against the Service Fabric directly for greater control.
That's where the money is.
I did a write up on the talk and what the Azure Service Fabric is a few days ago and posted it here.
I don't actually think that Windows Fabric is open product. It is used for infrastructure purposes, and not for deploying custom services. For your custom services you have to use platform built on top of Windows Fabric, like Service Bus, Windows Server App Fabric.
I think Windows Fabric is for internal use by Windows Azure and Private Cloud for clustering, load balancing and so on.
UPDATE:
I've started developing Windows Azure application and here is what I've found.
I've added a Service role to Azure application and started it on local development machine (under Azure emulator). And my service was published in and started under Windows Fabric!
So the conclusion is: Windows Fabric is a platform for running YOUR Cloud Services.
Fabric which the name suggests in itself, is back-end.
It is no different than iSCSI or EIGRP. The main difference is that it is generic in form rather than specific like the aforementioned services/protocols.
IIS is a server service specific to web hosting.
SQL the same but database only..
fabric, applied to host fabric aware services and software.
Windows Fabric is used internal by Microsoft to building highly available, resilient and scalable services. It has been used for Service Bus, SQL Database, Document DB etc. according to this video: Building Resilient, Scalable Services with Microsoft Azure Service Fabric
Until now it has not been available for external parties but has now been announced as Service Fabric which will be available on Windows Azure and Window Server 2016.
Read more here: http://azure.microsoft.com/en-us/campaigns/service-fabric/
Related
What is the best way to build Teams messaging extension using the bot framework without ngrock. My organization is not even allowing me to use it for testing or development. My web search pointed me to Azure Service Bus, Azure Relay and a dedicated NGINX Linux server with public IP. Just wanted to know what would be the ideal way and the costs associated it if someone has already developed an app?
I've created a simple Stateful Actor and a Web API (self hosted) and deployed it to Azure. It has worked and I can browse the nodes in the Service Fabric Explorer.
Azure gives me a url but when I add /api/values to the end (which works fine locally) it downloads a file called values and I can't open it as it is a binary file.
I want to call the web api from a Xamarin app (ie normal Rest api call) but if I can't call it via a browser I'm a bit stuck.
I would comment this on Stephen's answer, but I lack sufficient reputation.
To add a custom port to the Load Balancer after the service fabric cluster has been created you can (in the newer Azure portal):
Navigate to the load balancer resource for your service fabric cluster.
Under "Settings" find the "Load balancing rules" option.
This will have at least two rules, more if you did setup custom rules during the setup of the cluster.
Add a new rule.
Give it a name
'Port' is the external port you'd like to hit.
'BackendPort' is the port your service is configured to listen on.
The defaults on the other settings work in a pinch.
Note if you have multiple ports to enable, they each need their own rule.
I do know the above worked in my 'hello world' sandbox project.
I'm climbing the service fabric learning curve myself so I can't comment with authority on the other settings.
Have discovered what was missing.
https://azure.microsoft.com/en-us/documentation/articles/service-fabric-cluster-creation-via-portal/
This link here walks through creating the Service Fabric app on Azure and in particular the field "Application input endpoints" needs to have the port you want to use. For the samples, they are mostly port 80 or 8081.
There is supposed to be a way to add these ports afterwards which I tried (and so did a Microsoft support engineer) and it did not seem to work. You are supposed to be able to add these ports to the Load Balancer associated with the Service Fabric App.
I recreated my Service Fabric app, exactly as I did before but this time filled in the ports I want to use in the Node Type section and now I can hit the webapi services I've deployed. This field can be left blank which is what I did first time round and was why I had issues.
Not really related to Service Fabric, it's just how you set up your HTTP response headers in Web API. Recommend tagging this with asp.net or asp.net-web-api for a more thorough answer.
Tutorials and technical resources around Azure Service Fabric Stateless Web API tend to be slightly disjointed, given that the platform and resources are still quite immature.
This Stateless Web API tutorial, at the time of writing, is very effective.
As prerequisite to the tutorial:
Update Visual Studio to the latest version (Extensions and Updates)
Update the Service Fabric SDK to the latest version (Web Platform Installer)
Explicitly specify the EndPoint Port attribute (defined in ServiceManifest.xml) when setting up your Azure Service Fabric Cluster Node Type parameters
Following these steps will successfully allow deployment to both local and remote clusters, and will expose your Web API endpoints for consumption.
I am kind of new to system architecture. That is, all of my web apps have been relatively flat...two machines at the most running web client and database.
I have been handed the following architecture:
1 VMware machine will run the web application, an MVC 3 app.
1 VMWare machine will host the SQL Server database
1 VMWare machine will host the services.
The machine I'm confused about is the last one. From what I understand, the services project contains references to three other projects: the model, where the entity framework edmx resides, the entities project, which contains T4 templates that use the entity edmx file as input, and the business project which is where the actual business rules are implemented and the meat of the CRUD actions take place.
From what I understand, the intent is to not run an IIS WCF web services interface, but to make calls to WCF services (like those hosted in the MMC services snap in) on the machine over the internet. There is a deployment project in the solution for the services project but I don't know if it's configured properly. I think the idea is to just run the installer on the services machine and it will work.
My specific question is if there are any important things that I need to keep in mind when implementing, configuring, and deploying these services?
I'm kind of new to all of this. I was under the impression that you had to make calls to WCF services via IIS hosted endpoints and that you couldn't (or it at least was inadvisable) to make what amounts to RPC-like calls to machines over the internet.
Since you are new to WCF services, I suggest reading this MSDN article on Hosting and Consuming WCF services.
From what you describe, it looks like you are using Windows Service as a host for your WCF service.
The most common choice for a host is IIS because of its extensive features including self-starting services, ease of deployment, load balancing and so on.
Windows Service is a valid host, provided you can justify the question 'Why not IIS?'. Maybe, you need full control over the activation and lifetime of your WCF service. Not sure.
p.s. Ensure the account that your Windows Service runs under, has the minimum privileges.
This question has probably less to do with actual programming and more to do with environment setup.
I'm developing an application for a Windows CE device, which will use a service hosted in Microsoft Azure. Obviously, this is all under development, and the service itself has not yet been uploaded to Azure. So I'm using the emulators provided by MS to deploy the service locally. Also, I don't think uploading the service to Azure just to debug it is a good idea, as that could net us a bill for Azure we don't yet want to pay.
Also, please note, I'm using VS2008 for the Windows CE project and VS2010 for the Azure project (thank you MS for dropping support for mobile devices -_-).
The problem is, the service seems to be accessible only via 127.0.0.1 or localhost, and if I physically connect a Windows CE device or use an emulated one, it becomes a new entity on the network, and cannot access that service any more.
How can I debug my Window CE application and have it see the service, whilst still being able to debug the service itself?
You are correct, the development fabric (the compute emulator that allows you to build an azure application and debug it locally) is only meant for local development. There are some hacks that allow you to get around that, but I wouldn't recommend it.
My recommendation would be to spin up the service in a more traditional hosting environment, at least in these early stages. You can define it as a web app just as you always would have, and get it functioning. Then, when you know its mostly complete, create a cloud service project and do an add existing to bring your web app into the cloud service solution. Once in, its a simple matter to add the web app as a web role.
From there, you can complete testing of the service in both the local and hosted azure environments as needed. This allows you to minimize your development costs while still leveraging the power of the cloud. As an upside, you also have done most of the basic work to ensure your service is compatible with multiple deployment scenarios giving you a greater degree of choice for its final production state.
OK, I don't know if this was intentional, or if I found one of the mentioned hacks, but I saw that IIS hosts the Azure site I created on port 5100, and the binding for this site is *, so it accepts all connections.
Using this I could access the service from my emulator, and I could still debug all Azure related stuff.
Real application how can i use this app fabric ??
How can i put my business logic in this and this logic use in my windows azure application??
Thanks
The Azure AppFabric is a collection of services that allow to you leverage functionality traditionally provided on premise by infrasture components common to most networks. Currently, it consists of the following:
Azure AppFabric Service Bus - allows for connection of applications by providing a centralized relay point in the cloud. Applications create outbound connections to the rendezvous location, thus helping mitigate the challenges posed by security measures like firewall restrictions on in-bound connections and IP masking via NAT layers. This feature includes both 'real time' options as well a 'message buffer' dynamic to allow for more disconnected style communication.
Azure AppFabric Access Control Service - the "ACS" allows WIF applications to quickly access various identity providers and consume a single format of claims token. Used in conjunction with products like ADFS, it allows cloud hosted applications to authenticate against on-premise identity stores.
Azure AppFabric Cache Service - currently in public testing, this service brings the "Velocity" style functionality to applications. This provides them with a distributed cache system as well as a new session provider.
There's more features/services coming in 2011, but these are the hot ones currently. Regarding hosting your business logic, this is not something that is currently available in the Azure AppFabric. There's been mentions that we may eventually see the potential for placing applications "on the edge", meaning the servers that front the Azure AppFabric connections, but no ETA or even firm commitment that this will happen.
You can implement your business logic in Windows Azure, in a web or worker role depending if you need it to be synchronous or asynchronous.
You can surface the business logic using the service bus, though you could also implement your logic on premise and surface them via the service bus.
AppFabric is not a business logic layer. Think of AppFabric as cross-cuts, or glue between different parts of your application.
For now Business logic goes in components like a web or worker role, or an on premise app which you could expose on the internet using AppFabric Service Bus.
In a future release, AppFabric will release "Composite Apps" which in a nutshell seem to allow you to deploy managed WCF/WF workflow services, which makes for a better "business engine". But for now I think you could probably just use Workflow services in a web role.