Migrationsszenarien für Web-Services: JAX-RPC auf JAX-WS und JAXB

In diesem Artikel werden Szenarien für die Migration von JAX-RPC-Web-Services (Java™ API for XML-based RPC) auf JAX-WS- (Java API for XML-Based Web Services) und JAXB-Web-Services (Java Architecture for XML Binding) beschrieben.

Tooländerungen können durch eine Entwicklungsumgebung wie den Assembliertools, die mit WebSphere Application Server bereitgestellt werden, zum größten Teil vor den Benutzern verborgen werden. Je nach den in der XML angegebenen Daten können auch einige Methoden, die für den JAX-RPC-Service verwendet wurden, mit geringfügigen oder gar keinen Änderungen in einem JAX-WS-Service verwendet werden. Es gibt aber auch Bedingungen, die Änderungen im JAX-WS-Service erforderlich machen.

Das Kompatibilität in Java-EE-Umgebungen eine große Rolle spielt, unterstützen die meisten Anwendungsserver, die Unterstützung für die neueren Spezifikationen JAX-WS und JAXB bieten, die frühere Spezifikation JAX-RPC auch weiterhin. Infolgedessen bleiben vorhandene Web-Services wahrscheinlich JAX-RPC-basiert, während neue Web-Services mit den Programmiermodellen JAX-WS und JAXB entwickelt werden.

Nach einer gewissen Zeit, in der Anwendungen überarbeitet und neu geschrieben werden müssen, empfiehlt es sich jedoch, JAX-RPC-basierte Web-Services auf die Programmiermodelle JAX-WS und JAXB umzustellen. Ein Anlass hierfür könnte beispielsweise sein, dass sich ein Lieferant zur Bereitstellung von Erweiterungen für Servicequalitäten entschließt, die nur in den neuen Programmiermodellen verfügbar sind. Die Unterstützung für SOAP 1.2 und SOAP Message Transmission Optimization Mechanism (MTOM) ist beispielsweise nur in den Programmiermodellen JAX-WS 2.x und JAXB 2.x, aber nicht in JAX-RPC verfügbar.

Die folgenden Informationen enthalten Hinweise auf Probleme, die bei der Migration von JAX-RPC auf JAX-WS und JAXB auftreten können.
Anmerkung: Die Begriffe migrieren und Migration, die in diesem Topic verwendet werden, beziehen sich, sofern nicht anders angegeben, immer auf die Umstellung von einer JAX-RPC- auf eine JAX-WS- und JAXB-Umgebung.

Vergleich der Programmiermodelle JAX-RPC und JAX-WS/JAXB

Wenn Sie zusätzliche Informationen suchen, in denen die Unterschiede zwischen den Programmiermodellen JAX-RPC und JAX-WS/JAXB beschrieben werden, finden Sie auf der Website von IBM developerWorks verschiedene veröffentlichte Hinweise und Tipps zu Web-Services.

Entwicklungsmodelle

Die Kombination der Entwicklungsmodelle JAX-RPC und JAX-WS und JAXB auf hoher Ebene wird in der folgenden Abbildung gezeigt: Vergleich der Entwicklungsmodelle

Auf hoher Ebene sind die Modelle sehr ähnlich. Der einzige Unterschied besteht darin, dass das Modell JAX-RPC portierbare und nicht portierbare Artefakte erzeugt. Die Modelle JAX-WS und JAXB hingegen erzeugen keine nicht portierbaren Artefakte.

