As I wrote before it is quite easy to set up a web service proxy with Mule3. in this example I take it a step further and I describe how you can add WS-Security implementation to it. Although in the end this also is quite easy you have to make the correct configuration choices to get everything to work.

The first thing I had to do in my Mule config was to drop the pattern prefix. This took me a while to discover because I think this isn’t very clear in the documentation. Anyway, after that change it is fairly straight forward.

Here is the Mule config I ended up with:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesoft.org/schema/mule/core"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:cxf="http://www.mulesoft.org/schema/mule/cxf"
      xmlns:spring="http://www.springframework.org/schema/beans"
      xmlns:http="http://www.mulesoft.org/schema/mule/http"
      xsi:schemaLocation="
        http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/3.2/mule.xsd
        http://www.mulesoft.org/schema/mule/cxf http://www.mulesoft.org/schema/mule/cxf/3.2/mule-cxf.xsd
        http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
        http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/3.2/mule-http.xsd">
 
    <flow name="create-client">
        <http:inbound-endpoint address="http://localhost:8080/create-client">
            <cxf:proxy-service/> 
        </http:inbound-endpoint>
        <http:outbound-endpoint address="http://localhost:8081/create-client">
            <cxf:proxy-client>
                <cxf:outInterceptors>
                    <spring:bean class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
                        <spring:constructor-arg>
                            <spring:map>
                                <spring:entry key="action" value="Timestamp Signature" />
                                <spring:entry key="user" value="${signature.user}" />
                                <spring:entry key="signaturePropFile" value="ws-security.properties" />
                                <spring:entry key="passwordCallbackClass" value="nl.redstream.adapter.MyKeystorePasswordCallback"/>
                            </spring:map>
                        </spring:constructor-arg>
                    </spring:bean>
                    <spring:bean class="org.apache.cxf.interceptor.LoggingOutInterceptor" />
                </cxf:outInterceptors>
            </cxf:proxy-client>
        </http:outbound-endpoint>    
    </flow>
    <flow name="get-client-status">
        <http:inbound-endpoint address="http://localhost:8081/get-status">
            <cxf:proxy-service>
                <cxf:inInterceptors>
                    <spring:bean class="org.apache.cxf.interceptor.LoggingInInterceptor" />
                    <spring:bean class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
                        <spring:constructor-arg>
                            <spring:map>
                                <spring:entry key="action" value="Signature" /> 
                                <spring:entry key="signaturePropFile" value="ws-security.properties" />
                            </spring:map>
                        </spring:constructor-arg>
                    </spring:bean>
                </cxf:inInterceptors>
            </cxf:proxy-service>
        </http:inbound-endpoint>
        <http:outbound-endpoint address="http://localhost:8080/get-status">
            <cxf:proxy-client />
        </http:outbound-endpoint>    
    </flow>
</mule>

As you can see I have added two flows. The first flow is ‘create-client’. I receive the incoming call from my own ‘inside’-application and add a signature and timestamp to it before I forward it to the ‘outside’ service.
The second flow works the other way around: I receive a signed message from the ‘outside’ client app and I need to validate this before I pas the message to my ‘inside’ application. To create the signature I need the password for to make use of my private key in the keystore. To supply this password I simply implemented the PasswordCallbackHandler that returns the corresponding password by looking it up in a property file. For more info about configuring the WS-security with CFX see here and also I found this entry about Apache WSS4J quite handy.
The security property file that is referred to in my Mule config file contains the following:

1
2
3
4

org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
org.apache.ws.security.crypto.merlin.keystore.type=JKS
org.apache.ws.security.crypto.merlin.file=/KeyStores/redstreamKeystore.jks
org.apache.ws.security.crypto.merlin.keystore.password=myPassword

For both flows I added the logging interceptor which is quite handy during testing and developing to see what is received and sent out. In the next post I will show how to generate the keystores and configure SoapUI to test the proxy manually.

In this post I show you how I setup a little test to see if and how easy I could manage to route the traffic to and from a web service through Mule ESB. The business case for this is an issue that one of our customers ran into when using web services. In a program hundreds of calls are done in a relative short period. Most of the time this isn’t a problem but sometimes vague issues occur. To get a better insight in this issue I want to put Mule in the middle so I can log the request and response and hopefully get a better idea about what is sent across the line. This is called the Web Service Proxy pattern and is commonly used to validate and audit the web service calls. For more background info about this pattern see this article.

To get started I downloaded the Mule Standalone edition here and installed it. That isn’t very hard, just untar the thing and set the MULE_HOME property. Go to the bin directory and give ‘./mule’ and off you go (except for a warning when running on MacOS 64-bit, but it doesn’t seem to harm so far…):

To create a test web service I setup a MockService in SoapUI. Like this:

All you need is a WSDL available. I just picked one from a previous project for testing purposes. With this MockService started you can fire your SOAP requests and will receive a (predefined) response from the MockService:

Next step is create a new Mule project (I still favor Maven above the Mule Studio):

• create new Maven project with

mvn mule-project-archetype:create -DartifactId=WSProxy -DmuleVersion=3.1.2

• Set up the WS Proxy

To create WS Proxy I followed the description here
Note: to make use of the pre-defined ‘pattern’ you must add the following dependency to the pom:

1 2 3 4 5 6

<dependency> <groupId>org.mule.patterns</groupId> <artifactId>mule-patterns-all</artifactId> <version>${mule.version}</version> <scope>provided</scope> </dependency>

My Mule config file looks like this:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

<?xml version="1.0" encoding="UTF-8"?> <mule xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:pattern="http://www.mulesoft.org/schema/mule/pattern" xsi:schemaLocation=" http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/3.1/mule.xsd http://www.mulesoft.org/schema/mule/pattern http://www.mulesoft.org/schema/mule/pattern/3.1/mule-pattern.xsd"> <description> Proxies a Web Service </description> <custom-transformer name="my-transformer" class="nl.redstream.proxy.wsproxy.MyTransformer" /> <object-to-string-transformer name="ObjectToStringTransformer" />   <pattern:web-service-proxy name="my-order-ws-proxy" inboundAddress="http://Pascal-Almas-MacBook-Pro.local:8090/my-order" responseTransformer-refs="ObjectToStringTransformer my-transformer" outboundAddress="http://Pascal-Almas-MacBook-Pro.local:8088/mockDataServiceSoapBinding" /> </mule>

