Share via

Paging in Service Oriented Architectures

  • Article

Paging in Service Oriented Architectures

We had an interesting Email thread a couple weeks ago about how you support pages of output to a UI in a Service Oriented Architecture. My initial thought is that you don’t. If you are truly building loosely-coupled services you can’t have a service whose output changes depending on whether it is called by a Web App, a smart client or another service. If you create a service that accepts a record-number range as part of its input contact you could probably make it look like a service but it’s pretty tightly coupled and definitely requires maintaing state.

If you can’t build a paged service without violating some of the core principles of Service Orientation, how do you handle large result sets from a service? I think there are three ways:

· Don’t use services that produce large result sets.

· Handle the result set in the caller.

· Don’t use a service

The first option is the best solution and the hardest to implement. It requires rethinking the services you offer so they won’t return huge result sets that are too big for the UI to handle. Doing that while providing a rich user experience may not be possible. Our users are conditioned by Excell, Outlook, and Access to expect an essentially limitless number of data rows that they can scroll through untill they find the one they want. In most cases they only need a few rows but it’s easier to scroll through them all then to figure out how to specify the ones they need. They also want to be able to change the sort order and which column the results are sorted on instantly like they can in Outllook. This is really hard to do in a Web app and designing a service that can do this is a real challenge. Changing the UI Paradigm to allow them to easily specify the few records they need to see or maybe returning a very narrow result set with a colum or two they can scroll through to find the records they need more detail on may not be a convenient but it can result in a much more performant and scaleable application. Again while this would be my first choice as a solution, I recognise that there are applications where it’s not possible.

The second possible way of handling a bunch of output from a service it to accept it all and let the client handle the scrolling. This is generally pretty easy in a rich client or smart client situation. You can stored it in a dataset, on disk, or in a local database. With a client database you can even open a cursor on the resultset and scroll back and forth to you heart’s content or resort the results on a different key – in short act like a standalone app. In a web application this generally involves caching the results in the webserver tier somewhere – either in a file or a database. I you manage the cache consistency you can serve pages to multiple users with the same result set. Even if you decide to use this option, you will want to design your application to limit result set size whenever possible because returning huge result sets is expensive even if it get amotized over several client requests with caching.

The last way to handle large result sets in a Service oriented application is to not use a service. This might be a case where service oreintation does more harm then good. You can just pull pages of results directly from the database and bypass the service. This obviously makes this part of the application tighly coupled but that may be the best way to get the job done in some cases. There are standard ways to page data from a database. For SQL Server, one of the best set of techinques is available here: https://www.aspfaq.com/show.asp?id=2120 Itzik Ben-Gan’s new Insdie TSQL book has some good paging techniques in chapters 4,7, and 8. https://www.amazon.com/gp/product/0735623139/qid=1145561341/sr=1-3/ref=sr_1_3/102-9729535-9477708?s=books&v=glance&n=283155

There was also a paging white paper in the works but it hasn’t been published yet.

So in general, I don’t think adding paging capabilities to a service makes much sense (although you obviously are free to do it if it makes sense in your application). My first choice for a solution would be to design your services so paging isn’t necessary but if that’s not possible, either caching or using standard database paging techniques will work. Caching is probably the best approach from a performance and scalability viewpoint but database paging will work if none of the other solutions are possible in your architecture. Like most things in architecture, the answer is “it depends”.

Comments