Develop a simple web service that can be passed by a UsernameToken in the SOAP Header, and that makes it possible and very easy for J2EE applications in WebSphere that have J2EE Security enabled to access the service by supporting authentication using LTPA Tokens in the SOAP Header.

Share:

Rajiv Ramachandran (rramachandran@prolifics.com), Senior consultant, Prolifics

Rajiv Ramachandran photoRajiv Ramachandran is a key member of Prolifics' highly specialized team of IBM WebSphere experts retained to architect, build and troubleshoot custom WebSphere, Portal and Business Integration solutions. He specializes in Enterprise Architectures, Business Integration and SOA development. He is part of Prolifics' West Coast practice.



04 April 2006

Also available in Chinese

Introduction

It's a given in today's world of enterprise application development that service-oriented architecture (SOA) is the preferred way to architect solutions. Enterprises have already adopted, or are in the process of adopting, web services as an implementation of SOA in their domain. Yet another trend that is becoming increasingly visible is that, with both the Java™ Enterprise Edition (J2EE) and .NET platforms providing a well defined framework for building web services based applications, enterprises now end up having applications built on top of these two platforms within their infrastructure. In this context interoperability becomes a key concern. However it doesn't stop there. Tools are available to help build and deploy services that may be accessed over an internal network or even the Internet, but these services need to be secured. All of a sudden the world of SOA does not look that easy to implement any more. The same service needs to be accessible from diverse platforms, to accept and validate security credentials, and be simple enough for developers to build and for clients to consume.

This article focuses on a small piece of this big concern. We develop a simple web service that can be invoked from the .NET platform by passing a UsernameToken in the SOAP Header, and can also be invoked from J2EE applications in WebSphere with J2EE Security enabled by passing the native LTPA Tokens in the SOAP Header. What allows the same service to be securely accessed from both the platforms is the definition of multiple ports for a single web service and the ability to define security policies at the port level. The business logic in this web service is implemented just once; however the service is configured to support multiple authentication mechanisms so that it can be easily accessed by clients from different platforms.

The target environment for this discussion is IBM WebSphere® Application Server Version 6.0 and later, with Rational® Software Architect Version 6.0.1 used for development.

This article assumes familiarity with the following:

  • Basic web service concepts such as SOAP, WSDL, and XML
  • Use of Rational Software Architect and Rational Application Developer for developing J2EE Applications and web services

Developing the "Print" web service using the top-down approach