• Fire up the proxy

To run the Mule application just make sure your Mule installation is running and in your project execute the command ‘mvn clean install’
You should see a message in your Mule console like this:

Now we can put the proxy at work by redirecting the SoapUI request to the url: http://Pascal-Almas-MacBook-Pro.local:8090/my-order. It should the be forwarded to the original url and the translator I put in between should output the content to the Mule console:

However if you try this for the first time big chance you will run into this issue (at least I did). To get around this issue modify the soapUI settings like this:

Some time ago I was asked to review existing web services for a customer. The main thing I noticed was that they were using Microsoft’s diffgram elements and attributes in their input and output messages. I was not familiar with this format but found out that it has been created by Microsoft to make synchronizing datasets in .Net easier. In this case the web services were implemented with Spring-WS, so there was no real reason to use this format on the server side. Besides, it only makes the web service less useful on the client side since it leads to complications if you want to use a XML-Object mapper like JAXB (see this for example). One of the issues with Diffgram is that, besides the XML containing the Diffgram element, also the XSD is included. This XSD describes the content of the Diffram Dataset, however, the XSD and the resulting Dataset do not match because extra attributes are added (this is described in more detail here).
I decided to create a new web service that would accept incoming messages without this diffgram and ms-data elements and attributes (and would have a similar response). To make this work, I made use of an XSL transformation in combination with the interceptors in Spring-WS (the assumption is that only the content of the DataInstance part of the DiffGram are interesting).
For example this is the original request the web service is expecting:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<?xml version="1.0" encoding="UTF-8"?>
<diffgr:diffgram xmlns:msdata="urn:schemas-microsoft-com:xml-msdata" xmlns:diffgr="urn:schemas-microsoft-com:xml-diffgram-v1">
	<CustomerDataSet>
		<Customers diffgr:id="Customers1" msdata:rowOrder="0" diffgr:hasChanges="inserted">
			<CustomerID>ALFKI</CustomerID>
			<CompanyName>New Company</CompanyName>
		</Customers>
		<Customers diffgr:id="Customers2" msdata:rowOrder="1"  diffgr:hasChanges="inserted">
			<CustomerID>ANATR</CustomerID>
			<CompanyName>Ana Trujillo Emparedados y Helados</CompanyName>
		</Customers>
		<Customers diffgr:id="Customers3" msdata:rowOrder="2"  diffgr:hasChanges="inserted">
			<CustomerID>ANTON</CustomerID>
			<CompanyName>Antonio Moreno Taquera</CompanyName>
		</Customers>
		<Customers diffgr:id="Customers4" msdata:rowOrder="3"  diffgr:hasChanges="inserted">
			<CustomerID>AROUT</CustomerID>
			<CompanyName>Around the Horn</CompanyName>
		</Customers>
	</CustomerDataSet>
</diffgr:diffgram>

I created a new web service endpoint to which I added the XSLT interceptors. The new endpoint would expect this as a request:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<?xml version="1.0" encoding="UTF-8"?>
<CustomerDataSet>
	<Customers>
		<CustomerID>ALFKI</CustomerID>
		<CompanyName>New Company</CompanyName>
	</Customers>
	<Customers>
		<CustomerID>ANATR</CustomerID>
		<CompanyName>Ana Trujillo Emparedados y Helados</CompanyName>
	</Customers>
	<Customers>
		<CustomerID>ANTON</CustomerID>
		<CompanyName>Antonio Moreno Taquera</CompanyName>
	</Customers>
	<Customers>
		<CustomerID>AROUT</CustomerID>
		<CompanyName>Around the Horn</CompanyName>
	</Customers>
</CustomerDataSet>

As you can see this last example is quite simple and easy to use in combination with JAXB for example.
To create the original request out of the new one I made use of the following XSLT:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fo="http://www.w3.org/1999/XSL/Format" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:fn="http://www.w3.org/2005/xpath-functions" exclude-result-prefixes="xs fn fo">
	<xsl:output method="xml" encoding="UTF-8" indent="yes"/>
	<xsl:template match="/">
		<diffgr:diffgram xmlns:msdata="urn:schemas-microsoft-com:xml-msdata" xmlns:diffgr="urn:schemas-microsoft-com:xml-diffgram-v1">
			<xsl:copy>
				<!-- copy the attributes (if any) of the root element -->
				<xsl:copy-of select="@*"/>
				<xsl:apply-templates/>
			</xsl:copy>
		</diffgr:diffgram>
	</xsl:template>
	<!-- match any other element and copy it with the attributes -->
	<xsl:template match="*">
		<xsl:copy>
			<xsl:copy-of select="@*"/>
			<xsl:apply-templates/>
		</xsl:copy>
	</xsl:template>
	<xsl:template match="/CustomerDataSet/Customers">
		<Customers>
			<xsl:attribute name="id" namespace="urn:schemas-microsoft-com:xml-diffgram-v1">Customers<xsl:value-of select="position()"/></xsl:attribute>
			<xsl:attribute name="rowOrder" namespace="urn:schemas-microsoft-com:xml-msdata"><xsl:value-of select="position()-1"/></xsl:attribute>
			<xsl:attribute name="hasChanges" namespace="urn:schemas-microsoft-com:xml-diffgram-v1">inserted</xsl:attribute>
			<xsl:apply-templates/>
		</Customers>
	</xsl:template>
</xsl:stylesheet>

And for the response the opposite transformation is performed. The original response is used as input and the XSLT will filter out all diffgram and ms-data elements and attributes.
Here is an example XSL that takes the original CustomerDataSet as input and tranforms it the the more ‘simple’ format:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

