Create a Web Service that receives SOAP attachments with Rational Application Developer

Learn how to use IBM® Rational® Application Developer to create a Web service that can receive a SOAP message containing attachments, in addition to the normal content contained in the body of the message. We'll use a simple example, in which the service receives a text message in the body, and a text message, jpeg file, and zip file as attachments.

Share:

Francis DiNardo (fdinardo@us.ibm.com), Consulting IT Specialist, IBM

Francis Dinardo's pictureFrancis DiNardo is a Consulting IT Specialist with IBM Software Services for WebSphere and is based out of IBM Research Triangle Park near Raleigh, North Carolina. He specializes in Software Engineering and Application Development using IBM WebSphere middleware products. You can reach Francis at fdinardo@us.ibm.com.


developerWorks Contributing author
        level

Irina Singh (irinas@us.ibm.com), Senior Consultant, IBM

Irina Singh photoIrina Singh is a Senior Consultant with IBM Software Services for WebSphere. Irina has over 10 years of consulting experience with Fortune 500 companies and has exposure to a broad range of technologies that include mainframes, WebSphere, Portal, J2EE, Web Services and SOA. Her recent interests include Web services security. Irina has a Bachelor's Degree in Electrical Engineering from Indian Institute of Technology (IIT), Kanpur.



28 June 2006

Introduction

In this article, you'll use the IBM Rational Application Developer (hereafter called Application Developer) interactive development environment (IDE) to create both a service and a client for the service that receives a text message in the body and a text message, a jpeg file and a zip file as attachments. The client is provided here to demonstrate the sending of a SOAP message with attachments to a Web service and to provide an example of a good pattern for connecting to and sending a message to a Web service.

Most of the project artifacts created in this exercise are generated automatically by the Application Developer tooling, with the exception of the WSDL file from which the two projects are generated. Although you probably want to use Application Developer to enhance productivity, you can create the project artifacts manually (if you have a lot of time on your hands!). By examining the generated artifacts, you can understand the techniques required to send a SOAP message with attachments.

In this exercise, we'll start with a WSDL file that describes a service that accepts a message with a text body, as well as text, .zip, .jpg file attachments. We'll use that WSDL file to create both the service and the client projects, which contain all the required code, but we'll manually enhance the code to demonstrate some additional features. In particular, we'll add some code to the generated artifacts that will write trace messages to the Application Developer console so we can understand the execution of the system. In addition, we'll add a JAX-RPC hander to the service application so we can illustrate the use of some simple SOAP Attachments API for Java™ (SAAJ) code that confirms that an attachment exists. The handler code is not required, but it introduces you to techniques that you can use to provide additional message processing when an application has requirements that go beyond the simple sending of a message.


Prepare the environment

This section describes the steps to prepare your environment.

Prepare the source files

The AttachmentsFiles.zip file available in the Download section contains six files that you'll use during this exercise:

  • AttachmentIBM.wsdl - this is the wsdl file from which the 2 projects will be generated.
  • AttachmentIBMHandler.java - this is an optional file containing SAAJ code that can be used to confirm that an attachment is included with the message.
  • AttachmentIBMTest.jsp - this is another optional file that contains several lines of code that invokes the test client we create.
  • AttachmentIBMBindingImpl.java - This is the class that implements the AttachmentIBM Interface and contains the code that provides that function of the operation. This is generated by one of the wizards during this exercise, but the generated version does not contain all the code you'll need, so this version has my own custom code which can be copied into the generated version.
  • fed.zip - a sample zip file to use as an attachment.
  • fed.jpg - a sample jpeg file to use as an attachment.

Unzip these files to a folder from which you can import them into Application Developer as needed during the development of this project; for example, C:\temp1.

Note: if you put the fed.jpg file and fed.zip file in a folder other than c:\temp1, you'll have to change the reference to those files in the AttachmentIBMTest.jsp.

Start Application Developer

Start Application Developer, preferably with a fresh workspace. Once open, enable Web services tooling by doing the following:

  1. Select Window => Preferences => Workspace => Capabilities.
  2. Check Web Services Developer and Advanced J2EE.

Start the server

On the Servers tab, right-click WebSphere Application Server v6 and select Start.


Create the service from a WSDL file

This section describes the steps for creating the service.

