| Table of Contents |
|---|
...
An endpoint is composed of 4 elements (address, binding, contract and behavior) which collectively describe what the service can do, in what format the data will be provided and how clients can reach the service. In order to make sense of the terms used to describe the elements of an endpoint, I will use a real-life analogy as an example: You are tasked with getting an important message to a recipient on the other side of the city at 1600 Pennsylvania Avenue and it must make it there by a specific time.
Addresses
The most obvious element of an endpoint is its address. It tells clients where to reach the service. In our real-life example, that would be 1600 Pennsylvania Avenue and in a computer, it may be a URL such as mytravelagency.com. WCF defines an object named EndpointAddress to hold this address. It contains some other additional properties which I won't go into detail now to keep this introduction simple.
...
The 3rd element in an endpoint is the contract. Contracts simply spell out what functionality (operations) the service can provide, how to specify any inputs it may be required to act on your request and how the data will be provided back to you. For example, it makes no sense to send a message to 1600 Pennsylvania Avenue that says "List trips on sale" as that it's not an function the entity at that address can provide. Thus a service must provide all the functions it can support and the inputs and responses for each of those functions. Any slight deviation from that contract and the service cannot provide the clients what they seek. We'll spend more time on contracts later when creating our first service.
...
All communication exchanged between clients and services are done using a WCF object called a Message. It doesn't matter what the data being exchanged is (a picture, text, etc). WCF will simply treat it all as a message. It is up to the clients and services to insert/extract their data into/from the payload area of the message. Headers associated with the message will be use by WCF to further route those messages.
Message Exchange Patterns
The interaction of how clients exchange messages with the services is termed message exchange patterns (MEPs). The most common pattern used is the request-reply, which is easy to understand as the client making a request and the service providing a reply. The client will wait for a reply and no other work will be performed until the reply arrives or WCF times out the request. By pressing the ON SALE button in our travel agency website example, the client is The reason this is a very common pattern is that most services want to consume data. They want to get information from a server back to the user, eg, what is the current stock price? what is on my schedule today?
Continuing our example of a travel agency website, a client can press the ON SALE button, thereby making a request to get all-on-sale-trips and the service is replying will reply with the discounted trips.
...
A typical request-reply message pattern where the client makes a request and its execution stops until the reply is received.
Obviously, pausing the entire client application while the request is astounding will lead to a very unpleasant experience (e.g. the browser temporarily freezes while it waits) so there are other mechanisms for allowing the application to handle other work while it waits for the results. In this case, the request is then said to be executing asynchronously.
A second message pattern is one where the client simply sends a message to the service and doesn't expect a reply. This is called the one-way pattern. This pattern can used for sending status or metrics to the service or for periodically saving data a customer may be typing into a browser from (such as when you edit a wiki document).
References
- .NET Documentation:
...