<?xml version="1.0" encoding="UTF-8"?>
<?altova_samplexml example-original.xml?>
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:diffgr="urn:schemas-microsoft-com:xml-diffgram-v1" xmlns:fo="http://www.w3.org/1999/XSL/Format" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:fn="http://www.w3.org/2005/xpath-functions" exclude-result-prefixes="xs fn fo ">
	<xsl:output method="xml" encoding="UTF-8" indent="yes"/>
	<xsl:template match="/">
		<xsl:copy>
			<!-- copy the attributes (if any) of the root element -->
			<xsl:copy-of select="@*"/>
			<xsl:apply-templates/>
		</xsl:copy>
	</xsl:template>
	<!-- match any other element and copy it with the attributes. Use local-name to get rid of the diffgr and ms-data namespaces -->
	<xsl:template match="*">
		<xsl:element name="{local-name()}">
			<xsl:copy-of select="@*"/>
			<xsl:apply-templates/>
		</xsl:element>
	</xsl:template>
	<!-- do not copy the attributes for  element'Customers' "/> -->
	<xsl:template match="/diffgr:diffgram/CustomerDataSet/Customers">
		<xsl:element name="{local-name()}">
			<xsl:apply-templates/>
		</xsl:element>
	</xsl:template>
	<!-- Remove the tag for the diffgram -->
	<xsl:template match="/diffgr:diffgram">
		<xsl:apply-templates/>
	</xsl:template>
</xsl:stylesheet>

With this post I have shown how you can use a simple XSLT to get rid of the Diffgram elements and attributes, of course with some assumptions that should be taken into account.

From time to time I am evaluating a tool or framework for which I need a web service. Although there are examples of running serviuces available on the web, I don´t always have access to the web and sometimes you need some more control over the service so you can edit/influence the corresponding WSDL. For these cases I created the following class which is all you need to get a web service running on your local machine (assuming you have JDK1.6 installed).
All the source you need is the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

package nl.redstream.ws;
 
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;
import javax.xml.ws.Endpoint;
 
/**
 * @author Pascal Alma
 */
 
@WebService
public class EchoServer {
 
	@SOAPBinding(style = Style.DOCUMENT)
	public String getEcho(String txt) {
			return "echo: " + txt;
		}
 
	public static void main(String[] args) {
		EchoServer myServer = new EchoServer ();
		Endpoint endpoint = Endpoint.publish(
				"http://localhost:8181/echo", myServer);
	}
}

When you run this class (and leave it running), you can point your browser to go to ‘http://localhost:8181/echo?wsdl’ and you receive the wsdl for the web service:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

<?xml version="1.0" encoding="UTF-8"?><!-- Published by JAX-WS RI at http://jax-ws.dev.java.net. RI's version is JAX-WS RI 2.1.6 in JDK 6. --><!-- Generated by JAX-WS RI at http://jax-ws.dev.java.net. RI's version is JAX-WS RI 2.1.6 in JDK 6. --><definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://ws.redstream.nl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://ws.redstream.nl/" name="EchoServerService">
<types>
  <xsd:schema>
    <xsd:import namespace="http://ws.redstream.nl/" schemaLocation="http://localhost:8181/echo?xsd=1"></xsd:import>
  </xsd:schema>
</types>
<message name="getEcho">
  <part name="parameters" element="tns:getEcho"></part>
</message>
<message name="getEchoResponse">
  <part name="parameters" element="tns:getEchoResponse"></part>
</message>
<portType name="EchoServer">
  <operation name="getEcho">
    <input message="tns:getEcho"></input>
    <output message="tns:getEchoResponse"></output>
  </operation>
</portType>
<binding name="EchoServerPortBinding" type="tns:EchoServer">
  <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"></soap:binding>
  <operation name="getEcho">
    <soap:operation soapAction=""></soap:operation>
    <input>
      <soap:body use="literal"></soap:body>
    </input>
    <output>
      <soap:body use="literal"></soap:body>
    </output>
  </operation>
</binding>
<service name="EchoServerService">
  <port name="EchoServerPort" binding="tns:EchoServerPortBinding">
    <soap:address location="http://localhost:8181/echo"></soap:address>
  </port>
</service>
</definitions>

You can now test your tool/ product by using this web service.

In my current project we are going to need a BPEL engine besides our Mule CE implementation. Actually, we will use Mule for our stateless communication between systems and use BPEL for the stateful processes. One of the possible frameworks to use as a BPEL engine is Apache ODE. In this post I will show you how you can start a BPEL process in Apache ODE with Mule. As you will see, it is merely a combination of posts I made earlier, but I think it is nice to have the complete thing in one post.

Step 0: Assumptionss
Assumed is:

• an Apache ODE instance (preferably deployed in Tomcat)
• Maven 2.2.0
• JDK 1.6
• Netbeans 6.8,
• Mule CE 2.2.2-SNAPSHOT

Of course, it might work with other version but these are the versions I used.

Step 1: Create a running BPEL process

The first step is to create a running BPEL example. I use the latest version of Netbeans for that and
this post. To make use of the SOA wizards in the new Netbeans you have to enable this as an extension as described here.
To create the BPEL example perform the following steps:

1. Creating a new BPEL module named ‘TextModule’
   
2. Add a WSDL to the project

Add a WSDL that describes the web service (remark: I wasn’t able to create a document-literal web service with the wizard in Netbeans so I edited the source by hand afterwards). Here is my WSDL.

3. Add a BPEL process to the module, name it ‘txtLengthProcess’
   

   This created process is empty so add functionality to it by following the guidelines as in this post. I ended up with the following process diagram:
   
   The mapping in the assignment step looks like this:
   
   I created the necessary variables to assign the values to in the ‘receive’ and ‘reply’ step.

4. Create a file ‘deploy.xml’
   My file has the following content:

   1 2 3 4 5 6 7 8 9 10 11 12

   <?xml version="1.0" encoding="UTF-8"?> <deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03" xmlns:pns="http://www.redstream.nl/TxtLengthProcess" xmlns:wns="http://www.redstream.nl/TxtLengthService">   <process name="pns:TxtLengthProcess"> <active>true</active> <provide partnerLink="TxtLengthPartnerLink"> <service name="wns:TxtLengthServiceService" port="TxtLengthServicePort"/> </provide> </process> </deploy>