In der Abbildung werden die folgenden Komponenten gezeigt:
  • WSDL-Datei (Web Services Description Language): Ein Dokument, das der von der Organisation W3C veröffentlichten WSDL-Empfehlung entspricht.
  • (Optional) Konfigurationsdateien:
    • WSDL-Java-Generierungstool: Die Spezifikationen beschreiben die erforderlichen Zuordnungen, aber nicht die Namen der Tools. Für JAX-WS und JAXB wird gewöhnlich das Tool "wsimport" verwendet, und für JAX-RPC werden die Tools "wscompile" und "wsdeploy" verwendet.
    • Portierbare Artefakte: Dies sind Dateien, die vom WSDL-Java-Generierungstool generiert werden und klar strukturierte Zuordnungen in den Spezifikationen JAX-RPC bzw. JAX-WS und JAXB haben. Diese Artefakte können unverändert in den verschiedenen Implementierungen von JAX-RPC bzw. JAX-WS und JAXB verwendet werden.
    • Nicht portierbare Artefakte: Dies sind Dateien, die vom WSDL-Java-Generierungstool generiert werden und keine klar strukturierten Zuordnungen in den Spezifikationen JAX-RPC bzw. JAX-WS und JAXB haben. Diese Artefakte müssen im Allgemeinen für die jeweilige Implementierung von JAX-RPC bzw. JAX-WS/JAXB geändert werden.
    • Implementierungscode: Dies ist der Code, der bestimmte Voraussetzungen für die Implementierung erfüllen muss.
    • Implementierungsinformationen: Zusätzliche Informationen, die erforderlich sind, um die Anwendung in einer bestimmten Umgebung auszuführen.
    • WAR-Datei (Web-Archiv): Im Kontext der Abbildung "SampleService" ist eine WAR-Datei eine Archivdatei, die alle Elemente enthält, die erforderlich sind, um einen Web-Service in einer bestimmten Umgebung zu implementieren. Diese Datei wird manchmal auch als aufbereitete WAR-Datei bezeichnet.

Entwicklungs- und Laufzeitumgebungen

Eine spezielle Entwicklungsumgebung vereinfacht die Migration von Web-Services durch die Automatisierung vieler Tasks. Für die Entwicklung von WebSphere-basierten Anwendungen, zu denen auch Web-Services gehören, können Sie die mit WebSphere Application Server bereitgestellten Assembliertools verwenden.

Der folgende Beispielcode in diesem Artikel wurde in den folgenden Laufzeitumgebungen getestet:
  • IBM WebSphere Application Server Version 6.1 (unterstützt die Spezifikation JAX-RPC)
  • IBM WebSphere Application Server Version 6.1 Feature Pack for Web Services (unterstützt die Spezifikationen JAX-WS und JAXB)

Beispiele

In den folgenden Beispielen werden einige Codeänderungen beschrieben, die Sie unter Umständen vornehmen müssen, um Ihre JAX-RPC-Web-Services auf JAX-WS- und JAXB-Web-Services zu migrieren. Hervorgehoben werden insbesondere die Änderungen im Implementierungscode, die Sie sowohl auf Client- als auch auf Serverseite vornehmen müssen. Wenn keine neuen Funktionen eingeführt werden sollen, sind die erforderlichen Änderungen für die Umstellung von JAX-RPC auf JAX-WS und JAXB möglicherweise geringfügig.

Das erste Beispiel ist ein JAX-RPC-basierter Beispiel-Web-Services, der aus einer WSDL-Datei (Top-down-Entwicklung) entwickelt wurde. Dieselbe WSDL-Datei wird für die Generierung des JAX-WS- und JAXB-basierten Service verwendet. Die WSDL-Datei beschreibt den Web-Service "SampleService" mit den folgenden Operationen, die in der nachfolgenden Abbildung beschrieben werden:

Wie in der Abbildung gezeigt, werden die folgenden fünf Operationen angeboten:
  • xsd:int calcShippingCost(xsd:int, xsd:int)
  • xsd:string getAccountNumber(xsd:string)
  • xsd:dateTime calculateShippingDate(xsd:dateTime)
  • xsd:string ckAvailability(xsd:int) creates invalidDateFault
  • Person findSalesRep(xsd:string)
Nehmen wir auch an, dass "Person" durch das folgende Schemafragment in der WSDL-Datei beschrieben wird:
<complexType name="Person">
	<sequence>
				<element name="name" type="xsd:string"/>
				<element name="age" type="xsd:int"/>
				<element name="location" type="impl:Address/>
		</sequence>
		</complexType>
"Address" wird mit dem folgenden Fragment definiert:
<complexType name="Address">
	<sequence>
				<element name="street" type="xsd:string"/>
				<element name="city" type="xsd:string"/>
				<element name ="state" type="xsd:string"/>
				<element name="zip" type="xsd:int"/>
		</sequence>
		</complexType>
In der folgenden Abbildung wird auch gezeigt, dass die Operation "ckAvailability(xsd:int)" eine Ausnahme vom Typ "invalidDateFault" erzeugt. Beispielservice

