FAQ History

Search Feedback

Code Examples

The first part of this tutorial used code fragments to walk you through the fundamentals of using the JAXM API. In this section, you will use some of those code fragments to create applications. First, you will see the program Request.java. Then you will see how to create and run the following applications:

UddiPing.java -- A simple standalone example that sends a message to a UDDI test registry and receives a response
SOAPFaultTest.java -- A simple standalone example that shows how to specify SOAP faults
JAXM Simple -- A simple example of sending and receiving a message using the local provider
SAAJ Simple -- An application similar to the Simple example except that it is written using only the SAAJ API
JAXM Translator -- An application that uses a simple translation service to translate a given word into different languages
JAXM Tags -- An example that uses JavaServer Pages tags to generate and consume a SOAP message
JAXM Provider -- A simple example of a JAXM provider
JAXM Provider Administrator -- A simple web-based administrative tool for the JAXM provider

This list presents the sample applications according to what they do. You can also look at the sample applications as examples of the three possible types of JAXM client:

Those that do not use a messaging provider and also do not run in a container

These are called standalone applications. The samples UddiPing and SOAPFaultTest are examples of standalone clients.

Those that do not use a messaging provider and run in a container

The samples JAXM Simple, SAAJ Simple, JAXM Translator, and JAXM Tags are examples of this type.

Those that use a messaging provider and run in a container

There are no samples of this type at this release.

Setting the Classpath

Before you can compile and run the examples, you need to set the classpath for both compiling and executing the programs.

To set the compilation and execution classpaths:

Choose Options from the Tools menu.
Expand the Building node, then the Compiler Types node.
Choose External Compilation.
Select the Expert tab.
Click the Class Path property and open the property editor.
Click Add JAR/Zip.
In the file chooser, navigate to the directory <S1STUDIO_HOME>/jwsdp/common/lib and choose the file jaxm-api.jar.
Click OK.
Click Add JAR/Zip again and repeat steps 7-8. This time, choose the file commons-logging.jar.
Expand the Debugging and Executing node, then the Execution Types node.
Choose External Execution.
Select the Expert tab.
Click the Class Path property, then double-click the ellipsis in the value field.
In the property editor, click Add JAR/Zip.
In the file chooser, navigate to the directory <S1STUDIO_HOME>/jwsdp/common/lib and choose the jaxm-api.jar file.
Click OK.
Click Close in the Options window.

Changing Server Permissions

Two of the examples, JAXM Translator and JAXM Tags, require certain permissions to be granted in order to run successfully. To make these changes, perform the following steps:

Open the following file in an editor:

<S1AS7_HOME>/domains/domain1/server1/config/server.policy  

Find the following line:

permission java.util.PropertyPermission "*", "read"; 

Add write permission by changing the line as follows:

permission java.util.PropertyPermission "*", "read,write"; 

Append the following lines of text to the end of the file. The entire string between grant codebase and the opening curly brace ({) should be on one line:

// This permission applies to the privileged jaxm-tags webapp
grant codeBase "file:${com.sun.aas.installRoot}/domains/
domain1/server1/applications/j2ee-modules/-" {
permission java.util.logging.LoggingPermission "control", "";
}; 

Restart the server instance so the changes will take effect.

The Request.java Program

The class Request.java puts together the code fragments used in the section Client without a Messaging Provider and adds what is needed to make it a complete example of a client sending a request-response message. In addition to putting all the code together, it adds import statements, a main method, and a try/catch block with exception handling. The file Request.java, shown here in its entirety, is a standalone client application that uses the SAAJ API (the javax.xml.soap package). It does not need to use the javax.xml.messaging package because it does not use a messaging provider.

