UI Middle-tier Communication Methods

R

Robby

Ultimate Contributor
Joined
Nov 17, 2002
Messages
3,460
Location
Montreal, Ca.
I'm posting the following on behalf of a colleague....

I am trying to decide which data format to work with from ASP.Net. Currently my Business layer assemblies communicate in XML. An XML request is formulated within the UI code and sent to the BusinessServices layer, which in turn processes the XML and returns an XML reply. This method was chosen for a number of reasons:

1) complete decoupling between the UI and Business Service layer
2) Before .Net and the advent of WebServices, it was a way for external clients integrate portions of the applications via this XML API

Question 1
---------------
Now that clients can communicate with my application via web services, should I continue to communicate with XML in both directions or does this add overhead in my Business services layer? Having to validate the XML and decode it.

Question 2
---------------
Formulating XML, sending it to the Business layer and then decoding the reply adds some overhead to my UI layer. Should I continue in this manner or pass dataset's (or arrays or whatever) back from the Business Services layer and work with that?

Thanks for reading DS. :)
 
I can make a few comments based on how I've done things... just opinions and it may make more sense to go a different route for you - who knows? :)

Question 1:
Using any types other than base types (int, string, etc.) is difficult if your clients need to communicate with your web services but can't understand the .NET types. Passing an ArrayList is probably not a good idea, for instance. In that respect, parameters to webservices that clients will use should probably be generic. Speed and more network traffic (for bulkier XML) is a tradeoff for having more options with clients. If your clients can all agree to use .NET, then you could obviously open things up a bit. It's sort of the same argument you have when deciding if your Web based apps should target IE or any browser.

We've mostly decided to use basic types (ints and strings) for simple methods and anything more complex requires XML that must be validated server-side. Once you get the basics of schema validation down, it's not so bad.

Question 2:
Again, what you want to return depends on your needs. I have one project that needs to return info to multiple clients which might be a browser, a VB6 app using SOAP and other clients who use WebSphere (I don't know why... tsk tsk tsk). Pretty much the ONLY route to go was to use XML since any operating system/language can make an XML string. Speed has not been an issue that we've noticed.

On another project, however, we use pretty much whatever we want (within the confines of what's serializable for WebServices). Besides base types, we use DataSets (to and from) and Hashtables (mostly to pass params).

As a side note, our webservices are nothing more than simple pass-throughs for the most part. The real code lives in a separate class file. This has helped us numerous times when we need to use a class from more than one web service or when we need to return a DataSet as a DataSet and as XML (the project uses about 90% WinForms code and 10% web based code). It's easy to create one method that returns ds and another that returns ds.GetXml().

-Nerseus
 
Thanks for the heads up.

The only types that my dataservice uses are string, int, datetime and GUID (SqlGuid). All XML requests via from a web service or internal from ASP.net are validated against a schema. I know using XML is especially useful when making a request on multiple rows (ex delete multiple records from a datagrid).

My webservice classes are wrappers around my business service layer. Good idea for the multiple methods to return dataset and XML. I'll overload these and have a go at it.
 
Back
Top