Develop Reference

Getting the XML request from ClientBase<T>

I am currently using ClientBase to access a web service. This works correctly but I need to log the XML request that is being sent off to the service.
I can see that there are ways of doing this using listeners and other similar methods, but I need to access this XML request in the method from which it is being submitted in my codebase.
Is there any way in which this is supported?

The "XML" is only ever created (serialized) after the control flow leaves your method and enters the WCF code that actually does the call. So if you were theoretically able to get it from within your code, you'd have to get it "after" the actual call. This is also the reason why the intended way to do this, is implement/register a IClientMessageInspector.
The only other thing, which includes some unnecessary manual labor, would be to manually serialize the arguments you pass to the WCF call using the NetDataContractSerializer or DataContractSerializer. Mind you, though that this will only give you the payload, not the complete message (including headers, etc.).
I'd really go for the way that is suggested for this (see link above).

You can try some AOP programming. If you are using Unity for DI, you can try Unity with Interception or Interception alone using Intercept class.

How can I write a web service that returns a dynamic set of variables in .NET?

My current set up is an ASMX web service that has an Item object, and returns a List<> of Items.
Item has 114 fields of various types. It is consumed by .NET web apps, as well as Java web apps (using Axis2 to generate a client proxy).
My problem is that every time we want to add a field to the result set, we have to modify the service to add the field to the object, as well as generate a new client proxy for the java side. Also, the mapping of the sql fields to the object fields is one large method loading each field from the datareader into the object, making sure to convert to the proper datatype.
Is there a more dynamic way to do this? I looked into a list of Dictionary, but that cannot be serialized. An alternative is to send a List<> of Struct with Key and Value fields. This now puts the effort of parsing the types onto the client, which isn't necessarily optimal.
Is there a pattern that handles something like this, or barring that, does anyone have a good solution to help make this a little more maintainable? I'm open to converting it to WCF (though I am not too familiar with WCF) if there is a decent way for our Java apps to consume the service.
If you need more details, just ask. Thanks!

Outside of using something like a List<KeyValuePair<string, object>> I don't think you're going to find any other solution; WCF isn't going to help much in that respect.
I think that's actually a good solution, it will make the reading of your data much simpler and scalable, and you wouldn't need to change your server side code much when you add new fields.
You could write code on the clients that do the work of mapping the value pairs back to a real structure, and then most of the code changes (when a field is added) is isolated to your clients. Also, if your clients don't need the new fields, you can just ignore the changes without breaking anything.

How can I parse REST service response?

I have set up my REST service and it works fine. This is the response that I get from the service is shown in the figure:
How can I parse this type of request in my WPF application?

