We have a WCF service that has operations which receive a List of data contract objects as their parameter and return a List of different data contract objects eg.
List<CheckOutResponse> ProcessCheckOut(List<CheckOutRequest> obj);
This service is currently being consumed by a WCF client and it works great.
We now need to expose the same service to a legacy application built on .NET 1.1. I understand the binding changes that I need to make in the service's web.config, use the basicHttp binding and set the correct service behavior etc.
My problem is the data contracts. I believe that the .NET 1.1 clients use the XMLSerializer and this cannot work with data contracts.
I really don't want to change the data contracts to some other .NET 1.1 compatible complex types because we'd then need a load of regression testing with the existing WCF client.
Has anyone worked out a solution to this problem?
There should be no problem with the serialization. The .NET 1.1 client will simply see a structure that places the values into elements instead of attributes.
Related
I'm writing a WCF services that will be exposed to number of customers. Some customers use .NET client and other use Java and php etc.
When developing the WCF Services do I need to worry about whether consumers will be .NET or others? In other words, if I return .NET collections i.e List will the Java client deserializes this easily or should I only return primitive types e.g. Array.
Thank you in advance.
As long as you do the "normal" WCF development workflow - no.
WCF is designed from the group up to be as interoperable as possible; anything you can express in the WSDL/XSD that describes your service should be useable by other systems, e.g. Java or others.
You cannot however use .NET specific "trickery" to get around some of WCF's limitations (e.g. sharing contract assembly between server and client) - those wouldn't be portable. Also: you cannot use any .NET specific types that aren't serializable in your data contracts.
No lists will not be an issue for java etc. Try to use the basicHttpBinding binding for maximum compatibility.
Is it possible to use oData with a WCF service application but not use WCF Data Services?
It will be great if someone could shed more light on oData. I have done some Googling on this topic, but whenever I search for "wcf odata", I get information about WCF Data Services.
Any help/links will be appreciated.
WCF Data Services is the Microsoft implementation of the general OData protocol. As such, only WCF Data Services are / support / implement OData - a "normal" WCF service does not (and can not).
You might need to elaborate exactly why you feel the need or urge to use OData but not use WCF Data Services. What's the issue / problem you have with that setup? WHY do you want to use only a "normal" WCF service??
Update: ok, so you want to have services that expose data in different fashions and with different methods. What you could do is create a regular WCF service that's exposing both SOAP endpoints as well as a webHttpBinding REST endpoint. This will work - but then it's a "regular" WCF service, with methods that take parameters and return some data structure. This is not WCF Data Service (OData).
OData is more of a "here's my data collection, you can browse around in it" kind of approach - it's more about exposing an entire data model to the outside world using REST. This doesn't mix and match with SOAP - which is a lot more procedure-oriented, e.g. LoadCustomer, SaveInvoice and so forth.
So while it's absolutely possible to have procedure-oriented WCF services exposing both SOAP and REST endpoints at the same time, I don't really see how you can mix and match the "expose-this-resource" kind of approach for WCF Data Services / OData with a SOAP binding - this just doesn't work, I believe.
So if you must expose your data model of WCF Data Services (OData), you will need to author a second, pretty different looking regular WCF services for the SOAP clients, that might be based on the same data in the end (access the same database, for instance), but it's "face" will look quite different.
There is a new(ish) project from Microsoft called WCF WebApi (NuGet Package), which is simplifying doing RESTful WCF. It really takes to heart the "Representation" part of REST, so that you can expose your data in many representations (JSON, XML, oData, PNG, etc) based on content negotiation (or optionally whatever convention you want) all from the same service contract operation. Currently baked into the framework is the ability to support oData GET queries, by simply returning a collection .AsQueryable().
While this isn't a pure WCF/oData solution, as your question is speaking to, I thought I would mention the project in case it fit your specific requirements. The current Go-Live licensing might prove prohibitive, as might the "preview" status of this code; but if not, this may be a solution for you.
* UPDATE * This project was rolled into ASP.NET (usually in conjunction with ASP.NET MVC) and is no longer under the WCF team. The new product is called ASP.NET WebAPI.
I am going develop a WPF windows based application. I want to work with Entity Framework Self Tracking Entities and WCF. I was wondering if using Json is possible/recommended? If yes, please assist me; is there any tutorial that can help?
You can use the DataContractJsonSerializer to serialize the messages. You will have to use a REST based service (WebHttpBinding) as SOAP mandates XML as the message payload.
You can tell WCF to use the DatcontractJsonSerializer on the service side by settings in the WebGet and WebInvoke attributes but on the client side you will have to manually use this serializer as REST doesn;t have a metadata standard and therefore you have to create the requests and manage responses in a more manual fashion
Here is a reasonable guide to using Json and REST support in WCF
However, what is your driver to using Json? WCF is much more geared to SOAP based interaction currently (although the WCF 4.5 WebApi is going to address that to quite a degree). As your client is WPF you don't seem to gain alot from using Json
I have a custom data entity (data object) that is exposed via a WCF webservice. The WCF service lives in a web application. I then have a Silverlight application with a service reference to that WCF service. When i add the service reference a proxy is generated, and that includes a version of the custom data entity.
How should i structure my code so that the data entity is declared in one place, and shared amongst the project containing the WCF service and any Silverlight applications that reference it? I want to eliminate the version of the data entity that is generated with the proxy.
There is a good example of how to do this here by Pete Brown. Using that approach you can use the same classes in both the Silverlight client and in the WCF service without having to use the generated objects.
Declare the data entities in the WCF service or a project that the service refereneces, then from the Silverlight project add the entities as links and make sure the "Reuse types in referenced assemblies" checkbox is selected from the Service Reference Settings dialog.
You can put the types in either the Silverlight or WCF side.
I have tried doing things this way and found that using DTOs instead and mapping them to the entities in the Silverlight side to be much cleaner and easier to work with although I did write a bunch of mapping code to get the DTOs into the entities and vice versa.
I´m not quite shure why anybody want to do that. You have to understand that the type you find in the proxy is a projection of the Type you have at Service server site. It´s defined in the *.g.cs files and gets generated new if you update the service reference.
In my opinion it´s the best way to have it declared in a single location, and project it. You need it in two places and it´s single defined.
I may be wrong anyway .....
Does anyone know of any problems with using WCF to expose a SOAP interface for non .NET clients? For example incompatibilities with other SOAP libraries?
This is so that the SOAP interface can be exposed for third parties to integrate with our software.
Some of the problem areas I've encountered with WCF:
It generates WSDL that is split
across multiple URLs. That is, one
part of the schema is at one URL,
another is at a different URL, etc.
The "main" WSDL URL (the one with
just "?WSDL" after the service name)
references the others via xsd:import
elements. Many SOAP clients (eg pre-.NET Delphi) have enormous difficulty with this idiom. So you really have to "flatten" your WSDL in order to achieve interoperability in practice. One solution is given here.
WCF doesn't generate XML namespaces
the same way as, say, ASMX web
services. WCF has a tendency to
place any service or data contract
into a namespace of its own
choosing. Again, some SOAP clients have difficulty with this. You can increase you interoperability level by adding an explicit namespace to your ServiceContract and DataContract attributes.
Many SOAP clients won't handle
faults as nicely as WCF clients. For example,
the proxy generation code won't
create client-side objects for the
faults declared in the WSDL. The
faults will still be transmitted to
the client, of course, but the
client then has to do more work to
figure out what kind of fault it
was.
versions of the WS-* standards stack can also be an interoperability issue - for example the version of WS-Addressing (2003) supported by some java implementations eg Oracle BPEL is not supported by WCF which supports the later draft and 1.0 versions but not the earlier 2003 one
Generally everything works fine. It will obviously depend on the client you're using - not everyone implement SOAP properly.
P.S. Could you please rephrase your question if you hope for more specific answer?