Contracts are another critical component of the policy that
must be agreed upon between clients and services. Contracts up until today
were written with either IDL (Interface Definition Language) or WSDL (Web Service
Description Language). WSDL is the most recent attempt at answering the what
a service is supposed to do. WSDL has the same information you see in IDL plus
much more. WSDL is not really changing with the introduction of WCF services;
what does change is how we go about defining what our WSDL should look like.
WCF services have defined a variety of contract types that
are used to put together the WSDL document that a service exposes. Service
contracts, data contracts, and message contracts all help to define the WSDL a
service will expose. I will walk us through the different contract types and
map them to those elements of WSDL we are already familiar with. This will
help to show some of the obvious parallels between WSDL and WCF service definitions.
Service contracts are the API for your service. These
contracts can be defined using interfaces, or they can be defined on the actual
class that implements the service behavior. The following is an example of a
service contract using a C# interface.
public interface IFamilyGuyGoodies
As you have probably already realized, this service contract
does not specify much. This really just demonstrates the use of an interface
instead of a class to define a service. You should take note that the access
modifiers have been left off intentionally. The concept of public and
private are meaningless when identifying methods on a service contract. If
you expose that functionality using the [OperationContract] then it will be
capable of being invoked externally. This again goes back to making explicit
decisions about the behavior that is exposed.
It is also important to note that within the service
contract and operation contract there are a number of declarative settings that
can be enforced. For example, if this method was intended to use simplex
messaging then you would specify IsOneWay=True. It is also within this service
contract definition that I can make explicit assertions about my binding
requirements. I would add an attribute [BindingRequirements()] to specify
transaction flow requirements or reliable messaging requirements.
The service contract maps to the portType section of the
WSDL document. With the current ASMX stack the [webMethods()] that you define
are what make up this section. With WCF, you are capable of making specific
decisions about how you want consumers to interact with your service by
building interfaces first before diving right into implementation. This
decision to focus on API first can lead to much better decisions about what is
truly required to invoke a service operation.
WCF gives us a whole new level of control for how we specify
the data that is passed back and forth between the client and the service. A
data contract allows us to specify what members of a custom type are serialized
and how those members are serialized. The data contracts are analogous to the
type element in WSDL today. The following is an example of a data contract in
[DataMember] string quoteText;
I have again used a simple type to demonstrate the most
obvious advantages of the data contracts with WCF. Notice the [DataMember]
attribute; this is the only way to identify to the serializer that this member
should be expected as part of the SOAP payload. As with service contracts, the
access modifiers are meaningless.
I also used this simple example to showcase the implicit
versioning available in the data contract. Notice that the episodeFound
member above was added in a later version of the data contract. This in turn
allows a client to specify that it is using version 1 of this service and that that
portion of the data is not required to communicate successfully with the
WCF data contracts give developers their first set of built-in
versioning capabilities. Abiding by some very simple rules will allow for the
flexibility to add and remove portions of your data being sent back and forth
to a service. This reinforces a couple of service tenets. First, you are
obviously exchanging contracts and schema, not types. If you understand how
this code translates to WSDL, this becomes even more apparent. I also believe
that through data contract versioning you are able to remain autonomous. If
the services we develop today can supply a variety of versions to a variety of
consumers then the service can remain in control of how to handle those various
versions and maintain self-governance.
One of the types of services that we discussed earlier was a
typed message service. This type of service uses typed messages to invoke a
service and receives typed messages as responses. One of the common needs of
these types of services is to manipulate the format of the actual SOAP message
that is being passed between the client and the service. In the past this would
have to be done with complicated SOAP extensions. With WCF message contracts,
we are able to easily specify the portions of a message that should live in the
SOAP header and those that should live in the body. Often, these two sections
of the message will have different encryption requirements, and the message
contract is a good way to provide flexibility in how we structure that
message. The message contract maps to the message section of WSDL today. The
following is an example of a WCF message contract.
public class FamilyGuyQuoteRequest
You will notice a couple of interesting things in the simple
message contract defined above. First of all, notice how simple it is to
specify where a member would live in a SOAP message. When using the
[MessageHeader] attribute, I am telling the serializer to expect this field in
the SOAP header. I also have used the MustUnderstand enumeration to tell the
serializer that this is a required field in my SOAP header.
Message contracts round out the primary contract types that
go into specifying exactly what a service will be passing on the wire. This
takes the guesswork out of service definition. As I mentioned above, this is a
vast improvement on the implicit approaches today. We really do not have this
type of flexibility with ASMX. Our current approaches would require us to plug
into the HTTP pipeline and intercept messages using SOAP extensions.
So Am I Truly Contract-First Now?
An interesting ongoing debate amongst those in the industry
that are designing, delivering, and teaching service-orientation is whether or
not a code-first approach will ever allow us to design and deliver services
that are truly loosely coupled, interoperable, and ultimately long-lived. What
we just looked at was a very distinct set of technologies that map directly to
the WSDL contract that is generated when this service is exposed. Were we
actually doing contract-first development with a code-first approach?
The purists would say that contract-first means focusing
on schema (XSD) and behavior (interface) before ever writing any code. What I
would say is that we do this now by specifying data contracts (schema/XSD),
service contract (behavior/interface), and message contracts when necessary.
These approaches are still very code-centric and will require some level of
governance to avoid developers diving right into implementation before a
contract has been agreed upon. However, with the right level of discipline, I
think WCF has found an interesting middle ground for contract-first service