Applying Service-Oriented Architectures with .NET

The term Service-Oriented Architecture (SOA) refers to a modular architecture where interaction between system components is achieved through communication. This approach has evolved for years and is now the basis of all communication between systems over the Internet. SOA allows applications from different organizations to exchange data and transactions automatically. Besides that, it allows organizations to offer services on the Internet. For instance, in a banking application, SOA can allow separate services for account management, transaction processing, and customer support to communicate seamlessly. More than that, it can enable suppliers to access customer support directly.

Moreover, as we discussed in Chapter 11, Applying a Microservice Architecture to Your Enterprise Application, communication-based interaction solves the binary compatibility and version mismatch problems that inevitably appear in complex systems made...

Technical requirements

This chapter requires the Visual Studio 2022 free Community edition or better with all the database tools installed.

All the concepts in this chapter will be clarified with practical examples based on the WWTravelClub book use case, located in Chapter 21, Case Study. You will find the code for this chapter at https://github.com/PacktPublishing/Software-Architecture-with-C-Sharp-12-and-.NET-8-4E.

Understanding the principles of the SOA approach

Like classes in an object-oriented architecture, services are implementations of interfaces that, in turn, come from a system’s functional specifications. Therefore, the first step in service design is the definition of its abstract interface. During this initial stage, you might have two approaches:

• Define all the service operations as interface methods that operate on the types of your favorite language (C#, Java, C++, JavaScript, and so on) and decide which operations to implement with synchronous communication and which ones to implement with asynchronous communication.
• Create the contract first in an interoperable format. In this approach, you can use definition files using patterns like OpenAPI, Protobuf, WSDL, and AsyncAPI without touching the programming language with which the services will be developed, using some tools to help.

The interfaces that are defined in this initial stage will not...

SOAP web services

The Simple Object Access Protocol (SOAP) allows both one-way messages and request/reply messages. Communication can be both synchronous and asynchronous, as explained in Chapter 1, Understanding the Importance of Software Architecture, and Chapter 2, Non-Functional Requirements, but if the underlying protocol is synchronous, such as in the case of HTTP, the sender receives an acknowledgment saying that the message was received (but not necessarily processed). When asynchronous communication is used, the sender must listen for incoming communications. Often, asynchronous communication is implemented with the Publisher/Subscriber pattern, which we described in Chapter 6, Design Patterns and .NET 8 Implementation.

Messages are represented as XML documents called envelopes. Each envelope contains header, body, and fault elements. The body is where the actual content of the message is placed. The fault element contains possible errors, so it is the way exceptions...

REST web services

REST services were initially conceived to avoid the complex machinery of SOAP in simple cases, such as calls to a service from the JavaScript code of a web page. Then, they gradually became the preferred choice for complex systems. REST services use HTTP to exchange data in JSON or, less commonly, in XML format. Simply put, they replace the SOAP body with the HTTP body, the SOAP header with the HTTP header, and the HTTP response code replaces the fault element and furnishes further auxiliary information on the operation that was performed.

The main reason for the success of REST services is that HTTP already offers most of the SOAP features natively, which means we can avoid building a SOAP level on top of HTTP. Moreover, the whole HTTP machinery is simpler than SOAP: simpler to program, simpler to configure, and simpler to implement efficiently.

Moreover, REST services impose fewer constraints on the clients. Type compatibility between servers and clients...

How does .NET 8 deal with SOA?

WCF technology has not been ported to .NET 5+ and there are no plans to perform a complete port of it. Part of the source code was donated, and an open-source project started out of it. You can find information about this project at https://github.com/CoreWCF/CoreWCF. Instead, Microsoft is investing in gRPC, Google’s open-source technology. Besides, .NET 8 has excellent support for REST services through ASP.NET Core.

There is a tool developed by Microsoft to help you with the migration of WCF applications to the latest .NET. You can find it at https://devblogs.microsoft.com/dotnet/migration-wcf-to-corewcf-upgrade-assistant/.

The main reasons behind the decision to abandon WCF are as follows:

• As we have already discussed, SOAP technology has been overtaken by REST technology in most application areas.
• WCF technology is strictly tied to Windows, so it would be very expensive to reimplement all its features from...

Summary

In this chapter, we introduced SOA, its design principles, and its constraints. Among them, interoperability is worth remembering.

Then, we focused on well-established standards for business applications that achieve the interoperability that is needed for publicly exposed services. Therefore, SOAP and REST services were discussed in detail, along with the transition from SOAP services to REST services that has taken place in most application areas in the last few years. Then, REST service principles, authentication/authorization, and documentation were described in greater detail.

Finally, we looked at the tools that are available in .NET 8 that we can use to implement and interact with services. We looked at a variety of frameworks for intra-cluster communication, such as .NET remoting and gRPC, and tools for SOAP- and REST-based public services.

Here, we mainly focused on REST services. Their ASP.NET Core implementations were described in detail, along with...

Questions

1. Can services use cookie-based sessions?
2. Is it good practice to implement a service with a custom communication protocol? Why or why not?
3. Can a POST request to a REST service cause a deletion?
4. How many dot-separated parts are contained in a JWT bearer token?
5. By default, where are the complex type parameters of a REST service’s action methods taken from?
6. How is a controller declared as a REST service?
7. What are the main documentation attributes of ASP.NET Core services?
8. How are ASP.NET Core REST service routing rules declared?
9. How should a proxy be declared so that we can take advantage of .NET HttpClientFactory class features?

Further reading

• This chapter mainly focused on the more commonly used REST service. If you are interested in SOAP services, a good place to start is the Wikipedia page regarding SOAP specifications: https://en.wikipedia.org/wiki/List_of_web_service_specifications. On the other hand, if you are interested in the Microsoft .NET WCF technology for implementing SOAP services, you can refer to WCF’s official documentation here: https://docs.microsoft.com/en-us/dotnet/framework/wcf/.
• This chapter mentioned the AMQP protocol as an option for intra-cluster communication without describing it. Detailed information on this protocol is available on AMQP’s official site: https://www.amqp.org/.
• More information on gRPC is available on Google gRPC’s official site: https://grpc.io/. More information on the Visual Studio gRPC project template can be found here: https://docs.microsoft.com/en-US/aspnet/core/grpc/. You may also want to check out gRPC-Web at https...