I've been playing around with WCF and I have managed to a WCF service to generate both SOAP, POX, and JSON formats pretty easily based on this example (I added the soap config).
http://www.c-sharpcorner.com/UploadFile/ashutosh.shukla1/3040/Default.aspx
And I see that if you add a timestamp field to your data base tables you can actually have a plain old WCF service work with Linq to SQL via this-
http://jonkruger.com/blog/2008/02/10/linq-to-sql-in-disconnectedn-tier-scenarios-saving-an-object/
I'm still a little confused about WCF vs WCF Data Services vs WCF Ria Services. I guess my goal and my question is.
Is it possible to write one service with multiple endpoints that does it all...POX, JSON, Java client compatible SOAP 1.1 with https and user name/password protection, and OData secured with https possibly as well? If so that sounds amazing, as I can create a self hosted uber data provider service that offers numerous ways clients can connect and use data.
Are we there yet? If so what do I use (still confused on the differences)?
Related
I have created a WCF service and hosted it through self hosting. This service doesn't have any metada published.
First Question
Can I consume it through Visual Studio, Add Service Reference? Hopefully not.
Can I consume it by creating manual proxy, i.e. ChannelFactory<ServiceContract>....?Hopefully yes.
Now in the second scenario, the client must be .Net, right?
So it implies that, to consume a wcf service on a non-.net platform, we have to expose its metadata?
Can't a WCF service without metadata, consume by Ajax client, or say Java client??
There are 3 options to consume a WCF Service:
If the service exposes a WSDL use "add service reference" from VS (or an equivalent from another platform). Note that if you do not want to expose the WSDL you could expose it just temporarly, save the WSDL in a file, and then send it to user in any platform to generate proxy from it. You can turn off the WSDL immediately after you save it. Also note that even if the WSDL is not exposed still you need to protect the web service from unauthorized access.
If this is a .Net client it can compile with the same Service Contract assembly and use ChannelFactory etc.
Any platform can send raw soap message (e.g. XML) to the service. Of course they need to know what is the right format. A WSDL can help but even without it if they have a working sample they can imitate it.
WCF provides REST (Representational State Transfer) support to consume it by non .NET client like JavaScript (AJAX), java, Objective C, web browser, etc...
Basically WCF REST is exposes methods and transferring data over the HTTP protocol and it supports all HTTP operations (GET, POST, PUT, and DELETE). This feature is making it platform independent as well as it doesn’t require metadata exposed.
Please refere below links to get more about WCF REST:
An Introduction To RESTful Services With WCF
WCF REST Programming Model Overview
WCF Rest vs. WCF SOAP
Create RESTful WCF Service API: Step By Step Guide
I have built a web service (WCF) as part of our company product, to support mobile devicies. The service is exposed via SOAP and is consumed by Android and Windows Phone 7 clients. Now we are spreading and need to add support for iPhone clients and those lazy iPhone developers are complaing, that they won't use SOAP, because its terrible, microsoftish, bloatware and there is no sufficient framework for that, etc etc and JSON ftw!
As it is WCF it was easy to create json api for this web service (new interface and little changes in web.config, love WCF!), the only problem is that I am using the built-in WCF Authentication service for authorization and this service is of course exposed via SOAP and I didn´t find a way to make it REST with json. So is there a way to somehow make it RESTful and consume/respond json?
My actual plan is to make another auth service, that will internally just call the existing WCF one via SOAP, but I don't like this workaround. I assume that, if there is not a way to make the WCF one RESTfull, later or sooner, I end up writing the auth service, which in my opinon will not be that hard.
I've been told that adding an HTTP RPC web service given an existing SOAP web service implemented with WCF is as simple as adding a webHttpBinding and a couple of attributes.
I'd be grateful if someone could show how to implement such an HTTP RPC web service using webHttpBinding given an existing SOAP web service that is based on WCF. It would be super helpful if the answer could show all the code for both services and even more helpful if the example is self-contained so that someone could install for testing without having to know anything about either. FYI, while I have programmed on the .NET stack it's been ~5 years and today all my work is on LAMP so I'm just not familiar enough with the latest generation .NET stack or it's current runtime environments.
My specific use-case is a set of two (2) services where one responds with an AuthToken and then a second service where I pass the AuthToken and Username, Password and another bit of information and the response back is a user object with attributes like 'first_name', 'last_name', etc. Ideally I'd be able to access those same services via two different URLs and the responses I would get back would be in JSON format.
Note I'm looking for an example to be installed by someone else who programs on the .NET stack but isn't highly motivated to do won't much extra work. I'm trying to get an HTTP-based web service I can use without having to add a SOAP client to the existing PHP framework I am using and I think if I could get a concise example of how to add such an HTTP RPC web service the .NET programmer might be happily willing to add the HTTP RPC web service for my needs. FYI, the web service in question was developed specifically for this use case and is not part of a standard set of SOAP services documented for and in use by lots of other developers.
I have a web service that is used by many different clients using many different languages.
I want to switch it to wcf to take advantage of the many different endpoints.
However what has been stopping me is that I am afraid that the clients will have to use a special sdk to connect (if they are using java or php or some other language) that is different then the sdk they use to connect to the existing web service.
Is this true? Or is connecting to WCF the exact same as it is for web services in other languages.
The project I am currently working on has multiple WCF configurations, some are using the default SOAP implementation, and some are using a POX (plain-old-xml) style message.
So the short answer is 'yes' you can configure WCF in such a way to work with just about anything.
However, be warned that as soon as you step outside the default little box that WCF has set up for you, it gets pretty complicated. You end up with a lot of custom message parsing and security handling if you go to a POX message format. Its easier if you stick with SOAP though.
As for needing a 'special SDK' you won't. You can communicate with WCF with simple HTTP POST messages if needed.
I have clients that are using VB.NET apps (using SOAP) and Java apps (using POX) to hit my WCF services.
A basicHttpBinding endpoint in WCF is exactly a standard SOAP endpoint, and your Java or PHP clients will not have to change in any way.
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