How to control WSDL namespaces in WCF is a common question, so I will tackle this first. I will assume WSDL basics to be known.
WSDLs exported by WCF
WCF services by default export a tree of WSDLs, i.e. several WSDLs, imported one from another using wsdl:import construct.
This is because different WSDL elements exported by WCF service have different lifecycles: wsdl:service, wsdl:binding, wsdl:portType and schemas. For example schemas are prescribed by vertical industry standard; contract is written once for all providers; binding is prescribed by a vertical industry standard; service is implemented by individual provider.
Each of these WSDL elements has a namespace uri associated with it. In WSDL such namespace uri is assigned by the @targetNamespace attribute on <wsdl:definitions> root that contains one of these elements. Hence there are four types of namespaces in WSDLs generated by WCF.
There is always one WSDL generated for one target namespace URI. I.e. if the namespaces uris match for wsdl:portType and wsdl:binding , these elements are bundled into the same WSDL. XML Schemas are always exported as separate documents.
Compatibility note:
wsdl:import – the construct that allows to build the WSDL tree and put wsdl:service, wsdl:binding and wsdl:portType into different namespaces - was not very well supported by early toolkits. For example if your service is required to be consumed by early versions of InfoPath or Visual Studio ATL sproxy.exe tool, you will need to set the target namespaces for wsdl:service, wsdl:binding and wsdl:portType to the same URI.
Control WSDL Namespaces
Here is how you control target namespaces for wsdl:service, wsdl:binding , wsdl:portType and schemas. WSDL has also wsdl:message – those are bundled together with the wsdl:portType
Service namespace
This is the target namespace of the root WSDL where <wsdl:service…/> element resides containing endpoints (<wsdl:port>)
Code
Set via ServiceBehavior attribute on the service class (not the contract!)
[ServiceBehavior(Name="MyService", Namespace="http://myservice.com/",
ConfigurationName="MyServiceConfiguration")]
public class MyService : IMyServiceContract
default for ConfigurationName (used in config) and Name (exported name into WSDL) is the name of the class. Default for the namespace is the “http://tempuri.org”
WSDL
<wsdl:definitions name="MyService" targetNamespace="http://myservice.com/" …>
...
<wsdl:service name="MyService">
...
Note, we had an unfortunate bug in RC0 that caused stack overflow when you used this setting. This is fixed in later bits.
Binding namespace
This is the target namespace for the WSDL that contains wsdl:binding elements. wsdl:binding is where WCF exports bindings together with certain serialization aspects.
Config
<services>
<service name="MyServiceConfiguration"...>
<endpoint name="MyServiceEndpoint"
bindingNamespace="http://myservice.com/binding"
contract="Namespaces.MyServiceContract" ...>
Code
Binding b = new CustomBinding();
b.Namespace = "http://myservice.com/binding";
se = sh.AddServiceEndpoint(typeof(MyServiceContract), b, "http://myservice.com:8080");
WSDL
<wsdl:definitions targetNamespace="http://myservice.com/binding" …>
...
<wsdl:binding name="MyServiceEndpoint">
...
Contract namespace
This is the target namespace for the WSDL that contains wsdl:portType . ServiceContract is exported there.
Code
[ServiceContract(Name = "MyServiceContract", Namespace = "http://gadgets.org/contract")]
public interface MyServiceContract {}
WSDL
<wsdl:definitions targetNamespace="http://gadgets.org/contract">
...
<wsdl:portType name="MyServiceContract">
...
Schema namespace
DataContract types , XmlSeriazer types and wrapper elements defined by MessageContract are being exported into schemas. Schemas namespace are set on individual DataContract , XmlSerializer or MessageContract attributes.
Code
[DataContract(Name="Order", Namespace="http://gadgets.org/types")]
public class Order
{
[DataMember]
public string Id;
}
[MessageContract(IsWrapped = true, WrapperNamespace="http://gadgets.org/messages")]
public class MyServiceUpdateRequest
{
[MessageBodyMember(Namespace = "http://startrek.net/messages")]
public Order Order;
}
WSDL
wsdl:types is always put into the same WSDL as wsdl:portType. It always contains a single xsd:schema referencing all the schemas used by that portType.
<wsdl:definitions targetNamespace="http://gadgets.org/contract">
<wsdl:types>
<xsd:schema targetNamespace="http://gadgets.org/contract/Imports">
<xsd:import schemaLocation="http://myservice.com:8080/?xsd=xsd0" namespace="http://gadgets.org/messages"/>
<xsd:import schemaLocation="http://myservice.com:8080/?xsd=xsd1"
namespace="http://schemas.microsoft.com/2003/10/Serialization/"/>
<xsd:import schemaLocation="http://myservice.com:8080/?xsd=xsd2" namespace="http://gadgets.org/types"/>
</xsd:schema>
</wsdl:types>
<wsdl:message name="MyServiceUpdateRequest">
<wsdl:part name="parameters" element="q1:MyServiceUpdateRequest" xmlns:q1="http://gadgets.org/messages"/>
</wsdl:message>
XSD
<xs:schema elementFormDefault="qualified" targetNamespace="http://gadgets.org/messages" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://gadgets.org/messages">
<xs:import schemaLocation="http://localhost:8080/?xsd=xsd2" namespace="http://gadgets.org/types"/>
<xs:element name="MyServiceUpdateRequest">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="Order" nillable="true" type="q1:Order" xmlns:q1="http://gadgets.org/types"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
<xs:schema elementFormDefault="qualified" targetNamespace="http://gadgets.org/types" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://gadgets.org/types">
<xs:complexType name="Order">
<xs:sequence/>
</xs:complexType>
<xs:element name="Order" nillable="true" type="tns:Order"/>
</xs:schema>
Note there is the third schema whenever you use DataContract / XmlFormatter as a formatter for your service contract. This defines several helper elements and types for certain CLR types schema representation.
There were many questions recently on how to control various aspects of WSDL (metadata) generated by WCF services.
There are three phases one can use:
1) Design time: settings on data contract, message contract, service contract, service behavior, binding,
2) Runtime: implement IWsdlImportExtension and work with ServiceDescriptionCollection inside BeforeImport call.
3) Runtime: substitute your own MetadataImporter and party on.
The following two posts I will dedicate to #1.
Wednesday June 14th 8:30 / 9:30 myself and Nilesh Junnarkar from Oracle will show Interoperability between WCF and Oracle Fusion MiddleWare on Secure Reliable and Binary web services.
CON319 - (WinFX) Windows Communication Foundation: Building Interoperable Services
Room 153ABC. Wed June 14th, 8:30am - 9:45am.
We show interop between Java and .Net quite often, but usually use pure .Net "hello world" app talking to Java "hello world" service. In reality folks want to see Office talking to SAP/Oracle/DB2/SQL backends.
This year we're up to the challenge and will include Excel app invoking Java web services hosted on Oracle Fusion app server securely and reliably via WCF Service Moniker.
Scenario will include Infocard authentication and basic WS-Federation exchange.
Right next to it, at chalk talk:
CONTLC37 - Enterprise Web Services Interoperability between .NET and Java Using WCF and Sun's GlassFish
Connected Systems Theater, Blue Arena in TLC, Wed June 14th, 14:00 - 15:15
myself and Gerald Beuchelt will show set of demos with Sun GlassFish/WSIT code - repeat from JavaOne 2006, but not only. The jewel in certain sense will be Gerald's FIFI - Fast Infoset channel for WCF. If you're into how to make webservices fast yet interoperable, should be interesting discussion.
Kavita has full list of chalk talk sessions here
This is the second year Microsoft actively participates at JavaOne. Monday was a long day of endless installation hassle and frustration:), but tomorrow will be fun. Expect significant progress on interoperability in core WS-* protocols and identity space between WCF and Java to be demostrated.
1) In the Jonathan Schwartz / Jeff Jackson’s keynote 9:20-10:10am myself and Sun Tango team will demo InfoCard & WCF interoperating with Sun Java Web Services and Security Token Service (Identity provider) built using Tango project; as well as Java and WCF services and Identity Providers interoperating on Secure RM exchange with Federated Trust. Single Sign-On and Federated Trust interop between MS and Sun at JavaOne is another encouraging sign of convergence in the area of Identity.
2) In the following session TS-5540, 11am, Esplanade,307-310 we will drill into the keynote demo and cover interoperability between WCF / InfoCard and Sun GlassFish stack on a fairly involved business integration scenario featuring: MTOM, WS-Security 1.1/SecureConversation/WS-Trust, Secure RM, Secure MTOM.
3) In the evening, BOF-2477, 9:30-10:20pm, Hall E-135, Mike Jones and I will participate together with Sun folks in the BOF dedicated to Web Services Security and Identity.
more - later
In WCF (Indigo) we are taking interop seriously. Given the scale of Indigo, the WS-* architecture and future plans, there is work to do. I am looking for an energetic strong technical program manager passionated about distributed systems, web services and interoperability to help me on this endeavour. If you are it, you're welcome to drop me a note at kirillg_public@hotmail.com (or my ms alias), while we're waiting for the job description to propagate to members.microsoft.com/careers .
Job ad is pasted here:
The Windows Communication Foundation (WCF, aka “Indigo”) is Microsoft’s next generation distributed application platform. Join the Indigo team and make cross platform interoperability a reality for WCF. Enterprise solutions are never based on one platform. As illustrated by the "Building Software That Is Interoperable By Design" mail from Bill Gates and with almost every distributed platform feature decision we are betting success of our enterprise business on interoperability.
You will engage with product teams from our industry partners driving interoperability between our respective platforms. You will be involved in analyzing and addressing customer requirements in the product, working on tools that help diagnose interoperability issues as well as improve interoperability experience for enterprise developers. This effort will affect the WCF programming model, and will focus on ensuring that developers are productive building interoperable Enterprise-grade distributed applications. This is a highly challenging technical position with a great deal of interaction with architecture, development, and test teams as well as a significant percentage of coding required implementing the tools.
This position requires strong design skills, excellent communication skills (you will interact frequently with internal/external customers) and the ability to make the right feature tradeoffs. A passion for SOAP interoperability across vendor stacks and a solid software development or/and computer science background are required. Familiarity with Microsoft .NET technologies (such as C#, .NET Framework and the CLR) and/or competitive offerings (Java, J2EE, WebLogic or WebSphere) is a strong plus.
While preparing for PDC then decompressing after it, I completely forgot about blogging. It was a great event. A number of intriguing conversations about Web Services, Security, interop.
We did a talk with Simon where I played Dr. WCF and he was the patient. Interesting demos involving interop on Security, Secure MTOM, Secure RM with WebLogic and Apache Axis:
In the first demo we were showing off new HL7 wizard (software factory) in Whidbey that allows you to pick exact use-case and generate HL7 WSDLs for it. Really cool stuff, especially if you know the complexity of HL7 WSDLs and schemas - don't try to put them together by hand..
The second demo we accessed a service running on WebLogic for patient's record locator info (EMR pointer).The EMR was pointing to a service running Apache Axis 2.0 + WSS4J that we queried for an XRay using Secure MTOM.
The third demo was taking Simon's heartbeat measurements using real Nellcor device and sending them using Indigo over Secure RM to a service running Apache Axis 1.3, Sandesha and WSS4J.
Dims has the Apache Axis part of 2nd and 3rd demos here.
We will post the WCF (Indigo) part closer to B2 release. The most fun of course was preparation of those demos...:) Dims is just plain awesome to work with.
Our slides are available here, including the infamous BIG WS-* TENT.
We are planning a 4-day Windows Communications Foundation (WCF, a.k.a Indigo) Interop Plug-fest on Monday November 7, 2005 to Thursday November 10, 2005 at Microsoft Redmond campus.
The WCF (Indigo) Interop Plug-fest is an ad-hoc, open forum for implementers of various Web Services protocols to meet with engineers from the WCF(Indigo) team and test interoperability with the upcoming release.
Please send mail to kirillg@microsoft.com and jthelin@microsoft.com introducing your implementation if you’re interested in attending.
Scenarios drafts as well as pointers to test endpoints are available online - http://mssoapinterop.org/ilab/wcfinteroplab.htm . We recommend you to join the WS-Builders@yahoogroups.com discussion group and use it for questions around scenarios documents and WCF(Indigo) interoperability.
Here is an invite with further logistics info: http://mssoapinterop.org/ilab/WCFInteropPlugFest_invite.doc
Your interop experience with Indigo (especially the upcoming drop or if you have been on one of the interop workshops) may lead you to say “man this thing is strict:”. Indigo rejects many invalid messages that other toolkits would accept.
The key reason for being strict on read is to keep the protocols architecture simple and viable long term. Look at the browsers world - so much invalid html can be happily accepted, that it is simply impossible to describe the established profile. And therefore it is very hard to build a new implementation/fix existing implementations that would not break someone's page. We should make web services future cleaner.
If you really need Indigo to consume some invalid message, Vipul shared a great post here that will help.
This week (May 16th - 20th) we held WS-Management interop workshop in Redmond. Indigo participated among others. Three things I liked about this workshop:
1) Atmosphere - it's all about getting things to work, very much like in old soapbuilders days, pure interop fest. Sure there are some agreements to sign to ensure that feedback provided does not limit broad availability (as one of my favorite folks at MS put “welcome to 21st century”), but everything else is very informal.
2) Presence of both software and hardware among the 13 participating implementations. This trully shows the spec is mature and is set to succeed.Interoperability rate accomplished was impressive.
3) Imagine being able to discover everything about management interfaces without having to search the web about what particular methods this resource exposes and what types it works with. Indigo will provide great development framework for the WS-Management interfaces. Add Web Reference experience, generated Indigo proxy and VS intellisense - everything you need to explore management interfaces.