Sehen Sie sich den von den Tools erstellten Service-Code an. In den folgenden Informationen wird unter anderem geprüft, was für eine JAX-RPC-Laufzeitumgebung und was für eine JAX-WS/JAXB-Laufzeitumgebung generiert wird.

Für JAX-RPC akzeptieren die Tools die WSDL-Datei als Eingabe und generieren neben anderen Dateien die Schnittstellen "SampleService.java" und "SampleServiceImpl.java". Die Schnittstelle "SampleService.java" definiert eine Schnittstelle, und der generierte Code kann im folgenden Codeblock geprüft werden. Die Schnittstelle "SampleServiceSoapBindingImpl.java" ist das Gerüst einer Implementierung, und Sie ändern diese Gerüst gewöhnlich, um eigene Logik hinzuzufügen.

JAX-RPC-Version von SampleService.java:
/**  
* SampleService.java  
*  
* Diese Datei wurde automatisch vom IBM Web-Service-Emitter
* "WSDL2Java" aus der WSDL generiert.
* cf20633.22 v82906122346  
*/  
package simple;  
public interface SampleService extends java.rmi.Remote { 	
		public java.lang.Integer calcShippingCost(java.lang.Integer shippingWt, 			
					java.lang.Integer shippingZone) throws java.rmi.RemoteException;
		public java.lang.String getAccountNumber(java.lang.String accountName)  		
				throws java.rmi.RemoteException;  	
	public java.lang.String[] ckAvailability(int[] itemNumbers) 					
				throws java.rmi.RemoteException, simple.InvalidDateFault;  	
	public java.util.Calendar calculateShippingDate( 			
				java.util.Calendar requestedDate)                      
				throws java.rmi.RemoteException;  	
		public simple.Person findSalesRep(java.lang.String saleRepName) 			
				throws java.rmi.RemoteException; }   
Für JAX-WS und JAXB akzeptieren die Tools die WSDL-Datei als Eingabe und generieren wie bei JAX-RPC die Schnittstellen "SampleService.java" und "SampleServiceImpl.java". Wie bei JAX-RPC definiert die Schnittstelle "SampleService.java" eine Schnittstelle, die im folgenden Codeblock gezeigt wird. Die Schnittstelle "SampleServiceImpl.java" ist das Gerüst einer Implementierung, und Sie ändern diese Gerüst gewöhnlich, um eigene Logik hinzuzufügen.
Anmerkung: Der Code wird von den Tools annotiert.
JAX-WS- und JAXB-Version der Schnittstelle "SampleService.java":
package simple;  
	import java.util.List;
	import javax.jws.WebMethod;
	import javax.jws.WebParam;
	import javax.jws.WebResult;
	import javax.jws.WebService;
	import javax.xml.datatype.XMLGregorianCalendar;
	import javax.xml.ws.RequestWrapper;
	import javax.xml.ws.ResponseWrapper;

/**  
* Diese Klasse wurde von der JAX-WS-SI generiert.
* JAX-WS RI IBM 2.0_03-06/12/2007 07:44 PM(Raja)-fcs
* Generierte Quellenversion: 2.0
*   
*/ 
@WebService(name = "SampleService", targetNamespace = "http://simple") public interface SampleService {       

	/**      
	*       
		* @param shippingWt      
		* @param shippingZone      
	* @return 
		* returns java.lang.Integer      
	*/     
	@WebMethod
		@WebResult(name = "shippingCost", targetNamespace = "")     
		@RequestWrapper(localName = "calcShippingCost", targetNamespace = "http://simple", className = "simple.CalcShippingCost")     
		@ResponseWrapper(localName = "calcShippingCostResponse", targetNamespace = "http://simple", className = "simple.CalcShippingCostResponse")     
		public Integer calcShippingCost(         
			@WebParam(name = "shippingWt", targetNamespace = "")         
	Integer shippingWt,
			@WebParam(name = "shippingZone", targetNamespace = "")         
	Integer shippingZone);

