WCF services are powerful as you have just seen. It is possible to expose a single service in more ways than just one. This allows developers to support things like net.tcp binary messages and SOAP messages from the same service. If you are an enterprise developer supporting multiple clients this is a blessing since it means .Net consumers of your service can use TCP while other consumers use WS*. The nice thing is the developer doesn’t have to code it, just declaratively express how he wants the service configured.
For this example I have removed everything from the web.config file before launching so I can configure the service completely from scratch. Opening the web.config with the editor shows a blank configuration as follows.
Follow the steps to initialize the configuration.
Step 1
Make sure your solution builds.
Step 2
Click “Create a New Service” in the right panel of the editor.
Step 3
Browse to the bin directory and select the WcfService1.dll (if the file doesn’t show up, go back to step 1)
Double click this file and select your service implementation.
Step 4
The service type should be displayed on the previous screen. Press Next->.
Step 5
Select the contract. This should automatically be selected to WcfService1.IMyService. Press Next->.
Step 6
Since we are using IIS to host our service select the HTTP option for the communication mode.
Step 7
Select the basic web services interoperability. We’ll come back later on and add advance web services interoperability.
Step 8
Delete the “http://” from the address field. Since we are developing we don’t know which port this will get assigned as of yet.
Press Next->. A dialog will appear. Select Yes.
Press Finish on the next screen.
At this point we have an almost configured service. If you drill down into the Services folder within the tool down to the end point the configuration should look something like this.
Step 9
Let’s clean up our configuration. In the screen shot above in the configuration section. Give this endpoint a name of “Basic”. This will let us know later on this endpoint is our BasicHttpBinding configuration which supports the SOAP1.1 protocol.
Step 10
Click on the “Services” folder in the editor.
Step 11
Next to the binding configuration there is a link that says “Click to Create”. Click this link to create a binding configuration. While this isn’t necessary in all instances it is a good practice to have a binding configuration. This gives you more control over how your binding is configured and is a good practice to initialize early on.
Clicking this link will create a new binding. In the name field under the configuration section, give it a name of “Basic”. The defaults for this example are fine.
Note: Clicking on the Security tab in the above screen the Mode should be set to None.
At this point you should be able to save your configuration and press F5 in Visual Studio to launch your service in debug mode. You should be presented with a web page that looks like the following:
Step 1
Under the Advanced folder in the editor, select the “Service Behaviors”.
Click the “New Service Behavior Configuration” link in the right pane.
Step 2
Name the behavior “ServiceBehavior”. In the bottom section press the add button and select the “serviceMetaData” option and press Add.
The end result should look like the following.
Step 3
Under the “Service Behaviors” folder, select the newly created “ServiceBehavior” option and then the “serviceMetadata” option underneath that. In the right pane change the HttpGetEnabled to True.
Step 4
Select the service under the Services folder and apply the new service behavior to the service.
Step 5
Save the configuration and reload the service in the browser. The page should be changed to the following:
Clicking on the link should display the WSDL for the service.
At this point our service is configured to support the SOAP1.1 protocol through the BasicHttpBinding and is also exposing the WSDL for the service. What if we want to also expose the service with the SOAP1.2 protocol and support secure and non-secure messages? No problem. We can expose the service all of those ways without touching any code only the configuration.
Step 1
Under the Services folder select the EndPoints folder for the service and add a new service endpoint. Give it a name of WsPlain. This endpoint will serve as a standard SOAP1.2 message that isn’t encrypted. Change the binding to wsHttpBinding. In the address field, copy the address from your browser. In my case, my project used the address of http://localhost:5606/Service.svc. Paste this into the address field and add /WsPlain to the end of it so it looks like the following:
http://localhost:5606/Service.svc/WsPlain
Each binding for each endpoint has to have a separate address. Doing it this way allows us to keep our one service file and offer it up in various configurations. In the contract option browse to the DLL in the bin directory and select the contract used previously. The end result should look similar to this:
Step 2
Just as we did previously, click on the Services folder and create a binding configuration for this endpoint. Refer to step 10 and 11 above.
Provide a name of WsPlain for the new binding. In the security tab change the mode to “None” and set all other options to false or none. This is setting up our binding so there is no security on our message. By default the binding is configured to be secure.
The final settings for the WsPlain endpoint should be similar to this.
Step 3
To configure a secure binding using wsHttpBinding follow these same steps above but leave the default values in the security tab of the binding configuration. Call this end point and binding WsSecured. The new endpoint should look like this:
That’s it, our service is now configured three different ways and is configured to support SOAP1.1, SOAP1.2 and WS*. Pretty cool huh?
Setting Up Basic Http Binding
Before we add multiple bindings to our single service, let’s focus on adding one binding. In order to configure our service we are going to use the Microsoft Service Configuration Editor. This editor allows us to configure our WCF service and can be launched right from Visual Studio. To launch the editor, right click on the web.config file. An option should be in the menu that says “Edit WCF Configuration”. If it doesn’t don’t worry, sometimes, Visual Studio doesn’t pickup this option. A trick is to go to the tools menu in Visual Studio and select the editor from there. After the editor is launched it will then show up in the menu when you right click the web.config file.For this example I have removed everything from the web.config file before launching so I can configure the service completely from scratch. Opening the web.config with the editor shows a blank configuration as follows.
Follow the steps to initialize the configuration.
Step 1
Make sure your solution builds.
Step 2
Click “Create a New Service” in the right panel of the editor.
Step 3
Browse to the bin directory and select the WcfService1.dll (if the file doesn’t show up, go back to step 1)
Double click this file and select your service implementation.
Step 4
The service type should be displayed on the previous screen. Press Next->.
Step 5
Select the contract. This should automatically be selected to WcfService1.IMyService. Press Next->.
Step 6
Since we are using IIS to host our service select the HTTP option for the communication mode.
Step 7
Select the basic web services interoperability. We’ll come back later on and add advance web services interoperability.
Step 8
Delete the “http://” from the address field. Since we are developing we don’t know which port this will get assigned as of yet.
Press Next->. A dialog will appear. Select Yes.
Press Finish on the next screen.
At this point we have an almost configured service. If you drill down into the Services folder within the tool down to the end point the configuration should look something like this.
Step 9
Let’s clean up our configuration. In the screen shot above in the configuration section. Give this endpoint a name of “Basic”. This will let us know later on this endpoint is our BasicHttpBinding configuration which supports the SOAP1.1 protocol.
Step 10
Click on the “Services” folder in the editor.
Step 11
Next to the binding configuration there is a link that says “Click to Create”. Click this link to create a binding configuration. While this isn’t necessary in all instances it is a good practice to have a binding configuration. This gives you more control over how your binding is configured and is a good practice to initialize early on.
Clicking this link will create a new binding. In the name field under the configuration section, give it a name of “Basic”. The defaults for this example are fine.
Note: Clicking on the Security tab in the above screen the Mode should be set to None.
At this point you should be able to save your configuration and press F5 in Visual Studio to launch your service in debug mode. You should be presented with a web page that looks like the following:
Exposing Our Service’s WSDL
Unlike previous ASMX services, the WSDL (web service definition language) for WCF services is not automatically generated. The previous image even tells us that “Metadata publishing for this service is currently disabled.”. This is because we haven’t configured our service to expose any meta data about it. To expose a WSDL for a service we need toconfigure our service to provide meta information. Note: The mexHttpBinding is also used to share meta information about a service. While the name isn’t very “gump” it stands for Meta Data Exchange. Toget started configuring the service to expose the WSDL follow the following steps.Step 1
Under the Advanced folder in the editor, select the “Service Behaviors”.
Click the “New Service Behavior Configuration” link in the right pane.
Step 2
Name the behavior “ServiceBehavior”. In the bottom section press the add button and select the “serviceMetaData” option and press Add.
The end result should look like the following.
Step 3
Under the “Service Behaviors” folder, select the newly created “ServiceBehavior” option and then the “serviceMetadata” option underneath that. In the right pane change the HttpGetEnabled to True.
Step 4
Select the service under the Services folder and apply the new service behavior to the service.
Step 5
Save the configuration and reload the service in the browser. The page should be changed to the following:
Clicking on the link should display the WSDL for the service.
At this point our service is configured to support the SOAP1.1 protocol through the BasicHttpBinding and is also exposing the WSDL for the service. What if we want to also expose the service with the SOAP1.2 protocol and support secure and non-secure messages? No problem. We can expose the service all of those ways without touching any code only the configuration.
Adding More Bindings and Endpoints To Our Service
Now that we have the basic binding working let’s expose two additional endpoints for our service which support the WS* protocol but are configured differently. We’ll expose a plain SOAP1.2 protocol message using the wsHttpBinding that is a plain message as well as a secured message using the wsHttpBinding.Step 1
Under the Services folder select the EndPoints folder for the service and add a new service endpoint. Give it a name of WsPlain. This endpoint will serve as a standard SOAP1.2 message that isn’t encrypted. Change the binding to wsHttpBinding. In the address field, copy the address from your browser. In my case, my project used the address of http://localhost:5606/Service.svc. Paste this into the address field and add /WsPlain to the end of it so it looks like the following:
http://localhost:5606/Service.svc/WsPlain
Each binding for each endpoint has to have a separate address. Doing it this way allows us to keep our one service file and offer it up in various configurations. In the contract option browse to the DLL in the bin directory and select the contract used previously. The end result should look similar to this:
Step 2
Just as we did previously, click on the Services folder and create a binding configuration for this endpoint. Refer to step 10 and 11 above.
Provide a name of WsPlain for the new binding. In the security tab change the mode to “None” and set all other options to false or none. This is setting up our binding so there is no security on our message. By default the binding is configured to be secure.
The final settings for the WsPlain endpoint should be similar to this.
Step 3
To configure a secure binding using wsHttpBinding follow these same steps above but leave the default values in the security tab of the binding configuration. Call this end point and binding WsSecured. The new endpoint should look like this:
That’s it, our service is now configured three different ways and is configured to support SOAP1.1, SOAP1.2 and WS*. Pretty cool huh?
No comments:
Post a Comment