1.Why are all parameters in all of your services declared as optional when most of the times they really aren't?"
Now if you navigate to SvcFile.svc?xsd=xsd0 (if not that then xsd=xsd1 or xsd=xsd2), you can see the schema for this operation and the xs:element elements for all 3 parameters and the return value have minOccurs="0" attribute. This essentially makes these parameters optional in the WSDL, SOAP UI and proxy/client code generated using some java toolkit they are using. As is pretty obvious, we don't want the control to even enter the Transfer method if the SOAP (1.2/1.1) request comes in without any of those parameters.
2.At least for simple parameters, you can use an IParameterInspector to enforce that they are present (see below). This solution has two limitations: it doesn't change the WSDL (which will still note the parameters are optional), and it doesn't work for nullable types. To work for nullable types you'd actually need a new formatter (basically doing the deserialization of the different parameters yourself).
ans:
changing the WSDL to reflect the required nature of parameters is my primary goal.
ts good to see how we can validate that required parameters are actually present in a message at the infrastructure level. However, that is not really a problem for most services because when these required parameters are "validated" by the service, in almost all cases a value of 0 or null is invalid anyways.
In this case, sort of rewriting the WSDL for the service (which is easy to do, if not to maintain - you'll need to save the WSDL+XSD files generated for the service, edit them, and link to them via the ExternalMetadataLocation property of the ServiceMetadataBehavior), you're left with the solution listed in your previous blog post.
finally
I'm looking for a way to make method parameters required in an OperationContract without switching to MessageContract. For example, I want to be able to declare a method like the following:
public int Transfer([DataParameter(IsRequired=true)]int SourceAccount, [DataParameter(IsRequired=true)]int TargetAccount, [DataParameter(IsRequired=true)]double Amount);
and have System.ServiceModel.Description.
DataContractSerializerMessageContractExporter.ExportBody method not put minOccurs="0" in the WSDL for the operation.
Friday, April 9, 2010
OperationContract with required parameters
OperationContract with required parameters
I'm looking for a way to make method parameters required in an OperationContract without switching to MessageContract. For example, I want to be able to declare a method like the following:
public int Transfer([DataParameter(IsRequired=true)]int SourceAccount, [DataParameter(IsRequired=true)]int TargetAccount, [DataParameter(IsRequired=true)]double Amount);
and have System.ServiceModel.Description.
DataContractSerializerMessageContractExporter.ExportBody method not put minOccurs="0" in the WSDL for the operation.
READ AND LEAVE IT(convert all services to MessageContracts)
My enhancement request is to provide a way to tag parameters in an OperationContract as required without switching all our services to MessageContracts.
I'm afraid manually editing the WSDLs and publishing them at different URL is not maintainable at all and is a lot more prone to errors. I would rather convert all services to MessageContracts but the fact is I'm not going to do that either for now. Right now, I'm thinking of investigating the possibility of inheriting from the System.ServiceModel.Description.DataContractSerializerMessageContractExporter class and overriding the ExportBody method and then plugging in that custom DCSMCE into the WCF pipeline. Unfortunately, while DataContractSerializerMessageContractImporter is public, DataContractSerializerMessageContractExporter is an internal class. So I will probably need to do hacky and evil things using reflection, which I would rather not have done either. :)
LINK:
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/e707ed20-c09c-4e26-927a-7c3071d74ed7/#46f3cc78-d70f-48b8-9947-2429e789a300
I'm looking for a way to make method parameters required in an OperationContract without switching to MessageContract. For example, I want to be able to declare a method like the following:
public int Transfer([DataParameter(IsRequired=true)]int SourceAccount, [DataParameter(IsRequired=true)]int TargetAccount, [DataParameter(IsRequired=true)]double Amount);
and have System.ServiceModel.Description.
DataContractSerializerMessageContractExporter.ExportBody method not put minOccurs="0" in the WSDL for the operation.
READ AND LEAVE IT(convert all services to MessageContracts)
My enhancement request is to provide a way to tag parameters in an OperationContract as required without switching all our services to MessageContracts.
I'm afraid manually editing the WSDLs and publishing them at different URL is not maintainable at all and is a lot more prone to errors. I would rather convert all services to MessageContracts but the fact is I'm not going to do that either for now. Right now, I'm thinking of investigating the possibility of inheriting from the System.ServiceModel.Description.DataContractSerializerMessageContractExporter class and overriding the ExportBody method and then plugging in that custom DCSMCE into the WCF pipeline. Unfortunately, while DataContractSerializerMessageContractImporter is public, DataContractSerializerMessageContractExporter is an internal class. So I will probably need to do hacky and evil things using reflection, which I would rather not have done either. :)
LINK:
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/e707ed20-c09c-4e26-927a-7c3071d74ed7/#46f3cc78-d70f-48b8-9947-2429e789a300
Wednesday, April 7, 2010
OperationContract Attribute
The OperationContract attribute, as with the ServiceContract attribute, provides for even greater control over the WSDL generation. Generally you’ll accept most of the defaults, but for certain features, such as duplex messaging, you’ll need to use options indicating the operation is one-way. Additionally, for session management, you’ll be leveraging some of the options for overall service session management.
Table 4-6 describes the properties in the OperationContract attribute type.
Table 4-6. OperationContractAttribute Properties
Class Property Description
Action
Controls the action on the request (input) message; the default is the contract namespace, contract name, and operation name. Use this in conjunction with * to indicate the operation can handle all unmatched operation requests—there can be only one of these, and it must take a message as a parameter.
AsyncPattern
Provides for the implementation of an asynchronous process on the server, client, or both tiers. This feature aids .NET clients in supporting operations with the efficiency of using a single client thread.
IsInitiating
Indicates that this operation is an initiation of a session; the default is true, so if you require session initiation, you need to set all operations to false except the initiation operation.
IsOneWay
Indicates that the operation returns nothing (void) or can’t accept out parameters. The default is false; as a result, all operations without it return an empty message that is useful for capturing exceptions. If applying the value of true to an operation that is marked with a return type other than void, WCF doesn’t throw a compiler error. Instead, it throws an InvalidOperation exception when the WCF framework inspects the ServiceContract types at runtime.
IsTerminating
Indicates this operation terminates the session and the channel should close.
Name Overrides the operation name from the method name on the interface.
ReplyAction
Controls the action on the reply (output) message. Used in conjunction with the Action property.
Table 4-6 describes the properties in the OperationContract attribute type.
Table 4-6. OperationContractAttribute Properties
Class Property Description
Action
Controls the action on the request (input) message; the default is the contract namespace, contract name, and operation name. Use this in conjunction with * to indicate the operation can handle all unmatched operation requests—there can be only one of these, and it must take a message as a parameter.
AsyncPattern
Provides for the implementation of an asynchronous process on the server, client, or both tiers. This feature aids .NET clients in supporting operations with the efficiency of using a single client thread.
IsInitiating
Indicates that this operation is an initiation of a session; the default is true, so if you require session initiation, you need to set all operations to false except the initiation operation.
IsOneWay
Indicates that the operation returns nothing (void) or can’t accept out parameters. The default is false; as a result, all operations without it return an empty message that is useful for capturing exceptions. If applying the value of true to an operation that is marked with a return type other than void, WCF doesn’t throw a compiler error. Instead, it throws an InvalidOperation exception when the WCF framework inspects the ServiceContract types at runtime.
IsTerminating
Indicates this operation terminates the session and the channel should close.
Name Overrides the operation name from the method name on the interface.
ReplyAction
Controls the action on the reply (output) message. Used in conjunction with the Action property.
what are the various ways of hosting a WCF service?
Answer:
There are three major ways to host a WCF service:-
1. Self hosting the service in his own application domain. This we have already covered
in the first section. The service comes in to existence when you create the object of
ServiceHost class and the service closes when you call the Close of the ServiceHost
class.
2. Host in application domain or process provided by IIS Server.
3. Host in Application domain and process provided by WAS (Windows Activation
Service) Server.
There are three major ways to host a WCF service:-
1. Self hosting the service in his own application domain. This we have already covered
in the first section. The service comes in to existence when you create the object of
ServiceHost class and the service closes when you call the Close of the ServiceHost
class.
2. Host in application domain or process provided by IIS Server.
3. Host in Application domain and process provided by WAS (Windows Activation
Service) Server.
differance between data contact and message constarct
Contract Type Member Attributes Description
ServiceContract OperationContract Describes the operations a service can perform. Maps CLR types to WSDL.
DataContract DataMember Describes a data structure. Maps CLR types to XSD.
MessageContract MessageBody, MessageHeader Defines the structure of the message on the wire. Maps CLR types to SOAP messages.
A data contract describes the data that your service operations exchange. Data contracts describe only the data transferred from one side to the other; generally they do not describe the message that carries the data.A message contract would hold all the required information about the message payload itself ie: itself.
Use Message Contracts to implement SOAP Headers, etc.
I would think MessageContract is better suited for this purpose since it is specifically for custom defining
the Message Headers and Message Body.
Basically a WCF Message ( ie message contract NOT data contract ) will call the serializer once for each member in the body and add the result to the output message .
Now if you send a DataContract it will serialize the entire stream.
My requirement is that I need to Pass in Additional Header information to the WCFservice, this I can do with Message Contracts but I need to maintain two set of Contracts one for the Request (which will contain Message Header + body) and another for Reply which will contain Body Only.
Alternatively if use DataContract I don't have option to pass the Headers, but this can be done in other means(by using Server and Client Message Inspectors).
ServiceContract OperationContract Describes the operations a service can perform. Maps CLR types to WSDL.
DataContract DataMember Describes a data structure. Maps CLR types to XSD.
MessageContract MessageBody, MessageHeader Defines the structure of the message on the wire. Maps CLR types to SOAP messages.
A data contract describes the data that your service operations exchange. Data contracts describe only the data transferred from one side to the other; generally they do not describe the message that carries the data.A message contract would hold all the required information about the message payload itself ie:
Use Message Contracts to implement SOAP Headers, etc.
I would think MessageContract is better suited for this purpose since it is specifically for custom defining
the Message Headers and Message Body.
Basically a WCF Message ( ie message contract NOT data contract ) will call the serializer once for each member in the body and add the result to the output message .
Now if you send a DataContract it will serialize the entire stream.
My requirement is that I need to Pass in Additional Header information to the WCFservice, this I can do with Message Contracts but I need to maintain two set of Contracts one for the Request (which will contain Message Header + body) and another for Reply which will contain Body Only.
Alternatively if use DataContract I don't have option to pass the Headers, but this can be done in other means(by using Server and Client Message Inspectors).
Subscribe to:
Posts (Atom)