I think most of you prefer to implement service port type  first while try to build a wcf service. That is ok, however, did you ever take the final stub class in your consideration, in the meanwhile you are coding a wcf service?

 As known, we can use ?WSDL to get wsdl displayed in IE. Most of time, we will get the following WSDL:

<wsdl:import namespace=http://services/ location=http://XXXX/Service.svc?wsdl=wsdl0 />

<wsdl:types />

Unfortunately, Schemas and Messages are missing. It will be a big impact to generate proxy class by wsdl.exe or access by SOAP UI.

At then, we have to query like http://XXXX/Service.svc?wsdl=wsdl0, http://XXXX/Service.svc?xsd=xsdn (n starts from 0) to get schemas and Messages.

If this service is large enough, you will find it will be a tough job.

 

Ok, what should we do now? I think we have two approaches:

1, facilitate a static wsdl file before developing services. and configure  <system.serviceModel> section like the following:

<services>

<!-- Replace the parameters below for your service implementation -->

   <service name="ServicePortType" behaviorConfiguration="ServiceBehavior" >

      <endpoint address="" binding="basicHttpBinding" bindingNamespace=http://service/ contract="IServicePortType"

   />

   </service>

</services>

<behaviors>

<serviceBehaviors>

<behavior name="ServiceBehavior" >

<serviceMetadata httpGetEnabled="true" externalMetadataLocation="..\service.wsdl"/>

</behavior>

</serviceBehaviors>

</behaviors>

Ok, job is done. Next time , if you attempt to link  http://XXXX/Service.svc?wsdl, you wil get a flat wsdl.

 

2, Develop a custom behavior to support Inlined XSD.

posted on 2011-03-31 14:40  方夜羽  阅读(472)  评论(0)    收藏  举报