Choosing a Technology
| Retired Content |
|---|
The Web Service Software Factory is now maintained by the community and can be found on the Service Factory site. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. Retired: November 2011 |
The Service Factory supports two technology extenders (WCF and ASMX) that add technology-specific properties and validation rules to each of the shapes on the models. The technology of a model is chosen after some level of design and is a required stage before code can be generated. You can continue to make changes to the models (such as additions and deletions) after a technology is chosen, and you can even change the technology choice.
Note
After a model is associated with a technology, it will always be associated with a technology. This is important because after a model is no longer technology-agnostic, they are more difficult to move between model projects. The model project is the Visual Studio project the models belong to when they are created.
The following sections provide detail about the technology extension properties for each model:
- Service Contract Model
- Data Contract Model
- Host Model
Additional extenders can be added to the Service Factory by using the extensibility points provided in the source code. To learn more about the extensibility points and how to build your own version of the Service Factory, see Service Factory Architecture and the Extending the Service Factory Hands-on Lab, respectively.
Service Contract Model
After you choose a value for the Technology Extender property on the Service Contract Model's design surface, you may be required to provide values for certain properties before the model will pass validation. For example, the Is Wrapped property on Messages must be set to True if they contain more than one message part. Other properties can be changed later and still maintain a valid model.
Understanding the Message Wrapping Behavior
The following table illustrates the wrapping behavior when different Is Wrapped and Technology Extender properties values are applied to the Message and XSD Message elements.
|
ModelElement |
Technology and Serializer Type |
Is Wrapped |
ResultingBehavior |
|---|---|---|---|
|
Message |
WCF Extension and DataContractSerializer |
True |
A MessageContract type will be created with its Wrapped property set True |
|
False* |
A MessageContract type will be created with its Wrapped property set False |
||
|
ASMX Extension and DataContractSerializer |
N/A |
A validation rule will prevent this combination since ASMX does not support the DataContractSerializer. |
|
|
XSD Message |
WCF Extension and DataContractSerializer |
True |
A MessageContract type will be created with its Wrapped property set True |
|
False |
A MessageContract type will be created with its Wrapped property set False |
||
|
ASMX Extension and XmlSerializer |
True |
An XML-serializable type will be created that represents the message. |
|
|
False |
No type will be created to represent the message. The referenced XSD will be used to generate the data contract types. |
* If a message has more than one part, the message's Is Wrapped property must be set to True.
Data Contract Model Compatibility Matrix
The following table illustrates the possible Technology Extension and Serializer Type properties across the Service Contract Model and Data Contract Model.
|
Model Element |
Service Contract Model Technology Extension |
Service Contract Model Serializer Type Property |
Data Contract Model Technology Extension |
|---|---|---|---|
|
Message: Data Contract Message Part |
WCF |
DataContractSerializer |
WCF |
|
WCF |
XMLSerializer |
ASMX |
|
|
ASMX |
XmlSerializer * |
ASMX |
|
|
Operation:Data Contract Fault |
WCF |
Either Serializer Type |
WCF |
|
ASMX |
XmlSerializer * |
ASMX |
|
|
Operation:XSD Element Fault |
WCF |
DataContractSerializer ** |
This does not influence the type created |
* The ASMX Technology Extender only supports XmlSerializer as the serializer type.
** The XSD Element Fault is not supported with XmlSerializer as the serializer type.
The following section will describe the Data Contract Model in more detail.
Data Contract Model
After you choose a value for the Technology Extender property on the Data Contract Model's design surface, you are required to provide values for the following properties before the model will pass validation:
- Collection Types. The Primitive Data Type Collection and the Data Contract Collection have an extender property named Collection Type. The value of this property specifies the .NET generic collection type that should be created during code generation.
- Data Member Order. The Data Contract and Fault Contract have members that have an extension property named Order. When using the WCF Technology Extension, these properties are required to be unique and sequenced within the data contract or fault contract. Starting with a value of zero is recommended.
The Data Contract Model and the Service Contract Model can be combined to produce a result similar to what can be achieved with the command line tools available today as shown in the following table.
Technology Extension on the Data Contract Model |
Serializer Used on the Service Contract Model |
Corresponding Behavior with Existing Command Line Tools |
|---|---|---|
WCF Extension |
DataContractSerializer |
svcutil.exe /dconly |
ASMX Extension |
XMLSerializer |
xsd.exe /classes |
Host Model
Unlike the Service Contract Model and Data Contract Model, the Technology Extension on the Host Model is not applied at the model level as a property. Instead, only the Host Application and the Client Application have a Technology Extension property and they are applied individually.
Like the other models, only after a Technology Extension is specified are the extension properties available. However, there are only two extension properties on the Host Model and they both are associated with the WCF Technology Extension:
- Enable Metadata Publishing. This property is attached to a Service Reference, which is associated with a host application. Setting this property to true will create an endpoint that is invisible on the model but exposes the WSDL and policy metadata from the service. You must set this property to true before generating code if you will be generating the client's proxy classes. For more information, see Generating the Implementation.
- Binding Type. This property is on an Endpoint shape attached to a service reference. This value correlates to the standard binding types supplied by WCF.
None of the elements in the Host Model have extension properties for the ASMX Extension.