What I want is to decorate my data contracts with few attributes (e.g. min,max, string length etc.) and get the XML schema generated for my SOAP (non .net) clients. After some research on internet, I have come across the following article:
http://wcfsecurity.codeplex.com/wikipage?title=How%20To%20-%20Perform%20Message%20Validation%20with%20Schemas%20in%20WCF
This seems to be pretty manual to me. I am after some more decent solution and out of the box functionality. With WCF offering so much, I will be surprised if it has missed this whole concept of SOAP standard validation.
Any help on this will be much appreciated.
The XML schemas for the DataContract objects are found in the WSDL for the service. WCF does not explicitly validate soap messages against these schemas for a number of reasons. First, the process of deserializing soap messages, in effect, performs validation based on the DataContract or XML serialization defined on the data classes. Next, there is a definite performance hit if every soap message was being validated against the XML schemas. Lastly, WCF supports soap message versioning for both forward and backward compatibility through the IExtensibleDataObject optional interface capability. To do this, XML schema validation would most likely be too strict.
Related
I have read several posts about WSDL and SOAP but still I'm confusing the actual meanings of those terms. Now, I understand that you need to construct a request message in order to consume a webservice, would it be post or get message. When talking about SOAP based webservices, you need to communicate with a webserver via constructed XML documents that are SOAP compliant. So, you need to build that manually or using proper libraries. What about WSDL, when this thing comes in?
Wikipedia states "WSDL is often used in combination with SOAP and an XML Schema to provide Web services over the Internet. A client program connecting to a Web service can read the WSDL file to determine what operations are available on the server.". So that means that WSDL is just some file describing what services are available on webserver, and I guess, such communication must also be done using SOAP. But if I know all the webservices I use, I mean, if they are hardcoded then that means that I'm not dealing with WSDL at all. IMHO WSDL is just for very smart systems where before using webservices a program needs to read status and determine what to read. Am I right?
WSDL is a means to describe what operations (method) the webservice has as well as the input/output of those methods. In the past, way before the mobile becomes popular, WSDL is used as a means for creating what is known as a stub/proxy classes.
These classes is basically generated by specific Generator (such as WSDL2Java for Java or WSDL.exe for .NET) whose job is to read the WSDL, get the methods along with its input/output and generate a language specific classes to expose those services natively. In effect, it is hiding the SOAP messages from the user and the from the consumer of the webservice point of view, they are dealing with the native classes of their language of choice.
WebService with SOAP thus was heralded as means of integration between heterogeneous systems, allowing a communication that is language independent. For example the language for implementation for the service could be in C# but the consumer of the webservices can be in Java. If the consumer is Java programmer, by using the WSDL to auto generate the classes, the Java programmers don't even need to know the concept of SOAP or XML. All the programmers know that they are dealing with Java object.
Nowadays, SOAP is more transparent and well known than it was in the past. As a result, by choice programmer can directly code the SOAP message, bypassing the need to generate the code via WSDL
I'm building a WCF SOAP service at the moment. I will, of course, need some authentication on the service.
Reading this very helpful blog post says that to use the built-in authentication points requires that the endpoint use the wsHttp binding.
This would be fine if I could guarantee that users would be communicating with the service through a client based on the meta-data exposed by WCF (basically, something like a client written in C# with a web service reference). However, I can't guarantee this!
I will still need to allow users to communicate with just raw (unencrypted) XML.
So, questions:
Does the wsHttp binding still allow for raw XML input?
If not, would I be wiser to
Implement two separate authetication points? One for raw XML input and one for encrypted input
Or
Allow input from wsHttp to fall back on some in-method validation that would be shared with the raw XML input?
Is it wise to allow users to pass their credentials inside a raw XML request?
EDIT: It sounds like I miscommunicated or misunderstood something in my original post, so here I will clarify what I mean by "raw XML".
By raw XML, I mean just the SOAP packet and the accompanying HTTP headers - as I might send from soapUI or Fiddler. As I understand it, messages over the wsHttp binding are encrypted when a client is generated from the WSDL (for example, in C#).
If this is not the case, then how would I go about attaching the same sorts of credentials to a raw XML (for want of a better term) request as I do a request run through a client? Are they attached as HTTP headers? XML elements in the SOAP envelope?
wsHttp is a SOAP binding, which means that your content gets wrapped in a SOAP envelope, possibly with headers relating to the message and various WS-* specifications being used.
I would ask why you need to support raw XML? Most platforms today support SOAP messaging and the whole idea of SOAP is to provide interoperability between different platforms. On most platforms it is as easy to develop a SOAP client as a raw XML client. In most cases, it is simply a case of taking the WSDL and generating a client. If you want to use standard facilities like authentication and message encryption then this is a much better way to go.
There are currently no hooks to do interoperable authentication for raw XML. You will have to come up with your own mechanism to do this and it will be non-standard. For your web service users, this means it will be probably entail more development effort than if you just went with SOAP.
Consider this scenario that two WCF clients connect to one WCF service(server), this service will receive an object from one client and send it to the other one through some operation contract and client callbacks, both clients have the type for this object but we do not want the WCF service(server) to be dependent on this type.
The project is much bigger than this, but I wonder if you can send an object with an unknown type to a service and somehow receive it back on the other client. I saw this but it does not help me at all: Can WCF service transmit type (client doesn't know this type) information?
Thanks in advance.
You can do certain things with the "raw" Message data type - but it's really not pretty programming...
Read about it here:
How to pass arbitrary data in a Message object using WCF
WCF : Untyped messages on WCF operations.
Sending an "object" with unknown type is not possible in WCF because WCF requires a full compatibility with WSDL - and WSDL requires transparent type definition.
Having said that, if you use a type of object I believe there is a way for this to be loaded as a string and in WSDL it is defined as xs:anyType.
I personally would prefer defining the type as string and passing an XML which can be serialised using plain XML Serialization. I have used this in our company and it works really well, especially since we will be storing the XML as document in database.
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.
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?