5. Deploy it to the Tomcat instance that is running Apache ODE
   To deploy the process create a directory named ‘TxtLengthService’ under ‘/webapps/ode/WEB-INF/processes’. Copy the three files (deploy.xml, TxtLengthProcess.bpel and TxtLengthService.wsdl) to this directory. When your deployment was successful you’ll see the ‘TxtLengthService.wsdl’ at http://localhost:8080/ode/services/listServices:
   
6. (Optional) you can test the service with SoapUI
   With a successful request-response you will get the following result:
   

If you want more details on how to set up a Apache ODE service have look here. It goes into more detail then I am in this post.

Step 2: Generate Java client for web service to start ODE process

We use Metro for this because we had some bad experiences when using CXF for this. It is described here how to do this in combination with Maven.
I created a new Maven project with this ‘pom.xml’.
When the client is generated you can test it with a test class like this:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

package nl.redstream.ws.test;   import nl.redstream.txtlengthservice.TxtLengthService; import org.junit.Test;   /** * * @author pascal */ public class TestService {   @Test public void testIt() { TxtLengthService service = new TxtLengthService();   String value = service.getTxtLengthServiceSOAP11PortHttp().txtLengthOperation("RedStream");   System.out.println("result = " + value); } }

Step 3: Create the Mule project

To let Mule call the BPEL process I created a new Maven project that is able to test the call with a Mule client. The project is based on this ‘pom.xml’.
The used ‘ode-test-config.xml’ looks like:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

<?xml version="1.0" encoding="UTF-8"?> <mule xmlns="http://www.mulesource.org/schema/mule/core/2.2" xmlns:spring="http://www.springframework.org/schema/beans" xmlns:test="http://www.mulesource.org/schema/mule/test/2.2" xmlns:vm="http://www.mulesource.org/schema/mule/vm/2.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://www.mulesource.org/schema/mule/core/2.2 http://www.mulesource.org/schema/mule/core/2.2/mule.xsd http://www.mulesource.org/schema/mule/test/2.2 http://www.mulesource.org/schema/mule/test/2.2/mule-test.xsd http://www.mulesource.org/schema/mule/vm/2.2 http://www.mulesource.org/schema/mule/vm/2.2/mule-vm.xsd http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">   <model name="mule-ode"> <service name="start"> <inbound> <vm:inbound-endpoint path="msg-in" synchronous="true"/> </inbound> <component class="nl.redstream.mule.BpelProcessClient" /> </service> </model> </mule>

The created component class that handles the call to the SOAP client looks like:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

package nl.redstream.mule;   import nl.redstream.txtlengthservice.TxtLengthService;   /** * * @author pascal */ public class BpelProcessClient {   public String callProcess(String request) { return new TxtLengthService().getTxtLengthServiceSOAP11PortHttp().txtLengthOperation(request); } }

And the used test class looks like:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

package nl.redstream.mule;   import org.junit.Test; import org.mule.api.MuleException; import org.mule.api.MuleMessage; import org.mule.module.client.MuleClient; import org.mule.tck.FunctionalTestCase;   public class BpelProcessClientTest extends FunctionalTestCase {   private MuleClient client = null;   protected MuleClient getClient() { try { if (client == null) { client = new MuleClient(); } } catch (MuleException e) { throw new RuntimeException(e); } return client; }   protected final String getConfigResources() { return "config/ode-test-config.xml "; }   @Test public void testBpelTest() throws MuleException { MuleMessage msg = getClient().send("vm://msg-in", "123456789012345", null); System.out.println("payload = " + msg.getPayload()); } }

When the test class is executed this results in the following output:

