Export (0) Print
Expand All

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.
This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

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. Choosing 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.

Ff699411.note(en-us,PandP.10).gifNote:
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, it is more difficult to move between model projects. The model project is the Visual Studio project that the models belong to when they are created.

The following sections provide information about the technology extension properties for each model:

You can add extenders to the Service Factory by using the extensibility points provided in the source code. To learn more about the extensibility see Service Factory Architecture.

Service Contract Model

After you choose a value for the Implementation Technology property on the Service Contract Model design surface, you might 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 the messages 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.

Model
Element

Technology and Serializer Type

Is Wrapped

Resulting Behavior

Message

WCF Extension and DataContractSerializer

True

A MessageContract type will be created with its Wrapped property set to True.

False*

A MessageContract type will be created with its Wrapped property set to False.

ASMX Extension and DataContractSerializer

N/A

A validation rule will prevent this combination because ASMX does not support the DataContractSerializer.

XSD Message

WCF Extension and DataContractSerializer

True

A MessageContract type will be created with its Wrapped property set to True.

False

A MessageContract type will be created with its Wrapped property set to 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 Implementation Technology 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 Implementation Technology 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 an Implementation Technology property and they are applied individually.

Like the other models, only after an Implementation Technology is specified are the extension properties available. However, there are only two extension properties on the Host Model and both of them are associated with the WCF Implementation Technology:

  • 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.

Show:
© 2014 Microsoft