when creating a WCF RESTful service, part of the configuration includes creating a service endpoint. Something like the below
<service name="MyService" behaviorConfiguration="serviceBehavior">
<endpoint address="" binding="webHttpBinding" bindingConfiguration="UsernameWithTransport" contract="IMyService" behaviorConfiguration="web"></endpoint>
</service>
My question is, what exactly is the contract provided for? Does it provide some sort of information to the browser that tries to access it?
In WCF The contract (ContractDescription) is a collection of operations that specifies what the endpoint communicates to the outside world. Each operation is a message exchange. For example, a request message and an associated reply message form a request/reply message exchange.
A ContractDescription object is used to describe WCF contracts and their operations. Within a ContractDescription, each contract operation has a corresponding OperationDescription that describes aspects of the each operation that is part of the contract, such as whether the operation is one-way or request/reply. Each OperationDescription also describes the messages that make up the operation using a MessageDescriptionCollection. ContractDescription contains a reference to an interface that defines the contract using the programming model. This interface is marked with ServiceContractAttribute and its methods that correspond to endpoint operations are marked with the OperationContractAttribute.
The contract is also important because you can expose distinct service contracts in a single WCF service.
Related
I have a single service, one backing binary, that I want to configure to have two different endpoints. The problem is, I want a different serviceBehavior for each endpoint, to specify different security requirements.
E.G:
<service behaviorConfiguration="behavior1" name="MyServiceClass">
<endpoint address="endpoint1" bindingConfiguration="binding1" contract="IMyServiceContract"/>
</service>
<service behaviorConfiguration="behavior2" name="MyServiceClass">
<endpoint address="endpoint2" bindingConfiguration="binding2" contract="IMyServiceContract"/>
</service>
Is such a WCF configuration valid, or attainable in another format?
I'm not sure you can do it from config only, but there exists a code and config solution based around the extensibility point exposed by the IEndpointBehavior interface. This allows you to define behaviors at the endpoint level.
It's not particularly well documented as I don't think it's used very often. According to MSDN:
Endpoint behaviors, which implement IEndpointBehavior, are the primary
mechanism by which you modify the entire service or client run time
for a specific endpoint.
There are two mechanisms for adding endpoint behaviors to a service.
Add the behavior to the Behaviors property.
Implement a custom BehaviorExtensionElement that extends
configuration.
Specific examples of the first option exist here, and here, but I can't find anything about the second.
What is the difference between the Service node/section and the Client node/section in the configuration section? Why configure endpoints in one section over the other? Which is best for interoperability?
I'm currently building a service that talks to another service. I have endpoints for my clients and endpoints for the other service. Visual Studio seems to lump all the endpoints into the Client section.
I thought that client node was for your consumption and service node was for producing. But when you create a new wcf service visual studio puts your new service endpoint settings under the client node. I have moved my endpoint between both sections trying to figure out what the difference is.
When should I use service over client?
<system.serviceModel>
<services>
<service> <!--I noticed some tutorials and using wcf config edit tool
puts producer endpoint settings here -->
<endpoint blah settings/>
<endpoint blah settings/>
</service>
</services>
<client> <!--Visual Studio puts both producer and consumer endpoint
settings here -->
<endpoint blah settings />
<endpoint blah settings />
<endpoint blah settings />
</client>
<bindings>.....
</system.serviceModel>
Many settings in the WCF web.config (or app.config for that matter) can be shared for both consumers of a service as well as publishers of a service including:
Bindings
Endpoint Behaviors
Diagnostics
However as you have discovered, some config is specific to a service. A well-written service usually specifies:
It's base address. This is a convenience when defining a service as it allows your to define endpoints using relative addresses. Clients however don't use this particular setting as they need an absolute path. For this reason it makes no sense to specify in the section
Services can also be clients. If the client and server endpoints were all plonked together, WCF would not be able to know which should utilise the base address for one thing
Service behavior
By dividing up config between client and server, WCF is better able to know where to look for endpoints.
Which is best for interoperability?
I don't think that has anything to do with it. WCF is a means to achieve interopability but just by using WCF does not imply you will achieve it. Interopability is established when both parties agree on say a particular service contract; canonical data model; data transformation; message version or many of the other patterns as defined by SOA Patterns.org So there are various patterns you must follow. e.g. If you change a method on service contract but have not updated the clients then you have broken interopability by breaking the schema of the service.
Visual Studio seems to lump all the endpoints into the Client section
If your WCF process is both a consumer and producer of WCF services then it should not be putting all the endpoints under
I am new in WCF. I know that we have to write endpoint in config file at service end and as well as client end. suppose I have multiple endpoint like
<services>
<service name="YourNamespace.YourService" behaviorConfiguration="Default">
<endpoint name="Default"
address="http://YourServer/Services/MyService"
binding="basicHttpBinding"
contract="YourNamespace.IYourService"/>
<endpoint name="TCP"
address="net.tcp://YourServer/ServicesTCP/MyService"
binding="netTcpBinding"
contract="YourNamespace.IYourService"/>
<endpoint name="Dual"
address="http://YourServer/Services/MyService/Dual"
binding="wsDualHttpBinding"
clientBaseAddress="http://localhost:8001/client/"
contract="YourNamespace.IYourDualService"/>
<endpoint name="mex"
address=""
binding="mexHttpBinding"
contract="IMetadataExchange"/>
</service>
</services>
we know that we can not create proxy at client side with endpoint address like
http://YourServer/Services/MyService/Dual or
net.tcp://YourServer/ServicesTCP/MyService
rather if we need to create proxy at client side then we need to provide mex endpoint address. so I just do not understand what is the use of endpoint address?
When we create proxy at client side and call service then we just do not understand our proxy is using what endpoint address to connect to service?
That is why I just want to know how endpoint address come into role?
I know that we can write separate mex endpoint for tcp in config file as a result we can create proxy with that mex url as a result when client would connect to service then tcp protocol will be used for communication but for other http endpoints one mex endpoint works fine.
My important question is which I really like to know that suppose i have 3 endpoints like basichttp,wshttp,wsdualbidning then one mex endpoint works for all of them to create proxy. so tell me in that case when client connect to service then which endpoint address will be used to connect to that service?
It will be great help if some one discuss this issue with great detail and with sample config entry and as well as sample service code?
UPDATED Part
Tom Redfern said...service endpoints is not required in case of internal use. suppose I have developed a service which is hosted in console apps and other client need to connect to that service. so tell me in this case how client can connect to service without proxy class and call various method of service. I just like to know without proxy how can I connect and call various method of wcf service. please come with some sample code for client side just to show how programmatically I can connect and call various method of wcf service without proxy.
An endpoint needs a way of addressing it. This is both fundamental and reasonable.
Your argument that the client only requires a metadata endpoint address in order to resolve the actual service endpoints only holds true when you are exposing a metadata endpoint (which is by no means required) and when the consumer has no other means to consume the service (perhaps the service is public).
Most services are developed for internal consumption where the ability to bind directly to an endpoint via referencing a shared types assembly (rather than via a service proxy) is commonplace. Knowledge of the endpoint address in these instances is absolutely required.
If you read about the history of UDDI, this was designed as a means to distribute service metadata to consumers who would have no need to know anything else about the service. However, how often do you see a UDDI server? I have seen it used in exactly one company (I have worked in about 20 in total).
I am trying to find some good tutorials that would show me to create a simple SOAP based service using WCF and deploy it. I have been googling for the past 2 hour and can't seem to find any good resource.. Can anyone help me?
As for resources: there's the MSDN WCF Developer Center which has everything from beginner's tutorials to articles and sample code.
Also, check out the screen cast library up on MSDN for some really useful, 10-15 minute chunks of information on just about any topic related to WCF you might be interested in.
Also very good are The Service Station articles in MSDN magazine on various aspects of WCF - some more basic like Serialization in WCF or WCF Bindings in Depth, some more advanced and esoteric - but always worth a look!
Update: for learning WCF and SOAP, check out e.g.
Getting Started Tutorial
First Steps Screencast about WCF (using SOAP!)
and a great many more - there are a ton of tutorial and learnings materials on WCF using SOAP bindings - not just REST stuff for sure!
REST / SOAP endpoints for a WCF service
You can expose the service in two different endpoints. the SOAP one can use the binding that support SOAP e.g. basicHttpBinding, the RESTful one can use the webHttpBinding. I assume your REST service will be in JSON, in that case, you need to configure the two endpoints with the following behaviour configuration
<endpointBehaviors>
<behavior name="jsonBehavior">
<enableWebScript/>
</behavior>
</endpointBehaviors>
An example of endpoint configuration in your scenario is
<services>
<service name="TestService">
<endpoint address="soap" binding="basicHttpBinding" contract="ITestService"/>
<endpoint address="json" binding="webHttpBinding" behaviorConfiguration="jsonBehavior" contract="ITestService"/>
</service>
</services>
so, the service will be available at
http://www.example.com/soap
http://www.example.com/json
Apply [WebGet] to the operation contract to make it RESTful. e.g.
public interface ITestService
{
[OperationContract]
[WebGet]
string HelloWorld(string text)
}
Note, if the REST service is not in JSON, parameters of the operations can not contain complex type.
For plain old XML as return format, this is an example that would work both for SOAP and XML.
[ServiceContract(Namespace = "http://test")]
public interface ITestService
{
[OperationContract]
[WebGet(UriTemplate = "accounts/{id}")]
Account[] GetAccount(string id);
}
POX behavior for REST Plain Old XML
<behavior name="poxBehavior">
<webHttp/>
</behavior>
Endpoints
<services>
<service name="TestService">
<endpoint address="soap" binding="basicHttpBinding" contract="ITestService"/>
<endpoint address="xml" binding="webHttpBinding" behaviorConfiguration="poxBehavior" contract="ITestService"/>
</service>
</services>
Service will be available at
http://www.example.com/soap
http://www.example.com/xml
REST request try it in browser,
http://www.example.com/xml/accounts/A123
SOAP request client endpoint configuration for SOAP service after adding the service reference,
<client>
<endpoint address="http://www.example.com/soap" binding="basicHttpBinding"
contract="ITestService" name="BasicHttpBinding_ITestService" />
in C#
TestServiceClient client = new TestServiceClient();
client.GetAccount("A123");
Another way of doing it is to expose two different service contract and each one with specific configuration. This may generate some duplicates at code level, however at the end of the day, you want to make it working.
WCF is a technology for building services. It does not assume that the services are SOAP services or RESTFul or anything else. You have to learn WCf basics such as Service and DataContracts, Endpoints, Bindings etc to be able to work with any kind of service.
The links given marc_s are very helpful for that.
Now as far as SOAP is concerned, it is a format\technology used to transport messages from one endpoint to another. This details is covered by the Binding aspect of the WCF. When you expose and consume services you just have to choose a Binding which uses SOAP.
Hence, you should, using links given by marc_s, learn WCF basics to build a service. Then you will know how to build a service and which binding to choose to use SOAP.
Hope this helps.
How many ServiceContracts can a WCF service have?
Specifically, since a ServiceContract is an attribute to an interface, how many interfaces can I code into one WCF web service? Is it a one-to-one?
Does it make sense to separate the contracts across multiple web services?
WCF services can have multiple endpoints, each of which can implement a different service contract.
For example, you could have a service declared as follows:
[ServiceBehavior(Namespace = "DemoService")]
public class DemoService : IDemoService, IDoNothingService
Which would have configuration along these lines:
<service name="DemoService" behaviorConfiguration="Debugging">
<host>
<baseAddresses>
<add baseAddress = "http://localhost/DemoService.svc" />
</baseAddresses>
</host>
<endpoint
address =""
binding="customBinding"
bindingConfiguration="InsecureCustom"
bindingNamespace="http://schemas.com/Demo" contract="IDemoService"/>
<endpoint
address =""
binding="customBinding"
bindingConfiguration="InsecureCustom"
bindingNamespace="http://schemas.com/Demo" contract="IDoNothingService"/>
</service>
Hope that helps, but if you were after the theoretical maximum interfaces you can have for a service I suspect it's some crazily large multiple of 2.
You can have a service implement all the service contracts you want. I mean, I don't know if there is a limit, but I don't think there is.
That's a neat way to separate operations that will be implemented by the same service in several conceptually different service contract interfaces.
#jdiaz
Of course you should strive to have very different business matters in different services, but consider the case in which you want that, for example, all your services implement a GetVersion() operation. You could have a service contract just for that operation and have every service implement it, instead of adding the GetVersion() operation to the contract of all your services.
A service can theoretically have any number of Endpoints, and each Endpoint is bound to a particular contract, or interface, so it is possible for a single conceptual (and configured) service to host multiple interfaces via multiple endpoints or alternatively for several endpoints to host the same interface.
If you are using the ServiceHost class to host your service, though, instead of IIS, you can only associate a single interface per ServiceHost. I'm not sure why this is the case, but it is.