Developing the web service using the top-down approach involves defining the service in the form of a WSDL and then providing a Java implementation for the service. At a very high level, the following steps are involved:

  1. Generate a skeleton WSDL using the wizard in Rational Software Architect and Rational Application Developer.
    • Create an Enterprise Application Project called "PrintService" and include in it a web module called "PrintServiceWeb".
    • Create a folder called "wsdl" under the "WebContent" folder of the "PrintServiceWeb" project .
    • Add a wsdl file in the "wsdl" folder called "PrintService.wsdl".
    • Change the target name space to "http://www.prolifics.com/PrintService/" and accept the defaults for the rest.

      Figure 1: Skeletal WSDL defined for the print service
      Skeletal WSDL defined for the print service
  2. Modify the generated artifacts to map to the definition of the "Print" service.
    • Rename the messages in the WSDL to "printRequest" and "printResponse".
    • Rename the operation to "print".
    • Rename the Port Type to "PrintService.NET".
    • Rename the Binding to "PrintServiceSOAP.NET"
    • Expand the Services and Rename the port to "PrintServiceSOAP.NET".
    • Change the location in the "soap:address" element to http://localhost:9080/PrintServiceWeb/services/PrintService.NET.
      Figure 2: Print service with the PrintServiceSOAP.NET Binding
      Figure 2: Print service with the PrintServiceSOAP.NET Binding
  1. Add additional PortType, Binding and Port definitions. This step is being done so that we will have the ability to configure different security requirements for different ports that expose the same service.
    • Add a new Port Type called PrintServiceJ2EE.
    • Add a new operation on the under this Port Type called "print". Un-check the "Create default Messages" option.
    • Right click on the "input for the "print" operation, select "Set Message", select "select an existing message" and choose printRequest.
    • Do the same steps for the "output" and map it to the "printResponse" message.
    • Add a new Binding called PrintServiceSOAPJ2EE, select the PrintServiceJ2EE Port Type, select SOAP protocol and use the document/literal binding option.
    • Add a new port called PrintServiceSOAPJ2EE; choose the PrintServiceSOAPJ2EE binding and the SOAP protocol. Set the following string in the location field: http://localhost:9080/PrintServiceWeb/services/PrintServiceJ2EE
      Figure 3: Print service with the PrintServiceSOAP.NET and PrintServiceSOAPJ2EE bindings
      Print service with the PrintServiceSOAP.NET and PrintServiceSOAPJ2EE bindings
  1. Use the "Generate Skeleton Java Bean" wizard to generate a java class that represents the web service.
    • Right click on the wsdl file and use the "Web services > Generate Java Bean Skeleton" option.
    • Go through the wizard accepting all the defaults to generate skeletal Java code for the web service.
      Figure 4: Generated Java Classes
      Figure 4: Generated Java Classes
  1. Develop the implementation of the service and access the same from the Java classes that were generated for the different port definitions in the WSDL.
    • Define a Java class called PrintServiceImpl under the com.prolifics.www package and implement the print method in this class.
    • Update the PrintServiceSOAPJ2EEImpl and the PrintServiceSOAPNETImpl to invoke the print method in the PrintServiceImpl class.

      Listing 1. Java implementation of the WebService
      PrintServiceImpl
      						
      package com.prolifics.www;
      						
      public class PrintServiceImpl {
        public java.lang.String print(java.lang.String printRequest) {
        System.out.println("PrintServiceImpl:print:Received Request:"+printRequest);
        return printRequest;
        }
      }
      						
      PrintServiceSOAPJ2EEImpl
      						
       /**
        * PrintServiceSOAPJ2EEImpl.java
        *
        * This file was auto-generated from WSDL
        * by the IBM web services WSDL2Java emitter.
        * o0516.14 v42205183324
       */
      						
      package com.prolifics.www;
      						
      public class PrintServiceSOAPJ2EEImpl
        implements com.prolifics.www.PrintServiceJ2EE
        public java.lang.String print(java.lang.String printRequest)
        throws java.rmi.RemoteException {
        return new PrintServiceImpl().print(printRequest);
        }
      }
      	
      						
      PrintServiceSOAPNETImpl
      						
       /**
        * PrintServiceSOAPNETImpl.java
        *
        * This file was auto-generated from WSDL
        * by the IBM web services WSDL2Java emitter.
        * o0516.14 v42205183324
      */
      						
      package com.prolifics.www;
      						
      public class PrintServiceSOAPNETImpl
         implements com.prolifics.www.PrintServiceNET{
      public java.lang.String print(java.lang.String printRequest) 
         throws java.rmi.RemoteException {
         return new PrintServiceImpl().print(printRequest);
         }
      }
  1. Define appropriate mappings in the "web.xml" for the URLs defined in the WSDL.
    • Open the web.xml file (PrintServiceWeb->WebContent->WEB-INF).
    • In the Servlets tab, select the "com_prolifics_www_PrintServiceSOAPNETImpl" entry.
    • Under URL Mappings, click Add and set the URL Pattern to services/PrintService.NET.
    • For the "com_prolifics_www_PrintServiceSOAPJ2EEImpl" entry add the mapping to "services/PrintServiceJ2EE"
      Figure 5: Defining mappings in web.xml
      Defining mappings in web.xml

This completes the definition of the "Print" web service.


Defining security tokens for the "Print" web service

Now that we have developed the Print web service, we can configure the deployment descriptor (webservices.xml) for the service to define the Security Tokens that can be accepted by the web service.

WebSphere Application Server Version 6.0 and later supports WS-Security V1.0. As a part of this specification the web services Security UsernameToken Profile was standardized and was one of the mechanisms by which authentication credentials could be passed from the client to the server. Using this profile ensures interoperability between WebSphere Application Server Version 6.0 and later and Microsoft Web service Extensions (WSE) V2.0 that also implements the finalized OASIS WS-Security V1.0.

Listing 2. Username token
<wsse:Security soapenv: mustUnderstand="1" xmlns:wsse=
    "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-secext-1.0.xsd">
  <wsse:UsernameToken>
	<wsse:Username>db2admin</wsse:Username>
	<wsse:Password Type=
	  "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wssusername-
      token-profile-1.0#PasswordText">db2admin</wsse:Password>
  </wsse:UsernameToken>
</wsse:Security>

