The Azure SDKs are collections of libraries that are built to make it easier to use Azure services from your choice of language. These libraries are designed to be compatible, communicative, diagnosable, reliable, and idiomatic. In this blog, we will see some of the architectural choices made by Azure SDK. These new libraries focus on productivity. There are many forms in this productivity like:
Creating a raw network request to a service, rich type system is also offered by the client libraries that enables the features like code completion and compile-time type safety.
By support features like optional parameter and, method overload. It offers “progressive disclosure” which means we can start using the services without understanding all the service options. We can learn additional topics as per our application demands.
Azure also offers developer experiences and credential types for using them to simplify and authenticating against the different Azure services.
Further adding to this productivity feature, we can also build the distributed cloud application. In which distributed means our service can make a network call. And network calls are susceptible to failure.
For this issue, Azure SDK architecture includes a feature to help the customer self-diagnose issues. For example, when we are create an XxxClient object, the constructor requires the URL endpoint where the service requests are made. If no service responds at that endpoint, it should be easy to debug this. Because we’re using the URL we passed to our client library. Our XxxClient objects also support logging so we can easily capture what raw HTTP requests our app has made to a service and what response the service returned.
XxxClient Object, Pipelines, and Policies
We construct some XxxClient objects so that our application can make a call when we are using our client libraries. When you create an XxxClient, we pass it to the URL of the service endpoint, the credential we wish to use to authenticate with the service and some options. The credential and options are used to create an HTTP pipeline.
This HTTP pipeline adds behavior to an HTTP response and request. Each behavior is called a policy like a retry policy, a logging policy, etc. So, we have an authentication policy which applies our credential. Each policy can modify or change an HTTP request’s query parameter, and headers before the requests are sent over the wire.
Read More: Getting Started With Web Apps In Microsoft Azure
Not all policy objects modify or change an HTTP request. By performing operations such as logging, retry policies, timeouts, and downloading of response payloads, some policies simply impact the flow of a request or response.
The order of the policies is important because each policy changes the request and then forward that changed request to the other policy. For example, where policy between the XxxClient’s method and the retry policy executes once per logical service operation. On the other hand, the policy between the retry policy and the transport policy executes once per physical network operation.
We can implement our own policies for things like client-side caching, circuit breakers, mocking, fault injection, and much more.
Thread Safety and Performance
The goal of the Azure SDK is to ensure that a single XxxClient object can be used by multiple threads simultaneously without data corruption. Pipelines are immutable so that policies in them cannot be changed.
The policy types in the Azure SDKs are all immutable. That means the policy object’s state is immutable once each policy object is constructed using its specified retry, logging, and options. While another thread is attempting to use that same retry policy then it is impossible for one thread to change the retry policy’s option.
Multiple XxxClient objects can share the single pipeline to preserve the memory and system resources since the pipeline and its policies are immutable. Since policy objects are immutable, multiple threads can use the same pipeline object at the same time without taking any locks. So, our pipeline offers scalability and phenomenal performance for our application.
However, since pipelines or policies are immutable, if your application wants to make network requests with different behavior like retry policy options, different credential type, etc., then your code must create a new XxxClient object specifying the desired credential and options. Now, code using the new object gets the new desired behavior and using the original object experiences the same old behavior.
Authentication Policy
Authentication policies are mutable. There are three authentication policies:
- Authentication with basic: Using Basic Authentication, authenticate with back end service.
- Authentication with client certificate: Using a client certificate we can authenticate with a back-end service.
- Authenticate with managed identity: For API management service, authenticate with the managed identity.
Authentication with Basic
Use authentication-basic tag policy to authenticate with the back-end service using basic authentication. Corresponding to the credential provided in the policy, this policy sets the HTTP Authorization header.
<authentication-basic username="">
</authentication-basic>
Where authentication-basic is a root element and username and password is an attribute which is required.
Authentication with client certificate
Use authentication-certificate tag policy to authenticate with the back-end service using a client certificate. The certificate is identified by its thumbprint and needs to be installed into API management.
<authentication-certificate thumbprint="">
</authentication-certificate>
Where thumbprint and certificate-id are attributed, either thumbprint or certificate-id is required.
We can also set the property for getting the certificate in byte array using the body attribute.
Looking to Hire .Net Developer from Dedicated Team? Contact Now.
Authenticate with managed identity
Use authentication-managed-identity tag policy to authenticate with the back-end service using the managed identity. To obtain an access token from Azure Active Directory for accessing the specified resource this policy essentially uses the managed identity. After successfully obtaining the token, the policy will set the value of the token using the Bearer scheme in the Authorization header.
<authentication-managed-identity client-id="client Id of user-assigned identity" ignore-error="true|false" output-token-variable-name="token-variable" resource="resource">
</authentication-managed-identity>
Conclusion
In this blog, we have seen how Azure SDK architecture and its policies work. Azure SDK architecture’s main goal is to focus on our productivity while consuming Azure services. Azure services also ensure the high performance, low resource consumption, and scalability of our app. This architecture even allows for threads safe and dynamic updating authentication credentials without requiring any downtime of our app.
Top comments (0)