2. Windows Communication Foundation 101
2/4/ :30 PM
Windows Communication Foundation 101
Марат Бакиров
Эксперт по разработке ПО
Microsoft Rus, Ekaterinburg
© 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

3. Содержание
Принципы SOA
Архитектура WCF
Контракты
Привязки

4. От объектов к сервисам Объектно-ориентированные Компонентные
Полиморфизм
Инкапсуляция
Наследование
1980s
Компонентные
Интерфейсы
Динамическая подгрузка
Метаданные в рантайме
1990s
Speaker Notes
For years, software development has focused on how to best reuse the code that we write. Ultimately, people and businesses want long-term return on their short-term investments in code. How do we do this?
We’ve seen 3 waves of advancement in this movement in recent decades:
1980s and Object-Orientation: Object-oriented development promised the idea of building reusable abstractions (called classes) that we could then inherit from in order to reuse the base class functionality. This shift from simple procedural-based code brought with it a lot of benefits including polymorphism (the ability to dynamically bind types at runtime), abstractions that included both state and behavior, and encapsulation (controlling which parts of the code the external world can access). However, Object-Orientation by itself didn’t facilitate the dynamic evolution of software at runtime. Once an application was built, it was static. There wasn’t an easy way to infuse new code into an application.
1990s and Components: Component-based development helped us overcome this challenge. It forced the developer to think about the external facing interface of the application. This enabled us to build systems that dynamically load and bind to new functionality at runtime (an application discovers new components after it has been built) and introduced the notion of an application as a growing/evolving organism. To facilitate dynamic loading, we saw a big emphasis on runtime metadata. In the past, you couldn’t easily discern application capabilities since there was very little/rudimentary metadata information stored as part of the application. Whereas C and C++ programs from 1980s were these relatively opaque collections of code, component-based applications of the 1990s enabled runtime inspection of code to determine what a particular component supported. This introduced the notion of self-describing systems. But while this metaphor worked really well on a single machine (using method invocation on an object reference), we hit scaling problems when we tried to stretch it out and apply it as the substrate for distributed software integration (across machines, etc).
2000s and Service-Orientation – With Service-Orientation, we retain the benefits of self-describing applications, explicit encapsulation, and dynamic loading of functionality. What changes is the metaphor with which we accomplish it. Instead of using method invocation on an object reference, we shift the conversation to that of message passing – a proven metaphor for scalable distributed software integration. In addition, to support dynamic loading of service-based functionality, we use schema to describes the structure of messages, behavioral contract to define acceptable message exchange patterns, and policy to define service semantics.
Simplifying service-oriented development is one of the biggest bets we’re making in "WCF". "WCF" takes the service-oriented concepts of message passing, schema, contract, and policy, and implicitly applies it to all of the services we build. As such, "WCF" provides you with
Сервис-ориентированные
Сообщения
Схема+контракт
Политики
2000s