WebSphere Application Server supports mechanisms beyond those defined in WS-Security V1.0 for authenticating users. One such mechanism is using an LTPA token in the SOAP Header to provide authentication credentials. For J2EE applications on WebSphere that have J2EE security enabled, to use the "Print" web service, you can use the LTPA token of the already authenticated user in the SOAP Header. This provides the authentication credentials to the web service for access (thus satisfying the authentication requirement), is more suitable, easy to develop and use on the WebSphere platform. On the web service side, with a port that accepts the UsernameToken, there is no compromise being made on interoperability of the service.

Listing 3. LTPA Token
<wsse:Security soapenv:mustUnderstand="1"
  xmlns:wsse=
  "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-secext-1.0.xsd">
  <wsse:BinarySecurityToken
  xmlns:wsst=http://www.ibm.com/websphere/appserver/tokentype/5.0.2 ValueType="wsst:LTPA">
  nwHBBZwUF+m94fAuY57oQrGFyKnIIYMM5OOlkbtMWx5yaIo=
  </wsse:BinarySecurityToken>
</wsse:Security>

The following steps will modify the deployment descriptor for the Print Service to enable the UsernameToken on port "PrintServiceSOAP.NET" and the Binary (LTPA) token on port "PrintServiceSOAPJ2EE":

  1. Define UsernameToken on the PrintServiceSOAP.NET port.
    • Open the webservices.xml file and switch to the Extensions tab.
    • Select the PrintServiceSOAP.NET Port Component Binding.
    • Expand the Request Consumer Service Configuration Details section and expand the Required Security Token section.
    • Click Add and enter the following information:
      • Name: usernameToken
      • Select "Username" as the Token Type and accept the rest of the values.
    • Under the Caller Part Section, click Add and enter the following information?
      • Name: usernameToken
      • Select "Username" as the Token Type and accept the rest of the values.
    • Switch to the Binding Configurations tab.
    • Select the PrintServiceSOAP.NET Port Component Binding.
    • Expand the Request Consumer Binding Configuration Details section and expand the Token Consumer section under the same.
    • Click Add and enter the following information:
      • Token consumer name: usernameTokenConsumer
      • Token consumer class: com.ibm.wsspi.wssecurity.token.UsernameTokenConsumer
      • Security Token: usernameToken
      • Value Type: Username Token
      • Select the check box: "use jaas.config".
      • Set the jaas.config name to system.wssecurity.UsernameToken.
      • Leave all the other fields as is.
    • Save and close the file.
  1. Define Binary Token (LTPA) on the PrintServiceSOAPJ2EE port
    • Open the webservices.xml file and switch to the Extensions tab.
    • Select the PrintServiceSOAPJ2EE Port Component Binding.
    • Expand the Request Consumer Service Configuration Details section and expand the Required Security Token section.
    • Click Add and enter the following information:
      • Name: ltpaToken
      • Select "LTPAToken" as the Token Type and accept the rest of the values.
    • Under the Caller Part section, click Add and enter the following information:
      • Name: ltpaToken
      • Select "LTPAToken" as the Token Type and accept the rest of the values.
    • Switch to the Binding Configurations tab.
    • Select the PrintServiceSOAPJ2EE Port Component Binding.
    • Expand the Request Consumer Binding Configuration Details section and expand the Token Consumer section under the same.
    • Click Add and enter the following information:
      • Token consumer name: ltpaTokenConsumer
      • Token consumer class: com.ibm.wsspi.wssecurity.token.LTPATokenConsumer
      • Security Token: ltpaToken
      • Value Type: LTPA Token
      • Leave all the other fields as is.
    • Save and close the file.

Developing clients for the "Print" web service

