Familjen Kumlien - Astrid, Ella, Mari och Svante

Ok, the backend component - a stateless session bean - is in place with a generated pojo delegate. The next step is to run the ejbdoclet xdoclet task on the session bean in order to generate home and remote interface. This task is not webservice specific so I won´t write more about it here but make sure it runs ok and that you have generated deployment descriptors, home and remote interfaces for your bean. It´s also important that the generated REMOTE interface must extend the interface you generated from the .wsdl file. This can be achieved by using the @ejb.interface using the 'extends' attribute to specify your webservice business interface + EJBObject.
One problem you might run into is a clash between the signature of the generated interface and decleration of the local interface in the ejb-jar.xml file. The methods in the generated interface all declare that they throw java.rmi.RemoteException which is required for the remote interface. But, the local interface of the EJB is not allowed to throw RemoteException which means that the local and remote interface can´t extend the same generated interface. One solution is to remove the local and local-home entries in the ejb-jar.xml file.

With the ejb interfaces and deployment descriptors in place you can move on to compile your code (using the javac ant task and put the compiled code in a .jar file (using the jar ant task).

The jar file is the input to the next task which is the weblogic specific wlappc task. Some people say the wlappc task is buggy and recommend the use of the java ant task, calling the weblogic.appc class directly. I prefer the wlappc task as long as it works, the syntax is not as verbose as the java task. If you decide to go with the wlappc task you need to define it in your build.xml file:

<taskdef name="wlappc" classname="weblogic.ant.taskdefs.j2ee.Appc" classpathref="classpath" />

The actual use of the task would look like

<wlappc debug="${debug}" source="${dir.dist}/${jar_file}">
<classpath refid="classpath"/>
</wlappc>

The java task is a little bit more cumbersome to write and looks something like

<java fork="yes" classname="weblogic.appc" failonerror="true">
<sysproperty key="weblogic.home" value="${path.3pp.lib}\bea\weblogic/" />
<classpath refid="classpath" />
<classpath path="${path.3pp.lib}/sun/tools/tools.jar" />
<arg line="-classpath ${path.3pp.lib}/bea/weblogic/webservices.jar;${path.3pp.lib}/bea/weblogic/weblogic.jar;${path.3pp.lib}/apache/log4j/log4j.jar ${dir.dist}/${jar_file}" />
</java>

Allmost there! Just one final step left which is to use the weblogic servicegen task. The servicegen takes an ejb jar file as input, generates all the needed webservice components and packages them into an .war file. This .war file is then packaged together with the .jar file into an .ear file which can be deployed in your BEA Weblogic server. First you need to define the servicegen task:

<taskdef name="servicegen" classname="weblogic.ant.taskdefs.webservices.servicegen.ServiceGenTask" classpathref="classpath" />

The servicegen task has a nested service element which must be present. The element describes a single Web Service. You specify the name of webservice with the serviceName attribute.