I need to pass an XML document to the web service. Is it possible to simply specify a contract with a method, say
void Method(XmlDocument myDocument);
and implement it in a standard way? I need to keep in my the Silverlight functionality, thus I want to avoid writing the XML to a stream... Is it a good approach?
Thank you in advance for the hints and replies!
Cheers
If i recall correctly, XmlDocument is not serializable (which is required for a webservice).
The easiest way would be to write the xml document to a string ( xml), send this to your webservice and there you can deserialize it again to an XmlDocument
I've personally done this (forced too...). WCF has string buffer and string deserialization limits in the WCF binding which you need to override if you are sending anything of size through the interface.
But that said, if your requirement is to simply send XML then create a class, decorate it with the WCF XML attributes and then declare your interface to send them.
If you are interoperating with an existing service, you should be able to use the WCF service tools in the windows SDK to create a WCF binding against the service for you.
If you must pass in that XML document, pass it as a string. But the whole point of the WCF services is that you don't have to fiddle around with XML yourself - you just call the method and pass it some parameters (ints, strings, your own types) and the WCF runtime handles all the thorny XML stuff for you....
Related
I'm trying to send objects which are serialised as JSON to my WCF service. The thing is, though, some of the data from my android isn't needed on the service side, so I didn't add the attributes. I was wondering how I'd be able to have it so it can lack the attributes but still receive it?
So, in my android, I have JSON like this {"buiildings":{"id":1, "name":"boob", "otherThing":"Ya"}} and my Building object in WCF only has the id and name as attributes, so it only expects them. Can I have it so it just ignores the other attribute?
Yes, You can pass as many as extra attribute in JSON object. it will not give any error at WCF side. but you are not able to use these extra attribute as it is not define in Building object in WCF.
But i suggest do not to pass extra attribute because it will increase request size, and cause effect on performance.
I have a vendor who doesn't seem to have a wsdl or is unwilling or doesn't know how to provide it. They have a number of web services (technically they are JSPs that return soap messages) and I need to use about 10-15 of these to get my stuff done.
Since there isn't a WSDL, I can't use the 'add web reference' functionality to generate proxy classes and such. I've gotten around this by using WebClient to make the calls and return the response as a string, but now I need to deserialize the response into client classes.
I've already made c# classes to match the xml that's returned, but I'm not sure how to deserialize from SOAP since there's so much xml noise. I could strip the SOAP envelope tags and then use the XML serializer to deserialize to a List<SomeType>, but that seems really dirty. Is there a nicer way?
i published an article detailing on how to deserialize a complex xml.
here is the link : http://blog.impact-works.com/2011/06/30/how-to-serializedeserialize-complex-xml-in-asp-net-c/
hope it helps
Have you tried using SoapFormatter.Deserialize() for deserializing the response. If so, this would be helpful.
http://msdn.microsoft.com/en-us/library/system.runtime.serialization.formatters.soap.soapformatter.deserialize(v=vs.71).aspx
I need to create a .NET web service that accepts xml, uses this to query a database, and then returns xml. I have been given xsd files for the request and response. Could someone point me in the right direction for where I start from or an example?
I haven't used WCF before so would prefer to use a simple asmx file to do this. I know how to get the data from the database, so it's the xml and web service bits where I'm lost.
I've tried googling this for a while but don't know where to start. Thanks.
The problem you have is that asmx and WCF are both code-first web service technologies. What this means is that you generally start with classes and the web service stack takes care of exposing your types as XML across the wire.
You are starting with a schema, which is not code. So if you want to use asmx/wcf you need to model your schema in code. You can do this by inferring a class structure from your schema using xsd.exe (or svcutil.exe for WCF).
Alternatively you can model your classes by hand based on the schema definition.
Once you have your classes then you can add declarative attributes to the code (See http://msdn.microsoft.com/en-us/library/83y7df3e.aspx for asmx, DataContract and DataMember for WCF). These attributes control:
how an incoming stream of XML is deserialized to a type when a service request is received, and
how instances of your response types get serialized to XML when passed out of your service
The problem with this approach is that getting your XML to validate against your XSD schemas will be a little bit hit and miss, as you cannot rely 100% on class inference from XSD, and additionally you may miss some fine detail if you are modelling it by hand.
Whichever way you do it you need to make sure that your request and response class instances cleanly serialize into XML which will validate against the XSD schemas you have been given.
Also look at a framework called WSCF-Blue which allows you to do contract-first web service design: http://wscfblue.codeplex.com/
Good luck, if you need any more detail about this please let me know via a comment.
From what I can understand, you need to build a webservice, which will accept XML as input, do some processing and spit out XML.
I assume you have a basic understanding of XML but dont know anything about XSD. In very simple terms, XSD is a document which is used to validate a XML file. Think of it a rule book for how XML file should be structed, you can read more about XSD from W3schools. Dont worry about the XSD to much right now. Get a few sample XML documents, which you need to accept as input and output. Build a console application to parse the sample XML file and get the results from the database. Then use the results to build the output XML by looking at the output sample XML. Once you have that completed, then you can use the .NET classes to validate your input and output XML from the XSD you have.
You can look at this answer to see how validation is done.
Once that is done, you can create your web service to return the XML as string.
Hope this help.
I'm a complete neub to working with WCF but have been put on a project that needs it. Although not given as a requirement I want this service to seemlessly work with any client regardless of the technology it is written in (e.g. Java).
Basically, the client will send me a block of XML which I will validate and process. If all is well, I am going to return an XML document with 2 fields in it (an exit code and a message).
If I use DataContracts (with 1 write only and 2 read only properties) will that do the trick or is there more to this than I am seeing.
Thanks much!
Clay
DataContracts are not "the solution"; the DC is one possible approach for message serialization. whether you want to use DC depends on what the XML must look like, or can look like, and also how you want or need to map from objects in program memory to messages (xml documents or fragments).
In particular, if you want or need xml attributes in the messages, then DataContracts is probably not the way to go.
DC can support this kind of input message:
<request>
<flavor>7</flavor>
<param>eiueuie</param>
</request>
notice all data is stored as xml elements. DataContract will not work for this kind of message:
<request flavor='7'>
<param>eiueuie</param>
</request>
...in which any of the message data is stored in xml attributes. If you want to use XML Attributes, then you probably want to use the XML Serializer. If you don't care one way or the other then DC will probably be fine.
BUT, the Xml Serializer cannot map private fields or properties into XML elements, while DC Can. So, if your object model requires that, then you cannot use XML Serializer and you should use DC.
To find out more on the tradeoff between DC and XMLS, read this.
Having said all that, the decision on whether to use DC or not is just one part of your design. You will also need to decide whether you want full SOAP Envelope support (which allows for things like message signatures and so on) or whether you want the simpler "REST" message format, which is probably better called "plain old XML" .
And then there are things like instancing, hosting and activation (use IIS or self-host?), logging/auditing, security (authentication and authorization), and so on.
So, WCF can work for you, for any type of client, but the choice to use DataContracts or not is just one piece of the puzzle.
Data contract is just definition of transferred data - it is not domain object so making decision about what will be read only doesn't make sense. Client will deserialize the response and you will have no control over its processing of the data = client can change response anyway. Response can be also changed by any processing component in WCF pipeline.
Just start with DataContract and basic SOAP service (basicHttpBinding) or basic REST service (webHttpBinding + webHttpBehavior) and you will be fine.
I've been asked to come up with a .net web service stub for multiple similar webservices which will:
implement create/read/update/delete/find for an arbitrary object.
hold persistent xml data for objects of that type.
Is there anything out there that does this job already or anything that can make the job of creating it easier?
You may look at WCF Data Services. As usual with Microsoft products it is impossible to understand what it really does by looking at the front page, but is something of a "query a database by specifying the query in the URL in a standardized format (OData)". It creates a WCF service as a front end, and you should be able to write your own dataprovider for XML files.
It is arbitrary in the sense that the technology is independent of the object type, but you need to create a schema for its specific datatypes.