5. Ориентация на сервисы: 4 принципа
2/4/ :30 PM
Четкие границы
Пересечение границ– четко определено
Пересечение границ стоит ресурсов
Сервисы самостоятельны
Мы должны понимать что используемый нами сервис будет развиваться и у нас нет контроля над этим
Сервисы управляются и разрабатываются независимо
Сервис, который мы используем может быт недоступен!
Сервисы предоставляют схему и контракт, но не код
Сервисы взаимодействуют по контрактам, которые не меняются.
Сервисы предоставляют только контракт, реализация может меняться.
Совместимость сервисов определяется политикой
Безопасность, гарантированная доставка , и прочее определяется политикой.
Требования и возможности сервиса также предоставляются политикой.
WCF – Первая система построенная полностью на идеологии SOA, но в то же время очень гибкая.
Speaker Notes
Tenet 1: Boundaries are Explicit. Based on the underlying concept of encapsulation, this tenet specifies the publishing and consumption of functionality as sets of services that abstract their underlying implementation. With Indigo, the attribute-based programming enables developers to explicitly define external service contracts. Without explicitly defining these, nothing within the class will be exposed publicly. In other words, Indigo provides an opt-in model for explicitly defining service boundaries.
Each service interaction is boundary crossing
Crossing service boundaries have costs
SO makes interaction formal intentional and explicit
Tenet 2: Services are Autonomous. Autonomy means we design the system to support the inevitable evolution of the service’s implementation over time. As we build our services, we need to assume that their internal implementation will evolve (be versioned) over time and that our services as well as the services on which we depend could change location at (almost) any time.
System topology evolves
There is no control over evolution
Services are deployed managed and versioned independently
Services should not fail when dependent services ae unavailable
Tenet 3: Services share schema and contract, not class. For those of you who are familiar with ASMX - this is exactly how ASMX works: The service publishes a contract that clients use to generate their own code to call the service. No types are shared between service and its clients by default. In addition, neither Service requires knowledge of each others’ internal workings in order to exchange data – they only need the published schemas & contracts
Services interact with schema/contracts
Services do not combine data and behaviour, they expose data and behaviour independent on implementation.
Contract and schemas remain stable over time.
Tenet 4: Service compatibility is determined based on policy. The services communicate through dynamically negotiated communications channels that support the necessary semantics (security, reliability, etc). Service policy statements created automatically based on configuration, class attributes, and method signatures. Client channels automatically configured via retrieved service policy. By “name” means that we reference a well known name in Policy that represents a whole specification of behavior that needs to be used when talking to this endpoint.
Policy separates interactions from the constraints on interactions
Capabilities and requirements are expressed in terms of policy expressions
"Indigo" is the first programming model built from the ground up to provide implicit service- oriented application development.
© 2005 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

