I think the best way to tackle your question is to review the workflow between client, Web service and Web application...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
(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:
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:
- User interacts with a Windows client application.
- 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.
- 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.
- 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
Dig Deeper on Development implications of microservices architecture
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.