**********************************************************************
* Mule ESB and Integration Platform *
* Version: 2.2.2-SNAPSHOT Build: 15252 *
* MuleSource, Inc. *
* For more information go to http://mule.mulesource.org *
* *
* Server started: 12/17/09 8:34 PM *
* Server ID: 3d3eb71b-eb43-11de-bca6-7b92b51f04e0 *
* JDK: 1.6.0_17 (mixed mode) *
* OS encoding: MacRoman, Mule encoding: UTF-8 *
* OS: Mac OS X (10.6.2, x86_64) *
* Host: macbook-van-pascal-alma.local (192.168.1.204) *
* *
* Agents Running: None *
**********************************************************************
INFO 2009-12-17 20:34:50,730 [main] org.mule.module.client.MuleClient: Using existing MuleContext: org.mule.DefaultMuleContext@1d6b6c55
INFO 2009-12-17 20:34:50,756 [main] org.mule.transport.vm.VMMessageDispatcher: Connected: endpoint.outbound.vm://msg-in
payload = 15
INFO 2009-12-17 20:34:51,784 [main] org.mule.transport.vm.VMConnector: Removing listener on endpointUri: vm://msg-in
INFO 2009-12-17 20:34:51,784 [main] org.mule.transport.vm.VMMessageReceiver: Disconnected: VMMessageReceiver{this=5a56182f, receiverKey=msg-in, endpoint=vm://msg-in}
INFO 2009-12-17 20:34:51,785 [main] org.mule.component.DefaultJavaComponent: Stopping: org.mule.component.DefaultJavaComponent component for: SedaService{start}
INFO 2009-12-17 20:34:51,785 [main] org.mule.model.seda.SedaService: Mule Service start has been stopped successfully
INFO 2009-12-17 20:34:51,787 [main] org.mule.transport.vm.VMConnector: Stopping: VMConnector{this=75d709a5, started=true, initialised=true, name=’connector.VM.0′, disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=true, supportedProtocols=[vm], serviceOverrides=null}
INFO 2009-12-17 20:34:51,787 [main] org.mule.transport.vm.VMConnector: Disconnected: VMConnector{this=75d709a5, started=false, initialised=true, name=’connector.VM.0′, disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=false, supportedProtocols=[vm], serviceOverrides=null}
INFO 2009-12-17 20:34:51,787 [main] org.mule.transport.vm.VMConnector: Stopped: VMConnector{this=75d709a5, started=false, initialised=true, name=’connector.VM.0′, disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=false, supportedProtocols=[vm], serviceOverrides=null}
INFO 2009-12-17 20:34:51,788 [main] org.mule.util.queue.TransactionalQueueManager: Stopping ResourceManager
INFO 2009-12-17 20:34:51,788 [main] org.mule.util.queue.TransactionalQueueManager: Stopped ResourceManager
INFO 2009-12-17 20:34:51,788 [main] org.mule.transport.vm.VMConnector: Disposing: VMConnector{this=75d709a5, started=false, initialised=true, name=’connector.VM.0′, disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=false, supportedProtocols=[vm], serviceOverrides=null}
INFO 2009-12-17 20:34:51,788 [main] org.mule.transport.vm.VMMessageDispatcher: Disconnected: VMMessageDispatcher{this=1915470e, endpoint=vm://msg-in, disposed=false}
INFO 2009-12-17 20:34:51,788 [main] org.mule.transport.vm.VMConnector: Disposed: VMConnector{this=75d709a5, started=false, initialised=false, name=’connector.VM.0′, disposed=true, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=false, supportedProtocols=[vm], serviceOverrides=null}
INFO 2009-12-17 20:34:51,789 [main] org.mule.config.spring.MuleApplicationContext: Closing org.mule.config.spring.MuleApplicationContext@356f144c: display name [org.mule.config.spring.MuleApplicationContext@356f144c]; startup date [Thu Dec 17 20:34:49 CET 2009]; root of context hierarchy
INFO 2009-12-17 20:34:51,789 [main] org.springframework.beans.factory.support.DefaultListableBeanFactory: Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@29abc69: defining beans [customEditorConfigurer,_muleObjectNameProcessor,_mulePropertyPlaceholderProcessor, _muleSimpleRegistryBootstrap,_muleNotificationManager,_muleConfiguration,._muleNotificationManager: notification.1,._muleNotificationManager:notification.2,._muleNotificationManager:notification.3, ._muleNotificationManager:notification.4,._muleNotificationManager:notification.5,._muleNotificationManager: notification.6,._muleNotificationManager:notification.7,._muleNotificationManager:notification.8, ._muleNotificationManager:notification.9,._muleNotificationManager:notification.10,_muleSystemModel, _muleQueueManager,_muleSecurityManager,_muleProperties,_muleEndpointFactory,_muleStreamCloserService, _defaultThreadingProfile,_defaultMessageDispatcherThreadingProfile,_defaultMessageRequesterThreadingProfile, _defaultMessageReceiverThreadingProfile,_defaultServiceThreadingProfile,_defaultRetryPolicyTemplate, mule-ode,start,.start:inbound.11,.start:inbound.11:inbound-endpoint.12,.start:component.13]; root of factory hierarchy
INFO 2009-12-17 20:34:51,995 [main] org.mule.DefaultMuleContext:
**********************************************************************
* Mule shut down normally on: 12/17/09 8:34 PM *
* Server was up for: 0 days, 0 hours, 0 mins, 1.318 sec *
**********************************************************************
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.103 sec

So by finishing this post you should be able to execute a (simple) BPEL process in Apache ODE by using Mule. However, it is not certain we will use Apache ODE like this. I think we would like Intalio|server more because of the handy features/tooling they have added to Apache ODE.

]]> http://www.redstream.nl/2009/12/18/combining-mule-with-a-bpel-engine/feed/ 0 http://www.redstream.nl/2009/07/05/error-import-wsdl-in-soapui/ http://www.redstream.nl/2009/07/05/error-import-wsdl-in-soapui/#comments Sun, 05 Jul 2009 10:08:46 +0000 Pascal Alma http://www.pascalalma.net/?p=920 Continue reading →]]>



Although it has been a while since I posted about SoapUI I am still receiving questions about the tool. The most frequently asked question is how to solve the error ‘Error import WSDL’ so I will post the steps I took in the past to solve this error, hoping that this might help you. The first step I usually take is to try to open the WSDL in a web browser.
If this is also not working and the WSDL runs on a machine on the world wide web then you have 3 options:

1. No access to internet

Easy to check if that is the case but you might just want to check it out to make sure

2. the link to the wsdl is dead

This often occurs if the source where you got the link from is rather old, like an article on the net that was posted in 2005.

3. a typo is made in the link

Make sure you have the right url with all ‘?’ and ‘/’ in the right place

If the WSDL in the browser is also not working and the WSDL runs on a machine in your local network then please check the following:

1. Make sure you can access the machine over HTTP

Try to ping the machine name or IP address to see if it is accessible from your machine. Although there is a chance the machine is accessible without being ping-able it often gives a good indication.

2. Make sure the web server hosting the wsdl (and webservice) is up

Point your browser to the machine and check if there is a web server running on port 80/8080/8000 or something like that. If the web server is down also the WSDL will not be found.

3. a typo is made in the link

Make sure you have the right url with all ‘?’ and ‘/’ in the right place

If the WSDL is showing up in the browser and the WSDL runs on a machine on the world wide web then you might check the following:

• Need a proxy to access the net

Check to see if your web browser uses a proxy to get access to the net. This is very common if your computer is connected to a companies network. If so, then add this proxy to the preferences in Soap UI so it will use the same proxy.

• a typo is made in the link

Make sure you have the right url with all ‘?’ and ‘/’ in the right place. I also recently heard leading or trailing spaces might lead to unexpected behaviour in SoapUI so please make sure to remove them.

If the WSDL is showing up in the browser and the WSDL runs on a machine in your local network then please check the following:

• a typo is made in the link

Make sure you have the right url with all ‘?’ and ‘/’ in the right place. I also recently heard leading or trailing spaces might lead to unexpected behaviour in SoapUI so please make sure to remove them.

• use the host’s IP address instead of host name

I once got the situation it was only working with the IP address, but apparently not able to resolve the host name, so you could try this.

So, these are the things you could check. I know there will be much more reasons why this error might show up (how about https access for example), but I hope that in your case these steps will help to solve it. If you know other solutions to this problem just let me know, so I can add them to this list.

]]> http://www.redstream.nl/2009/07/05/error-import-wsdl-in-soapui/feed/ 2 http://www.redstream.nl/2009/07/01/mule2-cxf-and-serializable-classes/ http://www.redstream.nl/2009/07/01/mule2-cxf-and-serializable-classes/#comments Wed, 01 Jul 2009 19:25:17 +0000 Pascal Alma http://www.pascalalma.net/?p=890 Continue reading →]]>