6. Архитектура Contract Binding Address Speaker Notes
Here’s a high-level view of the WCF architecture. At the top is your code, the code you’re developing in Visual Studio or your environment.
<click>The WCF service uses an address (like “ a binding that determins how the service communicates, and a contract that specifies what operations the service can carry out.
<click>The binding consists of modules that specify how the service communicates, such as
<click> which transport the service communicates on, whether http, tcp, etc
<click> what encoder the service uses, like a text/XML encoder, a binary encoder, or a custom encoder
<click> what kind of security the service requires
<click> and any other communication requirements.
<click> When a message comes into the service, it is taken off the transport
<click> decoded with the proper decoder
<click> security is negotiated away
<click> and then the message is dispatched to the appropriate part of your code.
Binding
Address

7. Компонентная архитектура
2/4/ :30 PM
Модель сервиса
Модель сообщений
CLR Type Integration
Transaction Behavior
Instancing Behavior
Reliable Messaging
Security
Channel
Custom Channel
HTTP Transport
TCP Transport
Поведение
Каналы
Metadata Behavior
Instancing Behavior
Security
Channel
HTTP Transport
Error Handling Behavior
Transaction Behavior
Reliable Messaging
TCP Transport
WCF применяет компонентую архитектуру.
У нас имеются транспортный слой, слой кодирования (binary/text), слой безопасности и дополнительные слои.
Фактически, binding – это набор компонентов.
Например, мы могли бы выбрать http транспорт , добавить туда безопасность (https/ssl), или взять tcp транспорт или даже произвольный канал.
Я видел даже протоколы взаимодействия по pop3/smtp!
После чего мы выбираем необходимое нам поведение сервиса – например. Необходимость подключения распределенных транзакций, режим создания обьектов сервиса (instancecontextmode - session mode – percall, single, persession)
Concurrency Behavior
CLR Type Integration
MSMQ Integration
Named Pipes
Custom Behavior
Throttling Behavior
Custom Channel
Queue Transport
© 2005 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

8. Взаимодействие сервисов
Сервис 1
Сервис 2
Клиент
Сообщение
Сервис
Сообщение
Speaker Notes:
Let’s start by discussing how services communicate. We won’t be discussing any particular network topology (decentralized, hub and spoke, etc), as that’s specific to your application scenario. Instead, we’ll go over how two services communicate, and you can apply that information to the right topology for your application.
Services communicate by sending messages to one another.
<Click>
One service initiates the communication by sending the message. This is the “caller”, or the “client”.
The other service receives that message, processes it, and reacts to it by executing some code. For example:
The caller could be part of a voting application. It sends a message to a centralized service that instructs the service to increment the number of votes for a particular candidate by 1 (or 2-4 if you’re in Florida).
The caller could be part of a Web-based online store application that sends a message to an order processing service with shopping cart information, which causes the service to process a user’s order.
The caller could be part of the order processing pipeline, without any UI. The caller has just validated a credit card number, so it sends a message to another service instructing that service to continue processing the order.
Of course, this doesn’t have to be a one-way conversation. The service could respond to the caller, or initiate communication with another service based on the caller’s message.
This is the basic communication model for WCF.
Transition:
In order for two services to interact, the caller needs to establish a connection to the service. How is that done?

9. Точки взаимодействия (endpoints)
Клиент
Сервис
Endpoint
Endpoint
Endpoint
Сообщение
Speaker Notes:
Services define endpoints and expose these endpoints so that clients can connect to them.
<Click>
An endpoint is similar to an interface on an object in object-oriented programming. Objects expose interfaces, and a client walks up to the object and picks an interface with which to communicate. The client doesn’t need to know anything about the implementation details of the object; it just uses the interface to access the object. In the same way, an endpoint on a service contains all the information a client needs to communicate with the service.
Because we want our WCF services to be loosely coupled, we don’t want the caller to be dependent on any implementation details of the service. Instead, the caller manufactures a copy of the endpoint (we call this a proxy) on its side. When the caller wants to communicate to the service, it makes local calls to its proxy; the proxy endpoint then takes care of communication with the service endpoint. Services only communicate through these endpoints, which means that the implementation details of a service can change without breaking any communication patterns.
A service can define multiple endpoints. This enables you to specify different ways to communicate with a given service through different endpoints. For example:
One endpoint might specify HTTP/text-based communication for traversing the corporate firewall and maximizing interoperability.
Another endpoint might specify TCP/binary-based communication for optimized communication within the firewall.
Transition:
Let’s examine the components of an endpoint.

10. Address, Binding, Contract Адрес, Связывание, Контракт
Клиент
Сервис A B C A B C
Сообщение A B C
Speaker Notes:
Each endpoint has three parts: an Address, a Binding, and a Contract, or “the ABCs”.
Addresses are the where of services. They define the location of the service, like “
Bindings are the how of services. They describe how the service communicates through that endpoint: what transport (HTTP, TCP, UDP, etc) it uses, what encoding (Text, Binary), and any additional capabilities such as security and reliable messaging that are available at a given endpoint. These communication details are usually separate from what the service actually does, and are often the concern of the person deploying the application, not the developer. That’s why bindings in WCF enable you to write and compile your entire WCF service separately from configuring how that service communicates. This provides a lot of flexibility after deployment: you can fundamentally change the way your app communicates without recompiling and redeploying it.
Contracts are the what of services. This is what we care most about as developers. Contracts define what the service actually does – its operations, the methods it can carry out, etc.
Transition:
So endpoints define everything a client needs to communicate with a service, but how does a caller find information about the various endpoints?
Address
Binding
Contract
(Где)
(Как)
(Что)

11. Метаданные Клиент Сервис Metadata A B C A B C Сообщение A B C
Speaker Notes:
How do we find out this sort of information with today’s component technologies? Consider a DCOM component. We can query a DCOM component and get a typelib that defines the interface to that component.
Similarly, WCF services expose metadata that completely describe the endpoints of that service.
The metadata describes the service contract in the form of XSD and WSDL
It describes the binding as WS-Policy
And it exposes the address of that service
When you develop a WCF service, WCF generates the metadata for the service so that any clients who want to call it (a .NET app, a Java app, etc) can download the metadata and use it to initiate communication with a service endpoint.
Transition:
There’s one more important piece of the WCF architecture, and that’s the local behavior of a service.

12. Поведение Клиент Сервис Metadata Message A B C Bv Bv Bv A B C A B C Bv
Speaker Notes:
The system semantics of a service are called behaviors. Behaviors are usually internal to the service.
Some examples of behaviors:
Instancing – what the instancing model is -- should a new instance of the service be created for each incoming call, or should a single instance of a service process all incoming calls, etc?
Concurrency – whether the service is single- or multi-threaded
Throttling – whether there’s a limit on the maximum number of messages, instances, or threads for your service.
Transition:
Now that we know all the pieces of the architecture, what happens at runtime?

13. Выполнение – (хостинг)
Metadata
Клиент
Сервис A B C Bv Bv Bv A B C
Сообщение A B C Bv
Speaker Notes:
WCF services are just managed code, so a WCF service can be hosted anywhere – in a Windows Form, a managed console window, IIS, etc., Windows Service
One hosting mechanism is a class called the ServiceHost. The ServiceHost looks at the configuration of your service and generates all the infrastructure needed to expose the service endpoints and publish the service’s metadata.
To expose a service, you simply create a new ServiceHost and open it. Or, if you deploy your service into IIS, it’ll open for you.
The caller examines the service metadata and uses it to generate a proxy on the caller side which communicates with a service endpoint.
One new interesting feature we have in vista and longhorn is WAS.
Transition:
Let’s see how we can use these basic concepts in code.
Proxy
ServiceHost<T>()
Hosting Environments
WAS
IIS
.exe
Windows Service
DllHost

14. Демонстрация Основы 2/4/2018 10:30 PM
© 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

15. Контракты Speaker Notes:
Now that we’ve seen the core concepts at a high level, let’s drill into contracts, bindings, and behaviors.

16. Типы контрактов Service Data Message
Описывает операции, выполняемые сервисом. CLR тип соответсвует WSDL.
Service
Структура данных. CLR тип соответсвует XSD.
Data
Speaker Notes:
Contracts are the “what” of the WCF service. They define the interfaces, methods, and data you choose to expose as an WCF service. In the demo we just saw, we used a service contract to define the service we were exposing on the wire and what operations it could carry out.
There are also a couple of other kinds of contracts and we’ll drill into each:
Data contract: Defines how to serialize complex data structures like classes on the wire. WCF knows how to serialize simple types like ints, but for complex types, you need a Data contract.
Message contract: Defines the structure of the message on the wire. By default, WCF messages are sent across the wire in a SOAP envelope which has a header and a body. The message contract specifies what goes in the header and what goes in the body. We’ll talk about why this is important in a minute.
Transition:
Let’s look at each of these contracts in more depth starting with the service contract.
Структура сообщений. CLR типа соответсвует SOAP сообщению.
Message

17. Контракт сервиса [ServiceContract] public interface ICalculator {
[OperationContract]
ComplexProblem SolveProblem (ComplexProblem p); }
Speaker Notes:
As we saw in the demo, we can add a ServiceContract attribute to an interface that signifies that the interface should be exposed on the wire as a WCF service.
WCF has an opt-in model for exposing services, so even though you decorated the interface name with the ServiceContract attribute, you also have to explicitly decorate any methods you want to expose as a part of that service with the OperationContract attribute.
Transition:
Like many attributes, ServiceContract and OperationContract can accept parameters. Let’s take a look at one.

18. Контракт сервиса: OneWay
[ServiceContract]
public interface IOneWayCalculator {
[OperationContract(IsOneWay=true)]
void StoreProblem (ComplexProblem p); }
Speaker Notes:
In this code snippet, we see the OperationContract attribute accepting an IsOneWay parameter.
IsOneWay determines the messaging pattern for the service.
Without the IsOneWay parameter, this method defaults to a request-reply pattern. It receives a request from a client and sends a reply associated with that request.
With the IsOneWay parameter, this method acts in a simplex (message-oriented) manner. It receives a request and doesn’t send any reply.
This gives you an easy way to decouple services. You may have had to change toolsets to get this sort of message pattern change in the past, but with WCF the difference between one-way message-oriented messaging and request-reply is a single parameter on the attribute.
Transition:
In addition to enabling you to easily use simplex messaging, WCF also offers full duplex messaging.

19. Контракт сервиса: Duplex
[ServiceContract(CallbackContract=
typeof(ICalculatorResults)]
public interface ICalculatorProblems {
[OperationContract(IsOneWay=true)]
void SolveProblem (ComplexProblem p); }
public interface ICalculatorResults
void Results(ComplexProblem p);
Анекдот
-Папа, сколько будет дважды два?
-А мы покупаем или продаем?
Speaker Notes:
WCF supports true duplex (asynchronous) messaging. Services can “call back” to callers using a duplex (or two-way) contract. This is an example of a simple duplex contract.
The CallbackContract parameter on the service’s ServiceContract links together the contract on the service side with the contract on the caller side.
Here we’re looking at the service code. The service implements the ICalculatorProblems service contract. The caller implements a separate contract called ICalculatorResults in its code.
The CallbackContract parameter here tells the service to be prepared to receive messages from an service of type ICalculatorResults. In order to properly format messages and call methods on the caller’s ICalculatorResults contract, the service needs to create a proxy for the caller’s ICalculatorResults.
That’s what we see here – we have the service interface decorated with the CallbackContract parameter on the ServiceContract attribute, and beneath it we have the proxy code for the ICalculatorResults contract on the caller’s side.
There may be situations where the service and the caller implement identical contracts, such as peer-to- peer applications. If the contracts are identical, there is no need to define the proxy contract. The service contract can simply reference itself in the CallbackContract parameter.
Transition:
When we’re communicating between services, how do we communicate the fact that something has gone wrong (that an error has occurred)?

20. Контракт данных [DataContract] public class ComplexNumber {
[DataMember] public double Real = 0.0D; [DataMember] public double Imaginary = 0.0D;
public ComplexNumber(double r, double i) { this.Real = r; this.Imaginary = i; } }
Speaker Notes:
You need a data contract when you’re sending complex types between services. WCF already knows how to send simple types like ints, doubles, strings, etc, but for more complex types like classes, you need to tell the service how to serialize that data to the wire.
Data contracts describe the structure and type of data sent across the wire, mapping a complex type to an XML Schema.
Like service contracts, data contracts are explicitly opt-in, meaning that you must explicitly call out which members of a class or struct are serialized with the DataMember attribute.
Transition:
Let’s move on to the last kind of contract, the message contract.

21. Контракт сообщений [MessageContract] public class ComplexProblem {
[MessageHeader] public string operation;
[MessageBody] public ComplexNumber n1;
[MessageBody] public ComplexNumber n2;
[MessageBody] public ComplexNumber solution;
// Constructors… }
Speaker Notes:
By default, a WCF message is sent as a SOAP envelope with a header and a body.
The MessageContract attribute lets you specify which parts of a message are included in the header and which are included in the body.
This is important because the message body is reserved for the destination application; any intermediaries, like routers or load balancers, can only look at the message header. That means that any information an intermediary needs should go in the message header.
For example, if I define a calculator service that requires load balancing across its various operations, I might include the operation information in the header. An intermediary router would examine the header and send add/subtract operations to one place and multiply/divide to another.
Using message contracts is just like using the other contract types we’ve seen – the MessageContract attribute indicates what’s in the message, and MessageHeader and MessageBody denote what data goes where.
Transition:
We’ve now discussed the three types of contracts, which define the what of services. Now let’s talk about the how of services: Bindings.

22. Демонстрация Контракты 2/4/2018 10:30 PM
© 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

23. Bindings (привязки) Speaker Notes:
Bindings specify the communication stack a service uses to send and receive messages.

24. Элементы привязки Транспорт Кодировка Security Reliability Протокол
HTTP
Text
TCP
Binary
WS-*
HTTP
Text
TCP
Binary
WS-*
Speaker Notes:
We specify that communication stack by choosing the transport, the encoding, and any additional protocols we want to use like security or reliable messaging.
You can think of a bindings as simply a combination of these modules: transport, encoding, and additional protocols.
When a message is received by a service, messages are pulled off the transport, decoded by the decoder, and processed by the protocol stack before going to code.
WCF ships with a number of preconfigured standard bindings.
<Click>
For instance, here’s one of our standard bindings, called BasicHttpBinding. It includes the HTTP Transport and an XML/Text Encoder.
If we wanted to add standard security and reliable messaging, we could use the WsHttpBinding, which adds default WS-* security and WS-* reliable messaging.
Or if we wanted to do more efficient, non-interoperable communication, we could use the NetTcpBinding. It uses the TCP transport and a binary encoder.
Another thing to note is the “custom” option for each of these modules. Each of these communication modules is an extensibility point. You could develop your own transport, encoder, or protocol, and simply plug that into the binding.
Transition:
Let’s take a look some of the standard bindings we ship with WCF.
Pipes
MTOM
Custom
Custom
Custom
MSMQ
Custom
Custom

25. T = Transport Security | S = WS-Security | O = One-Way Only
Стандартные привязки
Interop
Security
Session
Transx
Duplex
Stream
BasicHttpBinding BP T
WsHttpBinding WS TS
WsDualHttpBinding WS TS
NetTcpBinding TS O
Speaker Notes:
Each of the standard bindings defines a differently configured communication stack for our services. They span a variety of options: some are interoperable, some provide default security, some allow for sessions, etc.
These standard bindings are designed to solve most application needs out of the box.
Transition:
Bindings are also one of the ways WCF services integrate with applications you’ve built on existing Microsoft technologies. Let’s take a closer look.
NetNamedPipesBinding TS O
NetMsmqBinding TS
NetPeerTcpBinding TS
T = Transport Security | S = WS-Security | O = One-Way Only

26. Взаимодействие с существующими технологиями
ASMX/WSE3
WS-* Protocols
WCF
COM+/ES
Moniker
WS-* Protocols
WCF
Speaker Notes:
WCF is wire-interoperable with WSE3 and ASMX using the WsHttpBinding (for WSE3) and the BasicHttpBinding (for ASMX).
WCF offers a tool that creates a stub for a COM+/Enterprise Services application so that WCF services can communicate with the application using any standard binding.
For MSMQ, WCF offers the NetMsmqBinding that interops with today’s MSMQ applications.
Transition:
Bindings let you separate configuring how a service communicates from developing the service itself. Where do you specify the binding?
MSMQ
MSMQ Protocol
Moniker
WCF

27. Привязки в файле конфигурации
<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns=
"
<system.serviceModel>
<services>
<service type="CalculatorService">
<endpoint address=“
binding="basicHttpBinding"
contractType="ICalculator" />
</service>
</services>
</system.serviceModel>
</configuration>
Speaker Notes:
Bindings are typically defined in an XML configuration file that accompanies an application.
Here, we’ve specified the address, the binding, and the contract in the configuration file, rather than in code. We’re using the BasicHttpBinding, a standard binding that ships with WCF. We could also have used a custom binding.
Transition:
What do you do if you want to customize a pre-existing binding?

28. Конфигурация привязок
<endpoint address=“ binding="basicHttpBinding" bindingConfiguration="Binding1" contractType="ICalculator" />
<bindings> <basicHttpBinding> <binding configurationName="Binding1" hostNameComparisonMode="StrongWildcard" sendTimeout="00:10:00" maxMessageSize="65536" messageEncoding="Text" textEncoding="utf-8" </binding> </basicHttpBinding> </bindings>
Speaker Notes:
You can configure a pre-existing binding by simply adding a new section to your endpoint definition called bindingConfiguration.
bindingConfiguration references another section of config where you can tweak the settings of many of the properties associated with a binding, such as changing timeout values, or throttling the maximum size of a message.
Transition:

29. Custom Bindings <bindings> <customBinding>
<binding configurationName="Binding1">
<reliableSession bufferedMessagesQuota="32" inactivityTimeout="00:10:00" maxRetryCount="8" ordered="true" />
<httpsTransport manualAddressing="false" maxMessageSize="65536" hostNameComparisonMode="StrongWildcard"/>
<textMessageEncoding maxReadPoolSize="64" maxWritePoolSize="16" messageVersion="Default" writeEncoding="utf-8" />
</binding>
</customBinding>
</bindings>
Speaker Notes:
If you want to start from scratch, you can create a custom binding.
Within an endpoint definition, you simply specify that the binding is a customBinding, and then choose each module you’d like to include in that binding.
In addition to letting you choose your own communication stack, you could also include your own custom modules. So if your application needs to communicate with custom transports or use a custom encoder, you can build those modules and plug them into the binding configuration here.
Most importantly, what changes in your code if you do this? Nothing!
As a best practice, our customers often ask senior developers or architects to define a set of bindings that the rest of the team can use. That way, the rest of the team doesn’t need to learn the details of binding configuration.
Transition:
Let’s revisit our demo application and try using a configuration file.

30. Демонстрация Bindings 2/4/2018 10:30 PM
© 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

31. Подведем итоги и ссылки
Первая система изначально построенная на технологии SOA
Вопросы?

32. 2/4/ :30 PM
© 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
© 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.