Wer schon einmal einen Webservice entwickelt hat oder nur einen in eine eigene Anwendung einbinden wollte, hat sich sicher schon einmal gewünscht, diesen Webservice ohne viel Aufwand zu testen. Da wir keine uns befriedigende Lösung gefunden haben, schlagen wir in dieser Artikelserie eine eigene Lösung vor. Im letzten Teil haben wir gezeigt, daß unsere Lösung Formulare mit Eingabeelementen erzeugt, die auf den Typ des jeweiligen Parameters abgestimmt sind. Hier wollen wir den Umgang unseres Frameworks mit komplexen Datentypen veranschaulichen.

Neuer Webservice

Zur Veranschaulichung des Verhaltens unserer Lösung bei der Benutzung komplexer Datentypen werden wir hier zunächst kurz darauf eingehen, was wir damit meinen: Die Operation aus dem vorhergehenden Artikel wurde dafür so umgestellt, daß die beiden Parameter nunmehr in einem Struct übergeben werden. Die Operation berechnet deren Summe und deren Differenz und packt beide Werte wiederum in ein Struct, das dem Aufrufenden zurückgeliefert wird:

 	public ReturnStruct1 doMath(ParamStruct1 param)
	{
		ReturnStruct1 rv=new ReturnStruct1();
		rv.sum=param.a+param.b;
		rv.diff=param.a-param.b;
		return rv;
	}
	public struct ParamStruct1
	{
		public int a;
		public int b;
	}
	public struct ReturnStruct1
	{
		public int sum;
		public int diff;
	}

Mit dieser Konfiguration wird durch unsere Lösung das folgende Formular erzeugt:

Die Ausführung der Operation präsentiert anschließend die erwarteten Resultate:

Spätestens hier zeigt sich auch, daß XSP2 - im ersten Artikel der Reihe noch als eine der Möglichkeiten zur Umsetzung der von uns formulierten Anforderungen vorgestellt - bereits bei moderat schwierigeren Dienstkonfigurationen aufgeben muß: Das von XSP2 bereitete Formular sieht nämlich so aus:

 

In diesem Formular kann man die Inputparameter nicht mehr von Hand spezifizieren - auch nicht mit viel gutem Willen!