	/**      
	*       
	* 
	@param accountName      
	* @return 
	*     returns java.lang.String
	*/     
	@WebMethod
		@WebResult(name = "accountNumber", targetNamespace = "")     
		@RequestWrapper(localName = "getAccountNumber", targetNamespace = "http://simple", className = "simple.GetAccountNumber")     
		@ResponseWrapper(localName = "getAccountNumberResponse", targetNamespace = "http://simple", className = "simple.GetAccountNumberResponse")     
		public String getAccountNumber(         
				@WebParam(name = "accountName", targetNamespace = "")         
				String accountName);      
	/**      
	*       
		* @param requestedDate      
	* @return 
		*     returns javax.xml.datatype.XMLGregorianCalendar      
	*/     
	@WebMethod
		@WebResult(name = "actualDate", targetNamespace = "")     
		@RequestWrapper(localName = "calculateShippingDate", targetNamespace = "http://simple", className = "simple.CalculateShippingDate")     
		@ResponseWrapper(localName = "calculateShippingDateResponse", targetNamespace = "http://simple", className = "simple.CalculateShippingDateResponse")     
	public XMLGregorianCalendar calculateShippingDate(
				@WebParam(name = "requestedDate", targetNamespace = "")         
				XMLGregorianCalendar requestedDate);      
	/**      
	*       
		* @param itemNumbers      
	* @return 
		*     returns java.util.List<java.lang.String>      
		* @throws InvalidDateFault_Exception      
	*/     
	@WebMethod
		@WebResult(name = "itemAvailability", targetNamespace = "")     
		@RequestWrapper(localName = "ckAvailability", targetNamespace = "http://simple", className = "simple.CkAvailability")     
		@ResponseWrapper(localName = "ckAvailabilityResponse", targetNamespace = "http://simple", className = "simple.CkAvailabilityResponse")     
		public List<String> ckAvailability(         
				@WebParam(name = "itemNumbers", targetNamespace = "")         
				List<Integer> itemNumbers)         
		throws InvalidDateFault_Exception     
	;      
	/**      
	*       
		* @param saleRepName      
	* @return 
		*     returns simple.Person      
	*/     
	@WebMethod
		@WebResult(name = "salesRepInfo", targetNamespace = "")     
		@RequestWrapper(localName = "findSalesRep", targetNamespace = "http://simple", className = "simple.FindSalesRep")     
		@ResponseWrapper(localName = "findSalesRepResponse", targetNamespace = "http://simple", className = "simple.FindSalesRepResponse")     
		public Person findSalesRep(         
		@WebParam(name = "saleRepName", targetNamespace = "")         
		String saleRepName);  

}   

Vergleich der Codebeispiele

Auf den ersten Blick weisen die Schnittstellen nur wenig Ähnlichkeit auf. Wenn Sie die Zusatzinformationen, die durch die Annotationen für JAX-WS und JAXB hinzugefügt wurden, jedoch ignorieren, sind die Codebeispiele einander sehr ähnlich. Für die Methode "calcShippingCost" sind in der JAX-WS- JAXB-Version beispielsweise die folgenden Codezeilen enthalten:
@WebMethod
		@WebResult(name = "shippingCost", targetNamespace = "")     
		@RequestWrapper(localName = "calcShippingCost", targetNamespace = "http://simple", className = "simple.CalcShippingCost")     
		@ResponseWrapper(localName = "calcShippingCostResponse", targetNamespace = "http://simple", className = "simple.CalcShippingCostResponse")     
		public Integer calcShippingCost(         
				@WebParam(name = "shippingWt", targetNamespace = "")         
		Integer shippingWt,
				@WebParam(name = "shippingZone", targetNamespace = "")         
				Integer shippingZone);
Wenn Sie die Annotationen außer Acht lassen, leuten die Codezeilen wie folgt:
public Integer calcShippingCost(
        Integer shippingWt,
        Integer shippingZone);
Diese Zeilen sind nahezu identisch mit dem für JAX-RPC generierten Code. Der einzige Unterschied, der im Folgenden gezeigt wird, besteht darin, dass der JAX-RPC-Code den Fehler "java.rmi.RemoteException" erzeugen kann:
public java.lang.Integer calcShippingCost(java.lang.Integer shippingWt,
						java.lang.Integer shippingZone) throws java.rmi.RemoteException;
Nach dieser Logik haben drei Methoden im Wesentlichen dieselben Signaturen:
public Integer calcShippingCost(Integer shippingWt, Integer shippingZone)
		public String getAccountNumber(String accountName)
		public Person findSalesRep(String saleRepName) 
Das bedeutet, dass eine Migration von JAX-RPC auf JAX-WS keine direkten Auswirkungen auf diese Methoden hat und der ursprüngliche Implementierungscode, der in der JAX-RPC-basierten Umgebung erfolgreich ausgeführt wird, wahrscheinlich unverändert für diese Methoden verwendet werden kann.