Create an empty Web application project for the Web service

  1. Select File => New => Dynamic Web Project to open the New Project wizard.
  2. On the New Dynamic Web Project dialog, type AttachmentService in the Name field, accept the defaults for the rest of the fields, and click Finish, as shown in Figure 1:
    Figure 1. Create an empty Web application project for the Web service
    Create an empty Web Application Project for the Web Service

A new Web project is created with the structures seen in Figure 2:

Figure 2. New Web project
New Web project

Before continuing with the development of the service, deploy the new project to the WebSphere test server by doing the following:

  1. On the Servers tab, right-click the WebSphere server, then select Add and Remove Projects.
  2. Select AttachmentServiceEAR and click Add, then click Finish, as showin in Figure 3:
    Figure 3. Project ready for deployment
    Project ready for deployment

Generate Web service components in the new project

Now you need to add the new project AttachmentIBM.wsdl to the project so that it can be used to generate the Web services components of the project. To do this, do the following:

  1. Expand the AttachmentsService project, right-click WebContent, and select Import => File System => Next.
  2. In the Import dialog, browse to the folder where you unzipped the sample files. On the left of the dialog, click the name of the folder you selected (but don't click the check box). The contents of the file display on the right. Check AttachmentIBM.wsdl and click Finish, as shown in Figure 4:
    Figure 4. Project ready for deployment
    Project ready for deployment

AttachmentIBM.wsdl contains all the information required to generate a Web service, as well as a client that uses the service. Let's examine the contents of this file. Double-click AttachmentIBM.wsd to open it in the Application Developer text XML editor, and click the Source tab to view the code. Two sections are particularly significant to this exercise.

Listing 1 gives a message definition that describes the content of the message that is sent in the sendAttachments operation defined in Listing 2. This message is interesting because it's used by JAX-RPC to determine the Java data types that constitute the signature of the method that implements the sendAttachments operation.

Listing 1. The message definition
<message name="attachmentMsg">
  <part name="textBody" type ="xsd:string"/>
  <part name="textAttachment" type="xsd:hexBinary"/>
  <part name="imageAttachment" type="xsd:hexBinary"/>
  <part name="zipAttachment" type="xsd:hexBinary"/>
</message>

Ordinarily, this definition would result in a method signature that would have the first parameter declared as a Java String and each of the other parameters declared as a Java byte array. But, there's information in the bindings section of the wsdl that will change that, as seen in Listing 2.

Listing 2. The wsdl bindings section
  <binding name="AttachmentIBMBinding" type="tns:AttachmentIBM">
    <soap:binding style="document" 
        transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="sendAttachments">
      <soap:operation soapAction=""/>
      <input>
       <mime:multipartRelated>
       
          <mime:part>
            <soap:body use="literal"/>
          </mime:part>
          
          <mime:part>
            <mime:content part="textAttachment" type="text/plain"/>
          </mime:part>
          
          <mime:part>
            <mime:content part="imageAttachment" type="image/jpeg"/>
          </mime:part>
          
          <mime:part>
            <mime:content part="zipAttachment" type="application/zip"/>
          </mime:part>
		          
        </mime:multipartRelated>
      </input>
      <output>
        <soap:body use="literal"/>
      </output>
    </operation>
  </binding>

The bindings section contains MIME declarations that characterize the contents of the message.

The first mime:part refers to the body of the SOAP message. It's treated as a typical literal encoded style element.

The second mime:part section defines the textAttachment part of the message as having a mime type of text/plain. Because of this, JAX-RPC causes the second parameter to be generated as a Java String rather than a Java byte array. At runtime, the SOAP engine retrieves this AttachmentPart from the SOAPMessage and passes it to the operation as a Java String.

The third mime:part section defines the imageAttachment part of the message as having a mime type of image/jpeg. Because of this, JAX-RPC causes the third parameter to be generated as a java.awt.Image rather than a Java byte array. At runtime, the SOAP engine retrieves this AttachmentPart from the SOAPMessage and passes it to the operation as a Java Image.

The fourth mime:part section defines the zipAttachment part of the message as having a mime type of application/zip. Because of this, JAX-RPC causes the fourth parameter to be generated as a javax.activation.DataHandler rather than a Java byte array. At runtime, the SOAP engine retrieves this AttachmentPart from the SOAPMessage and passes it to the operation as a Java DataHandler. The mime type of this attachment cannot be mapped directly by JAX-RPC to a Java type. If a mime type is not one of the few types that JAX-RPC knows how to handle, it maps the attachment to a javax.activation.Datahandler class, which must be handled explicitly by the operation. See the JAX-RPC documentation for the mime type to Java type mappings.

Now that you understand the meaning of the wsdl file parts and you know what to expect from the mapping components, let's use the wsdl to create the Web services artifacts we need in our project:

  1. Close the editor.
  2. Right-click AttachmentIBM.wsdl, and select Web Services => Generate Java bean skeleton.
  3. The Web Service wizard starts. On the Web Services dialog, select Overwrite Files without warning and click Next, as ishown in Figure 5:
    Figure 5. Web Services dialog
    Web Services dialog
  4. In the Object Selection dialog, accept the defaults and click Next, as shown in Figure 6:
    Figure 6. Object Selection dialog
    Object Selection dialog
  5. In the Service Deployment Configuration dialog, accept the defaults and click Next, as shown in Figure 7:
    Figure 7. Service Deployment Configuration dialog
    Service Deployment Configuration dialog
  6. In the Web Service Skeleton Java Bean Configuration dialog, accept the defaults and click Finish, as shown in Figure 8:
    Figure 8. Web Service Skeleton Java Bean Configuration dialog
    Web Service Skeleton Java Bean Configuration dialogl

After the wizard finishes processing, you'll notice that several new files have been created in the project. Application Developer opens the new AttachmentIBMBindingImpl.java class in the Java editor. Before we look at the AttachmentIBMBindingImpl.java file, let's see what files have been added to the project. Figure 9 shows the Project Explorer:

Figure 9. Project Explorer
Project Explorer

Drill down to the AttachmentService => JavaResources => JavaSource folder and you'll see that a new package named ibm.attachment was created. Expand this folder and you'll see two new classes:

  • AttachmentIBM.java - This is a Java interface that's often referred to as the server skeleton. It declares the methods available in this Web service and is used by the server to demarshal the contents of the incoming SOAP message.
  • AttachmentIBMBindingImpl.java - This is the class that implements the AttachmentIBM interface, and contains the code that provides that function of the operation. The generated method is empty because it's up to the developers to provide code that satisfies the requirements of the operation. In a moment, we'll insert some code here that prints out some messages to the WebSphere console so we can monitor the execution of the test of this service.

Expand the WebContent => WEB-INF folder and you see two other new files:

  • webservices.xml - This file contains the definition of the service. Examine this file to see the reference to the AttachmentIBM.java as the Service Endpoint Interface and a reference to the AttachmentIBMBindingImpl.java class as the Service Implementation Bean.
  • AttachmentIBM_mapping.xml - This file describes the mappings from the incoming XML stream to the Java types declared in the method signature of the service operation. The content of this file is rather cryptic, but the rules for constructing these mappings are described in the JAX-RPC specification.

In addition, a change has been made to the web.xml file that inserts a servlet declaration for the AttachmentIBMBindingImpl.java class so that it can be invoked at runtime by the SOAP engine, as illustrated in Listing 3:

Listing 3. Servlet declaration for the AttachmentIBMBindingImpl.java class
<servlet>
	<servlet-name>ibm_attachment_AttachmentIBMBindingImpl</servlet-name>
	<servlet-class>ibm.attachment.AttachmentIBMBindingImpl</servlet-class>
	<load-on-startup>1</load-on-startup>
</servlet>

Now that we've examined the results of the Web service generation wizard, let's get back to the exercise. The wizard created the AttachmentIBMBindingImpl.java file and opened it in the Java editor. At this point, you would ordinarily start coding the real implementation of the service's operations. However, since we're only interested in the passing of attachments, we'll simply add a console message that displays the contents of the message body text and some information about the attachments that we passed to this service from our client application (which will be generated by a Application Developer wizard in the next section). Add the code in Listing 4 to the sendAttachments method of this class (you can type it in or copy it from the AttachmentIBMBindingImpl.java file provided in the Download section.

Listing 4. Additional code for the sendAttachments method
System.out.println("entering AttachmentBindingImpl.sendimage()");
System.out.println("The text Body is: " + textBody);
System.out.println("The text Attachment is: " + textAttachment);
System.out.println("Image properties are: " + imageAttachment.toString());    	
// TBD - should probably do something with zip file !
if (null != zipAttachment) {
    System.out.println("The Zip Attachment is received");
} else {
  System.out.println("The Zip Attachment is not received");
 }
 System.out.println("exiting AttachmentBindingImpl.sendimage()");

The class should now look like this:

Figure 10. The new AttachmentBindingImpl class
The new AttachmentBindingImpl class

Save and close the AttachmentIBMBindingImpl.java file.

Add optional handler to service project

Although we're officially finished with the service, let's add a new class to the project that can demonstrate that one of the two text messages that were passed to our service was actually passed as an attachment. We'll do this by creating a JAX-RPC handler that intercepts the incoming request message on the service side and examines the incoming message using classes from the SOAP Attachments API for Java (SAAJ). The handler class we define will look for SOAP AttachmentParts and display on the console the mime type of any parts found.

We'll use Application Developer to create the base Handler and then we'll add the SAAJ code that examines the SOAP message. The code for our handler is simple. You can either type in the code shown below or copy and paste it from the file provided with the article

Let's first create the basic class and then examine the generated code:

  1. In the service project, navigate to the JavaResources => JavaSource folder and right-click JavaSource.
  2. Select New=>class to start the New Class wizard.
  3. In the New Java Class dialog, type ibm.attachment.handler for the package name and AttachmentIBMHandler for the class name, then click Browse next to the SuperClass field.
  4. In the Superclass Selection dialog, type GenericHandler in the Choose a Type field. In the Qualifier field, select the GenericHandler class from the javax.xml.rpc.handler package and then click OK, as shown in Figure 11:
    Figure 11. Superclass Selection dialog
    Superclass Selection dialog
  5. Back in the in the New Java Class dialog, check Constructors from superclass and click Finish, as shown in Figure 12:
    Figure 12. The new AttachmentBindingImpl class
    The new AttachmentBindingImpl class

The handler we've just created is a skeleton, so we need to add some additional code that implements the function we want to provide. The GenericHandler from which we derived our handler has methods that are invoked by the SOAP runtime when a handler is called. One of those methods, handleRequest, is called just before an incoming request is passed to a Web service. This allows the developer of a JAX-RPC handler to do any kind of additional message manipulation or processing before it reaches the service. In our case, we just want to demonstrate that the message contains an attachment. We'll use a few lines of simple SAAJ code to do that:

  1. First, add the Java import statements in Listing 5 to the top of the class:
    Listing 5. The import statements
    import javax.xml.namespace.QName;
    import javax.xml.rpc.handler.GenericHandler;
    import javax.xml.rpc.handler.MessageContext;
    import javax.xml.rpc.handler.soap.SOAPMessageContext;
    import javax.xml.soap.AttachmentPart;
    import javax.xml.soap.SOAPMessage;
    import java.util.Iterator;
  2. Next add our implementation of the handleRequest method to the class by adding the code shown in Listing 6 to the body of the class:
    Listing 6. The handleRequest method
    	public boolean handleRequest(MessageContext mc) {
    		System.out.println("entering handleRequest");
    		
    		SOAPMessageContext smc = (SOAPMessageContext)mc;
    		SOAPMessage sm = smc.getMessage();
    		Iterator attachments = sm.getAttachments();
    		if (!attachments.hasNext()) {
    			System.out.println("No Attachments");
    		} else {
    			System.out.println("Has Attachments");
    			while (attachments.hasNext()) {
    			  AttachmentPart attachment = 
                      ( AttachmentPart)attachments.next();
    			  System.out.println("Attachment Type is: " 
                       + attachment.getContentType());
    			}
    		}
    		System.out.println("exiting handleRequest");
    		return true;
    	}

    You'll see that our simple handler examines the SOAPMessage and looks for AttachmentParts, outputting the mime type of any attachments found.

  3. Save and Close the AttachmentIBMHandler.java file.

Now you've added the handler to the project, but you also need to configure the project to use the handler at runtime. You do this by adding a handler section to the webservices.xml class as follows:

  1. Navigate to the WebContent=>WEB-INF folder and right-click webservices.xml, then select Open with => Web Services Editor.
  2. From the Handlers tab, click Add in the Handlers section.
  3. In the Class Browser dialog, type AttachmentIBMHandler in the Browse for a Java class field, then select the ibm.attachment.handler package from the Qualifiers field, and click OK, as shown in Figure 13:
    Figure 13. The AttachmentIBMHandler in the Class Browser
    The AttachmentIBMHandler in the Class Browser
  4. In some early versions of Application Developer, there is a bug in the editor that fails to show the Handler class in the Handlers section, though it has been added to the file. Save and close the editor and we'll check to see that the add process worked.
  5. Re-open the webservices.xml file by right-clicking webservices.xml and selecting Open with => Web Services Editor.
  6. On the Handlers tab, you should see the handler listed in the Handler section, as shown in Figure 14:
    Figure 14. Handler added
    Handler added
  7. Close the XML editor.
  8. In order to see exactly what was added to the webservices.xml file, we'll open the file in the text editor. Right-click webservices.xml and select Open with => XML Source Page Editor. You'll see that a three-line handler section has been added to the document in the port-component section, as shown in Figure 15:
    Figure 15. View of webservices.xml
    View of webservices.xml
  9. Close the editor. The service project is now finished and should like Figure 16:
    Figure 16. The finished project
    The finished project

Publish to the server

Sometimes, when changing a project's deployment descriptors, the server may not notice that a change has been made. In order to deploy the changes to the server, go to the Servers tab, right-click the WebSphere server, and select Publish. It may take a moment for the publish to complete.


Create a client from a WSDL file

Now that we've completed the service, we'll generate a client project to test our new Web service. We could test our Web service using the Web Services Explorer in Application Developer, but a generated client project contains code that can be used as a model for invoking a Web service. In addition, the generated client project produced by the Application Developer Client Generation wizard serves as a good example of a design for a client project.

Generate Web service client components

We'll use the same wsdl file from our Web service project to generate the new client project with Application Developer tooling.

  1. In the AttachmentService, right-click AttachmentIBM.wsdl, and click Web Services => Generate Client. In the Web Service Client dialog, select Java Proxy from the Client proxy type field, check Overwrite files without warning, and click Next, as shown in Figure 17:
    Figure 17. Web Service Client dialog
    Web Service Client dialog
  2. In the Web Service Selection page, accept the default (the wsdl file you selected) and click Next, as shown in Figure 18.
    Figure 18. The Web Service Selection page
    The Web Service Selection Page
  3. In the Client Environment Configuration page, type AttachmentClient in the Client project field and accept the default for the ear file. Click Next, as shown in Figure 19:
    Figure 19. Client Environment Configuration page
    Client Environment Configuration page
  4. In the Web Service Proxy page, accept the default values and click Finish, as shown in Figure 20:
    Figure 20. The Web Service Proxy page
    The Web Service Proxy Page
  5. When the wizard finishes processing you'll see the new AttachmentClient project under Dynamic Web Projects. Open this project and expand all the folders to see what was generated by the wizard, as shown in Figure 21:
    Figure 21. The wizard output
    The wizard output

The ibm.attachment package under the JavaSource folder contains a number of important classes:

  • AttachmentIBM.java - This is a Java Interface that represents the service itself and provides a declaration of its operations.
  • AttachmentIBMBindingStub.java - This class implements the AttachmentIBM interface. The code in this class binds to and invokes the Web service.
  • AttachmentIBMProxy.java - This class is used to retrieve an instance of the Web service. The code in this class first does a JNDI lookup to see if it can get an instance of the service. If no service is found, it uses the AttachmentIBMServiceLocator class to get an instance of the service for it.
  • AttachmentIBMService.java - This Java interface defines the methods used to locate the service. It's implemented by the AttachmentIBMServiceLocator class.
  • AttachmentIBMServiceLocator.java - This class contains the code that locates the service and returns an instance of the AttachmentIBM service.

Another interesting file is AttachmentIBM_mapping.xml located under WebContent => WEB-INF. This file serves the same function as the file of the same name in the AttachmentService project: it describes the mappings from the XML stream to the Java types declared in the method signature of the service operation. Once again, the content of this file is rather cryptic, but the rules for constructing these mappings are described in the JAX-RPC specification

Add a test JSP file

There's one last thing we need to do before we can test the Web service. We need to provide some code that uses the generated AttachmentIBMProxy to communicate with our Web service. This function is provided by a simple JSP file has accompanies this exercise. we'll describe the procedure for importing that code into the client project, but we'll also list the code so that it can be put into your own JSP if you prefer.

  1. In the AttachmentClient project, navigate to the WebContent folder, right-click it, and selectimport => File System => Next.
  2. In the Import dialog, browse to the folder in which you placed the sample code and select the AttachmentIBMTest.jsp file, then cllick Finish, as shown in Figure 22:
    Figure 22. The wizard output
    The wizard output

In case you'd rather provide your own JSP, Listing 7 shows the simple code that we put in our sample JSP:

Listing 7. A sample JSP
<%@page contentType="text/html;charset=UTF-8"%><HTML>
<HEAD>
<TITLE>Attachment Test </TITLE>
</HEAD>
<BODY>
<H1>FedTest</H1>

<jsp:useBean id="sampleAttachmentProxyid" scope="session" 
        class="ibm.attachment.AttachmentIBMProxy" />

<%

try {
	String imageFileName = "c:/temp1/fed.jpg";
	String zipFileName = "c:/temp1/fed.zip";
	
	javax.activation.FileDataSource fds = 
                new javax.activation.FileDataSource(zipFileName);
	javax.activation.DataHandler dh = 
                new javax.activation.DataHandler(fds);

	java.awt.Toolkit toolkit = java.awt.Toolkit.getDefaultToolkit();
	java.awt.Image image = toolkit.createImage(imageFileName);

	sampleAttachmentProxyid.sendAttachments("Body Text", 
                "Text Attachment", image, dh);
        
    } catch (Exception e) {
%>
Exception: <%=e.toString() %>
<%
}

String doneString = "Done";
		
%>
		
<%=doneString %>
		
</BODY>
</HTML>

It's important that the names and location of the jpg file and zip file referred to in the body of the jsp file match the names and locations to which you deployed those files in the first step of this exercise.

The AttachmentClient project is now complete. The contents of the project should match Figure 23:

Figure 23. The final project
The final project

Test the service with the generated client

In this section, we'll test the service and view the output.

Start the test

  1. In order to ensure that the server is ready for testing, it's a good idea to rebuild the workspace. To do this, select Project => Clean, then select Clean all projects and click OK.
  2. Once again, you should deploy the changes to the server. Go to the Servers tab, right-click the WebSphere server and click Publish.
  3. To start the test, right-click on the AttachmentIBMTest.jsp file in the AttachmentClient project and select Run=>Run on Server.
  4. In the Select a Server dialog, select the WebSphere server and click Finish, as shown in Figure 24:
    Figure 24. The server selection page
    The server selection page

This will open a browser and you'll see the output from the JSP appear in the browser. Since the JSP file invokes the AttachmentIBMProxy before it displays output, the results of the test should appear in the Console tab shortly after the browser shows the output from the JSP. In other words, you don't have to click anything on the browser in order for the test to complete.

View the output

Click the Console tab to see the output from the test, as shown in Figure 25:

Figure 25. The output from the test
The output from the test

The output shows that the handler examines the SOAP message, finds our three attachments, and outputs the mime type of each one. Then you see the output from the Web service that displays the two strings, one from the message body and one from the attachment, some properties of the image, and the fact that a zip attachment was present. (It's not in the scope of this paper to work with the DataHandler class that contains the zip file.)


Summary

In this paper we described a technique for creating a Web service that can receive a SOAP message containing attachments, in addition to the normal content contained in the body of the message. In this simple example, the service received a text message in the body, and a text message, a jpeg file and a zip file as attachments. We then ran the application on a test server and observed the output.


Download

DescriptionNameSize
Sample code for this articleAttachmentsFiles.zip  ( HTTP | FTP )8KB

Resources

Learn

Get products and technologies

  • Build your next development project with IBM trial software, available for download directly from developerWorks.
  • JAX-RPC: Download the JAX-RPC documentation.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=143254
ArticleTitle=Create a Web Service that receives SOAP attachments with Rational Application Developer
publish-date=06282006