 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / ASP.NET / Web Services / July 2004SoapEnvelope.SetBodyObject(object) and Serialization
We currently have an issue with serializing some objects into the body of a SoapEnvelope. The scenario is that we wish to serialize a number of "Data Transfer Object's" (Fowler, aka "Value Object" - Sun community). These objects are designed to be read-only and hence are immutable. The object state is passed into the constructor using parameters. As these objects are 'transfer' objects we mark them 'Serializable' and implement the ISerializable interface. So, nothing new there, just following good practice. Our issue is when we call SoapEnvelope.SetBodyObject(object), we receive a serialization error using the WSE soap formatter (SoapPlainFormatter). If we take control of the serialization process using either System.Runtime.Serialization.Soap.SoapFormatter or its binary equivalent then serialization is successful and we can proceed. The code can be made more generic by using the Template pattern, but in some ways it is still a 'code smell'. I noticed that SoapPlainFormatter implements ISoapFormatter, so it would appear that the formatter, was (at least originally) designed to be pluggable. However, I can see no way of achieving this. Sorry for the long preamble... my question is simple can the SoapEnvelope formatter be replaced? <rant warning> Why does the XmlSerializer, SoapSerializer & the SoapPlainFormatter, completely ignore the ISerializable interface. This in my opinion severely limits the functionality of those objects that can be serialized, and results in an inconsistent approach to object serialization. </rant warning> Your help is as always appreciated. Steve Hi Stephen, > We currently have an issue with serializing some objects into the body > of a SoapEnvelope. [quoted text clipped - 6 lines] > ISerializable interface. So, nothing new there, just following good > practice. BUt all that doesn't have anything to do with this. Runtime serialization (that is, that controlled by System.Runtime.Serialization) and Xml serialization (as that used in asmx and WSE) are completely different entities, and are controlled by entirely different sets of rules and attributes. > > Our issue is when we call SoapEnvelope.SetBodyObject(object), we > receive a serialization error using the WSE soap formatter [quoted text clipped - 11 lines] > serialization. > </rant warning> Actually, I'd contend that the way the XmlSerializer works is far more controllable (yes, it has more restrictions, but it allows you to control the serialization format). You might want to look into the IXmlSerializable interface instead of ISerializable...  SignatureTomas Restrepo tomasr@mvps.org Tomas > > We currently have an issue with serializing some objects into the body > > of a SoapEnvelope. [quoted text clipped - 12 lines] > entities, and are controlled by entirely different sets of rules and > attributes. I was originally setting the scenario. I should have ignored any serialization statements here as they were only added later when serialization using WSE failed. The point I was trying to get across was that I was following a well-known pattern for distributed applications, and hence I believe should be compatible with WSE. However due to the 'hard-coded' serialization of the envelope body object we found that it wasnt; unless we compromise our design or add additional and in my view unnecessary client/service code. > > > Our issue is when we call SoapEnvelope.SetBodyObject(object), we > > receive a serialization error using the WSE soap formatter [quoted text clipped - 15 lines] > controllable (yes, it has more restrictions, but it allows you to control > the serialization format). Yes I am aware that runtime and XML serialization have differing basis and provide differing functionality. What I contend is that the approach is inconsistent. I would not argue with you over the 'additional' capabilities offered by the XmlSerializer, in fact I don't care that one is better than the other. What I (currently) care about is that I cannot pass an object that doesn't have an default parameter-less constructor inside a SoapEnvelope. From a naive viewpoint, I would suggest talking to the XmlSerializer team about that 'opportunity' but as a more immediate response allow the SoapEnvelope body object serializer to be pluggable. (I am assuming from your reply it currently isn't) > You might want to look into the IXmlSerializable interface instead of > ISerializable... I didn't consider the IXmlSerializable interface as it is declared for internal use only! Secondly it doesn't overcome the parameter-less constructor issue. Sorry for sounding so negative on this subject, I do appreciated the efforts of the WSE team. Just have found using it in a real life scenario has proved that more soak testing is required! (see my previous thread about Kerberos Multi-Hop delegation). Steve Stephen: I agree that sometimes it is cumbersome or 'unnatural' to have to have that default ctor. However, I also think that it would be a tough thing to create a deserializer that can handle any type of ctor that happens to be used. Especially, you'd run into issues with multiple ctors in your DTO classes. As far as I am concerned, I provide read and write public properties and a default constructor, and count my blessings that I don't have to start writing XML serialization/deserialization myself... Also, I am not first-hand familiar with Fowler's work, but I do use the DTO model for my messages. I can hardly believe that Mr. Fowler would have objected very much to having read and write DTOs. My two cents... SignatureSven > Tomas > [quoted text clipped - 70 lines] > > Steve Sven DTO's in my design are immutable and hence not really meant to be read/write, the best way of achieving this (IMHO) is to pass in the state during the object construction. The parameterless constructor 'issue' has been overcome in the 'runtime' serialization versions by the coding practise of the special constructor. Something similar could be implemented for the other serialization mechanism's. However, I would suggest that making the actual serializer pluggable offsets the ownership from Microsoft/framework onto the application developer. It is also a relative painless and can satisfy everyone's needs. For now I intend to take the hit on pre-serializing the object before assigning it to the SoapEnvelope, as I prefer to keep the DTO's to the original design. Thanks for listening Steve Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.