import javax.xml.soap.*;
import java.util.*;
import java.net.URL;
public class Request {
    public static void main(String[] args)  {
        try {
            SOAPConnectionFactory scFactory =
                SOAPConnectionFactory.newInstance();
            SOAPConnection con = scFactory.createConnection();

            MessageFactory factory =
                MessageFactory.newInstance();
            SOAPMessage message = factory.createMessage();

            SOAPPart soapPart = message.getSOAPPart();
            SOAPEnvelope envelope = soapPart.getEnvelope();
            SOAPHeader header = envelope.getHeader();
            SOAPBody body = envelope.getBody();
            header.detachNode();

            Name bodyName = envelope.createName(
                "GetLastTradePrice", "m",
                "http://wombats.ztrade.com");
            SOAPBodyElement gltp =
                body.addBodyElement(bodyName);

            Name name = envelope.createName("symbol");
            SOAPElement symbol = gltp.addChildElement(name);
            symbol.addTextNode("SUNW");

            URL endpoint = new URL
                ("http://wombat.ztrade.com/quotes";
            SOAPMessage response = 
                con.call(message, endpoint);

            con.close();

            SOAPPart sp = response.getSOAPPart();
            SOAPEnvelope se = sp.getEnvelope();
            SOAPBody sb = se.getBody();

            Iterator it = sb.getChildElements(bodyName);
            SOAPBodyElement bodyElement =
                (SOAPBodyElement)it.next();
            String lastPrice = bodyElement.getValue();

            System.out.print("The last price for SUNW is ");
            System.out.println(lastPrice);

        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }
} 

In order for Request.java to be runnable, the second argument supplied to the method call has to be a valid existing URI, which is not true in this case. See the JAXM code in the case study for similar code that you can run (JAXM Client). Also, the application in the next section is one that you can run.

The UddiPing Example

The sample program UddiPing.java is another example of a standalone application. A Universal Description, Discovery and Integration (UDDI) service is a business registry and repository from which you can get information about businesses that have registered themselves with the registry service. For this example, the UddiPing application accesses a UDDI test registry to demonstrate a request being sent and a response being received. The application prints out the complete message that is returned, that is, the complete XML document as it looks when it comes over the wire. In addition to printing out the entire XML document, it also prints out just the text content of the response, making it much easier to see the information you want.

The files for the UddiPing example, in the directory <INSTALL>/j2eetutorial/examples/jaxm/uddiping, are uddi.properties and UddiPing.java.

You will be modifying the file uddi.properties, which contains the URL of the destination (the UDDI test registry) and the proxy host and proxy port of the sender. If you are not sure what the values for these are, you need to consult your system administrator or other person with that information.

Examining UddiPing

We will go through the file UddiPing.java a few lines at a time.

The first four lines of code import the packages used in the application.

import javax.xml.soap.*;
import javax.xml.messaging.*;
import java.util.*;
import java.io.*; 

The next few lines begin the definition of the class UddiPing, which starts with the definition of its main method. The first thing it does is check to see if two arguments were supplied. If not, it prints a usage message and exits.

public class UddiPing {
    public static void main(String[] args) {
        try {
            if (args.length != 2) {
                System.err.println("Usage: MyUddiPing " +
                    "properties-file business-name");
                System.exit(1);
            } 

The following lines create a java.util.Properties file that contains the system properties and the properties from the file uddi.properties that is in the uddiping directory.

            Properties myprops = new Properties();
            myprops.load(new FileInputStream(args[0]));

            Properties sysprops = System.getProperties();

            Enumeration it = myprops.propertyNames();
            while (it.hasMoreElements()) {
                String s = (String) it.nextElement(); 
                sysprops.setProperty(s, 
                    myprops.getProperty(s));
            } 

The next four lines create a SOAPMessage object. First, the code gets an instance of SOAPConnectionFactory and uses it to create a connection. Then it gets an instance of MessageFactory and uses it to create a message.

            SOAPConnectionFactory scf =
                SOAPConnectionFactory.newInstance();
            SOAPConnection connection = 
                scf.createConnection();
            MessageFactory msgFactory =
                MessageFactory.newInstance();
            SOAPMessage msg = msgFactory.createMessage();  

The new SOAPMessage object msg automatically contains a SOAPPart object that contains a SOAPEnvelope object. The SOAPEnvelope object contains a SOAPBody object, which is the element you want to access in order to add content to it. The next lines of code get the SOAPPart object, the SOAPEnvelope object, and the SOAPBody object.

            SOAPEnvelope envelope =
                msg.getSOAPPart().getEnvelope();
            SOAPBody body = envelope.getBody(); 

The following lines of code add an element with a fully-qualified name and then add two attributes to the new element. The first attribute has the name "generic" and the value "1.0". The second attribute has the name "maxRows" and the value "100". Then the code adds a child element with the name name and adds some text to it with the method addTextNode. The text added is the business name you will supply when you run the application.

            SOAPBodyElement findBusiness =
                body.addBodyElement(
                    envelope.createName("find_business",
                    "", "urn:uddi-org:api"));
            findBusiness.addAttribute(
                envelope.createName("generic", "1.0");
            findBusiness.addAttribute(
                envelope.createName("maxRows", "100");
            SOAPElement businessName =
                findBusiness.addChildElement(
                    envelope.createName("name"));
            businessName.addTextNode(args[1]);  

The next line of code creates the Java Object that represents the destination for this message. It gets the value of the property named "URL" from the system property file.

            Object endpoint = new URLEndpoint(
                System.getProperties().getProperty("URL")); 

The following line of code saves the changes that have been made to the message. This method will be called automatically when the message is sent, but it does not hurt to call it explicitly.

            msg.saveChanges();  

Next the message msg is sent to the destination that endpoint represents, which is the test UDDI registry. The method call will block until it gets a SOAPMessage object back, at which point it returns the reply.

            SOAPMessage reply = connection.call(msg, endpoint); 

In the next two lines, the first prints out a line giving the URL of the sender (the test registry), and the second prints out the returned message as an XML document.

           System.out.println("Received reply from: " +
                endpoint);
            reply.writeTo(System.out); 

The remaining code makes the reply more user-friendly. It gets the content from certain elements rather than printing out the whole XML document as it was sent over the wire. Because the content is in the SOAPBody object, the first thing you need to do is access it, as shown in the following line of code. You can access each element in separate method calls, as was done in Request.java, or you can access the SOAPBody object using this shorthand version.

            SOAPBody replyBody =
                reply.getSOAPPart().getEnvelope().getBody(); 

Next you might print out two blank lines to separate your results from the raw XML message and a third line that describes the text that follows.

            System.out.println("");
            System.out.println("");
            System.out.print(
                "Content extracted from the reply message: "); 

Now you can begin the process of getting all of the child elements from an element, getting the child elements from each of those, and so on, until you arrive at a text element that you can print out. Unfortunately, when you extract information from a registry, the number of subelements sometimes varies, making it difficult to know how many levels down the code needs to go. And in a test registry, there may be multiple entries for the same company name.

The code drills down through the subelements within the SOAP body and retrieves the name and description of the business. The method you use to retrieve child elements is the SOAPElement method getChildElements. When you give this method no arguments, it retrieves all of the child elements of the element on which it is called. If you know the Name object used to name an element, you can supply that to getChildElements and retrieve only the children with that name. In this example, however, you need to retrieve all elements and keep drilling down until you get to the elements that contain text content.

Here is the basic pattern that is repeated for drilling down:

            Iterator iter1 = replyBody.getChildElements();
            while (iter1.hasNext()) { 
                SOAPBodyElement bodyElement =
                    (SOAPBodyElement)iter1.next();
                Iterator iter2 = 
                    bodyElement.getChildElements();
                    while (iter2.hasNext()) {
                        . . . 

The method getChildElements returns the elements in the form of a java.util.Iterator object. You access the child elements by calling the method next on the Iterator object. The method Iterator.hasNext can be used in a while loop because it returns true as long as the next call to the method next will return a child element. The loop ends when there are no more child elements to retrieve.

An immediate child of a SOAPBody object is a SOAPBodyElement object, which is why calling iter1.next returns a SOAPBodyElement object. Children of SOAPBodyElement objects and all child elements from there down are SOAPElement objects. For example, the call iter2.next returns the SOAPElement object child2. Note that the method Iterator.next returns an Object, which has to be narrowed (cast) to the specific kind of object you are retrieving. Thus, the result of calling iter1.next is cast to a SOAPBodyElement object, whereas the results of calling iter2.next, iter3.next, and so on, are all cast to a SOAPElement object.

Here is the code that prints out the business name and description and then ends the program:

            Iterator iter1 = replyBody.getChildElements();
            while (iter1.hasNext()) { 
                SOAPBodyElement bodyElement =
                    (SOAPBodyElement)iter1.next();
                Iterator iter2 =
                    bodyElement.getChildElements();
                while (iter2.hasNext()) {
                    SOAPElement child2 =
                        (SOAPElement)iter2.next();
                    Iterator iter3 =
                        child2.getChildElements();
                    String content = child2.getValue();
                    System.out.println(content);
                    while (iter3.hasNext()) {
                        SOAPElement child3 =
                            (SOAPElement)iter3.next();
                        Iterator iter4 =
                            child3.getChildElements();
                        content = child3.getValue();
                        System.out.println(content);
                        while (iter4.hasNext()) {
                            SOAPElement child4 =
                                (SOAPElement)iter4.next();
                            content = child4.getValue();
                            System.out.println(content);
                        }
                    }
                }
            }
            connection.close();
        } catch (Exception ex) { 
            ex.printStackTrace(); 
        }
    }
} 

Editing the uddi.properties File

In order to run this example, you need to edit the uddi.properties file to specify a UDDI registry and the appropriate proxy host and port. Perform the following steps:

Mount the following filesystem by choosing Mount Filesystem from the File menu:

<INSTALL>/j2eetutorial/examples/jaxm/uddiping

INSTALL is the directory where you installed the Tutorial.

Right-click the uddi.properties file and choose the Edit menu item. The unedited file looks like this (the URLs are all on one line):

URL:http://uddi.ibm.com/testregistry/inquiryapi
#URL:http://localhost:8089/registry-server/
RegistryServerServlet
http.proxyHost:
http.proxyPort:8080

The default URL is the IBM test registry. If you wish, change the value of URL to another registry location. To use the Sun ONE Studio UDDI Server Registry, comment out the IBM registry and remove the comment character from the second line.

After http.proxyHost, insert the hostname and domain of your proxy server, if you access the Internet from behind a firewall. The format is usually myhost.mydomain.
If necessary, change the value http.proxyPort to one appropriate for your location. 8080 is the usual port number.
Save and close the file.

If you will be using the Sun ONE Studio UDDI Server Registry, start the registry if you have not already done so:

Select the Runtime tab of the Explorer.
Expand the UDDI Server Registry node.
Right-click the Internal UDDI Registry node and choose the Start Server menu item.

Compiling and Running UddiPing

To run the program, you need to specify two command-line arguments: the uddi.properties file and the name of the business for which you want to get a description.

Make sure you have followed the instructions in Setting the Classpath.

To compile and run UddiPing, perform the following steps:

Click the UddiPing file in the Filesystems tab.
In the property window for the file, choose the Execution tab.
Click Arguments, then double-click the ellipsis to bring up the property editor.
Enter the pathname of uddi.properties, a space, and Oracle. (If you are using the Sun ONE Studio UDDI Server Registry, enter a string from a business name that you know is in the registry.) On a Windows system, for example, you need to specify something like this (all on one line):

D:\j2eetutorial\examples\jaxm\uddiping\uddi.properties Oracle 

Click OK.

If you are on a Windows system, notice that the pathname appears in the field with double backslashes.

Right-click the UddiPing file in the Filesystems tab and choose the Execute menu item. This command compiles the source file, then executes the class file.

The program output window displays the response message as follows (all on one line):

<?xml version="1.0" encoding="UTF-8" ?><Envelope 
xmlns="http://schemas.xmlsoap.org/soap/envelope/"><Body>
<businessList generic="1.0" xmlns="urn:uddi-org:api" 
operator="www.ibm.com/services/uddi" 
truncated="false"><businessInfos><businessInfo 
businessKey="26B46510-81E8-11D5-A4A5-0004AC49CC1E">
<name>Oracle</name><description xml:lang="en">oracle powers 
the internet</description><serviceInfos></serviceInfos>
</businessInfo><businessInfo 
businessKey="2ACAA2D0-82A7-11D5-A4A5-0004AC49CC1E">
<name>Oracle Corporation</name><description 
xml:lang="en">Oracle Corporation provides the software and 
services for 
e-business.</description><serviceInfos><serviceInfo 
serviceKey="4EDB6FC0-82AB-11D5-A4A5-0004AC49CC1E" 
businessKey="2ACAA2D0-82A7-11D5-A4A5-0004AC49CC1E">
<name>E-Business Network</name></serviceInfo><serviceInfo 
serviceKey="3AD5A9B0-82AA-11D5-A4A5-0004AC49CC1E" 
businessKey="2ACAA2D0-82A7-11D5-A4A5-0004AC49CC1E">
<name>Oracle Store</name></serviceInfo><serviceInfo 
serviceKey="0735C300-82AB-11D5-A4A5-0004AC49CC1E" 
businessKey="2ACAA2D0-82A7-11D5-A4A5-0004AC49CC1E">
<name>Oracle Technology Network</name></serviceInfo>
<serviceInfo serviceKey="82757F80-82A9-11D5-A4A5-0004AC49CC1E" 
businessKey="2ACAA2D0-82A7-11D5-A4A5-0004AC49CC1E">
<name>Oracle.com</name></serviceInfo></serviceInfos>
</businessInfo></businessInfos></businessList>
</Body></Envelope> 

The following output appears after the full XML message.

Content extracted from the reply message: 

Oracle
oracle powers the internet

Oracle Corporation
Oracle Corporation provides the software and services for e-
business. 

There may be some occurrences of "null" in the output.

Running the program with Microsoft as the business-name property instead of Oracle produces the following output:

Received reply from: 
http://uddi.ibm.com/testregistry/inquiryapi
<?xml version="1.0" encoding="UTF-8" ?><Envelope 
xmlns="http://schemas.xmlsoap.org/soap/envelope/"><Body>
<businessList generic="1.0" xmlns="urn:uddi-org:api" 
operator="www.ibm.com/services/uddi" 
truncated="false"><businessInfos><businessInfo 
businessKey="D7475060-BF58-11D5-A432-0004AC49CC1E">
<name>Microsoft Corporation</name><description 
xml:lang="en">Computer Software and Hardware 
Manufacturer</description><serviceInfos></serviceInfos>
</businessInfo></businessInfos></businessList>
</Body></Envelope> 
Content extracted from the reply message:  
Microsoft Corporation
Computer Software and Hardware Manufacturer 

The SOAPFaultTest Example

The code SOAPFaultTest.java, based on the code fragments in a preceding section (SOAP Faults) creates a message with a SOAPFault object. It then retrieves the contents of the SOAPFault object and prints them out. You will find the code for SOAPFaultTest in the following directory:

<INSTALL>/j2eetutorial/examples/jaxm/fault 

Here is the file SOAPFaultTest.java.

import javax.xml.soap.*;
import java.util.*;

public class SOAPFaultTest {

    public static void main(String[] args) { 
        try {
            MessageFactory msgFactory =
                MessageFactory.newInstance();
            SOAPMessage msg = msgFactory.createMessage();
            SOAPEnvelope envelope =
                msg.getSOAPPart().getEnvelope();
            SOAPBody body = envelope.getBody(); 
            SOAPFault fault = body.addFault();

            fault.setFaultCode("Client"); 
            fault.setFaultString(
                "Message does not have necessary info"); 
            fault.setFaultActor("http://gizmos.com/order");

            Detail detail = fault.addDetail();

            Name entryName = envelope.createName("order", 
                "PO", "http://gizmos.com/orders/"); 
            DetailEntry entry = 
                detail.addDetailEntry(entryName); 
            entry.addTextNode(
                "quantity element does not have a value");

            Name entryName2 = 
                envelope.createName("confirmation", "PO",
                    "http://gizmos.com/confirm");
            DetailEntry entry2 =
                detail.addDetailEntry(entryName2); 
            entry2.addTextNode("Incomplete address: " + 
                "no zip code");

            msg.saveChanges();

            // Now retrieve the SOAPFault object and
            // its contents, after checking to see that 
            // there is one
            System.out.println(
                "Here is what the XML message looks like:");
            msg.writeTo(System.out);
            System.out.println();
            System.out.println();

            if ( body.hasFault() ) { 
                fault = body.getFault();
                String code = fault.getFaultCode();
                String string = fault.getFaultString(); 
                String actor = fault.getFaultActor();

                System.out.println("SOAP fault contains: ");
                System.out.println("  fault code = " + code);
                System.out.println("  fault string = " + 
                    string);
                if ( actor != null) { 
                    System.out.println("  fault actor = " +
                        actor);
                }

                detail = fault.getDetail();
                if ( detail != null) {
                    Iterator it = detail.getDetailEntries();
                    while ( it.hasNext() ) {
                        entry = (DetailEntry)it.next();
                        String value = entry.getValue();
                        System.out.println(
                            "  Detail entry = " + value);
                    }
                }
            }
        } catch (Exception ex) {
            ex.printStackTrace();
        } 
    } 
} 

Compiling and Running SOAPFaultTest.java

To compile and run SoapFaultTest, first make sure you followed the instructions in Setting the Classpath. Then perform the following steps:

Mount the following filesystem:

<INSTALL>/j2eetutorial/examples/jaxm/fault 

Right-click the SoapFaultTest file in the Filesystems tab and choose the Execute menu item.

The program output window displays the response message as follows (the SOAP message is all on one line):

Here is what the XML message looks like:
<?xml version="1.0" encoding="UTF-8"?>
<soap-env:Envelope xmlns:soap-
env="http://schemas.xmlsoap.org/soap/envelope/">
<soap-env:Header/><soap-env:Body>
<soap-env:Fault><faultcode>Client</faultcode>
<faultstring>Message does not have necessary info</faultstring>
<faultactor>http://gizmos.com/order</faultactor>
<detail><PO:order 
xmlns:PO="http://gizmos.com/orders/">quantity element does not 
have a value</PO:order><PO:confirmation 
xmlns:PO="http://gizmos.com/confirm">Incomplete address: no 
zip code</PO:confirmation></detail></soap-env:Fault>
</soap-env:Body></soap-env:Envelope>

SOAP fault contains: 
  fault code = Client
  fault string = Message does not have necessary info
  fault actor = http://gizmos.com/order
  Detail entry = quantity element does not have a value
  Detail entry = Incomplete address: no zip code 

Starting the Application Server

The UddiPing and SOAPFaultTest examples are standalone programs; that is, they do not run in a container. The remaining examples run in a container. If you have not already done so, start the Sun ONE Application Server now and specify it as the default server for Web Tier Applications.

The JAXM Simple Example

The JAXM Simple example shows how to send and receive a message using the local provider. Note that a local provider should not be confused with a messaging provider. The local provider is simply a mechanism for returning the reply to a message that was sent using the method SOAPConnection.call. Note that a message sent by this method will always be a request-response message. Running this example generates the files sent.msg and reply.msg, which you will find in the server instance configuration directory.

To deploy and run the JAXM Simple example, perform the following steps:

Mount the following filesystem:

<INSTALL>/j2eetutorial/examples/jaxm/jaxm-simple 

In the Mount Web Module dialog that appears, click OK to display the alternate view of the web module.
An information dialog may appear stating that ReceivingServlet.java cannot be converted to a servlet. Click OK.
Specify the following context root for the web module in the Context Root field of the WEB-INF property window:

/jaxm-simple 

Right-click the WEB-INF node and choose Deploy from the menu.
Right-click the WEB-INF node and choose Execute from the menu. If this doesn't work, open a web browser and enter the following URL:

localhost:80/jaxm-simple/ 

If the page cannot be found, make sure the server is running.

A web page appears with the following text:

This is a simple example of a round-trip JAXM message exchange.

Click here to send the message.

If you click the link, another page appears with the following text:

Sent message (check "sent.msg") and received reply (check "reply.msg").

You can find the files sent.msg and reply.msg in the following directory:

<S1AS7_HOME>/domains/domain1/server1/config 

The SAAJ Simple Example

The SAAJ Simple application is similar to the Simple example except that it is written using only the SAAJ API. In SAAJ Simple, the call method takes a Java Object rather than a URLEndpoint object to designate the recipient, and thus uses only the javax.xml.soap package. Running this example generates the files sent.msg and reply.msg, which you will find in the server instance configuration directory.

To deploy and run the SAAJ Simple example, perform the following steps:

Mount the following filesystem:

<INSTALL>/j2eetutorial/examples/jaxm/saaj-simple 

An information dialog may appear stating that ReceivingServlet.java cannot be converted to a servlet. Click OK.
Specify the following context root for the web module:

/saaj-simple 

Right-click the WEB-INF node and choose Deploy from the menu.
Right-click the WEB-INF node and choose Execute from the menu. If this doesn't work, open a web browser and enter the following URL:

localhost:80/saaj-simple/index.html 

A web page appears with the following text:

This is a simple example of a roundtrip SAAJ message exchange.

Click here to send the message.

If you click the link, another page appears with the following text:

Sent message (check "sent.msg") and received reply (check "reply.msg").

You can find the files sent.msg and reply.msg in the following directory:

<S1AS7_HOME>/domains/domain1/server1/config 

The JAXM Translator Example

The JAXM Translator example uses a simple translation service to translate a given word into different languages. If you have given the correct proxy host and proxy port, the word you supply will be translated into French, German, and Italian. Running this example generates the files request.msg and reply.msg in the server configuration directory.

Make sure you have followed the instructions in Changing Server Permissions before you begin.

To deploy and run the JAXM Translator example, perform the following steps:

Mount the following filesystem:

<INSTALL>/j2eetutorial/examples/jaxm/jaxm-translator 

An information dialog may appear stating that ReceivingServlet.java cannot be converted to a servlet. Click OK.
Specify the following context root for the web module:

/jaxm-translator 

Right-click the WEB-INF node and choose Deploy from the menu.
Right-click the WEB-INF node and choose Execute from the menu. If this doesn't work, open a web browser and enter the following URL:

localhost:80/jaxm-translator/index.html

A web page with the header "Translator Sample Application" appears.

Enter the proxy host and port for your system in the text fields provided.
Enter the text to be translated in the field provided.
Choose the In SOAPBody or As Attachments radio button and click Translate.
A web page appears with the word translated into the three languages.
Use the browser's back button to run the example again.

Check reply.msg after getting the reply in the SOAP body and again after getting the reply as an attachment to see the difference in what is sent as a reply.

You can find the files request.msg and reply.msg in the following directory:

<S1AS7_HOME>/domains/domain1/server1/config 

The JAXM Tags Example

The JAXM Tags example uses JavaServer Pages tags to generate and consume a SOAP message.

Make sure you have followed the instructions in Changing Server Permissions before you begin.

To deploy and run the JAXM Tags example, perform the following steps:

Mount the following filesystem:

<INSTALL>/j2eetutorial/examples/jaxm/jaxm-tags 

Specify the following context root for the web module:

/jaxm-tags 

Right-click the WEB-INF node and choose Deploy from the menu.
Right-click the WEB-INF node and choose Execute from the menu. If this doesn't work, open a web browser and enter the following URL:

localhost:80/jaxm-tags/index.html

If the page cannot be found, make sure the server is running.

A web page with the header "JSP Examples" appears. Click on each of the three links. For each, a page appears with the requests and responses.

The JAXM Provider

The JAXM Provider is a simple example of a JAXM provider.

The source files for the JAXM Provider, like those for the JAXM Provider Administrator, are in the directory <S1STUDIO_HOME>/jwsdp/services/.

Before you deploy the provider, use the application server administration tool to add <S1STUDIO_HOME>/jwsdp/common/lib/jaxm-runtime.jar to the application server classpath suffix and restart the application server. To do so:

Open the URL http://localhost:4848 in a browser
Select the server1 node.
Select the JVM Settings tab.
Click the Path Settings link.
Add <S1STUDIO_HOME>/jwsdp/common/lib/jaxm-runtime.jar to the Classpath Suffix text area.
Click Save.
Click the General tab.
Apply the changes, then stop and restart the server.

To deploy and run the JAXM Provider, perform the following steps:

Mount the following filesystem:

<S1STUDIO_HOME>/jwsdp/services/jaxm-provider

If you click on the file WEB-INF/provider.xml, you may notice that it is marked as having invalid XML. If you open this file in a text editor, right-click, and choose Validate XML from the menu, you will see an error message about a missing DTD file. Ignore this error message.

Specify the following context root for the web module:

/jaxm-provider 

Right-click the WEB-INF node and choose Deploy from the menu.

The JAXM Provider Administrator

The JAXM Provider Administrator is a simple web-based administrative tool for the JAXM provider.

The source files for the JAXM Provider Administrator are not in the tutorial examples directory. Instead, they are in <S1STUDIO_HOME>/jwsdp/services/.

To deploy and run the JAXM Provider Administrator, perform the following steps:

Mount the following filesystem:

<S1STUDIO_HOME>/jwsdp/services/jaxm-provideradmin

If you click on the file WEB-INF/provider.xml, you may notice that it is marked as having invalid XML. If you open this file in a text editor, right-click, and choose Validate XML from the menu, you will see an error message about a missing DTD file. Ignore this error message.

In order to run the JAXM Provider Administrator example using the Sun ONE Application Server, you need to change the security properties for the web.xml file as follows:
Expand the WEB-INF node if you have not already done so.
Click the web.xml file.
In the property window for the file, click the Security tab. You will see that the Security Constraints field contains the text "1 Security Constraint". Click this field, then click the ellipsis.
In the Property Editor, select the security constraint and click Remove.
Click OK.
Specify the following context root for the web module:

/jaxm-provideradmin 

Right-click the WEB-INF node and choose Deploy from the menu.
Right-click the WEB-INF node and choose Execute from the menu. If this doesn't work, open a web browser and enter the following URL:

localhost:80/jaxm-provideradmin/ 

The JAXM Provider Administration Tool appears. Expand the nodes in the left window to see what you can do in the tool. See the next section for more information.

Using the JAXM Provider Administration Tool

The Provider Administration tool is a convenient means of configuring a messaging provider. A messaging provider, a third party service, handles the behind-the-scenes details of the routing and transmission of JAXM messages. For more information about messaging providers, see Messaging Providers.

The Provider Administration tool is normally used by System Administrators, but others may use it as well. Exploring this tool gives you more of an idea of what a messaging provider needs to know. For example, a messaging provider maintains a list of the endpoints to which you can send messages. You can add a new endpoint to this list using the Provider Administration tool. If a message is not delivered successfully on the first try, a messaging provider will continue attempting to deliver it. You can specify the number of times the messaging provider should attempt delivery by supplying a retry limit. Setting this limit is another thing you can do with the Provider Administration tool.

The following lists the ways you can use the tool to set a messaging provider's properties.

To add, modify, or delete an endpoint
To change the number of retries (the number of times the provider will try to send a message)
To change the retry interval (the amount of time the provider will wait before trying to send a message again)
To change the directory where the provider logs messages
To set the number of messages per log file

FAQ History

Search Feedback

All of the material in The J2EE Tutorial for the Sun ONE Platform is copyright-protected and may not be published in other works without express written permission from Sun Microsystems.