This post is one of the series of posts about issues that occurred when we were using Mule2 in a real life project. As I wrote in my last post we were using CXF to call a webservice with Mule. After the issues we ran into as described in that article, we ended up with the folowing issue. The generated classes that are used for the XML to Java mapping has to be serializable. This is possible by using a binding file when generating the classes with Maven as described in the documentation here.
However, I haven’t been able to do this in my situation. And according to this post I am not the only one. So to keep the project moving I decided to make use of Metro JAX-WS instead of CXF, since this CXF thing had cost us enough of our precious time. With the Metro implementation we had it running in no time without any unexpected issues.

]]> http://www.redstream.nl/2009/07/01/mule2-cxf-and-serializable-classes/feed/ 3 http://www.redstream.nl/2009/03/14/make-serializable-jax-ws-clients-with-maven2/ http://www.redstream.nl/2009/03/14/make-serializable-jax-ws-clients-with-maven2/#comments Sat, 14 Mar 2009 20:24:30 +0000 Pascal Alma http://www.pascalalma.net/?p=667 Continue reading →]]>



As I described here I am using JAXWS’ wsimport function to generate a Webservice interface and the JAXB objects for my application. The generated JAXB objects are also used as parameters for some remote EJB calls. Therefore I had to make the JAXB objects serializable. But the question is how to do this since these classes are generated.
Well, in these situations Google is your friend. After a short search I found out to perform the following steps:

1. Create a binding file and add the xjc:serializable option to it.

It will look like this:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:jaxb="http://java.sun.com/xml/ns/jaxb" xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc" elementFormDefault="qualified" attributeFormDefault="unqualified" jaxb:extensionBindingPrefixes="xjc" jaxb:version="2.1"> <xs:annotation> <xs:appinfo> <jaxb:globalBindings> <xjc:serializable /> </jaxb:globalBindings> </xs:appinfo> </xs:annotation> </xs:schema>

I name the file ‘jaxb-bindings.xml’ and added it to the resources directory of my Maven project.

2. Setup the JAX-WS Maven plugin like this:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

... <!-- Plugin to generate JAXB classes and webservice interface --> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>jaxws-maven-plugin</artifactId> <version>1.10</version> <executions> <execution> <goals> <goal>wsimport</goal> </goals> </execution> </executions> <configuration> <wsdlDirectory>src/main/resources/wsdl</wsdlDirectory> <sourceDestDir>${basedir}/generated/src/main/java</sourceDestDir> <bindingFiles> <bindingFile>${basedir}/src/main/resources/jaxb/jaxb-bindings.xml</bindingFile> </bindingFiles> </configuration> <dependencies> <dependency> <groupId>javax.jws</groupId> <artifactId>jsr181-api</artifactId> <version>1.0-MR1</version> </dependency> </dependencies> </plugin> ...

This configuration looks similar to the one I had except of course the ‘bindingFiles’ part.

That’s it! If you generate the sources again by running ‘mvn clean install’ and check the generated files you will see that now they implement the Serializable interface.

]]> http://www.redstream.nl/2009/03/14/make-serializable-jax-ws-clients-with-maven2/feed/ 1 http://www.redstream.nl/2009/03/09/hello-world-with-glassfish-metro-and-maven/ http://www.redstream.nl/2009/03/09/hello-world-with-glassfish-metro-and-maven/#comments Mon, 09 Mar 2009 11:47:44 +0000 Pascal Alma http://www.pascalalma.net/?p=576 Continue reading →]]>



As might be clear by my latest posts I am currently working on a project where we use Glassfish and EJB3 as platform for our JEE application. One thing that we had to decide upon was the WebService framework we were going to use. There are quite some options available but I decided to have a look at Metro, the JAX-WS reference implementation. Also due to the fact that it is integrated with EJB3 and Glassfish.
To create my ‘HelloWorld’ service with Metro and Maven2 I used this post as a guideline. I am also going to work top-down (WSDL -> Java approach) so I will be starting with an existing WSDL and then generate/create the web service interface for that. Although the post I used as a guideline is very detailed I ran into some issues, mostly the result of using different versions of dependencies and plugins. In this post I show the steps I made to get it working. I am using Glassfish-v2ur2 (comes with Netbeans 6.5) , JDK1.5 and Maven 2.0.9.


1. Create the Maven2 project

Issue the command: mvn archetype:create -DgroupId=net.pascalalma.ws -DartifactId=echo-service
This results in a standard Maven project. I removed the generated java files since we don’t need them.

2. Setup the pom

The default pom that was created in the first step has to be modified. I added several things which I explain next:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

<dependencies> ... <dependency> <groupId>com.sun.xml.ws</groupId> <artifactId>jaxws-rt</artifactId> <version>2.1.4</version> </dependency> <dependency> <groupId>javax.jws</groupId> <artifactId>jsr181-api</artifactId> <version>1.0-MR1</version> </dependency> ... </dependencies>

These are dependencies that are used by the JAXWS plugin, which is used to generate the Webservice interface based on the supplied WSDL.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

<dependencies> ... <dependency> <groupId>glassfish</groupId> <artifactId>appserv-rt.jar</artifactId> <version>LATEST</version> <scope>system</scope> <systemPath>${glassfish.home}/lib/appserv-rt.jar</systemPath> </dependency> <dependency> <groupId>glassfish</groupId> <artifactId>javaee.jar</artifactId> <version>LATEST</version> <scope>system</scope> <systemPath>${glassfish.home}/lib/javaee.jar</systemPath> </dependency> ... </dependencies>

These dependencies are used to compile the generated code and the WebService implementation class.

Next there are some plugins to be configured:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

<build> <plugins> ... <!-- Plugin to generate JAXB classes and webservice interface --> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>jaxws-maven-plugin</artifactId> <version>1.10</version> <executions> <execution> <goals> <goal>wsimport</goal> </goals> </execution> </executions> <configuration> <wsdlDirectory> src/main/resources/wsdl </wsdlDirectory> <sourceDestDir> ${basedir}/generated/src/main/java </sourceDestDir> </configuration> <dependencies> <dependency> <groupId>javax.jws</groupId> <artifactId>jsr181-api</artifactId> <version>1.0-MR1</version> </dependency> </dependencies> </plugin> ... </plugins> </build>

