AppFabric is arguably the most mature part of Windows Azure, at least if you measure by how long it has been publicly available, if not broadly announced. AppFabric started life as BizTalk Services. It was seen as a complementary cloud offering to Biz-Talk Server. BizTalk is a high-end enterprise-grade messaging and integration platform, and indeed the services fit into that portfolio well. Some joke that it was called BizTalk Services as a clever way to keep it a secret, because BizTalk is one of the most underestimated products Microsoft has. Just ask a BizTalk developer.
When Windows Azure was announced at PDC 2008, the BizTalk Services were renamed to .NET Services. Over the following year, there was a push to get developers to work with the services and put the SDK through its paces. Out of that year of realworld testing came a lot of changes.
When Windows Azure went live in early 2010, the services were renamed again to Windows Azure platform AppFabric to tie it more closely to the Windows Azure platform. Some people were confused by the older .NET Services name, thinking it was just the runtime and base class library running in the cloud, which makes no sense whatsoever.
The two AppFabrics
Don’t confuse the AppFabric we’ll be covering in this chapter with the new Windows Server AppFabric product. They’re currently related by name alone. Over time they’ll merge to become the same product, but they aren’t there quite yet.
Windows Server AppFabric is essentially an extension to Windows Activation Service (WAS) and IIS that makes it easier to host WCF and Windows Workflow Foundation (WF)-based services in your own data center. It supplies tooling and simple infrastructure to provide a base-level messaging infrastructure. It doesn’t supply a local instance of the Access Control Service (ACS) or Service Bus service at this time. Likewise, Windows Azure platform AppFabric doesn’t provide any of the features that Windows Server AppFabric does, at least today. In early CTPs of Windows Azure platform AppFabric, there was the ability to host WF workflows in the cloud, but this was removed as it moved toward a production release.
The AppFabric we’re going to cover in this chapter makes two services available to you: Access Control Service and the Service Bus.
Two key AppFabric services
AppFabric is a library of services that focus on helping you run your services in the cloud and connect them to the rest of the world.
Not everything can run in the cloud. For example, you could have software running on devices out in the field, a client-side rich application that runs on your customer’s computers, or software that works with credit card information and can’t be stored off-premises. The two services in AppFabric are geared to help with these scenarios.
- Access Control Service (ACS) —This service provides a way to easily provide claimsbased access control for REST services. This means that it abstracts away authentication and the role-based minutia of building an authorization system. Several of Azure’s parts use ACS for their access control, including the Service Bus service in AppFabric.
- Service Bus—This service provides a bus in the cloud, allowing you to connect your services and clients together so they can be loosely coupled. A bus is simply a way to connect services together and route messages around. An advantage of the Service Bus is that you can connect it to anything, anywhere, without having to figure out the technology and magic that goes into making that possible.
As we look at each of these services, we’ll cover some basic examples. All of these examples rely on WCF. The samples will run as normal local applications, not as Azure applications. We did it this way to show you how these services can work outside of the cloud, but also to make the examples easier to use.
Each example has two pieces that need to run: a client and a service. You can run both simultaneously when you press F5 in Visual Studio by changing the startup projects in the solution configuration.
Source of Information : Manning Azure in Action 2010
When Windows Azure was announced at PDC 2008, the BizTalk Services were renamed to .NET Services. Over the following year, there was a push to get developers to work with the services and put the SDK through its paces. Out of that year of realworld testing came a lot of changes.
When Windows Azure went live in early 2010, the services were renamed again to Windows Azure platform AppFabric to tie it more closely to the Windows Azure platform. Some people were confused by the older .NET Services name, thinking it was just the runtime and base class library running in the cloud, which makes no sense whatsoever.
The two AppFabrics
Don’t confuse the AppFabric we’ll be covering in this chapter with the new Windows Server AppFabric product. They’re currently related by name alone. Over time they’ll merge to become the same product, but they aren’t there quite yet.
Windows Server AppFabric is essentially an extension to Windows Activation Service (WAS) and IIS that makes it easier to host WCF and Windows Workflow Foundation (WF)-based services in your own data center. It supplies tooling and simple infrastructure to provide a base-level messaging infrastructure. It doesn’t supply a local instance of the Access Control Service (ACS) or Service Bus service at this time. Likewise, Windows Azure platform AppFabric doesn’t provide any of the features that Windows Server AppFabric does, at least today. In early CTPs of Windows Azure platform AppFabric, there was the ability to host WF workflows in the cloud, but this was removed as it moved toward a production release.
The AppFabric we’re going to cover in this chapter makes two services available to you: Access Control Service and the Service Bus.
Two key AppFabric services
AppFabric is a library of services that focus on helping you run your services in the cloud and connect them to the rest of the world.
Not everything can run in the cloud. For example, you could have software running on devices out in the field, a client-side rich application that runs on your customer’s computers, or software that works with credit card information and can’t be stored off-premises. The two services in AppFabric are geared to help with these scenarios.
- Access Control Service (ACS) —This service provides a way to easily provide claimsbased access control for REST services. This means that it abstracts away authentication and the role-based minutia of building an authorization system. Several of Azure’s parts use ACS for their access control, including the Service Bus service in AppFabric.
- Service Bus—This service provides a bus in the cloud, allowing you to connect your services and clients together so they can be loosely coupled. A bus is simply a way to connect services together and route messages around. An advantage of the Service Bus is that you can connect it to anything, anywhere, without having to figure out the technology and magic that goes into making that possible.
As we look at each of these services, we’ll cover some basic examples. All of these examples rely on WCF. The samples will run as normal local applications, not as Azure applications. We did it this way to show you how these services can work outside of the cloud, but also to make the examples easier to use.
Each example has two pieces that need to run: a client and a service. You can run both simultaneously when you press F5 in Visual Studio by changing the startup projects in the solution configuration.
Source of Information : Manning Azure in Action 2010
|
|
0 comments
Post a Comment