Is there a way to retrieve wcf binding type and security mode just from a wsdl?
i.e. I want to know what bindings are supported by a wcf service by reading it's wsdl, is it possible?
Thanks
No - the WSDL only defines what operations are available on your service - plus it is totally unaware of and independent of WCF.
The only thing that might be included in WSDL (depending on where it came from) are certain bits of information about security needed, e.g. whether to connect using http vs. https, or other tidbits.
Marc
Related
In WCF there are several different types of HTTP based bindings:
BasicHttpBinding
WsHttpBinding
WebHttpBinding
What are the differences among these 3?
In particular what are the differences in terms of features / performance and compatability?
You're comparing apples to oranges here:
webHttpBinding is the REST-style binding, where you basically just hit a URL and get back a truckload of XML or JSON from the web service
basicHttpBinding and wsHttpBinding are two SOAP-based bindings which is quite different from REST. SOAP has the advantage of having WSDL and XSD to describe the service, its methods, and the data being passed around in great detail (REST doesn't have anything like that - yet). On the other hand, you can't just browse to a wsHttpBinding endpoint with your browser and look at XML - you have to use a SOAP client, e.g. the WcfTestClient or your own app.
So your first decision must be: REST vs. SOAP (or you can expose both types of endpoints from your service - that's possible, too).
Then, between basicHttpBinding and wsHttpBinding, there differences are as follows:
basicHttpBinding is the very basic binding - SOAP 1.1, not much in terms of security, not much else in terms of features - but compatible to just about any SOAP client out there --> great for interoperability, weak on features and security
wsHttpBinding is the full-blown binding, which supports a ton of WS-* features and standards - it has lots more security features, you can use sessionful connections, you can use reliable messaging, you can use transactional control - just a lot more stuff, but wsHttpBinding is also a lot *heavier" and adds a lot of overhead to your messages as they travel across the network
For an in-depth comparison (including a table and code examples) between the two check out this codeproject article: Differences between BasicHttpBinding and WsHttpBinding
If your are getting missing service namespace reference when copying your files to the web server, try the following. We found that publishing the project and copying out the App_WebReference.dll file in to the bin folder will fix that. Using the bindings that are generated from adding the service into your project found in the web.config can then be copied to your servers web.config .
Is it possible to add a service reference in visual studio, which generates the local proxy class to call the WCF service when using the netTcpBinding?
As I understood it, the service reference method requires a WSDL to be exposed by the service, which is only supported by the http bindings no?
Perhaps, could I add the service reference locally in development, but then switch the configuration to use nettcp at runtime in production?
The reason I am asking is because I am hosting in a windows service (server 2003, so no WAS, and can't use IIS). And we are unable to change the permissions to do the HTTP namespace reservation ... so we can't use the HTTP bindings. NetTcp works, but in this specific case the object graph we're passing back and forth involves objects generated in the service by an EDMX model ... so we can't share it in a contract assembly.
Thanks in advance!
Simply add a binding using mexTcpBinding.
Is it possible to add a service reference in visual studio,
which generates the local proxy class to call the
WCF service when using the netTcpBinding?
Yes, most definitely!
As I understood it, the service reference method requires a WSDL
to be exposed by the service, which is only supported by the http bindings no?
No, definitely not - WCF metadata (either its own specific format, or exposed as WSDL / XSD files) is definitely available for all SOAP-based calls - regardless of their transport.
Can you show us what you have, in terms of server-side config? Most likely, you're just missing a little config setting or something - if we see what you have, we might be able to pinpoint that and help you more!
All bindings are exposed though WSDL. If you add the NETTCP bindings svcutil will atuo generate the client correctly. I haven't used it in the ADD reference in VS as i have always preferred to generate the class with svcutil.
I am learning WCF,one of the benefits of WCF is that you can use WCF even the client and service are not in the same network.Can anyone explain why?
Why using normal asp.net services, .NET remoting or Windows enterprise service client and service have to be in the same network?
Another question is that does the client needs to have a service contract interface and data contract? I assume not ,but how the client understand the type returned from the WCF services?
Edit: Reflecting More comments
A primer on WCF (such as What Is Windows Communication Foundation?) is a good place to start. WCF can use SOAP to implement the contracts way down deep. WCF also uses a variety of communication facilities within windows (and any custom ones you want to create) so talking across machines is built in.
The very essence of contract (IMO) implies that this is present on both sides of the communication. In a pure .net cases I've usually put the contract definitions in separate assemblies and share them. In other places I've used WSDL to be the main contract definition so that the client and service share definitions.
Edit: Answering comments
You can knock up simple examples of communication in WCF easilyy (provided you know the basics of comms on windows including firewalls etc). However doing something custom is not easy but there are many many resources on the web and books to help you get there.
The books i used:
http://www.amazon.com/Programming-WCF-Services-Juval-Lowy/dp/0596526997
http://www.amazon.com/Essential-Windows-Communication-Foundation-WCF/dp/0321440064/ref=pd_bxgy_b_img_c
http://www.amazon.com/Inside-Windows-Communication-Foundation-Developer/dp/0735623066/ref=sr_1_1?ie=UTF8&s=books&qid=1252111759&sr=1-1
Another question on SO with a set of resources is "WCF for the Totally Clueless"
I don't know where you read that a benefit of WCF is that it allows the client and server to be on different networks. They can already be on different networks using .NET Remoting or DCOM (Enterprise Services).
The client does need to know the service contract and any other contracts required in order to use the service. This can be provided through WSDL or the Metadata Exchange Protocol (mex). If using .NET on both sides, then it is possible to share the contract assemblies, but this introduces a coupling between client and service.
Previous Microsoft technologies were designed for some specific needs in particular environment. For example ASMX Web Services were designed to send and receive messages using SOAP over Http only. .NET Remoting specific to Microsoft environment, no interoperability. But WCF is designed to send and receive messages using any format (SOAP as default) over any transport protocol i.e. HTTP, TCP, NamedPipes, MSMQ etc.
And your second question "but how the client understand the type returned from the WCF services?"
Its through proxy, client interacts with proxy which contains all the types etc.
You can find a good concepts and questions here for understanding WCF core concepts.
I use the term network services to refer to things such as NNTP, IMAP, POP3... things which have a defined protocol layered on top of TCP/IP.
I'm having a very difficult time figuring out how I can connect to an existing network service using a WCF client. I haven't found any examples other than ones that are basically using C#-ified socket code.
Can anyone refer me to any examples of using WCF to talk to a legacy service as something other than a glorified socket?
Is WCF even appropriate for this type of requirement?
Thanks.
WCF comes with a set of standard bindings, here is a list of the bindings provided in 3.5:
http://msdn.microsoft.com/en-us/library/ms730879.aspx
If you need to use anything else, WCF is probably not the way to go. Even if you could build your own binding, the cost would outweigh the benefit.
If you have a requirement in your project that everything should use WCF, you could build a WCF facade over your sockets code.
Well, the term "WCF" actually means 2 things:
The framework: "ABC" - Address, binding, contract
Actual use of a combination of the above (for example, a WCF webservice using BasicHttpBinding)
There's not built in bindings for the protocols you mentioned, which is why the examples you'll see looks like "glorified sockets" - That's what they are. That's what a binding is: A level of abstraction built on a basic protocol (typically UDP/IP or TCP/IP).
Now, with all this being said, you need to build / borrow / steal / whatever a binding that is usable with your protocol of choice. This might look like you're just injecting sockets into the WCF framework, and honestly, that's just what it is :)... So what's so great about it?
If you managed to implement your binding to-the-specs, you got yourself a very easily substituted component, which will fit into all WCF applications. Whether you want this behaviour or not, is up to you and your requirements :)
Good luck with it.
Well, WCF at its heart is the unified communication engine offering by Microsoft, based on SOAP - it replaces ASMX web services, WSE, .NET Remoting and more.
As such, it's SOAP based and therefore can talk to anything that talks SOAP - which I doubt is the case for POP3 or other services. So I don't think you can write a WCF client for these services, really.
As for writing these services from scratch and exposing them as WCF services - that might work, since basically the WCF service implementation can do anything, and then present itself to the outside world as a SOAP service - could work, question is: what's the benefit?
Marc
i have been reading a little about REST services and i would love to know more.
I wonder if anyone can confirm, currently we have a wcf web service (ending in .svc) and we have many clients accessing (i.e. form linux, max and PC) ...
if i was to change my server to use REST then would the clients break?
If you CHANGE the service to be a RESTful format, then yes...existing clients would have to change.
If you ADD a RESTful endpoint and kept the existing endpoint as well, then no...existing clients could continue to use the old endpoint until they migrated their code to use the new RESTful endpoint.
Well, the two world are really SOAP vs. REST.
The "normal" WCF services using NetTcpBinding, basicHttpBinding, wsHttpBinding etc. are all using SOAP - your message is embededded in a SOAP envelope and sent across the wire, and the response comes back the same way. That's why you can't just point your browser to a WCF service and get data - browsers can't send and receive SOAP messages.
Advantages of SOAP: you have things like WSDL/XSD to clearly and very strictly define what your service does and what kind of data you send around.
REST is a totally different beast - no more SOAP, no more WSDL and XSD, no more creating a client that knows about the data types being shuffled back and forth - you just have URL's which represent resources, and you get back some XML - not a whole lot of system support for describing WHAT that XML will be - you'll have to hope the developer of the REST service provides some documentation about what can be retrieved, and what it looks like.
So REST is a totally different beast than SOAP, and it's implemented in WCF using the webHttpBinding.
So if you have existing "traditional" WCF service and clients, and you now switch your service to REST, then yes - 100% sure you'll break EVERY client....
Marc