This plugin is used for the actual generation of the Java code. It will put the code in the ‘generated’ folder.
The next two plugins are used for compiling and cleaning the code. I have described the use of these plugins here.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

<build> <plugins> ... <!-- Plugin to add delete path to build cycle --> <plugin> <artifactId>maven-clean-plugin</artifactId> <version>2.2</version> <configuration> <filesets> <fileset> <directory>generated/src/main/java</directory> <includes> <include>**/*.java</include> </includes> </fileset> </filesets> </configuration> </plugin> </plugins> </build> ... </plugins> </build>

And finally I add the necessary code to tell the compiler JDK 1.5 has to be used:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

<build> <plugins> ... <!-- plugin to compile Java1.5 code --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.0.2</version> <configuration> <source>1.5</source> <target>1.5</target> </configuration> </plugin> ... </plugins> </build>

The complete pom.xml can be found here.

3. Create the WSDL

As shown in the plugin configuration I have added a WSDL file to a ‘wsdl’ folder in the ‘resource’ folder. The WSDL looks like this:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

<?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions name="DoubleIt" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://www.redstream.nl/EchoIt" xmlns:types="http://www.redstream.nl/EchoIt/types" targetNamespace="http://www.redstream.nl/EchoIt"> <wsdl:types> <xsd:schema targetNamespace="http://www.redstream.nl/EchoIt/types"> <xsd:element name="EchoIt"> <xsd:complexType> <xsd:sequence> <xsd:element name="textToEcho" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="EchoItResponse"> <xsd:complexType> <xsd:sequence> <xsd:element name="echoedText" type="xsd:string" /> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> </wsdl:types> <wsdl:message name="EchoItRequest"> <wsdl:part element="types:EchoIt" name="parameters" /> </wsdl:message> <wsdl:message name="EchoItResponse"> <wsdl:part element="types:EchoItResponse" name="parameters" /> </wsdl:message> <wsdl:portType name="EchoItPortType"> <wsdl:operation name="EchoIt"> <wsdl:input message="tns:EchoItRequest" /> <wsdl:output message="tns:EchoItResponse" /> </wsdl:operation> </wsdl:portType> <wsdl:binding name="EchoItBinding" type="tns:EchoItPortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> <wsdl:operation name="EchoIt"> <soap:operation soapAction=""/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="EchoItService"> <wsdl:port name="EchoItPort" binding="tns:EchoItBinding"> <soap:address location="http://localhost:8080/echoit/echoit"/> </wsdl:port> </wsdl:service> </wsdl:definitions>

4. Generate the code

When all this is in place we can generate the Java code by simply issue the command:
mvn clean install
In Netbeans we can see the generated code in our project browser:


5. Create Web Service implementation

Next step is to create the implementation class for the web service. Please note that I will create a EJB Web Service endpoint. This way I don’t need a web container nor any web deployment descriptor.
Here is the web service implementation:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

package net.pascalalma.ws;   import javax.ejb.Stateless; import javax.jws.WebService;   /** * Hello world! * */ @WebService(targetNamespace = "http://www.redstream.nl/EchoIt", portName="EchoItPort", serviceName="EchoItService", endpointInterface="nl.redstream.echoit.EchoItPortType") @Stateless public class EchoServiceImpl { public String echoIt(String it) { return "Echo " + it +"!"; } }

6. Deploy it to Glassfish

With the implementation in place rebuild the project so a ejb-jar is created. Again issue the command:
mvn clean install
The created jar file in the ‘target’ directory can then be deployed to Glassfish. This can be done by using a Maven plugin as described here or by using the Glassfish Admin Console. I used the last one in this case. It should look similar to this after successful deployment:


7. Test the service

The easiest way to test it is, if you already have the Glassfish Admin Console open, to click the ‘test’ button and fill in a text as input parameter. As result you should get something like:


Well, if you did the things as I described you have a big chance it will work in one time, but in my case there were some problems when trying to get this to work. Some of the Issues I ran into while building the projects:

1. Missing dependencies

Missing:
———-
1) com.sun.xml.ws:jaxws-tools:jar:2.1.5

I had to use another plugin version then the one that is recommended at the plugin homepage:

1 2 3 4 5 6

<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>jaxws-maven-plugin</artifactId> <version>1.10</version> ... </plugin>

2. More missing libraries

I then ran into this one:

org.apache.maven.lifecycle.LifecycleExecutionException: Error executing: wsimport [-s, /Users/pascal/projects/metro-service/echo-service/target/generated, -d, /Users/pascal/projects/metro-service/echo-service/target/classes, /Users/pascal/projects/metro-service/echo-service/src/main/webapp/WEB-INF/wsdl/echo-it.wsdl]
…

See also this thread.

It appears it has something to do with JDK1.5 instead of JDK1.6. I solved it by adding the dependencies for the JSR181.

I hope that this posts avoids the exceptions which I encountered and make the use of JAXWS with Maven more smoothly because in the end it is a very nice solution!

]]> http://www.redstream.nl/2009/03/09/hello-world-with-glassfish-metro-and-maven/feed/ 4 http://www.redstream.nl/2009/02/11/create-a-ejb3-webservice-with-maven2-running-on-glassfish/ http://www.redstream.nl/2009/02/11/create-a-ejb3-webservice-with-maven2-running-on-glassfish/#comments Wed, 11 Feb 2009 12:04:03 +0000 Pascal Alma http://www.pascalalma.net/?p=476 Continue reading →]]>



A year ago I posted how you could create a EJB3 webservice and deploy it on JBoss with Maven. Currently I am doing a similar thing at my project, but this time I deploy it to Glassfish. The creation of the web serive is similar but for the deployment you will need another plugin (if you want Maven to deploy the webservice, of course).
The ‘settings.xml’ file for Maven2 looks like:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

