AJAX webservices - extensions of web or biz layer?

Question

My question is possibly a subtle one:

Web services - are they extensions of the presentation/web layer? ..or are they extensions of the biz/data layer?

That may seem like a dumb question. Web services are an extension of the web tier. I'm not so sure though. I'm building a pretty standard webform with some AJAX-y features, and it seems to me I could build the web services in one of two ways:

1. they could retrieve data for me (biz/data layer extension).
   example: GetUserData(userEmail)
   where the web form has javascript on it that knows how to consume the user data and make changes to markup
2. they could return completely rendered user controls (html; extension of web layer)
   example: RenderUserProfileControl(userEmail)
   where the web form has simple/dumb js that only copies and pastes the web service html in to the form

I could see it working in either scenario, but I'm interested in different points of view... Thoughts?

Answer 1

I would say definitely not #2, but #1 is valid.

I also think (and this is opinion) that web services as a data access layer is not ideal. The service has to have a little bit more value (in general - I am sure there are notable exceptions to this).

Answer 2

Even in scenario 1, this service is presenting the data that is available in the data layer, and is not part of the data layer itself, it's just that it's presenting data in a different format than a UI format (ie. JSON, xml etc.)

Regards which scenario I would use, I would go for scenario #1 as that service is reusable in other web forms and other scenarios.

Answer 3

While #1 (def. not #2) is generally the correct approach (expose just the data needed to the view layer and have all markup handled there), be careful with the web portion of the service in your design.

Data should only be exposed as a web service (SOAP/WSDL, REST) if it is meant to be consumed remotely (some SOA architects may argue this, but I think that is out of scope for this question), otherwise you are likely doing too much, and over-designing your request and response format. Use what makes sense for your application - an Ajax framework that facilitates client/server communication and abstracts the underlying format of communication can be a big help. The important thing is to nicely encapsulate the code that retrieves the data you want (you can call it a service, but likely it will just be a nicely written helper class) so it can be re-used, and then expose this data in whatever way makes the most sense for the given application.

Answer 4

In my mind, a web service has 2 characteristics:

1. it exposes data to external sources, i.e. other sources than the application they reside within. In this sense I agree with @Pete in that you're not really designing a web service; you're designing a helper class that responds to requests in a web-service-like fashion. A semantic distinction, perhaps, but one that's proved useful to me.
2. it returns data (and only data) in a format that is reusable by multiple consumers. For me this is the answer to your "why not #2" question - if you return web-control-like structures then you limit the usefulness of the web service to other potential callers. They must present the data the way you're returning it, and can't choose to represent it in another way, which minimises the usefulness (and re-usefulness) of the service as a whole.

All of that said, if what you really are looking at is a helper class that responds like a web-service and you only ever intend to use it in this one use case then you can do whatever you like, and your case #2 will work. From my perspective, though, it breaks the separation of responsibilities; you're combining data-access and rendering functions in the same class. I suspect that even if you don't care about MVC patterns option #2 will make your classes harder to maintain, and you're certainly limiting their future usefulness to you; if you ever wanted to access the same data but render it differently you'd need to refactor.