I recently received this question at SearchWebService.com...

How can I call a Web page from my Web service page after extracting an XML file into a dataset? My Web page will display data from a created dataset into a DataGrid control. Can I return data directly into a Web service page using Visual Studio .NET?

Probably because I have had to go through some interesting integration patterns in the past, I answered the question with two flavors...discussions welcome.

Here's my answer:

I think the best way to tackle your question is to review the workflow between client, Web service and Web application (pages). If the client application is the Web application, then the workflow looks something like this:

1. User browses to a page.

2. During the Page.Load event you invoke a Web service to get the dataset, before binding that dataset response to a DataGrid control on the Web page.

3. The page is returned to the browser with the populated DataGrid rendered as HTML.

The call chain looks like this:

Browser->Web Page->Web Service

What may be misleading about your question is the statement “call a Web page from my Web service”. Web services are data centric calls. They do not return HTML that can be displayed in a browser, therefore they should not be responsible for “calling” a Web page. Rather, the Web page should call the Web service to gather data, and present it. The driver behind the activity is the user who navigates to a page that leverages the service.

That said there is another possibility that can be interesting. Consider this workflow:

1. User interacts with a Windows client application.
2. The application at some point invokes a Web service to gather data from a remote server. The Web service establishes a session for the caller, and allocates the dataset to the session. The Web service returns XML that includes a link to a Web page exposed by the same server.
3. The client application retrieves the XML response, which includes a URL to a Web page to navigate to (with session established) and the client application launches a browser (or, has an embedded custom browser) to the URL.
4. The requested URL (page) retrieves the dataset from the session object, and displays the page fully populated.

So, the call chain is now:

Windows App->Web Service

Windows App -> Browser -> Web Page

This type of workflow may seem disconnected, however it is one technique whereby a legacy application can integrate with a modern user interface (through the browser) when the legacy app wants to integrate the modern application’s services as part of a user interface workflow, in addition to data exchange. For example, the insurance industry has many legacy agency management system applications, some even DOS-based entry screens, that “work” therefore will not be replaced. These agency management systems hold important data necessary to create certificates of insurance, a service often provided by external, modern applications. These modern vendor applications rely on data from the agency management system to function, therefore a data exchange must be automated as part of the workflow, enabling the modern application interface to pick up where the legacy system left off, and finish the job.