AWS Feed
Supporting development of Core WCF
Core WCF is a port of Windows Communication Framework (WCF) to .NET Core. Used to build service-oriented applications based on the .NET Framework, WCF enabled applications to asynchronously send data, packaged as messages, between service endpoints. WCF is a popular framework supporting many service-based use cases, including processing business transactions, reporting, monitoring, exposing workflows (implemented with Windows Workflow Foundation) as a service, and more.
Microsoft started the project to port WCF to .NET Core, and Amazon Web Services (AWS) joined in last year, to benefit both our customer bases. Contributions from AWS helped the project gain additional velocity and reach its first General Availability (GA) release after 21 months of development. AWS is now the second highest contributor to the project, outside Microsoft. This all helps both Microsoft and AWS customers with applications using WCF gain confidence in the potential to port those applications to .NET Core.
In this interview, I’m joined by Biroj Nayak, a Senior Software Development Engineer working in Amazon Elastic Compute Cloud (Amazon EC2), to talk about the open source Core WCF project and the contributions he’s been involved with.
Steve Roberts: Biroj, thanks for talking to me about the Core WCF project. To get started, tell us about your experience in getting up to speed and working on the project.
Biroj Nayak: Initially, it was challenging from a technical perspective as I was new to the internals of WCF, but slowly I was able to find traction and accelerate my understanding and then start contributing bug fixes and features.
To give you an example, one of the first pull requests I worked on—about 1.5 years ago—was to enable NetTCP on Linux in default mode, which turned out to be a simple bug in the original code. On Linux, we must create a Generic Identity object (as Windows Identity is native to Windows) and store that identity when the client and server are communicating over a Negotiate stream. It was a 20-30-line code fix, but it took me three weeks to determine root cause. This was partly because the code base was so large (for me at the time), and I didn’t have a full understanding of the underlying architecture. Also, as my primary development environment was on Windows, getting everything set up so that I could remotely debug on a domain-joined Linux environment took time.
Once I’d located the problem, a Microsoft WCF team member guided me in how I could best fix it. After that, I started solving a few more small bugs and features, making use of a direct consultation with Microsoft on a regular basis. After three or four months, I had enough confidence to start tackling a big feature.
Cross-collaboration has been super. Because this was the first .NET project where both Microsoft and AWS were involved in contributions, we needed to find a compatible sync and common ground between the teams, which was initially difficult due to different team priorities. Both teams agreed to have a bi-weekly meeting where we would discuss various pending items, release plans, and blocking issues. Eventually, that lead us to find a good rhythm and enabled both teams to make significant contributions.
I had experience of using WCF to build several APIs for customers but, as I mentioned, I was new to the internals of WCF. First, I needed to come up to speed on the initial ideas behind the Core WCF project and obviously develop my understanding of how the framework worked internally. Second, I needed to understand how to build a new component that was easily extendable yet still fit into the same architecture, with same API, as WCF but now also adopt async operations internally. We also, of course, wanted to improve some of the internal architecture as we adopted async operations.
The project members were super helpful in answering my questions and clarifying how things worked. That, in turn, helped me come up to speed quickly so that I could begin to contribute.
SR: Core WCF is one of the projects of the .NET Foundation, of which AWS is also a member. What’s been you experience working with the Foundation?
BN: The experience was great! Once we decided we wanted to collaborate on the Core WCF project, the .NET Foundation helped us set up a relationship with the Microsoft team already working on the project. The Foundation helped us connect with the main author of the project, enabling us to discuss the objectives of both companies for Core WCF in relation to helping our respective customers. The Foundation also played a role in helping promote the first generally available (GA) release. This promotion helped drive more traffic to the Core WCF project repository, making more customers aware of it. InfoQ also published an article on the project, which briefly mentioned that AWS was a contributor.
SR: What types of customers are Microsoft and AWS looking to help with the project?
BN: We were looking to help two types of customer. The first is customers with existing WCF-based applications that have been running for several years and who have spent quite a lot of effort in developing and maintaining those applications. Those customers were willing to adopt .NET Core and then containerize those applications to run on Linux or Windows, but they did not want to spend any further effort in rewriting or otherwise making significant changes to those applications. By ensuring that Core WCF maintained the API contracts in WCF, customers could more easily port those applications to .NET Core and not break compatibility with other consumers of their application’s services.
The second type of customer is those who are comfortable with WCF but who want to develop net-new applications using .NET Core and still use WCF features without compromise.
From an AWS perspective, customers with WCF-based services hosted on-premises or on Windows in EC2 are now able to port those applications to .NET Core and run them on Linux in EC2, or containerize them and run them on container services from AWS, such as Amazon Elastic Container Service, without the need to refactor or make other changes to their API. This approach helps those customers in their modernization journey to the cloud and provides license freedom.
SR: What versions of .NET Core does the project currently support?
BN: Core WCF officially supports .NET Core 3.1, across all platforms (Windows, Linux, and macOS). We have plans to support .NET 6 early in 2022.
SR: Can applications that have adopted .NET 5 also use the current release of Core WCF?
BN: It should work for certain scenarios, but we have not yet found enough time to test it for 0.1. For next release (0.2 GA) scheduled in July, the Core WCF would work for .NET 5. Also, after the next feature release, we will start planning on adding support for .NET 6, which we hope to support in January 2022.
SR: As a contributor, what area did you find to be the most technically challenging?
BN: The most challenging part was understanding the internals of multiple components that build the WCF framework. It’s a huge code base, so understanding all possible flows within a span of few months was impossible. I had to approach the code base on a case-by-case basis. The problem with case-by-case approach is you are not getting a holistic view of framework as such. So, I had to find a balance between both situations to be effective.
As an example where I needed to develop a more holistic view, WCF provides for various authentication mechanisms, such as at the transport layer only, transport plus authenticating client and server, and end-to-end authentication with message level encryption. Each of the transport layer authentication mechanisms has several sub-options, too.
When I was working on incorporating support for transport plus authenticating client and server, I noted that there were three options. The first was Basic Auth (UserName and PasswordToken), which relied mostly on SQL server behind the service to handle the authentication.
The second option was Certificate Auth, where the client validates the server using a server certificate and the server validates the client, again using a certificate. These used peer or chain trust via private/public key mechanisms.
And the third option was Kerberos for the client and server to validate when they belonged to same domain (using GSSAPI under the layer).
Finally, there was an option for federated authentication via token issuance, (for example, Active Directory Federation Service [ADFS] connecting to any cloud service provided via a token).
When I first approached the support for Basic Auth, I found the original code base supported flows across all transports and all sub-options. I found I needed to widen my scope to understand which part I needed to port for my first objective of adding Basic Auth, but at the same time build and understand the framework for other authentication mechanisms to incorporate later. The balance came in determining where I had enough context and understanding to start work on that first objective without boxing myself in from a technical perspective.
As porting of APIs progressed, I also needed to keep in mind that the current programming model in .NET Core is more advanced than what was available in the .NET Framework when WCF was created. Many APIs needed to be transformed to support async operations, yet still maintain backwards compatibility. Another of our primary goals, along with compatibility, was to ensure that Core WCF supported multiple platforms. This meant that many APIs that targeted the Windows platform needed disambiguation and to ensure they worked on other platforms, such as Linux.
An example of disambiguation is in how to perform role-based authorization for an API call. Windows environments use NT Identity, which is specific to Windows Security. Behind the scenes, it uses Active Directory roles to determine which roles the user has, and the associated permissions. On Linux, there is no concept of NT Identity. So, to determine roles we must call LDAP and, based on the output, configure the same result set for roles and permissions as we’d get for a Windows user account.
We also needed to ensure that customers adopting Core WCF could host those applications on Kestrel, the cross-platform web server for ASP.NET Core, as well as Internet Information Services (IIS), when containerizing.
SR: Which of your contributions are you most proud of?
BN: I think the one I’m most proud of was my pull request to add WSHttp, WSSecurity, and SecurityBinding features to enable Transport and Message Credentials. It was a very large PR with over 40K lines of code, which took me four to five months to get published, reviewed, and merged into mainline. I received approximately 1,000 comments over 15 iterations. However, after the PR was accepted, I felt much more comfortable debugging and navigating my way around the internals of the framework and gained new clarity on the architecture of the framework. This effort drove new insights into how we will extend and build new layers on top of the framework. This PR also helped make AWS the second highest code contributor after Microsoft.
SR: Core WCF is generally available (GA) as v0.1.0, and I guess the team is now looking to the future. Can you summarize what features the team is prioritizing for the next major release, and when that might be?
BN: We are currently targeting a release in July to add support for Transport Message credentials across NetTcp and BasicHttp protocols. Along with that, the current 1.0 GA has support for Windows Authentication using Kerberos across Linux and Windows, and we are planning to add support for role-based permissions across all platforms.
Anyone working with the original WCF today has possibly made use of configuration to define endpoint binding and behaviors. We have a plan to ingest that configuration data and transform it into equivalent Core WCF APIs for hosting, which is also planned for next immediate release.
We are also looking to add support for WSDL, WS-Trust/WS-Federation, a generic message queue, bindings such as Named Pipe, message-level security, and a new transport for gRPC. The best way to track the items added to each upcoming release is by watching the Core WCF milestones page. We’ve also opened a roadmap issue, which lists the proposed features that you can vote on.
SR: Some readers may be interested in getting involved. What do you think they need to know to be successful when getting started and working on the project?
BN: New contributors are always welcome. I would suggest beginning by looking for issues tagged as good first issue or by starting a discussion and tagging other developers already contributing to the project to help you come up to speed.
Once you’re comfortable, try and take ownership of a single area and build it end-to-end. There are still components present in WCF to build that are not yet available in Core WCF, and anyone interested in helping can find details in our feature roadmap issue. This all helps the project gain additional momentum and assists customers who are looking to adopt Core WCF but are currently blocked by missing components.
There is also a community sync meeting every month, and you can find details on GitHub. In these meetings, developers or customers bring their questions and we respond to them in the call.
Wrapping up
Thanks to Biroj for talking to me about this project and his contributions. Core WCF is an exciting project that benefits not just AWS customers but anyone who has applications based on the original Windows Communication Framework. We’re looking forward to future contributions and opportunities for collaboration. Be sure to check out the project’s roadmap and let the wider team know what features are important for you or that you’d like to help with.