Web Services and Data Binding?

What does it mean to bind to a web service? It's not hard to think of taking the result of a web service and binding it as input to some set of controls, but what about changes to that data? Should data from web services be read-only, requiring an explicit call to add, remove or update or should their be some standard WS-CRUD standard? What do you nice folks do?

I'm not nice... which is why I'm not afraid to tell you that your model is missing a layer of abstraction, and that absraction is known as a document.

...hey, what do you know? I *am* nice. :)

I agree, a service returns data that gets applied to your document. You bind to your model - not your returned data.

I try to return XmlDocument from all of my services and then de-serialize it into a bindable collection class.

On a side note, .NET 1.1 ASMX does this funny thing when you use XmlDocument as the return type. In the Reference.cs (or .vb) it writes out XmlNode and I always have to go in and change it to XmlDocument.

I don't see how you would bind to a web service though. There may be something that could be added onto WCF to make binding available, but that would be a separate API, no?

IMO this would be something that would greatly benefit some orgs. On several projects the teams look at the returned document as thier objects. It's always very frustrating. Usually degrades into cooking up datatables and shoving the document data into those and then binding. Unelegant comes to mind.

I have designed a set of WebServices that handle our core needs for our company. I have ProcessDataRequest, ProcessSecurityRequest, ProcessLoggingRequest, etc. All of these services take in only an XmlDocument using a SOA or contract approach. This way, I can use schemas to define certain parameters and allow them to passed in a via Xml. For example, <Root><DataRequest ApplicationName='Core' Environment='DEV' StoredProcedure='GetCustomers'/></Root>. This is just a simple example but by doing this, it allows me to create a central framework and have to framework define interfaces and do all of the heavy lifting. I then allow other applications that plug-in to the framework to use these core services. My ProcessDataRequest service returns both an XmlDocument and a DataSet. I bind to either but I use a proxy that is generated by my business objects that populate and generate the DataRequest nodes. This makes the work of handling the Data Access Layer very nice since my developers do not need to maintain connection strings in their plug-ins nor do they have to write any of the data access code for generating or binding the objects returned by the services. I let my framework handle this by using some code generation and business objects. I am also taking advantage of the RAD features available by .NET 2.0 pertaining to binding to custom business objects. If you would like more information, I am currently working on an article concerning this architecture.

Isn't this a little along the lines of what WS-Transfer was trying to do?

*shakes head at the disturbing lack of interoperability in the above examples*

My initial, knee jerk, reaction is: "Why would you want to do that?" By establishing a WS-CRUD standard we would just be furthering the misconception that web services are no more than RPC back-ends for our applications instead of stand alone autonomous services.

Binding to a 'loosely coupled' web service just doesn't sound right. But saying that...

Personally I think we need a spec for "web queries", that is a specialization of a web service that allows you to provide where-clause expressions, some form of output translation (in XQuery?), establish a notification or polling strategy, and possibly allow for crud edits a la in-place-editing. I agree that it's a requirement because it's such a common scenario that needs a simple solution. Trying to implement this using what we have today will be like putting a square peg into a round hole.