Zwei Methoden haben jedoch andere Signaturen:

Für JAX-RPC:
public java.util.Calendar calculateShippingDate( 			
			java.util.Calendar requestedDate)                      
public java.lang.String[] ckAvailability(int[] itemNumbers) 					
		throws java.rmi.RemoteException,                                  
	simple.InvalidDateFault
JAX-WS und JAXB:
public XMLGregorianCalendar calculateShippingDate( 			
		XMLGregorianCalendar requestedDate)  	
public List<String> ckAvailability(List<Integer> itemNumbers) 
	throws InvalidDateFault_Exception 
Anmerkung: Sie finden den Vergleich der Gerüstimplementierungsdateien wahrscheinlich einfacher, das in der Datei "SampleServiceImpl.java" keine Annotationen enthalten sind:
  • SampleServiceSoapBindingImpl.java
  • SampleServiceImpl.java
Die Abweichungen bei den Signaturen sind auf Folgendes zurückzuführen:
  • Unterschiede bei der Zuordnung von XML-Namen zu Java-Namen

    Für die Methode "calculateShippingDate" wurden der Eingabeparameter und der Rückgabeparameter vom Typ "java.util.Calendar" in den Typ "XMLGregorianCalendar" geändert. Dies liegt daran, dass diese Parameter in der WSDL-Datei mit dem Typ "xsd:dateTime" angegeben wurden. JAX-RPC weist diesen Datentyp "java.util.Calendar" zu, während JAX-WS und JAXB diesen Typ "XMLGregorianCalendar" zuweisen.

  • Unterschiede bei den Zuordnungen von XML zu Java

    Bei der Methode "ckAvailability" ist die Änderung auf die Datenzuordnungen für XML-Feldgruppen zurückzuführen.

    JAX-RPC ordnet die folgenden WSDL-Elemente zu:
    <element maxOccurs="unbounded" name="itemNumbers" type="xsd:int"/>
    <element maxOccurs="unbounded" name="itemAvailability" type="xsd:string"/>
    Die vorherigen Elemente werden der folgenden Java-Quelle zugeordnet:
    int[] itemNumbers
    java.lang.String[] itemAvailability
    JAX-WS und JAXB ordnen die folgenden WSDL-Elemente zu:
    List<Integer> itemNumbers 
    List<String> ckAvailability
  • Unterschiede bei den Zuordnungen von Ausnahmen
    Für die Methode "ckAvailability" generiert der JAX-RPC-Code den folgenden Fehler:
    simple.InvalidDateFault
    Der JAX-WS-Code generiert den folgenden Fehler:
    InvalidDateFault_Exception
    Mit Ausnahme der Namen sind die Konstruktoren für diese Ausnahmen verschieden. Deshalb kann der tatsächliche JAX-RPC-Code, der den Fehler erzeugt, wie folgt angezeigt werden:
    throw new InvalidDateFault("this is an InvalidDateFault");
    Bei JAX-WS verwendet der Code einen ähnlichen Befehl wie im folgenden Beispiel:
    throw new InvalidDateFault_Exception( "this is an InvalidDateFault_Exception", new InvalidDateFault()); 
    In den Fällen, in denen Ausnahmen verwendet werden, muss der Code, der diese Ausnahmen verwendet, geändert werden.

Code migrieren

Nachdem Sie sich jetzt mit den Unterschieden zwischen den Codes vertraut gemacht haben, sehen Sie sich den ursprünglichen Code für die Methoden an, die geändert werden müssen. Im Folgenden wird erläutert, wie Sie diesen Code so ändern, dass er in einer JAX-WS- und JAXB-Umgebung funktioniert.

