The answer depends on whether the target web service is part of the same application or not.
If the target web service is part of the same application as the JSP or servlet, the short answer is that you shouldn't call the web service. The fact that you want to probably means that there is business logic in the web service that should instead be placed in a Java control.
To invoke a web service from within a WebLogic Workshop application, you use a Web Service control. But you should not use a Web Service control to invoke a web service that resides in the same application. Invoking a web service via a Web Service control means marshalling the method parameters into a SOAP message on the calling end and unmarshalling the SOAP message on the receiving end, then again for the method return value. This is very inefficient when the invocation is local.
In general, you should place business logic in custom Java controls instead of in web services. This allows you to access the business logic from various contexts in the application (web services, other controls, page flows) without incurring the cost of data marshalling and unmarshalling. Web Service controls should only be used to invoke web services that are truly external to your application.
If the target web service is remote and your JSP is part of a page flow, you can create a Web Service control from the web service's WSDL file and use the Web Service control from the page flow. To learn more about Web Service controls, see Web Service Control.
An alternative is to use the Java proxy classes for the web service from a JSP or servlet. WebLogic Workshop will generate a Java proxy that you may use to communicate with a WebLogic Workshop web service from any Java client, including a JSP page or servlet. The Java proxy is provided as a JAR file containing the web service-specific proxy classes.
For detailed instructions on how to use a Java proxy, see How Do I: Use the Java Proxy for a Web Service?