<settings> <profiles> <profile> <id>develop</id> <properties> <glassfish.home>/Applications/NetBeans/glassfish-v2ur2</glassfish.home> <hibernate.show_sql>true</hibernate.show_sql> </properties> <pluginRepositories> <pluginRepository> <id>maven.java.net</id> <name>Java.net Maven2 Repository</name> <url>http://download.java.net/maven/2</url> </pluginRepository> </pluginRepositories> </profile> </profiles> <activeProfiles> <activeProfile>develop</activeProfile> </activeProfiles> </settings>

Lateron we’ll see that Maven uses the Glassfish plugin and the property for the deployment of our application.
I have created a project ‘my-ejb-project’ with a simple EJB session bean. The bean (and it’s interface) looks like this:

1 2 3 4 5 6 7 8 9

package net.pascalalma.services;   import javax.ejb.Remote;   @Remote public interface EchoService {   public String sayHello(String subject); }

and its implementation:

1 2 3 4 5 6 7 8 9 10 11 12

package net.pascalalma.services.impl;   import javax.ejb.Stateless; import net.pascalalma.services.EchoService;   @Stateless public class EchoServiceBean implements EchoService {   public String sayHello(String name) { return "Hi " + name + "!"; } }

To build this project I have this in the project’s pom.xml file:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>net.pascalalma</groupId> <artifactId>my-ejb-project</artifactId> <packaging>ejb</packaging> <version>1.0-SNAPSHOT</version> <name>my-ejb-project</name> <url>http://www.redstream.nl</url> <dependencies> <dependency> <groupId>glassfish</groupId> <artifactId>appserv-rt.jar</artifactId> <version>LATEST</version> <scope>system</scope> <systemPath>${glassfish.home}/lib/appserv-rt.jar</systemPath> </dependency> <dependency> <groupId>glassfish</groupId> <artifactId>javaee.jar</artifactId> <version>LATEST</version> <scope>system</scope> <systemPath>${glassfish.home}/lib/javaee.jar</systemPath> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.1</version> <scope>test</scope> </dependency> </dependencies> <build> <sourceDirectory>src/main/java</sourceDirectory> <finalName>my-ejb-project</finalName> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.5</source> <target>1.5</target> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-ejb-plugin</artifactId> <configuration> <ejbVersion>3.0</ejbVersion> </configuration> </plugin> </plugins> </build> </project>

As you can see I am referring to the libraries of Glassfish of my local installation. It appears that the libraries you get from the global Maven repositories only contain the interfaces and no implementation so these can not be used when you want (unit) test your beans outside the container.

Besides this ejb-project I have also created a ear-project that is used to create an ear file containing the EJB’s jar file (and optionally other deliverables like war-file etc). The pom file of this project looks like (the project doesn’t contain anything else):

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>net.pascalalma</groupId> <artifactId>my-ear-project</artifactId> <packaging>ear</packaging> <version>1.0-SNAPSHOT</version> <name>my-ear-project</name> <url>http://maven.apache.org</url> <dependencies> <dependency> <groupId>net.pascalalma</groupId> <artifactId>my-ejb-project</artifactId> <version>1.0-SNAPSHOT</version> <type>ejb</type> </dependency> </dependencies> <build> <plugins> <plugin> <artifactId>maven-ear-plugin</artifactId> <configuration> <displayName>My Service</displayName> <description>My EJB Component for Echo Service</description> <version>1.4</version> <modules> <ejbModule> <groupId>net.pascalalma</groupId> <artifactId>my-ejb-project</artifactId> </ejbModule> </modules> </configuration> </plugin> <plugin> <groupId>org.glassfish.maven.plugin</groupId> <artifactId>maven-glassfish-plugin</artifactId> <version>2.1</version>   <configuration> <glassfishDirectory>${glassfish.home}</glassfishDirectory> <user>admin</user> <passwordFile>${glassfish.home}/domains/domain1/config/domain-passwords</passwordFile> <autoCreate>false</autoCreate> <debug>true</debug> <echo>true</echo> <terse>false</terse> <domain> <name>domain1</name> <httpPort>8080</httpPort> <adminPort>4848</adminPort> <reuse>true</reuse> </domain> <components> <component> <name>${project.artifactId}</name> <artifact>${project.build.directory}/${project.build.finalName}.ear</artifact> </component> </components> </configuration> </plugin> </plugins> </build> </project>

With all this in place we are able to build the EJB3 project with the command:
mvn clean install
and to package and deploy the EAR project with:
mvn clean package glassfish:deploy
In the Admin Console of Glasfish you will see the deployed project if everything went well:


To make our EJB3 bean available as a webservice, we have to add some annotations to the source, so the code of the interface and the bean will become something like this:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

package net.pascalalma.services;   import javax.ejb.Remote; import javax.jws.WebService; import javax.jws.soap.SOAPBinding;   @Remote @WebService @SOAPBinding(style = javax.jws.soap.SOAPBinding.Style.DOCUMENT ,use = javax.jws.soap.SOAPBinding.Use.LITERAL ,parameterStyle = javax.jws.soap.SOAPBinding.ParameterStyle.WRAPPED) public interface EchoService {   public String sayHello(String subject); }

and the implementation class:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

package net.pascalalma.services.impl;   import javax.ejb.Stateless; import javax.jws.WebService; import net.pascalalma.services.EchoService;   @Stateless @WebService(endpointInterface = "net.pascalalma.services.EchoService",serviceName="EchoService") public class EchoServiceBean implements EchoService {   public String sayHello(String name) { return "Hi " + name + "!"; } }

That’s it! Now rebuild and redeploy the packages and it is done!
To test the webservice I ‘ll use the Admin Console of Glassfish again. You will see under the heading ‘Web Services’ that there is added a web service:


Now select that web service and you will get a screen where you can enter the Test page for this service:


After clicking the button we can enter a value as input parameter for our service:


And the Admin Console will show the result of our call by showing the soap messages (request+ response):


Of course, this test functionality is much more limited then we have in SoapUI but to quickly check if the service is running it will do just fine.

]]> http://www.redstream.nl/2009/02/11/create-a-ejb3-webservice-with-maven2-running-on-glassfish/feed/ 6