Writing a Java-based Web Service

Advanced Customization > Info*Engine User’s Guide > Web Services Framework > Writing a Java-based Web Service

You also have the option of manually implementing your service directly in Java. In this case, you can generate a web service project using the following Apache Ant script:

<Windchill>/bin/adminTools/WebServices/new-project.xml

with a service.type of java. Then, in place of specifying the service.type.id property, instead specify the class to implement Java using the service.class property.

For example:

% cd <Windchill>
% mkdir prog_examples/jws/MyJavaProject
% ant -Dproject.dir=<Windchill>/prog_examples/jws/MyJavaProject
-Dservlet.name=MyJavaService
-Dsecurity.policy=userNameAuthSymmetricKeys -Dmain.class=org.myorg.MyJavaServiceClient
-Dservice.type=java -Dservice.class=org.myorg.MyJavaService
-f bin/adminTools/WebServices/new-project.xml create

Creating the new project generates a base class for your new web service, which can be found at:

<Windchill>/prog_examples/jws/MyJavaProject/src/org/myorg/MyJavaService.java

This contains source code that looks something like:

package org.myorg;

import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;
import com.ptc.jws.servlet.JaxWsWebService;

@WebService()
public class MyJavaService extends JaxWsWebService
{
@WebMethod(operationName="add")
public int add ( int a, int b )
{
return a+b;
}
}

You can also simply replace the example add method with your own web service method. You can also add other web service methods and any required supporting classes within the src directory of your project. Then compile, package, and deploy your new service as follows:

% cd <Windchill>/prog_examples/jws/MyJavaService/src/
% ant

This compiles your web service and packages it in a JAR file based on your servlet name within <Windchill>/codebase/WEB-INF/lib. This also deploys the service, which is secured using the security policy you specified when creating your project. Then you can implement your web service client in the same manner as described in Writing a Java-based Web Service Client.

If you choose to generate the client portion of your web service project, the client source code example might not compile properly if uncommented (it is commented out in the main method of your web service client). The client-generated source code assumes the web service in question is Info*Engine-based, and therefore generates source code based upon that assumption. You must then compile your client, examine the client side source code artifacts in the gensrc_client directory, and then adjust your client source accordingly. Finally, you must then rerun the ant compile and ant dist commands to recompile and package your client.

Consult the standard Java javadoc for the javax.jws, javax.xml.ws, and related packages to learn more about writing a Java web service. You can download these at http://java.sun.com.

Note that in the generated source code example your new web service class extends com.ptc.jws.servlet.JaxWsService. This is not an absolute requirement, but it is strongly suggested and provides you with some basic conveniences, such as:

• Access to an implicitly instantiated log4j logger in the $log instance variable, the logger name of which is based on your web service class name.

You can log messages by simply invoking methods on the logger such as:

$log.debug (“my message”);

Consult the log4j documentation for more information on logging with log4j, found at http://logging.apache.org/log4j/.

• Access to the javax.xml.ws.WebServiceContext associated with a web service request in the $wsc instance variable.

• Access to the javax.xml.ws.handler.MessageContext associated with a web service request using the getMessageContext() method.

• Access to the associated javax.servlet.http.HttpServletRequest object using the getServletRequest() method. This is important because this object is the only HttpServletRequest object that has been properly configured with the authenticated username used to access your service.

Standard Java web services provide access to the HttpServletRequest object through the MessageContext object stored under the MessageContext.SERVLET_REQUEST key. You should NOT use this servlet request object, but rather use the one returned using the getServletRequest() method of your web service. Using the HttpServletRequest object would create a conflict, as the security layer that preprocesses web service requests extracts and validates the security credentials from the incoming SOAP requests based on your security policy, and then imposes those credentials using a javax.servlet.http.HttpServletRequestWrapper object. The MessageContext key SERVLET_REQUEST is an immutable property, and so the security layer must store its version of the HttpServletRequest object under another key within the MessageContext. This object has the validated username imposed in the getRemoteUser() and getUserPrincipal() methods of this HttpServletRequest object.

Was this helpful?