I am developing a WCF SOA(ish) architecture application that I needs to receive and return XML.
I have scoured the net for best practices. The only thing I know is sending raw xml as a string is going to cause problems.
I was therefore looking at an XmlTextReader type object that could perhaps be more elegantly marshalled from a to b and then back.
I get an error when i try and call my service that takes a XmlTextReader as a type and frankly it is confusing the hell out of me.
Bottom line it needs to accept and recieve large amounts of xml and I can't/don't want to use my own definded types.
Any help?
One answer without deeper analysis : you could maybe convert XML to Base64 encoded string and send it like that.
You could use XElement - personally have only used this on relatively small chunks of Xml - YMMV.
Related
I have recently started working with protobuf in my project and I am wondering, is there some way to deserialize a proto message if I don't know exactly what entity I have? When I am working with JSON or XML I can easily do it.
I was searching for some way to convert protobuf to json or xml, but found nothing for c#.
I have already looked in popular libraries, but they can only serialize json to protobuf, but not in both directions.
Does someone know how to solve this problem? I would be appreciative for any advice or solution!
In general, you can't work with protobufs if you don't know the message format. In order to be compact the wire format doesn't include all the information necessary to reconstruct the message. JSON and XML contain a lot of extra stuff in the message that allows you to (kind of) work with them even if you have no idea what they contain, but the trade-off there is a bloated format.
By the way, do not try to "guess" what a message is by going down a list of possible message formats and trying one after the other until your message successfully deserializes. It's entirely possible to "get lucky" and have a message of one type successfully deserialize as a different type, but with bogus data. I have been bitten by that one rather badly. :(
Look at union types if you want to wrap several different message types in a single message: https://developers.google.com/protocol-buffers/docs/techniques#union
There is a workaround (mentioned in the comments) of using self-describing messages, but I've never found them to be useful and evidently google didn't either: https://developers.google.com/protocol-buffers/docs/techniques#self-description
While nearly completing a new release, we've ignored the large size of the XML data that our WCF service returns to our silverlight client. Now we're investigating how to shrink the data, so that the results aren't in the 10-100mb range.
Its seems clear that binary serialization is the solution, and it seems easy enough to serialize the data into binary with, for instance, SharpSerializer, but through all of the SO posts about binary serialization and other tutorials I've come across, no one addresses how to send the serialized data across the wire to the Client. I expect I'm missing some obvious but critical piece to the WCF service puzzle.
Hopefully someone can lend me some help. Let me know if I should include more information.
First, try the built-in binary encoding (<binaryMessageEncoding> in config, see http://www.mostlydevelopers.com/blog/post/2009/10/14/Silverlight-3-WCF-Binary-Message-Encoding.aspx and http://www.silverlight.net/learn/data-networking/network-services-(soap,-rest-and-more)/how-do-i-use-binary-encoding-for-wcf-with-silverlight-3 ).
Your data will probably shrink, but please note that the built-in binary encoding was designed to be as fast as possible, not as small as possible.
If that's not enough and you want to use a 3rd=party component to do the serialization to binary data, you can indeed return this data as a byte[] (but you will also need to use <binaryMessageEncoding> above to prevent WCF from base64-encoding the data to make it valid XML). You can also use Stream instead of byte[], this won't give you true streaming behavior on the Silverlight client side but can give you true streaming on the server side.
I apologise if this is a duplicate thread...
I have a c# web service where I return an xml object that I need to parse into a Hashmap in my android application, the returned object from the service is .Net type Dictionary
most of the other calls are returning json which I can parse into a JsonObject with the response string but this particular call needs to return xml for other apps
could anyone please advise whats the simplest way to go out parsing xml returned from a web service into java objects or at least be able to maybe create an xml document from the response and pull values out of that?
many thanks in advance
There are mainly two ways and based on your requirement you need to choose one.
1) SAX parser: Mainly useful if you want to read all elements in XML document and create java objects. Here is a referene. SAXParsing. This is less memory consuming approach because entire xml file won't be cached while processing.
2) DOM parser: This is useful when you want to read specific parts of the xml (you can use this to parse entire file, but I use more when I need to play with part of the xml). This is more memory consuming approach, because entire xml file will be cached while processing. Here is an example. Dom parsing
You may use Sun inbuilt API for these parsing mechanisms (or) there are other third party APIs like Apache etc.,
Try JAXB or SimpleXML
I have a C# TCP chat program. Currently, I have formatted the messages sent using strings i.e, a "login" message starts with a "3" then followed by a "U:" then the username etc.
I think this method is very crude in a way that it's not really readable and not standardized. In early research, I have read that I can format my messages using XML but I dont know where to start exactly. Do I just make a string builder and append it tags like .append("<Login>"+message)?
The most common approach for dealing with a problem like this is to use serialization. Serialization is the process of converting an in-memory object into a format that can be easily streamed "over the wire," and de-serialization is the reverse process of converting the serialized format back into an object. .NET has good support for XML and binary serialization out-of-the-box, but there are other ways to implement this. Here's a link to get you started:
http://msdn.microsoft.com/en-us/library/7ay27kt9(VS.71).aspx
You can send whatever you like over the connection - as long as it's just for your program it doesn't really matter what you choose. Xml might give you some benefits as it lends itself to some kind of more structured messages and there are many classes and tools and knowledge around on the net regarding XML. JSon format might be another option - it will make it potentially easier creating a JavaScript client for it in case you want to go web based.
Unless there is a reqirement that 3rd parties be able to read these messages then I would probably favour binary serialisation, as it has a more compact format.
That said, I'd probably just use WCF rather than uisng TCP directly.
If you want to know more about XML serialisation then the most commonly used methods are:
Generating a stronly typed C# object decorated with attributes to control XML serialisation using XSD.exe, and then using XmlSerializer to serialise and deserialise XML. (recommended)
Using the XmlDocument class
You can write our XML yourself as a string, but its better to use the serialisation methods made available in the .Net framework as it makes things considerably easier and reduces the chance that you will make a mistake and inadvertantly start working with invalid xml.
I am using webservice. I am getting data to Java in the form of C# dataset how to retrieve values from dataset in Java.
I've handled this by using XPath with Xalan to query the DOM document that Axis hands to me. The schema of the serialized DataSet is pretty clear and easy to query. I just had to be sure to set up Xalan with the proper namespaces to perform the queries.
I ran into one problem handing the data this way. The serialized DataSet doesn't contain an element for data that is null. If you know what data you are expecting then this isn't a problem. However, if you don't know exactly what data to expect, you can extract the fields that are in the DataSet from the XML document.
Does this mean you are using the web service to transport the actual DataSet object?
Just convert the C# data set to xml or a formatted string on the C# side before it gets sent to the web service. Then you can easily re-parse the web service output into whatever java object you want. (I would just go with a formatted string, I havent used any Java XML libraries that come CLOSE to being as good as C#'s XDoc).
A dataset is serialized as XML. You will have to create an XML object on the
Java side and consume it by binding the XML to items in your application.
For simple report output, XSLT would help to simply the work.
or
Try to stay away from anything that's .NET-specific. Don't return
a DataSet, for instance. Stick to using simple types, arrays and structs of
simple types, and you'll be fine.
Happy coding
It depends on the format of the webservice. If it's a SOAP service look to a prior SO answer: consuming-a-web-service-in-java
If it's restful. I'd suggest using JSON if possible because the JSON serializer on the .Net side generally gives you a more agnostic serialization. Then, Java-side httpclient gives you a robust way to connect, and Json-lib lets you parse, rock, and roll.