Accessing a JSP page could be considered the same as accessing a Web service. If
you think about it, calling a JSP page is a large method packaged in the form of
a servlet, which sends back character output. The biggest difference is in the
packaging.
A Web service defines an interface through which it's possible
to define exactly the data being sent to and from the Web service.
The JSP page,
on the other hand, just hands back a large character text stream in the HTTP
wrapper. This makes it hard to parse a JSP result for finer work. This makes a
Web service easier to use programmatically over a straight JSP page. Whenever
fine control of the data being sent over a HTTP request is required, it is time
to use a Web service.
The next fact to consider is state. One thing JSP and servlets
give the programmer is a concept of state: application, session, page, and so
on. A service isn't as tied to the concept of state. In fact, keeping a Web
service stateless has the advantage of making a Web service easier to scale and
move around from project to project.
However, a Web service doesn't necessarily
have access to maintaining state in the same manner as a JSP page. State within
a Web service will depend on the Web service server implementation being used by
a project. Some Web service servers will not maintain state; others, such as
Microsoft's .NET, will provide their Web services the exact same options of
state that an ASP page enjoys (application, session, and so on). Apache SOAP
does provide state management, and we will explore this idea further.
Reference:
Comments
Post a Comment