The response you have there is seemingly an XML structure that contains publisher information. As for parsing it you have a number of options however all of these require/prefer you to have the schema for the resulting XML.
Use the Visual Studio XSD tool to create schema classes in your project. Once you have these you can then deserialise the XML into an object. You can then use the object within your WPF application.
Use XmlDocument to load the XML then use xPath queries to extract the data you need.
Use XDocument (linq to XML) to load the XML then use LINQ style queries to extract the data you need.
Personally, I would use option 1 - It does require a schema (the other options don't technically need one) but it does give you objects which IMHO are much easier to maintain and use than xpath/linq queries.
It is also worth mentioning that depending on how the service reference was added to the client (and how the service exposes itself) you may already have this XML class bound into the client service reference. As an example you service reference in the client may allow you to do this:
PublisherInfo pi = myServiceClient.GetPublisherInfo();
In which case all the conversion from XML to PublisherInfo is handled for you. I am guessing that the sample XML above was obtain by calling the service in a browser, therefore the conversion to PublisherInfo obviously doesn't happen as this would occur within the client code.

Well, there are a number of ways. You could use XmlReader, load it into an XmlDocument, and more.
The former of those options exposes a constructor that accepts an input stream and an XmlReaderSettings instance.
But how is this response returned? If you showed us some code, or provided a little more information then you might find we have different approaches that are more appropriate.

Why do you need to parse it, why don't you use the classes generated by Visual Studio when you add the reference of your service to the WPF project?
If you really want to parse it, use the Xml libraries mentioned in the other answers

Sending information between JavaScript and Web Services using AJAX

Alright so I'm using Microsoft's Web Services and AJAX to get information from a SQL database for use with java script on the client side. And I'm wondering what the best method is. Before I started working on the project, the web services were setup to return a C# List filled with some objects. Those objects variables (ints, strings, etc.) contain the data I want to use. Of course, java script can't do much with this, to the best of my knowledge.
I then modified the web service to return a 2D Array, but java script got confused, and to the best of my knowledge can't handle 2D array's returned from C#. I then tried to use a regular array, but then a found the length property of an array in JS doesn't carry over, so I couldn't preform a for loop through all the items, because there wasn't anyway of knowing how many elements there were.
The only other thing I can thing of is returning a string with special char's to separate the data, but this seems way too convoluted. Any suggestions? Thanks in advance!

EDIT
First, I'm assuming your using a SOAP based Webservice. By SOAP, more or less I'm talking about a webservice (in this case C#) that generates XML messages to accept requests for data and send back results from those requests. You can read more about SOAP here: http://en.wikipedia.org/wiki/SOAP
Going from a C# webservice to a C# client application is fairly simple since Visual Studio will automatically generate a consumer class for your client application. Example of this here: http://my.execpc.com/~gopalan/dotnet/webservices/webservice_csharp_client.html (though I think Visual Studio has better integration than this example shows).
More or less, your JavaScript will need to generate the appropriate SOAP request (XML) for your WebService to understand which method you want to invoke. After it has been invoked, you'll need to use JavaScript to parse the response (also XML) for the data you want (jQuery is great for this).
Here is a library that will help you make the request and get a response from your webserver. http://www.ibm.com/developerworks/webservices/library/ws-wsajax/
Here's a similar question on the same topic with a pretty good example : Simplest SOAP example
Let me know if this is what you're looking for. Hope it helps!
ORIGINAL
Your Data (2D Array, List, etc.) is being serialized to XML.
So you'll need your Javascript to parse the XML and not treat it like literal C# objects.
OR like keatch said, return JSON

Try to return a JSON array. JSON is a standard notation for passing javascript objects.
See this link for reference: http://www.codeproject.com/KB/aspnet/CSJSON.aspx

Try this in your service:
[WebMethod]
[ScriptMethod(ResponseFormat = ResponseFormat.Json)]
public List<SomeObject> name()
{
....
}

WCF: Individual methods or a generic ProcessMessage method accepting xml

My company is developing an application that receives data from another company via TCP sockets and xml messages. This is delivered to a single gateway application which then broadcasts it to multiple copies of the same internal application on various machines in our organisation.
WCF was chosen as the technology to handle the internal communications (internally bi-directional). The developers considered two methods.
Individual methods exposed by the
WCF service for each different
message received by the gateway
application. The gateway
application would parse the incoming
external message and call the
appropriate WCF service method. The
incoming XML would be translated
into DataContract DTO’s and supplied
as argument to the appropriate WCF
method.
The internal application
exposed a WCF service with one
method “ProcessMessage” which
accepted an Xml string message as
argument. The internal app would
parse then deserialize the received
xml and process it accordingly.
The lead developer thought option two was the better option as it was “easier” to serialized/deserialize the xml. I thought the argument didn’t make sense because DataContracts are serialized and deserialized by WCF and by using WCF we had better typing of our data. In option 2 someone could call the WCF service and pass in any string. I believe option 1 presents a neater interface and makes the application more maintainable and useable.
Both options would still require parsing and validation of the original xml string at some point, so it may also be a question where is the recommended place to perform this validation.
I was wondering what the current thoughts are for passing this kind of information and what people’s opinions on both alternatives are.

Option 1 is suited if you can ensure that the client always sends serialized representations of data contracts to the server.
However if you need some flexibility in the serialization/deserialization logic and not get tightly coupled with DataContracts, then option 2 looks good. Particularly useful when you want to support alternate forms of xml (say Atom representations, raw xml in custom format etc)
Also in option 2 inside the ProcessMessage() method, you have the option of deciding whether or not to deserialize the incoming xml payload (based on request headers or something that is specific to your application).
In option 1, the WCF runtime will always deserialize the payload.

I recently asked a couple of questions around this area: XML vs Objects and XML vs Objects #2. You'll find the answers to those questions interesting.
For our particular problem we've decided on a hybrod approach, with the interface looking something like this:
// Just using fields for simplicity and no attributes shown.
interface WCFDataContract
{
// Header details
public int id;
public int version;
public DateTime writeDateTime;
public string xmlBlob;
// Footer details
public int anotherBitOfInformation;
public string andSoemMoreInfo;
public book andABooleanJustInCase;
}
The reason we use an xmlBlob is because we own the header and footer schema but not the blob in the middle. Also, we don't really have to process that blob, rather we just pass it to another library (created by another department). The other library returns us more strongly typed data.
Good luck - I know from experience that your option 2 can be quite seductive and can sometimes be hard to argue against without being accused of being overly pure and not pragmatic enough ;)

I hope I understood this right. I think it might make sense to have your gateway app handle all the deserialization and have your internal app expose WCF services that take actual DataContract objects.
This way, your deserialization of the TCP-based XML is more centralized at the gateway, and your internal apps don't need to worry about it, they just need to expose whatever WCF services make sense, and can deal with actual objects.
If you force the internal apps to do the deserialization, you might end up with more maintenance if the format changes or whatever.
So I think I would say option 1 (unless I misunderstood).