Share via

How far should Whidbey go with BP conformance?

  • Article

We plan to make services created with VS Whidbey BP 1.0 conformant by default. However, the developer has opportunities to make the service non-conformant. For example, using SOAP encoding (adding the SoapRpcServiceAttribute) would make it non conformant. So we’ll check the service’s WSDL when you navigate to the ASMX URL and we’ll tell you if the WSDL is non-conformant and how you can fix it. Similarly, there are opportunities to break conformance at run time. For example, R2738 states that a SOAP message must include all headers specified in the WSDL. This is not something we can check at design time so the question is, would you expect the framework to check this at run time? For example we could check it at the sender and/or at the receiver but it gets interesting when you think about an output message (a reply message) being sent from the server without some declared headers. We could send a fault to the client or write something out to the event log. Developers don’t often read the event log unless something breaks, so it would seem more useful if the framework return a fault to the client in this case. Any thoughts on how you'd like to see this work?

 

In general, should we add run-time BP conformance checking across the board (for all testable BP requirements)? Would you expect this to be something turned on by default or manually configurable in web.config or app.config? Other related thoughts and/or comments?

Comments