Contracts
WCF contracts are much like a contract that you and I would sign in real life. A contract I may sign could contain information such as the type of work I will perform and what information I might make available to the other party. A WCF contract contains very similar information. It contains information that stipulates what a service does and the type of information it will make available.
Given this information, there are three types of contracts: data, message, and service.
Data
A data contract explicitly stipulates the data that will be exchanged by the service. The service and the client do not need to agree on the types, but they do need to agree on the data contract. This includes parameters and return types.
Message
A message contract provides additional control over that of a data contract, in that it controls the SOAP messages sent and received by the service. In other words, a message contract lets you customize the type formatting of parameters in SOAP messages.
Most of the time a data contract is good enough, but there might be occasions when a little extra control is necessary.
Service
A service contract is what informs the clients and the rest of the outside world what the endpoint has to offer and communicate. Think of it as a single declaration that basically states "here are the data types of my messages, here is where I am located, and here are the protocols that I communicate with
Policy and binding
Policy and binding contracts specify important information such as security, protocol, and other information, and these policies are interrogated looking for the things that need to be satisfied before the two services start communicating
Service Runtime
The Service Runtime layer is the layer that specifies and manages the behaviors of the service that occur during service operation, or service runtime (thus "service runtime behaviors"). Service behaviors control service type behaviors. They have no control over endpoint or message behaviors. Likewise, endpoint and message behaviors have no control over service behaviors.
The following lists the various behaviors managed by the Service Runtime layer:
q Throttling Behavior: The Throttling behavior determines the number of processed messages.
q Error Behavior: The Error behavior specifies what action will be taken if an error occurs during service runtime.
q Metadata Behavior: The Metadata behavior controls whether or not metadata is exposed to the outside world.
q Instance Behavior: The Instance behavior drives how many instances of the service will be available to process messages.
q Message Inspection: Message Inspection gives the service the ability to inspect all or parts of a message.
q Transaction Behavior: The Transaction behavior enables transacted operations. That is, if a process fails during the service runtime it has the ability to rollback the transaction.
q Dispatch Behavior: When a message is processed by the WCF infrastructure, the Dispatch Behavior service determines how the message is to be handled and processed.
q Concurrency Behavior: The Concurrency behavior determines how each service, or instance of the service, handles threading. This behavior helps control how many threads can access a given instance of a service.
q Parameter Filtering: When a message is acted upon by the service, certain actions can be taken based on what is in the message headers. Parameter Filtering filters the message headers and executes preset actions based on the filter of the message headers.
Messaging
The Messaging layer defines what formats and data exchange patterns can be used during service communication. Client applications can be developed to access this layer and control messaging details and work directly with messages and channels.
The following lists the channels and components that the Messaging layer is composed of:
q WS Security Channel: The WS Security channel implements the WS-Security specification, which enables message security.
q WS Reliable Messaging Channel: Guaranteed message delivery is provided by the WS Reliable Messaging channel.
q Encoders: Encoders let you pick from a number of encodings for the message.
q HTTP Channel: The HTTP channel tells the service that message delivery will take place via the HTTP protocol.
q TCP Channel: The TCP channel tells the service that message delivery will take place via the TCP protocol.
q Transaction Flow Channel: The Transaction Flow channel governs transacted message patterns.
q NamedPipe Channel: The NamedPipe channel enables inter-process communication.
q MSMQ Channel: If your service needs to interoperate with MSMQ, this is the channel that enables that
Activation and Hosting
The Activation and Hosting layer provides different options in which a service can be started as well as hosted. Services can be hosted within the context of another application, or they can be self-hosted. This layer provides those options.
The following list details the hosting and activation options provided by this layer:
q Windows Activation Service: The Windows Activation Service enables WCF applications to be automatically started when running on a computer that is running the Windows Activation Service.
q .EXE: WCF allows services to be run as executables (.EXE files).
q Windows Services: WCF allows services to be run as a Windows service.
q COM+: WCF allows services to be run as a COM+ application
, this section lists a number of the great focus points that WCF has to offer. Think of it as the personality of WCF:
q Programming model
q Scalability
q Interoperability
q Enhanced communication
q Enterprise enabled
Programming Model
The great thing about WCF is that there is no "right way" to get from point A to point B. If fact, WCF lets users start at point A and go to point B any way they see fit. This is because the programming model in WCF lets developers control how and when they want to code things and yet gives them the ability to do that with a minimum amount of code.
As you have seen from the architecture, there are only a small handful of major components that a developer will need to work with to build high-class services. However, WCF also lets developers drill down to lower-level components if they desire to get more granular with their options. WCF makes this very simple. The WCF programming model lets a developer take whichever approach he or she desires. There is no single "right" way.
The programming model also combines many of the earlier technologies, such as the ones mentioned earlier in the chapter (MSMQ, COM+, WSE, and so on), into a single model.
Scalability
WCF services scale, and they scale in all directions. Not just up or out, but in all directions. They scale out via routing mechanisms and farms. Remember the book publisher example? The Order Process service was scaled out by providing an Order Process router, which routed orders to multiple Order Process services.
Services scale up by not being tied to a single OS or processor. Services scale up by the pure ability to deploy them on bigger and better servers and taking advantage of the new processor technologies that are starting to appear.
Services scale in by way of cross-process transports, meaning on-machine and cross-machine messaging and Object-RPC.
Services scale down by interfacing and communicating with devices such as printers, scanners, faxes, and so on.
Interoperability
How sweet is it to be able to build high-class services using a single programming model and at the same time take advantage of earlier technologies (see "Programming Model"), irrespective of the OS, environment, or platform? WCF services operate independent of all of these.
WCF services also take advantage of the WS architecture utilizing the already established standards as far as communication and protocols are concerned.
Enhanced Communication
Services aren't picky as far as transports, formats, or much else. You as a developer can choose from a handful of transports, different message formats, and surplus of message patterns.
Along these same lines, WCF is like the country of Switzerland (nice segue, heh?), in that services are neutral as far as transports and protocols are concerned. A service can use TCP, HTTP, Named Pipes, or any other protocol to communicate. The same goes for transports. In fact, if you want to build and use your own, feel free to do so.
The reason it is this way is because, as you hopefully have figured out by now, communication is completely separate from the service. They are completely independent from one another.
Enterprise Enabled
A lot of times there is a give-and-take relationship when dealing with web services, interoperability, and other important features geared toward enterprises. As a developer you have to weigh performance versus security, or reliability. At what cost does adding transactional capabilities add to your solution? Up until now, having the best of all worlds was a mere pipe dream.
Well, now it is time to wake up and smell the technology because WCF provides the ability to have security and reliability without sacrificing performance. And you can throw transactions into the mix as well.
A lot of this comes from the standards of the web service architecture, allowing you to build enterprise- class applications.
Now that you know what makes WCF tick, the chapter wraps up by discussing some of the great things you can do with WCF
No comments:
Post a Comment