"WCF Technology Insider" Translation 2: "WCF Technology Insider" introduction

General statement

Services are a major part of modern software architecture, and WCF is the platform for building a service program based on a Microsoft Windows system. WCF-authored services can interact with other vendors ' services (for example, IBM, BEA, and Novell), and WCF provides enough space for industry standards to evolve. For transport, WCF supports TCP/IP, HTTP, Microsoft Message Queuing (MSMQ), and named pipes. WCF also supports a range of ws-* specifications (read as ws-) protocols such as Ws-addressing, Ws-reliablemessaging (WS-RM), Ws-atomictransaction (Ws-at), ws-security , Ws-secureconversation, Ws-trust, and Ws-federation. Use WCF's application to send and receive SOAP messages and plain old XML messages. In the future, Microsoft will extend WCF support for new transport, protocol, and message structures. Microsoft has used WCF as a service IO system. Although uncertain in the future, it can be said that Microsoft will not use other technologies to replace WCF in the foreseeable future. Many products, such as Microsoft BizTalk Server and Windows Live Server, are compatible with WCF is a good proof.

The goal of this book is to provide readers with the knowledge necessary to use WCF design, development, and maintenance services. In my opinion, these tasks are beyond the individual WCF programming model. Success requires understanding the principles behind the service, the WCF Service programming model, and the WCF underlying architecture.

This kind of organization is not a new idea; it comes from past experience. When object-oriented trends become popular, developers and architects from process-oriented to object-oriented transformations need to learn more than just the syntax of a programming language. If process-oriented developers start using modern programming languages without understanding object-oriented objects, they can only use new languages to create process-oriented applications. Although the code can be compiled and run, it is not possible to use many of the features of the object-oriented language. This is my idea of learning from WCF developers about not being able to experience service-oriented advantages.

Some people think this method is a waste of time. In other words, the WCF team has successfully abstracted the underlying architecture of the message from the normal programming model, so there is no need to learn the underlying service-oriented patterns or how WCF implements these patterns. I do not agree with this view at all. This abstraction allows the WCF team to develop faster. But it has absolutely not freed developers and architects to go to service-oriented and understand how WCF works internally. Successful acceptance like C + + or Java object-oriented language requires developers to transform their thinking from process-oriented to object-oriented, and, in the same way, WCF learners need to improve their knowledge from component-oriented to service-oriented. If we fail, we will encounter many of the risks of lack of service-oriented features. Simply writing WCF programs and compiling and running is just one small step in long March. In the long run it is equally important to understand the WCF technical insider and understand the new programming pattern.

While we do not understand the characteristics of service-oriented architecture, we should know the underlying architecture of WCF. In other words, we should be aware of our platform. The common language Runtime (CLR) provides a supporting fact for this situation. The CLR team did a pretty good job of abstracting the garbage collector and the JIT compiler from the developers. As a result, we can write Microsoft. NET Framework applications without understanding or knowing how these subsystems work. For example, C + + developers migrating to C # will instinctively add a finalizer to each declared type without knowing the garbage collector. Unknowingly, this developer will increase the time allotted and the declaration cycle of these objects. For most C + + developers, simply saying "Don't do it" is not enough. They want to know why. Technically, adding a finalizer to a type is not a bug, it's really a lot of books and training courses that cost a lot of time to emphasize.

Similarly, knowing the WCF underlying architecture avoids wasting unnecessary effort on WCF, and developers can adjust their program capabilities to meet business requirements. For example, changing the binding's reliable message parameters in a constructor dynamically adjusts message orchestration between endpoints. WCF teams have abstracted these features and exposed them partially through bindings. This kind of message orchestration is sometimes necessary, and only developers who understand the message choreography can decide when to use this feature correctly. Further, to debug a program that uses reliable messages, you must master the configuration of reliable messages.

I want this book to strike a balance between service-oriented key concepts, the WCF Service programming model, and the WCF underlying architecture. This book will give you a rigorous vision of the insider of WCF technology, and you can design, build, debug, and maintain scalable and reliable distributed applications.

1. Audience-oriented:

This book is for architects, developers, and testers who want to learn how to design, write, or test WCF distributed applications. The previous chapters of this book are also helpful to business decision makers who want to learn more or evaluate WCF. This book is not suitable for junior developers or developers who have just learned. NET Framework programming. If so, I recommend that you read the Jeffrey Richter's CLR via C # (Microsoft Press, 2006) or Jeff Prosise Microsoft. NET programming before reading this book (Microsoft Press, 20 02). It would be helpful if you are a reader who is familiar with some distributed application development. But it's not necessary.