Let's go ahead and develop two forms of clients for the Print Service

  1. A .NET client for the Print Service. Here are steps to get a client working:
    • To get the .NET client to execute the following should be installed:
      • Microsoft .NET Framework Version 2.0 Redistributable Package (x86)
      • .NET Framework 2.0 Software Development Kit (SDK) (x86)
      • Microsoft web services Enhancements 2.0 Service Pack 3
    • Create a folder called DotNETClient and open a command prompt at "c:\DotNETClient".
    • Execute the following from the command line to generate a proxy class for the web service: C:\Program Files\Microsoft.NET\SDK\v2.0\Bin\wsdl" http://localhost:9080/PrintServiceWeb/wsdl/PrintService.wsdl.
    • This generates a class called PrintService.cs
    • Make the following update to the class definition in the PrintService.cs file and save the same:
      • FROM - public partial class PrintServiceSOAPNET : System.Web.Services.Protocols.SoapHttpClientProtocol
      • TO - public partial class PrintServiceSOAPNET : Microsoft.Web.Services2.WebServicesClientProtocol
    • To compile the generated proxy class to a DLL (PrintService.dll), execute the following command: C:\apps\DotNET\client>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\csc /t:library /r:System.Web.Services.dll,"C:\Program Files\Microsoft WSE\v2.0\Microsoft.Web.Services2.dll" PrintService.cs.
    • Create a PrintServiceClient.cs file that would be the test client and which would use the proxy to access the web service.
    Listing 4. PrintServiceClient.cs
    using System;
    using Microsoft.Web.Services2;
    using Microsoft.Web.Services2.Security.Tokens;
    namespace com.prolifics.www {
      public class PrintServiceClient {
      public static void Main(String[] args) {
      PrintServiceSOAPNET proxy = new PrintServiceSOAPNET ();
      proxy.Url="http://localhost:9081/PrintServiceWeb/services/PrintService.NET";
      proxy.RequestSoapContext.Security.Tokens
    	 .Add(new UsernameToken("db2admin","db2admin",PasswordOption.SendPlainText));
      String result = proxy.print("Test from DotNET");
      System.Console.WriteLine("result = " + result);
    	}
      }
    }
    • To compile the client code, execute the following command. It should create a executable called PrintServiceClient.exe: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\csc /r:PrintService.dll,"C:\Program Files\Microsoft WSE\v2.0\Microsoft.Web.Services2.dll" PrintServiceClient.cs
  1. A J2EE application that has J2EE security enabled on its components and acts as a client to the "Print" Web Service and accesses it using LTPA authentication.
    • Create an Enterprise Application Project called "PrintServiceJ2EEClient" and include in it a Web module called ("PrintServiceJ2EEClientWeb").
    • Generate a client for the Print web service (PrintServiceWeb :gt; WebContent :gt; wsdl :gt; PrintService.wsdl, Right click > Web services > Generate Client).
    • Select Web as the client type and the "PrintServiceJ2EEClientWeb" as the client project.
    • Open the web.xml file (PrintServiceJ2EEClientWeb :gt; WebContent :gt; WEB-INF :gt; web.xml).
    • Select the WS Extension tab.
      • Select the PortServiceSOAPJ2EE binding, expand the Request Generator Configuration section and the Security Token section.
      • Click the Add button
      • Add the following values:
        • Name: ltpaToken
        • Token Type: LTPAToken
    • Select the WS Binding tab.
      • Select the PortServiceSOAPJ2EE binding, expand the Security Request Generator Binding Configuration section and the Token Generator section.
      • Click the Add button.
      • Add the following values:
        • Token generator name: ltpaTokenGenerator
        • Token generator class: com.ibm.wsspi.wssecurity.token.LTPATokenGenerator
        • Security Token: ltpaToken
        • Check the "Use value type" checkbox.
        • Value type: LTPA Token
        • Call back hander: com.ibm.wsspi.wssecurity.auth.callback.LTPATokenCallbackHandler
        • Leave the rest of the fields as default.
    • Create a JSP called "testClient.jsp" (PrintServiceJ2EEClientWeb > WebContent)
    • Add the following snippet in the "testClient.jsp":

    Listing 5. testClient.jsp
    <%
     try {
      com.prolifics.www.PrintServiceJ2EEProxy proxy = 
       new com.prolifics.www.PrintServiceJ2EEProxy();
       proxy.setEndpoint
    	("http://localhost:9081/PrintServiceWeb/services/PrintServiceJ2EE");
    	String responseData = proxy.getPrintServiceJ2EE().print("Test With LTPA Token");
    	System.out.println("Response Data From Web Service:"+responseData);
        }catch(Exception e) {
    	e.printStackTrace();
      }
    %>
    • Enable J2EE Security on the client web application.
      • Open the web.xml file (PrintServiceJ2EEClientWeb > WebContent > WEB-INF > web.xml).
      • Select the Security tab.
      • Add a security role called administrator.
      • Add a security constraint called "GET_Constraint", set the resource name to "All", choose the HTTP GET method and set the pattern to /*
      • Under Authorized Roles, click Add and choose Administrator.
      • Close web.xml file.
      • Open the application.xml file (PrintServiceJ2EEClient > META-INF > application.xml).
      • Click on the Security tab.
        • Click Gather.
        • Select Administrator and choose All authenticated users.
        • Save and close the file.

Testing the "Print" web service

Before testing the "Print" web service we need to do the following:

  1. Enable global security on the WebSphere server. Here we are using the Operating System as the repository for user data.
    • Right click on the server defined in RAD/RSA and select "Run administrative console".
    • Log in and expand on Security Section and select Global Security.
    • Select the "Enable Global Security" check box and uncheck "Enforce Java 2 Security check box".
    • Under Authentication Mechanisms select LTPA and make sure your LTPA settings are configured.
    • Under Local OS define a valid user id for your system.
    • Save all the changes.
    • Log out of the console and close it.
    • Double click on the server definition:
      • Expand on the security selection.
        • Select the check box that indicates "Security is enabled on the server"
        • Enter a valid user id and password.
      • Expand on the Server Section.
        • Choose SOAP under Server connection type and admin port section.
    • Save and close the server definition file.
    • Restart the Server. Make sure the applications have already been added to the project.
  1. Enable TCPMON to look at the SOAP messages that flow between the clients and the web service that show the presence of Username and the Binary token.
    • Copy the tcpmon.jar file to a folder name, for example "tcpmon".
    • Open a command window and change to the tcpmon directory.
    • Execute java -cp tcpmon.jar tcpmon.
    • Define the following:
      • Listener Port # as 9081
      • Target Host Name as "localhost"
      • Target Port # as 9080
      • Click Add
      • Select the Port 9081 tab
      • Select the XML Format check box
      • Click on Switch Layout

To test the .NET Client, run the PrintServiceClient.exe from the command prompt:

Listing 6. TCPMON Messages - .NET Client
TCPMON Messages
----------------
    
Request
-------
POST /PrintServiceWeb/services/PrintService.NET HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web 
  Services Client Protocol 2.0.50727.42)
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://www.prolifics.com/PrintService/NewOperation"
Host: localhost
Content-Length: 1669
Expect: 100-continue
Connection: Keep-Alive
    
<?xml version="1.0" encoding="utf-8"?>
    
 <soap:Envelope 
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"x
  mlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
  xmlns:wsse=
    "http://docs.oasis-open.org/wss/2004/01/oasis-200401-
	wss-wssecurity-secext-1.0.xsd"
   xmlns:wsu=
	"http://docs.oasis-open.org/wss/2004/01/oasis-200401-
	wss-wssecurity-utility-1.0.xsd">
    
     <soap:Header>
    
     <wsa:Action>
      http://www.prolifics.com/PrintService/NewOperation
      </wsa:Action>
    
       <wsa:MessageID>
       uuid:ae17ad97-2968-4e33-9db9-98f6069bbf32
       </wsa:MessageID>
    
       <wsa:ReplyTo>
    
       <wsa:Address>
        http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous
       </wsa:Address>
    
       </wsa:ReplyTo>
    
       <wsa:To>
       http://localhost:9081/PrintServiceWeb/services/PrintService.NET
       </wsa:To>
    
       <wsse:Security soap:mustUnderstand="1">
   
       <wsu:Timestamp wsu:Id=
        "Timestamp-84157bfe-f81f-46e4-9ce3-45acd4730df4">
    
       <wsu:Created>2006-01-17T21:55:27Z</wsu:Created>
    
       <wsu:Expires>2006-01-17T22:00:27Z</wsu:Expires>
    
      </wsu:Timestamp>
    
      <wsse:UsernameToken 
       xmlns:wsu=
        "http://docs.oasis-open.org/wss/2004/01/oasis-200401-
        wss-wssecurity-utility-1.0.xsd" 
       wsu:Id="SecurityToken-27f38b42-94c0-4f55-8a76-3b99861ecde9">
    
      <wsse:Username>db2admin</wsse:Username>
    
       <wsse:Password 
        Type=<http://docs.oasis-open.org/wss/2004/01/oasis-200401-
        wss-username-token-profile-1.0#PasswordText">
        db2admin
       </wsse:Password>
    
       <wsse:Nonce>A0CP2eCABoWI3tNIcAhF5w==</wsse:Nonce>
    
       <wsu:Created>2006-01-17T21:55:27Z</wsu:Created>
    
        lt;/wsse:UsernameToken>
    
       </wsse:Security>
    
      </soap:Header>
    
     <soap:Body>
    
       <printRequest xmlns="http://www.prolifics.com/PrintService/">T
        est from DotNET
       </printRequest>
    
      </soap:Body>
    
    </soap:Envelope>
    
Response
--------
HTTP/1.1 100 Continue
Content-Length: 0
Date: Tue, 17 Jan 2006 21:55:27 GMT
HTTP/1.1 200 OK
Date: Tue, 17 Jan 2006 21:55:27 GMT
Content-Type: text/xml; charset=utf-8
Content-Language: en-US
Content-Length: 407
 
<soapenv:Envelope 
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
 	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <soapenv:Header/>
    
    <soapenv:Body>
    
     <p817:printResponse xmlns:p817=
        "http://www.prolifics.com/PrintService/">
        Test from DotNET
        </p817:printResponse>
    
 </soapenv:Body></soapenv:Envelope>

To test the J2EE Client, go to the following URL in a Browser: http://localhost:9080/PrintServiceJ2EEClientWeb/testClient.jsp and enter valid credentials to access the web resource.

Listing 7. TCPMON Messages - J2EE Client
TCPMON Messages
----------------
     
Request
-------
POST /PrintServiceWeb/services/PrintServiceJ2EE HTTP/1.1
Host: localhost
Accept: application/soap+xml,multipart/related,text/*
User-Agent: IBM WebServices/1.0
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: "http://www.prolifics.com/PrintService/print"
Connection: Keep-Alive
Content-Type: text/xml; charset=utf-8
Content-Length: 1073
Date: Mon, 16 Jan 2006 16:55:13 GMT     
     
   <soapenv:Envelope 
	  xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" 
	  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
	  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
	  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     
  <soapenv:Header>
     <wsse:Security soapenv:mustUnderstand="1" xmlns:wsse=
       "http://docs.oasis-open.org/wss/2004/01/oasis-200401-
       wss-wssecurity-secext-1.0.xsd">
     <wsse:BinarySecurityToken ValueType="wsst:LTPA"
     xmlns:wsst=
       "http://www.ibm.com/websphere/appserver/tokentype/5.0.2"
     >urUzkTCmIss15cWeZ9j9LEgr7J9XnhN7qMYPuddUBbiNSfOl2RnA/9KnK
     WulFakuYz6tJFV3Jn5iltIvpxbg5oxe+2H0r7UXb2COJU98yG1MiERV7Ccge
     Ajy6BpeXFiwaubu4Fw+4BZSxp93KmFJxZ+T9MeYLJaXiTNptyzDBUhlh
     SyuWEZcR4F7MqxH82y6l8RgvVJtBKSBlx+7P05k5UbtPPNQ18ADXXADVq/WstepVd+
    kQyZOn3Cf3nBnhniHZ6Wa1WWNtkj5o5uHqiy3byB+vSmoVK5P2
    KUPqIxfoRu9AHJLcqKGnEW1uLGFNkn3blIMwytx9vNpHc1p1C6U1E4IAr
    WnpBA4</wsse:BinarySecurityToken>
      </wsse:Security>
    </soapenv:Header>
 <soapenv:Body>
     <p817:printRequest xmlns:p817=
     "http://www.prolifics.com/PrintService/">
     Test With LTPA Token
     </p817:printRequest>
</soapenv:Body></soapenv:Envelope
     
     
Response
--------
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Language: en-US
Content-Length: 411
Date: Mon, 16 Jan 2006 16:55:13 GMT
     
<soapenv:Envelope 
   xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
   xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" 
   xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Header/>
   <soapenv:Body>
      <p817:printResponse xmlns:p817=
       "http://www.prolifics.com/PrintService/">Test With LTPA 
       Token</p817:printResponse>
 </soapenv:Body></soapenv:Envelope>

Conclusion

We've seen how defining multiple ports enables a simple web service to be made easily available to both .NET and J2EE clients -- and also support the requirement for basic authentication of users who try to access this service. This is just an example of a case where a multi-port model can be applied.

With enterprises increasingly adopting SOA and providers working on newer standards and improving the maturity of existing ones, it is going be a very exciting next few years in the areas of SOA, interoperability and security as new challenges emerge and new solutions are developed.


Download

DescriptionNameSize
Web service and client implementationmultiport-source.zip47KB

Resources

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 SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=107351
ArticleTitle=Multi-port web services
publish-date=04042006