Translation Azure Services Platform David Cheppel Part 2
The first part of the translation
Getting an overview of the Azure Service Platform is an important first step; however, a deeper understanding of each technology is also needed. In this section, each member of the Azure family is covered in a little more detail.
Windows Azure does two main things - it runs applications and stores their data. Accordingly, this section is divided into two parts, dedicated to each of them. The interaction of the parts is also very important, so its description will also be part of the section.
In Windows Azure, an application typically has several instances, each of which executes part or all of the application code. Each instance runs on its own virtual machine. All virtual machines run under Windows Server 2008 and they are provided by a hypervisor specifically designed for use in the cloud.
At the same time, the application on Windows Azure does not see the virtual machine on which it runs. The developer cannot provide his virtual machine image so that Windows Azure works on it, but he doesn’t need to worry about supporting this copy of Windows. Instead, the CTP version allows developers to create .NET 3.5 applications with two types of tools - one is run by Web Role and the other is Worker Role. Figure 5 shows how this all works.
Fig. 6 In the CTP version, the Windows Azure application consists of the Web Role and Worker Role instances, each running on its own virtual machine.
')
As the name implies, an instance of Web Role accepts incoming HTTP (or HTTPS) requests via Internet Information Services (IIS) 7. Web role can be implemented using ASP.NET, WCF, or another .NET technology that works with IIS. As shown in fig. 6, Windows Azure provides a built-in load balancer that distributes requests between different instances of Web Role, which are parts of the same application.
Worker Role, on the other hand, does not accept requests directly from the outside world - it cannot have external incoming network connections and there is no IIS on its virtual machines. Instead, it receives the source data from the Web Role, usually through a queue in the Windows Azure storage. The result of the Worker Role instances can be written to the Windows Azure storage or sent to the outside world - outgoing network connections are allowed. Unlike Web Role instances that are created to process HTTP requests and turn off after processing a request, Worker Role can run endlessly - this is a background task. Due to this lack of specialization, Worker Role can be implemented using any .NET technology that supports the main () method (there are some limitations related to Windows Azure trust, which will be described below).
Each virtual machine hosting an instance of Web Role or Worker Role contains a Windows Azure agent through which applications interact with the Windows Azure factory, as in Figure 6. The agent is available through a specific Windows Azure API, through which applications can write to the log managed by Windows Azure, send warnings to their owner through the Windows Azure factory, etc.
Although the current state of affairs may change in the future, in CTP, each virtual machine has its own physical core of the processor. Thanks to this, the performance of each application can be guaranteed - each instance of Web Role and Worker Role has its own dedicated core. To increase the performance of the entire application, its owner can increase the number of running instances specified in the configuration file. The Windows Azure factory will then “overclock” new virtual machines, assign kernels to them, and launch more application instances. The factory also determines when the Web instance or Worker Role crashes and starts a new one.
Pay attention to the corollary of this: to ensure scalability, instances of Web Role do not have to store their state. Any information about the client-specific state should be written to the Windows Azure storage or sent to the client with cookies. The statelessness of the Web role is required for the load balancer built into Windows Azure. Since you cannot bind to a specific instance of Web Role, you cannot guarantee that different requests from the same user will be processed by the same instance.
Both Web Role and Worker Role are implemented using standard .NET technologies. But to transfer existing applications to Windows Azure without changes most likely will not work. On the one hand, the way to access data is different. Access to Windows Azure storage is implemented through ADO.NET Web Services, a relatively new technology that is not yet universally used in local applications. Similarly, Worker Role typically uses a Windows Azure storage queue to receive input data, that is, an abstraction that has no analogues for local applications. Another limitation is that Windows Azure applications do not work in a fully trusted environment. On the contrary, they are limited by what Microsoft calls Windows Azure trust, which corresponds to the average degree of trust that most ASP.NET hosters use.
For developers, creating Windows Azure applications on the CTP version is very similar to developing traditional .NET applications. Microsoft provides VS2008 project templates for creating Windows Azure Web Role, Worker Role, and a combination of both roles. Developers can use any .NET language to choose from (although it is fair to say that Microsoft’s focus on developing Azure was in C #). Also, the Windows Azure SDK includes the version of the Windows Azure environment that runs on the development computer. It contains the storage, the Windows Azure agent and everything else that is available to the application running in the cloud. A developer can create and debug his application in his local cloud similarity, and then distribute it to a real cloud when it is ready. At the same time, some things in the cloud are completely different. It is not possible to connect the debugger to an application in the cloud, for example, so that debugging of cloud applications is done mainly due to an agent managed by Windows Azure.
Windows Azure provides developers and other services. For example, a Windows Azure application can send a message with some kind of warning through a Windows Azure agent, which the agent then delivers via mail, instant message or other means to the specified recipient. If necessary, Windows Azure can determine the application crash and send a warning. The platform also provides detailed information about the consumption of resources by the application, including processor time, incoming and outgoing traffic, and storage.
Applications work with data in a variety of ways. Sometimes, all you need is simple blobs; other situations require a more structured way to store information. In some cases, all that is needed is a mechanism for exchanging data between different parts of the application. Windows Azure storage covers all of these requirements as shown in Figure 2. 7
Fig. 7 Windows Azure allows you to store data in blobs, tables, and queues that are accessed through REST over HTTP.
The easiest way to store data in Windows Azure is using blobs. As in Figure 7, there is a simple hierarchy: a storage account can have one or more containers, each of which stores one or more blobs. Blobs can be large - up to 50 GB each - and to make the transfer of blobs easier, each of them can be divided into sub-blobs. If there is a transmission error, the retransmission may start from the most recently transmitted subblock. Blobs can have metadata, such as information about where JPEG photos were taken, or data about a song composer for an MP3 file.
For some types of data, blobs are the most, but in many situations they are not sufficiently structured. To enable applications to work with data at the level of small structural units, Windows Azure storage provides tables. Despite the similarity of names, they should not be confused with relational tables. In fact, although they are called tables, the data in them is stored as a simple hierarchy of entities with properties. The table does not have a specific data schema; instead, properties can be of various types, such as Int, String, Bool, or DateTime. And instead of using SQL for working with data, the application accesses the data through a query language with LINQ syntax. A single table can be quite large, with millions of entities storing terabytes of data, and Windows Azure can split the table between many servers if it is necessary for performance.
Both blobs and tables are for data storage. The third method of storing data in Windows Azure storage — the queue — was created for a slightly different purpose. The main role of queues is to provide interaction between Web Role and Worker Role instances. For example, a user sends a request to perform a resource-intensive task through a web page implemented in Web Role. The instance of Web Role that receives this request writes a message describing the work to be performed, into a queue. An instance of Worker Role that is waiting for a message in the queue reads a new message and does the required work. He can return the results of work through another queue or in some other way.
Regardless of storage method — in blobs, queues, or tables — three copies are stored for all data in Windows Azure. This gives independence from falls, since the loss of one copy is not fatal. The system also guarantees integrity, so that the application reading the data that it just recorded will receive exactly what it expects.
Data in Windows Azure storage is available to both Windows Azure applications and applications running in some other place. In both cases, they are equally accessible to all three data storage methods, using REST conventions to identify and provide data access. Everything is called a URI and is available through normal HTTP operations. A .NET client can use ADO.NET Services or LINQ, and from, for example, a Java application, Windows Azure data is accessed via standard REST. For example, a blob can be read via HTTP GET to a URI formatted like this:
This is the identifier that is assigned to each storage account created, and it uniquely identifies the blobs, tables, and queues created in that account. and these are just the names of the container and blob that are addressed in the request.
Similarly, a request to a specific table is expressed via an HTTP GET request to a URI of the form:
Here indicates the requested table, and the request to execute to this table.
Even queues are available to Windows Azure applications and external applications via HTTP GET to URIs:
The fee for computing resources and storage on the Windows Azure platform is charged independently. This means that a local application can only use Windows Azure storage, accessing its data through REST as described. But it is still fair to say that the main purpose of Windows Azure storage is to work with data from Azure applications. And since the data is not available to Azure applications directly, they remain available even when the Azure application using them is not running.
The main purpose of platforms for applications, whether cloud or local, is the support of applications and data. Windows Azure provides an environment for both. Looking into the future, we can expect that applications that should have been local Windows applications will be built on this new cloud platform.
Running applications in the cloud is in itself useful, but infrastructure services provided in the cloud are no less useful. These services can use both local and cloud applications, and they solve tasks that would be much more difficult to solve in another way. This section examines Microsoft's offerings in this area: .Net Access Control Service, .Net Service Bus, and .Net Workflow Service, which are collectively known as .Net Services.
Identity management is a fundamental part of most distributed applications. Based on user credentials, the application decides what is allowed to this user. To transfer this data, an application can use tokens defined using Security Assertion Markup Language (SAML). The SAML Token contains claims (claims), each of which represents specific information about the user. One statement may contain a user name, the other may indicate its role, such as “manager” or “CEO”, and the third one may contain its email. Tokens are created by applications known as security token service (STS), which digitally sign each token to confirm its source.
Once a client (for example, a Web browser) receives a user's token, it can provide it to the application. The application can now use assertions from the token to determine what is allowed to this user. At the same time, a couple of problems immediately appear:
Adding a new STS to this process can solve both problems. To ensure that the token contains the necessary assertions, this optional STS performs conversion of assertions. An STS can have rules that define the relationship between the source and final statements, and use these rules to create a token containing exactly the statements that the application needs. The solution to the second problem, commonly called identity federation, requires applications to trust this new STS. It is also required to establish a trusted relationship between this STS and the STS that issued the source token.
Adding an additional STS provides claims conversion capabilities and identity federation, both of which are very useful. But where should this STS be performed? You can use an STS that works within an organization — a service that some vendors provide. Why not run STS in the cloud? This will make it available to users and applications of any organization. It also shifts the concern for STS management and support to the service provider.
This is exactly what the Access Control Service offers: this is an STS in the cloud. To imagine how such an STS can be used, suppose an ISV that provides an application accessible via the Internet, with which users from different companies can work. Even if all companies can provide SAML tokens for their users, it is unlikely that they will contain exactly the set of statements that the application needs. Figure 8 shows how the Access Control Service solves this problem.
Fig. 8 Access Control Service provides rule-based claim conversion and identity federation.
Initially, the user application (in this example, the browser, but it could be a WCF client or something else) sends the access control user token (step 1). The service verifies the token's signature, verifies that the token is issued by a trusted STS. After that, the service creates and signs a new SAML token that contains the approvals required by the application.
To make such a transfer, the STS in the Access Control Service uses the rules defined by the owner of the application. For example, imagine an application that gives certain rights to any user who works as a manager in his company. Although each company may include a statement in its token, which indicates that the user is a manager, the statements of different companies may well be different. One company can use the string “Manager”, the other “Supervisor”, and the third in general is a special code expressed as an integer. To help applications work with all this diversity, the application owner can define a rule that converts all three of the above statements into one that contains the string “Decision Maker”. The life of the application after this becomes much simpler, since the work with the transformation of statements for it has already been done.
After creating a new token, Access Control Service returns a new token to the client (step 3), which then transfers it to the application (step 4). The application verifies the token's signature to ensure that it is issued by the STS in the Access Control Service. It should be noted that although the STS in the Access Control Service must establish trust with the STS of all user companies, the application itself must trust only the STS in the Access Control Service. When the trust to the token is confirmed, the application uses the claims contained therein to determine the user's rights.
Access Control Service – . , , , . Access Control Service , , , , , , . , — Access Control Service. , .
Access Control Service WS-Trust WS -Federation. . , GUI , API .
, . STS , , Access Control Service .
, , , . , . , - (REST SOAP), - . , .
-, ( ) ? - , . , , ? Network Address Translation (NAT) – , IP-. NAT , ? , .
Service Bus – .9.
Fig. 9 Service Bus , .
, Service Bus ( 1), . Service Bus URI, , . , URI. c , . Service Bus , . , NAT , Service Bus . -, , — .
( ) , Service Bus ( 2). Atom Publishing Protocol, AtomPub . , ( 3). Service Bus, , . , , Service Bus , .
, Service Bus . IP, Service Bus, IP . , IP. Service Bus DMZ, « » . , Service Bus Access Control Service. , Service Bus STS Access Control Service.
, Service Bus, WCF. WCF , Java, SOAP HTTP. Service Bus.
, . Service Bus – .
Windows Workflow Foundation workflow . Workflow – , enterprise-. , WF- . , .
Workflow Service . - , WF 3.5, workflows, . – . ten
Fig. 10 Workflow Service WF-, HTTP Service Bus
WF workflow activities, . activity , , , . WF activities, Base Activity Library (BAL), Workflow Service BAL. activities. , , , HTTP Service Bus, . 10, Workflow Service activities , . Workflow Service activities XML — .
, . WF Workflow Service workflow, . , Code Activity BAL, activity .
Workflow Service, workflow Visual Studio. , , , , API. API. Service Bus, , Workflow Service, Access Control Service — STS.
WF- . , , workflow . , WF- , Workflow Service .
SQL Service , . — , , .. , , , SQL Data Services.
. , . , , . , . SQL Data Services — .
, , Internet- ; - . , , SQL Data Services , SQL . , .11.
.11 SQL Data Services authorities, , .
SQL Data Services . authorities, .11. authority , Microsoft DNS . Authority , . : , SQL Data Services . — authority . , . , , . SQL Data Services String, DateTime, Base64Binary, Boolean Decimal. MIME .
, . — , LINQ C#, SOAP REST. — ADO.NET Data Services, REST. , ==, !=, >, <, AND, OR NOT. SQL , ORDER BY JOIN.
, , . , , , . , — . , . , .
SQL Data Servies URI, Windows Azure storage service. , URI, :
, SQL Data Services .Net . , , REST — HTTP — SOAP . , , SQL Data Services , Access Control Service STS.
Microsoft SQL Data Services . , Windows Azure storage, SQL Data Service Storage SQL Server, . , — , . SQL Data Services, , , .
A detailed look at technology.
Getting an overview of the Azure Service Platform is an important first step; however, a deeper understanding of each technology is also needed. In this section, each member of the Azure family is covered in a little more detail.
Windows Azure
Windows Azure does two main things - it runs applications and stores their data. Accordingly, this section is divided into two parts, dedicated to each of them. The interaction of the parts is also very important, so its description will also be part of the section.
Running applications
In Windows Azure, an application typically has several instances, each of which executes part or all of the application code. Each instance runs on its own virtual machine. All virtual machines run under Windows Server 2008 and they are provided by a hypervisor specifically designed for use in the cloud.
At the same time, the application on Windows Azure does not see the virtual machine on which it runs. The developer cannot provide his virtual machine image so that Windows Azure works on it, but he doesn’t need to worry about supporting this copy of Windows. Instead, the CTP version allows developers to create .NET 3.5 applications with two types of tools - one is run by Web Role and the other is Worker Role. Figure 5 shows how this all works.
Fig. 6 In the CTP version, the Windows Azure application consists of the Web Role and Worker Role instances, each running on its own virtual machine.
')
As the name implies, an instance of Web Role accepts incoming HTTP (or HTTPS) requests via Internet Information Services (IIS) 7. Web role can be implemented using ASP.NET, WCF, or another .NET technology that works with IIS. As shown in fig. 6, Windows Azure provides a built-in load balancer that distributes requests between different instances of Web Role, which are parts of the same application.
Worker Role, on the other hand, does not accept requests directly from the outside world - it cannot have external incoming network connections and there is no IIS on its virtual machines. Instead, it receives the source data from the Web Role, usually through a queue in the Windows Azure storage. The result of the Worker Role instances can be written to the Windows Azure storage or sent to the outside world - outgoing network connections are allowed. Unlike Web Role instances that are created to process HTTP requests and turn off after processing a request, Worker Role can run endlessly - this is a background task. Due to this lack of specialization, Worker Role can be implemented using any .NET technology that supports the main () method (there are some limitations related to Windows Azure trust, which will be described below).
Each virtual machine hosting an instance of Web Role or Worker Role contains a Windows Azure agent through which applications interact with the Windows Azure factory, as in Figure 6. The agent is available through a specific Windows Azure API, through which applications can write to the log managed by Windows Azure, send warnings to their owner through the Windows Azure factory, etc.
Although the current state of affairs may change in the future, in CTP, each virtual machine has its own physical core of the processor. Thanks to this, the performance of each application can be guaranteed - each instance of Web Role and Worker Role has its own dedicated core. To increase the performance of the entire application, its owner can increase the number of running instances specified in the configuration file. The Windows Azure factory will then “overclock” new virtual machines, assign kernels to them, and launch more application instances. The factory also determines when the Web instance or Worker Role crashes and starts a new one.
Pay attention to the corollary of this: to ensure scalability, instances of Web Role do not have to store their state. Any information about the client-specific state should be written to the Windows Azure storage or sent to the client with cookies. The statelessness of the Web role is required for the load balancer built into Windows Azure. Since you cannot bind to a specific instance of Web Role, you cannot guarantee that different requests from the same user will be processed by the same instance.
Both Web Role and Worker Role are implemented using standard .NET technologies. But to transfer existing applications to Windows Azure without changes most likely will not work. On the one hand, the way to access data is different. Access to Windows Azure storage is implemented through ADO.NET Web Services, a relatively new technology that is not yet universally used in local applications. Similarly, Worker Role typically uses a Windows Azure storage queue to receive input data, that is, an abstraction that has no analogues for local applications. Another limitation is that Windows Azure applications do not work in a fully trusted environment. On the contrary, they are limited by what Microsoft calls Windows Azure trust, which corresponds to the average degree of trust that most ASP.NET hosters use.
For developers, creating Windows Azure applications on the CTP version is very similar to developing traditional .NET applications. Microsoft provides VS2008 project templates for creating Windows Azure Web Role, Worker Role, and a combination of both roles. Developers can use any .NET language to choose from (although it is fair to say that Microsoft’s focus on developing Azure was in C #). Also, the Windows Azure SDK includes the version of the Windows Azure environment that runs on the development computer. It contains the storage, the Windows Azure agent and everything else that is available to the application running in the cloud. A developer can create and debug his application in his local cloud similarity, and then distribute it to a real cloud when it is ready. At the same time, some things in the cloud are completely different. It is not possible to connect the debugger to an application in the cloud, for example, so that debugging of cloud applications is done mainly due to an agent managed by Windows Azure.
Windows Azure provides developers and other services. For example, a Windows Azure application can send a message with some kind of warning through a Windows Azure agent, which the agent then delivers via mail, instant message or other means to the specified recipient. If necessary, Windows Azure can determine the application crash and send a warning. The platform also provides detailed information about the consumption of resources by the application, including processor time, incoming and outgoing traffic, and storage.
Data access
Applications work with data in a variety of ways. Sometimes, all you need is simple blobs; other situations require a more structured way to store information. In some cases, all that is needed is a mechanism for exchanging data between different parts of the application. Windows Azure storage covers all of these requirements as shown in Figure 2. 7
Fig. 7 Windows Azure allows you to store data in blobs, tables, and queues that are accessed through REST over HTTP.
The easiest way to store data in Windows Azure is using blobs. As in Figure 7, there is a simple hierarchy: a storage account can have one or more containers, each of which stores one or more blobs. Blobs can be large - up to 50 GB each - and to make the transfer of blobs easier, each of them can be divided into sub-blobs. If there is a transmission error, the retransmission may start from the most recently transmitted subblock. Blobs can have metadata, such as information about where JPEG photos were taken, or data about a song composer for an MP3 file.
For some types of data, blobs are the most, but in many situations they are not sufficiently structured. To enable applications to work with data at the level of small structural units, Windows Azure storage provides tables. Despite the similarity of names, they should not be confused with relational tables. In fact, although they are called tables, the data in them is stored as a simple hierarchy of entities with properties. The table does not have a specific data schema; instead, properties can be of various types, such as Int, String, Bool, or DateTime. And instead of using SQL for working with data, the application accesses the data through a query language with LINQ syntax. A single table can be quite large, with millions of entities storing terabytes of data, and Windows Azure can split the table between many servers if it is necessary for performance.
Both blobs and tables are for data storage. The third method of storing data in Windows Azure storage — the queue — was created for a slightly different purpose. The main role of queues is to provide interaction between Web Role and Worker Role instances. For example, a user sends a request to perform a resource-intensive task through a web page implemented in Web Role. The instance of Web Role that receives this request writes a message describing the work to be performed, into a queue. An instance of Worker Role that is waiting for a message in the queue reads a new message and does the required work. He can return the results of work through another queue or in some other way.
Regardless of storage method — in blobs, queues, or tables — three copies are stored for all data in Windows Azure. This gives independence from falls, since the loss of one copy is not fatal. The system also guarantees integrity, so that the application reading the data that it just recorded will receive exactly what it expects.
Data in Windows Azure storage is available to both Windows Azure applications and applications running in some other place. In both cases, they are equally accessible to all three data storage methods, using REST conventions to identify and provide data access. Everything is called a URI and is available through normal HTTP operations. A .NET client can use ADO.NET Services or LINQ, and from, for example, a Java application, Windows Azure data is accessed via standard REST. For example, a blob can be read via HTTP GET to a URI formatted like this:
http: // <StorageAcount> .blob.core.windows.net / <Container> / <BlobName>
This is the identifier that is assigned to each storage account created, and it uniquely identifies the blobs, tables, and queues created in that account. and these are just the names of the container and blob that are addressed in the request.
Similarly, a request to a specific table is expressed via an HTTP GET request to a URI of the form:
http: // <StorageAcount> .table.core.windows.net / <TableName>? $ filter = <Query>
Here indicates the requested table, and the request to execute to this table.
Even queues are available to Windows Azure applications and external applications via HTTP GET to URIs:
http: // <StorageAcount> .queue.core.windows.net / <QueueName>
The fee for computing resources and storage on the Windows Azure platform is charged independently. This means that a local application can only use Windows Azure storage, accessing its data through REST as described. But it is still fair to say that the main purpose of Windows Azure storage is to work with data from Azure applications. And since the data is not available to Azure applications directly, they remain available even when the Azure application using them is not running.
The main purpose of platforms for applications, whether cloud or local, is the support of applications and data. Windows Azure provides an environment for both. Looking into the future, we can expect that applications that should have been local Windows applications will be built on this new cloud platform.
.Net Services
Running applications in the cloud is in itself useful, but infrastructure services provided in the cloud are no less useful. These services can use both local and cloud applications, and they solve tasks that would be much more difficult to solve in another way. This section examines Microsoft's offerings in this area: .Net Access Control Service, .Net Service Bus, and .Net Workflow Service, which are collectively known as .Net Services.
Access Control Service
Identity management is a fundamental part of most distributed applications. Based on user credentials, the application decides what is allowed to this user. To transfer this data, an application can use tokens defined using Security Assertion Markup Language (SAML). The SAML Token contains claims (claims), each of which represents specific information about the user. One statement may contain a user name, the other may indicate its role, such as “manager” or “CEO”, and the third one may contain its email. Tokens are created by applications known as security token service (STS), which digitally sign each token to confirm its source.
Once a client (for example, a Web browser) receives a user's token, it can provide it to the application. The application can now use assertions from the token to determine what is allowed to this user. At the same time, a couple of problems immediately appear:
- What if the token does not contain the statements that the application needs? With claims based authentication, each application can define a set of claims that users must submit. At the same time, it’s not a fact that the STS that created the token added to it exactly what the application needs.
- What if the application does not trust the STS that issued the token? An application cannot accept all tokens that are issued by any STS. Instead, an application usually has a list of trusted STS certificates, which gives the application the ability to check sign tokens. Only tokens from trusted STS will be accepted by the application.
Adding a new STS to this process can solve both problems. To ensure that the token contains the necessary assertions, this optional STS performs conversion of assertions. An STS can have rules that define the relationship between the source and final statements, and use these rules to create a token containing exactly the statements that the application needs. The solution to the second problem, commonly called identity federation, requires applications to trust this new STS. It is also required to establish a trusted relationship between this STS and the STS that issued the source token.
Adding an additional STS provides claims conversion capabilities and identity federation, both of which are very useful. But where should this STS be performed? You can use an STS that works within an organization — a service that some vendors provide. Why not run STS in the cloud? This will make it available to users and applications of any organization. It also shifts the concern for STS management and support to the service provider.
This is exactly what the Access Control Service offers: this is an STS in the cloud. To imagine how such an STS can be used, suppose an ISV that provides an application accessible via the Internet, with which users from different companies can work. Even if all companies can provide SAML tokens for their users, it is unlikely that they will contain exactly the set of statements that the application needs. Figure 8 shows how the Access Control Service solves this problem.
Fig. 8 Access Control Service provides rule-based claim conversion and identity federation.
Initially, the user application (in this example, the browser, but it could be a WCF client or something else) sends the access control user token (step 1). The service verifies the token's signature, verifies that the token is issued by a trusted STS. After that, the service creates and signs a new SAML token that contains the approvals required by the application.
To make such a transfer, the STS in the Access Control Service uses the rules defined by the owner of the application. For example, imagine an application that gives certain rights to any user who works as a manager in his company. Although each company may include a statement in its token, which indicates that the user is a manager, the statements of different companies may well be different. One company can use the string “Manager”, the other “Supervisor”, and the third in general is a special code expressed as an integer. To help applications work with all this diversity, the application owner can define a rule that converts all three of the above statements into one that contains the string “Decision Maker”. The life of the application after this becomes much simpler, since the work with the transformation of statements for it has already been done.
After creating a new token, Access Control Service returns a new token to the client (step 3), which then transfers it to the application (step 4). The application verifies the token's signature to ensure that it is issued by the STS in the Access Control Service. It should be noted that although the STS in the Access Control Service must establish trust with the STS of all user companies, the application itself must trust only the STS in the Access Control Service. When the trust to the token is confirmed, the application uses the claims contained therein to determine the user's rights.
Access Control Service – . , , , . Access Control Service , , , , , , . , — Access Control Service. , .
Access Control Service WS-Trust WS -Federation. . , GUI , API .
, . STS , , Access Control Service .
Service Bus
, , , . , . , - (REST SOAP), - . , .
-, ( ) ? - , . , , ? Network Address Translation (NAT) – , IP-. NAT , ? , .
Service Bus – .9.
Fig. 9 Service Bus , .
, Service Bus ( 1), . Service Bus URI, , . , URI. c , . Service Bus , . , NAT , Service Bus . -, , — .
( ) , Service Bus ( 2). Atom Publishing Protocol, AtomPub . , ( 3). Service Bus, , . , , Service Bus , .
, Service Bus . IP, Service Bus, IP . , IP. Service Bus DMZ, « » . , Service Bus Access Control Service. , Service Bus STS Access Control Service.
, Service Bus, WCF. WCF , Java, SOAP HTTP. Service Bus.
, . Service Bus – .
Workflow Service
Windows Workflow Foundation workflow . Workflow – , enterprise-. , WF- . , .
Workflow Service . - , WF 3.5, workflows, . – . ten
Fig. 10 Workflow Service WF-, HTTP Service Bus
WF workflow activities, . activity , , , . WF activities, Base Activity Library (BAL), Workflow Service BAL. activities. , , , HTTP Service Bus, . 10, Workflow Service activities , . Workflow Service activities XML — .
, . WF Workflow Service workflow, . , Code Activity BAL, activity .
Workflow Service, workflow Visual Studio. , , , , API. API. Service Bus, , Workflow Service, Access Control Service — STS.
WF- . , , workflow . , WF- , Workflow Service .
SQL Services.
SQL Service , . — , , .. , , , SQL Data Services.
. , . , , . , . SQL Data Services — .
, , Internet- ; - . , , SQL Data Services , SQL . , .11.
.11 SQL Data Services authorities, , .
SQL Data Services . authorities, .11. authority , Microsoft DNS . Authority , . : , SQL Data Services . — authority . , . , , . SQL Data Services String, DateTime, Base64Binary, Boolean Decimal. MIME .
, . — , LINQ C#, SOAP REST. — ADO.NET Data Services, REST. , ==, !=, >, <, AND, OR NOT. SQL , ORDER BY JOIN.
, , . , , , . , — . , . , .
SQL Data Servies URI, Windows Azure storage service. , URI, :
http://<Authority>.data.database.windows.net/v1/<Container>/<Entity>
, SQL Data Services .Net . , , REST — HTTP — SOAP . , , SQL Data Services , Access Control Service STS.
Microsoft SQL Data Services . , Windows Azure storage, SQL Data Service Storage SQL Server, . , — , . SQL Data Services, , , .
To be continued
Source: https://habr.com/ru/post/50063/
All Articles