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.
Related
We are migrating our .net Remoting app to use WCF. One thing that confuses me now is the concept of "Known types" that WCF introduced but not needed by Remoting. While I am sort of understand what the known types are and what they do, what I am confused about is the difference between WCF and Remoting - On the sender's side, if WCF doesn't have enough type information about the object at hand to serialize it, why does Remoting? Same for the receiver: Why .net Remoting doesn't have a problem deserializing an object received but WCF does? Is that because Remoting sends metadata along with the data? If so why can't WCF do the same?
You're correct - .NET remoting sends type metadata with the requests. WCF can do the same, but by default it doesn't - it's a lot of extra information which makes the requests larger and more complex to process (affecting performance). Not sending the type information also allows for loosely coupled systems, where the client and the server can version separately, and as long as they adhere to the contracts established in the original version, they will continue working. And it also allows for WCF to talk to systems written in non-NET platforms (which isn't possible with remoting or other technologies which rely on shared type information).
If you really want to go with the non-known-types way, you can replace the default serializer used by WCF (the DataContractSerializer) with the NetDataContractSerializer, which will send type information with each request. To use that, search for "wcf netdatacontractserializer" and you'll find how to use it.
I'm working on adding a WCF services layer to my existing .NET application. This layer will be hosted in IIS and will be consumed by a variety of UIs, at least one of which will not use Microsoft technologies.
I can make a Web service in WCF that is consumed by my .NET application. However, I'm concerned about things that work in the .NET world but not with other technologies.
For example, simply throwing an exception from my WCF service works fine in .NET. But according to this article, one should approach exception handling with fault contracts to ensure compatibility with non-.NET consumers. The author labels this lack of foresight as The Fallacy of the .NET-Only World.
Does anyone have any high level suggestions or links to articles that cover interoperability between WCF and non-.NET consumers?
I realize I'm potentially working against the YAGNI principle. I'm only really looking to avoid things that will be incredibly difficult to overcome later when the developers of the non-.NET consumer report problems to me.
use any of the WCF bindings that don't start with net - avoid netTcp, netMsmq etc. - those are .NET only
make sure to make good use of DataContract/DataMember attributes, so that your method input and return parameters are easily and nicely serialized
avoid any .NET specific types in your data contracts - don't pass back an Exception or something like that - use the SOAP (or REST) elements for those things instead
don't use things like DataSet, DataTable etc. - they're all heavily tied to .NET
make sure to properly catch all errors on your service side - e.g. by implementing IErrorHandler - and pass back SOAP faults instead (if you're using a SOAP binding) or a HTTP error code (for REST)
TEST your services with non-.NET clients! Run a PHP page against them, code up something in Ruby - whatever - test it and make sure it works
One good way is to make your services RESTful.
From Wikipedia - Representational State Transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web.
REST style web services leverage the existing capabilities of HTTP to expose the services. Since almost every technology of building software can deal with HTTP you can be sure that your web services can be consumed by any non-DotNet consumer.
A very good example of RESTful services would be the stackOverflow API.
Here are some good links you can start with -
http://www.oracle.com/technetwork/articles/javase/index-137171.html
http://msdn.microsoft.com/en-us/magazine/dd315413.aspx
How do I go about making sure that my WCF service can be accessed from any other language(Java, PHP, whatever iOS uses, etc.)?
I have kept everything as httpbinding plus not used any of the .net roles/membership authentication for the clients. But there are some things that I am not sure of. Like, can I return a generic List that is readable by those other languages?
Any of the WCF bindings that don't start with net (netTcp, netMsmq etc.) should be fine - they're designed to be interoperable.
The most basic one is basicHttpBinding which is pretty much plain HTTP - nothing much can be added to it. You should be able to call this from any scripting language (PHP etc.).
The more advanced binding is wsHttpBinding which implements lots of the WS-* standards and can be called from other languages where the networking stack can handle WS-* - stuff like Java etc.
And then there's the webHttpBinding which exposes your service not via SOAP, but via a REST endpoint. This should be callable from just about any language, any device, any place.
And of course, you get the best coverage if you expose multiple endpoints from your service, offering a variety of choices to anyone trying to call you. All this is done simply in config - no code change necessary to support multiple endpoints, multiple bindings etc.
As for lists and stuff: WCF exchanges serialized messages - basically XML - which is governed by a XML schema. The combination of a WSDL and XSD is totally interoperable and can be understood by a wide variety of other languages.
A List<T> in .NET will be turned into an array in your XML structure, and that's totally interoperable - don't worry. The client might just get back an array instead of a list - but that's not a problem.
The only problem is that you cannot really model a generic list, since the XML schema doesn't support generics - you need to be explicit about what it is you're sending back. A List<T> won't work - a List<Customer> will (if your Customer object is part of your data contract and marked as such)
You cannot be 100% sure if you don't have any control over the client technology that is used to consume your services. But you can be very confident if your web service (WSDL) conforms to the WS-I basic profile v1.1. This standard is very widely supported and mature. You can use the excellent SoapUI test tool to test your WSDL for conformance.
There is ASMX, WCF, REST, and ADO.NET Data Services... I've used WCF and ASMX succesfully with Silverlight 2, but what about the others? What are the pros and cons of using each type of service with Silverlight 2?
WCF is probably what you want, since it is a framework that includes http, soap, tcp, json, etc.
You have multitude of options -
RESTful webservice (if u need more than just CRUD) + ADO.net Data Service (Data)
The Tried and tested ASMX
Build an all in one WCF service that uses SOAP/HTTP/TCP/JSON/Your custome binding
Number 3 is my personal choice.
Depending on your intent a few things you must also take into consideration:
RESTful web services are supported by ADO.NET Data Services as well as many other non-Microsoft platforms.
WCF Web services must include a policy xml file and support more enhanced but Microsoft specific implementations of WS-* (WS "deathstar" if you want my opinion)
ASMX web services are simple but lack the security model built around WCF (either RESTful or SOAP based).
If you want to do fast prototyping, I would recommend using ASMX services since they involve the least amount of effort. If you are doing something that involves a lot of database interaction, consider using ADO.NET Data Services and a RESTful approach. If you would like to add a lot of complexity, but benefit from more robust security and configuration, utilize WCF.
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?