Angenommen, der ursprüngliche (JAX-RPC-)Implementierungscode sieht wie folgt aus:
public java.util.Calendar calculateShippingDate(
     java.util.Calendar requestedDate) throws java.rmi.RemoteException {
// Datum auf das Sendedatum plus sieben Tage setzen
requestedDate.add(java.util.Calendar.DAY_OF_MONTH, 7);

// . . .

return requestedDate;
}
Sie können den neuen Code, wie in den folgenden Beispielen gezeigt, so schreiben, dass die neuen Typen direkt verwendet werden:
public XMLGregorianCalendar calculateShippingDate(
XMLGregorianCalendar requestedDate) {
try  {    
// Datentypfactory erstellen
DatatypeFactory df = DatatypeFactory.newInstance();
// Datum auf das Sendedatum plus sieben Tage setzen
Duration duration = df.newDuration("P7D");
requestedDate.add(duration);

} catch (DatatypeConfigurationException e) {
// TODO Automatisch generierter Catch-Block
e.printStackTrace();
}

// . . .

return requestedDate;
}
Wenn Sie den Code für die Methode "ckAvailability" migrieren möchten, müssen Sie Änderungen vornehmen, weil die Zuordnung von Feldgruppen und Ausnahmen von XML zu Java in JAX-RPC und JAX-WS unterschiedlich gehandhabt wird. Angenommen, der ursprüngliche JAX-RPC-Web-Service-Code gleicht dem folgenden Beispiel:
public java.lang.String[] ckAvailability(int[] itemNumbers)
{
    
    String[] myString = new String[itemNumbers.length];
    for (int j = 0; j < myString.length; j++) {
 
            . . .
             if ( . .. )

	   	   throw new simple.InvalidDateFault(“InvalidDateFault”);

            . . .
            if ( . . .) 
               myString[j] = “available:  “ + jitemNumbers[j] ;
            else
               myString[j] = “not available:  “ + jitemNumbers[j];
 
    }
    return myString;
}
Dieser Code akzeptiert "int[]" als Eingabe und gibt "String[]" zurück. Für die JAX-WS- und JAXB-Version sind dies die Elemente "List<Integer>" und "List<String>". Der JAX-RPC-Code für die Verarbeitung dieser Feldgruppen (unter Außerachtlassung des Codes für die Ausnahmen) gleicht dem folgenden:
public java.lang.String[] ckAvailability(int[] itemNumbers)
{
    
    String[] myString = new String[itemNumbers.length];
    for (int j = 0; j < jitemNumbers.length; j++) {
 

            . . .
            if ( . . .) 
               myString[j] = “available:  “ + itemNumbers.get(j);
            else
               myString[j] = “not available:  “ + itemNumbers.get(j); 
    }
    return myString;
}
Der entsprechende JAX-WS- und JAXB-Code, in dem "Lists" anstelle von "Array" verwendet wird, sieht folgendermaßen aus:
List <String> ckAvailability(List <Integer> itemNumbers)
{
    
    ArrayList<String> retList = new ArrayList<String>();
    for (int count = 0; count < itemNumbers.size(); count++) {
 

            . . .
            if ( . . .) 
               retList.add(“available:  “ + itemNumbers.get(j));
            else
               retList.add(“not available:  “ + itemNumbers.get(j)); 
    }
    return retList;
}
Die Unterschiede bei der Zuordnung von XML- zu Java-Ausnahmen zwingt den JAX-WS-Code zur Verwendung von "InvalidDateFault_Exception" anstelle von "InvalidDateFault".
Das bedeutet, dass Sie throw new simple.InvalidDateFault(“InvalidDateFault”); durch anderen Code ersetzen müssen. Deshalb wird die folgende Zeile für den neuen Code verwendet:
throw new InvalidDateFault_Exception( "test InvalidDateFault_Exception", new InvalidDateFault());  
Die endgültige JAX-WS- und JAXB-Implementierung der Methode kann dem folgenden Code gleichen:
List <String> ckAvailability(List <Integer> itemNumbers)
{
    
    ArrayList<String> retList = new ArrayList<String>();
    for (int count = 0; count < itemNumbers.size(); count++) {
 
if ( . . . ) {
   throw new InvalidDateFault_Exception(
   "test InvalidDateFault_Exception",
   new InvalidDateFault());
}

. . .
if ( . . .) 
   retList.add(“available:  “ + itemNumbers.get(count));
else
   retList.add(“not available:  “ + itemNumbers.get(count)); 
   }
   return retList;
}
Es gibt verschiedene Methoden für die Migration des Codes. Mit Erfahrung und einer effektiven Entwicklungsumgebung kann die Migration von JAX-RPC auf JAX-WS problemlos durchgeführt werden.

Symbol, das den Typ des Artikels anzeigt. Referenzartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rwbs_migjaxrpc2jaxws
Dateiname:rwbs_migjaxrpc2jaxws.html