Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Send data from netduino 2 plus to a Service with xml serialization

netduino; xml; serialization;

  • Please log in to reply
5 replies to this topic

#1 Olecram

Olecram

    New Member

  • Members
  • Pip
  • 3 posts

Posted 19 April 2014 - 05:07 AM

Hi, i'm trying to send data from a netduino plus 2 to a service that must store data on a database. Actually i use a socket and send the info like a string, but i think is better to do it with xml serialization. Is it possible? What is the recomendation for this? There are some examples?



#2 jrlyman3

jrlyman3

    Advanced Member

  • Members
  • PipPipPip
  • 67 posts
  • LocationNorth St Paul. MN

Posted 21 April 2014 - 01:46 AM

XML is easy to generate ... I'd probably just create the XML string in the same way I

would generate an output string.  You could create a method for each XML tag to clean

it up a bit.  Of course, XML is so verbose it will reduce your performance quite a bit.

Are you sure you don't want to use JSON?  :) I don't know of any libraries to do that

either.

 

Note that if you try to connect to the server and it doesn't respond, your thread will hang,

and if its the main thread, you're done ...



#3 401kill

401kill

    Member

  • Members
  • PipPip
  • 10 posts

Posted 26 April 2014 - 11:47 PM

For my project (somewhat similar, N+2 reporting to a WCF web service), I tried to use DPWS. Sending a request worked fine, but  the firmware doesn't implement the XmlReader class, so DPWS can't deserialize the response. This might work for you if your service calls are one-way only.

 

As jrlyman3 said, XML generation is comparatively slow due to the verbosity of the language. I configured my WCF services to use JSON instead (exposed via RESTful URLs), and used Json.NetMF to (de)serialize the data sent / received.

 

I did eventually end up forking the library to strip out the bits that I didn't need, but its a good starting point.


  • asciiman likes this

#4 riaan.marx

riaan.marx

    New Member

  • Members
  • Pip
  • 4 posts

Posted 03 May 2014 - 01:44 PM

Good day everyone.

Total newbe here wrt Netduino devices, but 15+ years of electronics and software development (including ASM based PIC microprocessors).

 

After days of trying to do a DPWS call to the simplest .NET WCF web service, I have to unfortunately say I could not get it to work. I get a socket exception just trying to instantiate the service proxy class exported by MFSvcUtil. (all still emulator based), so I doubt this is even supported.

 

RESTful services will get you up and running, but URLs have a maximum length so if you plan on passing text, you better keep it short. This is where xml serialization comes in handy, but DPWS seems to be little more than a four letter word....albeit an abbreviated one.

 

If any actual experts in this area could confirm or counter my conclusion, please respond as I am sure there are many more people struggling with the same issues.

Regards,

Riaan


---------------------------------------

Best regards,

Riaan Marx


#5 401kill

401kill

    Member

  • Members
  • PipPip
  • 10 posts

Posted 07 May 2014 - 08:32 AM

RESTful services will get you up and running, but URLs have a maximum length.

 

Correct - so if you are sending a lot of data, send a POST request with the message body containing JSON (or similar) serialized data. The max POST size is defined by your web server, not by the HTTP spec (and is usually adjustable).

 

XML serialization is anything but short! :) JSON is more lightweight, so faster to process and transmit. Less RAM usage too.



#6 Robert Hugo

Robert Hugo

    Advanced Member

  • Members
  • PipPipPip
  • 35 posts

Posted 10 June 2014 - 07:32 PM

Honestly, I think carte blanch statement about XML versus JSON statements are often biased and misleading. XML *can* be verbose, but sizes are easily comparable to JSON.

 

Regarding comparison in size, an examples:

 

JSON: { "SomePropertyName" : "SomePropertyValue" } (44 chars, 40 chars without spaces)

 

XML: <SomePropertyName>SomePropertyValue</SomePropertyName> (54 chars, spaces needed)

 

This shows a typical "verbose" version of an XML property, the difference showing a 35% larger footprint than JSON. This could easily be coded differently, e.g. <SomePropertyName Value="SomePropertyValue" /> resulting in 46 chars (45 with no space before the '/') and even 42/41 if "V" is used instead of "Value".

 

A second example:

 

JSON: { "P1" : "1", "P2" : "0", "P3" : "" } (37 chars, 27 chars without spaces)

 

XML: <Pins P1="1" P2="0" P3="" /> (28 chars, spaces needed)

 

The difference is negligable without spaces for JSON, equal without the space before the '/', and the extra element name "Pins" in a sense 'explains' the data making it's easier for a human to read. However since JSON doesn't have this metadata at all, and for comparative reasons, it could be shortened (not removed, since a tag name is required) to just '<P P1="1" P2="0" P3="" />' and it's down 25 chars (24 without the space before the slash). This can be further argued in favor of JSON by using an array, e.g. '{ P : ["1", "0", ""] }' resulting in 22 chars (16 chars without spaces) or '{ P : "1, 0, " }' (16/10) or in XML '<P>1,0,</P>' (11).

 

However, if the situation calls for it and it really is *that* tight, one would likely go for something akin to NMEA strings, like the OP appears to be already doing, e.g. "$1,0,;" resulting in only 6 chars, almost half of both.

 

The point here is that blue faces are common, even when none are truly needed.

 

IMO, simply pick the right "tool" for the job.

 

---

 

Regarding XML:

 

If access to some sort of XML DOM is available, the data transmitted/received can be used sort of like a database "right there".

 

If storing the data into a modern SQL Server, XML can generally be forwarded (with no intermediary parsing) directly to a stored procedure. This type of a SQL server can likely create XML too.

One can also transform the XML using XSL-T to other formats (e.g. HTML, CSV text, etc.) if needed.

We have a system that has been operational since mid 2000, using HTML (made using XSL-T from XML) and JavaScript on the front end (IIS), a WCF service (this was actually simulated using ASP before .NET 1.1 came out and we started using an ASMX web service) using only XML in/out on 32 distributed Windows servers across the city. The web service streams the XML through software plugins (using the .NET MEF) which in turn perform the operations according to stream data, such as connecting to the various SQL servers and other endpoints (e.g. Bing services, Active Directory, etc.). If a new endpoint is needed, we create a plugin based on the simple contract (interface) and the DLL is deployed (copied out :)) to the web servers. When the services are reloaded, the new functionality is available. Virtually no management of the web service engine itself.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.