XML-RPC

XML-RPC
Prin XML-RPC java capata niste functionalitati pe care nu le are prin RMI. XML-RPC e mult mai light decat RMI-ul din java, pasandu-se mai degraba parametri decat obiecte spre server.
Daca RMI necesita compilarea interfetelor pentru a se cunoaste metodele premise spre apelare, XML-RPC permite clientului sa specifice ce metode vrea sa foloseasca si se cauta handleri pentru aceste metode. Referinta la obiectele de pe server se fac prin nume si nu exista stub ca la RMI.

Exemplu de client-server care foloseste jarurile xmlrpc 3.1 de la
http://mirror.nyi.net/apache/ws/xmlrpc/binaries/ (Apache)

Clientul:

import java.net.URL;
import java.util.*;
import org.apache.xmlrpc.client.XmlRpcClient;
import org.apache.xmlrpc.client.XmlRpcClientConfigImpl;

public class Client {
public static void main (String [] args) {
 try {
  XmlRpcClient server = new XmlRpcClient();
  XmlRpcClientConfigImpl cnf = new XmlRpcClientConfigImpl();
  cnf.setServerURL(new URL("http://localhost/RPC2"));
  server.setConfig(cnf);
 
  Vector params = new Vector();
  params.addElement(new Integer(17));
  params.addElement(new Integer(13));

  Object result = server.execute("sample.sum", params);

  int sum = ((Integer) result).intValue();
  System.out.println("The sum is: "+ sum);
 } catch (Exception exception) {
  System.err.println("JavaClient: " + exception);
 }
 }
}

Serverul:

import org.apache.xmlrpc.server.PropertyHandlerMapping;
import org.apache.xmlrpc.server.XmlRpcServer;
import org.apache.xmlrpc.server.XmlRpcServerConfigImpl;
import org.apache.xmlrpc.webserver.WebServer;

public class Server {

public Integer sum(int x, int y) {
   return new Integer(x+y);
}

public static void main (String [] args) { 
 try {

  System.out.println("starting XML-RPC Server...");
  WebServer server = new WebServer(80);
   
  PropertyHandlerMapping map = new PropertyHandlerMapping();
  map.addHandler("sample", Server.class);
   
   
  XmlRpcServerConfigImpl cnf = new XmlRpcServerConfigImpl();
  XmlRpcServer srv = server.getXmlRpcServer();
  srv.setConfig(cnf);
  srv.setHandlerMapping(map);
   
  server.start();
   
  System.out.println("Started successfully.");
  } catch (Exception exception) {
   System.err.println("JavaServer: " + exception);
  }
  }
}

RMI – Remote Method Invocation

Prin RMI se poate apela cod de la distanta – metode ale obiectelor aflate pe un server pot fi apelate de clienti.

Stubs si Skeletons
Clientul cand doreste sa apeleze o metoda de la distanta, o apeleaza in mod oarecum transparent (apelul se face asupra unui obiect de tip stub). Stubul este un obiect ce se afla pe client. Rolul stubului este de a incapsula informatii ca parametrii metodei care se va apela pe server precum obiectul si metodele ce se vor apela. Pachetul trimis de client ajunge la server. Aici se afla un alt obiect, skeleton caruia ii revine rolul sa decodifice parametrii, sa apeleze metoda invocata de client, sa retina valoare returnata/sau exceptia si sa trimita inapoi un pachet cu rezultatul.

Exemplu de aplicatie care foloseste RMI
Serverul va creea un obiect Hello si clientul apeleaza o metoda a obiectului creeat pe server. Pentru a sti ce metoda a obiectului sa poate apela, clientul trebuie sa aiba la dispozitie o interfata cu aceste metode, interfata ce este implementata de obiectul de pe server. Aceasta interfata se afla atat pe server cat si pe client. Aceasta este :

import java.rmi.Remote;
import java.rmi.RemoteException;


public interface HelloInterface extends Remote {
 public String say() throws RemoteException;
}

Dupa cum se vede , aceasta interfata extinde interfata Remote – ca de altfel toate interfetele care sunt implementate de obiecte aflate la distanta, iar metodele interfetelor pot arunca RemoteException.

Clasa Hello implementeaza interfata HelloInterface:

import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;

public class Hello extends UnicastRemoteObject implements HelloInterface {
 
 private static final long serialVersionUID = 7896795898928782846L;
 private String message;
 
   public Hello (String msg) throws RemoteException {
     message = msg;
   }
   
   public String say() throws RemoteException {
     return message;
   }
}

Singura metoda disponibila apelabila de catre client este say(); Hello extinde clasa UnicastRemotObject, care extinde la randul ei RemoteObject, astfel ca Hello e o clasa accesibila de la distanta.



Clasele care vor fi instantiate pe parte de server extinzand UnicastRemoteObject, extind implicit RemoteServer. RMI returneaza clientului o referinta la obiectul de pe server si nu obiectul propriuzis -> e necesar un mecanism de localizare/inregistrare a unui obiect existent pe server. Pe server inregistrarea obiectului se face cu bind(), iar clientul obtine o referinta a obiectului de pe server cu metoda lookup().

Pornire serviciului de inregistrare se face executand start rmregistry (rmiregistry & pe linux), cu portul implicit 1099.
rmic ne ajuta la generarea claselor skeleton si stub (Hello_Skel.class, Hello_Stub.class) .

Clientul:

import java.rmi.Naming;

public class Client {
 public static void main (String[] argv) {
     try {
      HelloInterface hello = (HelloInterface) Naming.lookup ("//localhost/Hello");
      System.out.println (hello.say());
     } catch (Exception e) {
      e.printStackTrace();
       System.out.println ("HelloClient exception: " + e);
     }
   }

}

Serverul:

import java.rmi.Naming;

public class Server {
 public static void main (String[] argv) {
     try {
       Naming.rebind ("Hello", new Hello ("Hello, world!"));
       System.out.println ("Hello Server is ready.");
     } catch (Exception e) {
      e.printStackTrace();
       System.out.println ("Hello Server failed: " + e);
     }
   }
}

XHTML

XHTML - EXtensible HyperText Markup Language
XHTML este compatibil cu HTML 4.01.
Toate browserele noi au support pentru XHTML.

XHTML este un limbaj care foloseste markere si are aceeasi putere de expresie ca si HTML dar mai are in plus un avantaj, acela de a respecta sintaxa XML.
Pe cand HTML este o aplicatie de tip SGML (Standard Generalized Markup Language), care este un limbaj foarte flexibil, XHTML este o aplicatie a XML care este un subset mult mai restrictiv al SGML.
Documentele XHTML trebuie sa fie bine formate, de aceea ele permit ca procesarea automata sa fie facuta cu unelte standard XML, spre deosebire de HTML care necesita un parser destul de complex, tolerant si personalizat.

XHTML poate fi gandit ca intersectia HTML cu XML, pentru ca chiar a fost gandit ca o reformulare a HTML in XML. XHTML a devenit o recomandare a W3C (World Wide Web Consortium) pe 26 ianuarie 2000. Versiunea XHTML 1.1 a devenit recomandare a W3C pe 31 mai 2001. XHTML poate fi considerat a fi succesorul HTML.

Nevoia de reformulare a versiunii HTML a fost simtita datorita faptului ca informatiile World Wide Web trebuiau furnizate mai multor tipuri de dispozitive mobile (telefoane mobile, PDA-uri etc) diferite de cele traditionale desktop, unde nu puteau fi dezvoltate resursele suplimentare de care HTML avea nevoie. In practica totusi browserele care suportau HTML pentru astfel de dipozitive s-au dezvoltat mai repede decat suportul de XHTML pentru browserele traditionale de desktop.

Un alt motiv care facea atractiva noua tehnologie a XHTML era faptul ca se reducea cererea de parsere si agenti de utilizare. Cu HTML, agentii de utilizare (motoarele de cautare gen Google :) si restul) aveau sarcina dificila de a corecta erorile documentelor publicate. Aici XML aducea un suflu nou pentru ca cerea agentilor de utilizare sa dea o eroare fatala la intalnirea unui document XML gresit formatat. Aceasta inseamna ca un browser XHTML poate teoretic sa omita codul de recuperare din eroare, chiar daca are nevoie de mai multe verificari de detectie a erorilor. Recomandarea ca browserele sa posteze o eroare mai degraba decat sa incerce sa repare un continut gresit formatat ar trebui sa ajute la eliminarea greselilor din aceste documente. Chiar si atunci cand autorii nu isi valideaza codul, la un simplu test intr-un browser XML, erorile critice ale documentului vor fi scoase la iveala si astfel vor fi mai usor de corectat.

O caracteristica speciala a XHTML mostenita din XML sunt namespace-urile. Cu ajutorul acestor namespace-uri, autorii si comunitatile isi pot defini propriile elemente XML, atribute si modele de continut pe care le pot insera in documentele XHTML. Acest lucru este similar cu flexibilitatea semantica a atributului "class" intr-un element HTML, dar cu mai putine restrictii. Anumite namespace-uri/scheme W3C XML care pot fi incluse in XHTML, includ MathML pentru marcarea semanticii matematice, Scalable Vector Graphics pentru marcarea vectorilor grafici si RDFa pentru includerea datelor RDF.

Schimbarile de la HTML la XHTML versiunea 1.0 sunt foarte mici si sunt in principal facute pentru a asigura compatibilitatea cu XML. Cea mai importanta schimbare este aceea ca documentele sa fie bine formate si ca toate elementele sa fie inchise in mod explicit asa cum cere standardul XML. In XML toate numele de elemente si atribute sunt case-sensitive, astfle incat XHTML a abordat aceasta problema prin a defini toate numele tagurilor ca fiind lowercase.
In XHTML toate valorile atributelor trebuie inchise intre apostrofuri sau ghilimele in contrast cu HTML unde numai valorile de tip string trebuiau inchise cu ghilimele, valorile numerice sau booleene erau scrise pur si simplu, fara ghilimele.
In XHTML toate elementele trebuie sa fie inchise in mod explicit, inclusiv elementele goale cum ar fi img sau br: <img> si <br>.

XHTML 1.1 - este cea mai recenta recomandare W3C. Prezentarea este controlata numai de Cascading Style Sheets (CSS). Aceasta versiune a XHTML permite deasemenea folosirea de caractere de marcare ruby pentru limbile est-asiatice.
Modularizarea XHTML permite refolosirea unor mici chunkuri de XHTML de catre alte aplicatii XML intr-o maniera bine definita si permite extinderea XHTML in scopuri specializate.
XHTML 1.1 adauga conceptul de stricta conformitate a documentelor: astfel ca un document nu poate angaja anumite caracteristici, trebuie sa fie un document complet care contine numai elementele definite in modulele cerute de XHTML 1.1.
XHTML 2.0 in 2007 este inca in lucru dar este deja controversat pentru ca se desprinde de compatibilitatea backward cu versiunile anterioare.
XHTML 2.0 poate fi parsat in acelasi fel in care un agent utilizator ar parsa XHTML 1.1, folosind un parser XML si un document CSS conform cu specificatiile versiunii noi 2.0.

Noile add-uri aduse de XHTML 2.0 sunt:

• formele HTML vor fi inlocuite cu XForms, o specificatie de informatie introdusa de utilizator de tip XML care permite afisarea corecta de diferite dispozitive de interpretarea a informatiei
• HTML frames vor fi inlocuite cu XFrames
• DOM Events vor fi inlocuite de XML Events care foloseste Document Object Model
• un nou element de tip lista, tipul nl, va fi inclus pentru a proiecta o lista ca lista de navigatie, lucru care poate fi folosite in crearea meniurior imbricate
• orice element va fi capabil sa se comporte ca un hyperlink similar cu XLink, de exemplu <li href="articles.html">Articles</li>
• orice element va fi capabil sa refere o media alternativa cu atributul src, de exemplu: <src="tree.jpg" type="image/jpeg">Oak</p> este acelasi obiect ca si <object src="tree.jpg" type="iamge/jpeg"><p>Oak</p></object>
• atributul alt al unui element img a fost inlaturat: un text alterntiv poate fi dat in continutul unui element img, asemanator cu elementul object, de exemplu: <img src="abc_abecedar.jpg">ABC <em>Abecedar</em></img>.
• un singur element head (h) va fi adaugat. Nivelul acestor headinguri va fi indicat de elementele sectiunilor imbricate, fiecare avand propriul sau heading h
• elementele i, b, tt vor fi si ele inlaturate din versiunea 2.0, numai elementele de subprezentare de tipul sup si sub (adica superscript si subscript) pentru ca ele sunt necesare in anumite limbaje. Toate celelalte taguri se intentioneaza sa fie semantice (de exemplu <strong> pentru text strong si boldat), in timp ce permite agentilor utilizatori sa controleze prezentarea cu elemente CSS.
• adaugarea RDF triplu cu proprietatea si atributele care usureaza conversia de la XHTML la RDF/XML.

Cativa membrii ai familiei XHTML:

• XHTML Basic: o versiune light a XHTML pentru dispozitive care nu suporta dialectele XHTML mai mari si mai complexe folosita pentru handheld-uri si telefoane mobile (este o inlocuire a WML si C-HTML).
  
• XHTML Mobile Profile: bazat pe XHTML Basic, acest OMA (Open Mobile Alliance) efort tinteste in special catre telefoanele de mana adaugand elemente specifice telefoanelor mobile la XHTML Basic.
• XHTML+Voice: XHTML combinat cu Voice XML pentru a suporta interactiuni audio video.

Servlets

Ce e un servlet?
Servelturile sunt module de cod java care ruleaza intr-un server de aplicatii,
pentru a raspunde la cererile clientilor. Servletii nu sunt dependenti de un
un anumit protocol client-server, dar de cele mai multe ori sunt folositi cu HTTP.

Pentru a scrie servleti sunt necesare clasele javax.servlet (framework-ul de baza) si
javax.servlet.http (frameworkul care raspunde cererilor http).

Servletii HTTP se folosesc in mod curent pentru:
-procesare si/sau inmagazinarea datelor trimise printr-un form HTML
-creare de continut dinamic (de ex se returneaza catre client ce s-a obtinut la un query pe o baza de date)

Servlets vs CGI
Modul traditional de a extinde functionalitatea unui server este CGI (Common Gateway Interface) – interfata independenta de limbaj, ce permite serverului sa porneasca un proces nou care primeste informatiile unui request (ex parametrii) prin variabile de mediu sau intrarea standard si scrie raspunsul la iesirea standard. Fiecare request e procesat separat (o alta instanta de CGI/ script CGI).

Servletii au cateva avantaje fata de CGI:
-un servlet nu ruleaza intr-un process separate -> se elimina overheadul crearii unui nou process pentru fiecare request
-un servlet ramane in memorie, daca un request s-a terminat si urmeaza altul aceeasi instanta de servlet il va procesa
-in server exista o singura instanta de servlet care raspunde concurent la toate requesturile
-mult mai sigur

Arhitectura de baza a unui servlet
Un servlet e o instanta a unei clase ce extinde interfata javax.servlet.Servlet. Cei mai multi servleti extind insa o implementare standard a interfetei, cum ar fi javax.servlet.GenericServlet sau javax.servlet.http.HttpServlet.
Pentru a initializa un servlet, serverul de aplicatii incarca clasa Servlet si creeaza o instanta apeland cosntructorul fara argumente. Acesta apeleaza mai departe metoda init (se creeaza un obiect de tip ServerConfig).
Sevletul efectueaza o singura data aceasta procedura de setup, iar obiectul ServletConfig e obtinut prin metoda getServletConfig().
Cand servletul este initializat, metoda service(ServletRequest req, ServletResponse res)
e apelata la fiecare request pe servlet (poate fi apelata concurent ).
La descarcarea servletului din server, se apeleaza metoda destroy() (toate resursele alocate in init sunt eliberate).

Diagrama cu lifecycle-ul unui servlet:



In continuare dau un exemplu simplu de HTTP Servlet, care trimite clientului inapoi paramatrii dintr-un form.

Codul html pentru form este:

<HTML>
<HEAD>
<TITLE>HTML form tutorial example</TITLE>
</HEAD>
<BODY>
<H1>HTML form tutorial example</H1>
<FORM ACTION="http://localhost:8080/myservlet/MyServlet" METHOD="POST">
Name: <INPUT TYPE="TEXT" NAME="Name" VALUE="" SIZE="25" MAXLENGTH="50"> <BR>
Email: <INPUT TYPE="TEXT" NAME="Email" VALUE="" SIZE="25" MAXLENGTH="50"><BR>
<INPUT TYPE="SUBMIT" NAME="submit" VALUE="Sign Me Up!">
</FORM>
</BODY>
</HTML>

Clasa care extinde HttpServlet:

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;


public class MyServlet extends HttpServlet {

public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
doPost(req, res);
}

public void doPost(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {

res.setContentType("text/html");
PrintWriter out = res.getWriter();

out.println("(parametru,valoare):");
Enumeration en = req.getParameterNames();
while (en.hasMoreElements()) {
String param = (String) en.nextElement();
String value = req.getParameter(param);
out.println(param + "=" + value);
}
}
}



Iar fisierul de configurare web.xml este:

<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<display-name>
myservlet</display-name>
<servlet>
<description>
</description>
<display-name>
MyServlet</display-name>
<servlet-name>MyServlet</servlet-name>
<servlet-class>
MyServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>MyServlet</servlet-name>
<url-pattern>/MyServlet</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>index.jsp</welcome-file>
<welcome-file>default.html</welcome-file>
<welcome-file>default.htm</welcome-file>
<welcome-file>default.jsp</welcome-file>
</welcome-file-list>
</web-app>



DOM vs SAX

DOM este o metoda mai convenienta de manipulare a fisierelor XML, dar la folosirea lui trebuie luate in considerare urmatoarele aspecte :

• Fisierul XML trebuie parsat in totaliate inainte de a se incepe procesarea lui. Cum majoritarea implementarilor DOM sunt memory-based, aceasta aduce o limitare majora la cantitatea de XML ce trebuie procesat. De aici rezulta ca si limitarea de a face procesare in paralel pe mai multe portiuni din XML este limitata (prin pipelining)
• Structura de DOM defineste numai niste noduri generice, pe cand in majoritatea limbajelor orientate obiect se doreste sa se implementeze clase concrete de noduri.

SAX este mult mai folositor atunci cand :

• Se doreste procesarea unor cantitati mari de XML, dar informatia cautata este punctuala, in sensul ca se doreste prelucrarea unei portiuni mici din XML din diverse zone din document (e event driven)
• Mai putina alocare de memorie
• Mai multe stagii din procesarea documentului XML sunt interconectate – spre a forma un pipeline, nemaifiind nevoie de procesarea intregului document inainte
• La folosirea lui se scrie in general mai mult cod decat ca atunci cand e folosit DOM

Web Services / Axis

Ce este un web service

Este un lucru foarte normal ca dou programe (procese) sa comunice intre ele pe acceasi masina, folosind fisiere, IPC-uri, pipe-uri, cozi de mesaje, memorie partajata etc. Acest lucru se poate generaliza si la nivel de mai multe masini, adica aceleasi doua programe pot exista pe masini diferite, unul server iar celalalt client, metoda de comunica fiind socketii.
Un exemplu foarte la indemana este un client (un browser Firefox) si un server ruland Apache, comunicand la nivel HTTP, dar de multe ori se doreste ca serverul sa faca lucruri ceva mai complicate decat sa trimita clientului o pagina html, cum ar fi sa execute niste calcule foarte complexe si sa transmita rezultatul clientului. Acest lucru s-ar putea face in nenumarate feluri. O modalitate ar fi sa copii (scp) un script care face calculele, sa te conectezi apoi pe server si sa executi scriptul (ssh), apoi sa preiei rezultatele, dar aceasta metoda este destul de obositoare, mai ales cand trebuie sa repeti operatiunea. Web Services vin in ajutorul nostru, facand toate aceste lucruri intr-un mod unitar, generic si standardizat, toate pe baza paradigmei client-server.

Cum functioneaza un web service

Diagrama :

  +--------------------------------------+

  |         web service registry         |

  |         (aka service broker)         |

  |                (UDDI)                |

  +--------------------------------------+

         ^                        ^

         |                        |

     (2) |                    (1) |

         |  (the client           |  (the web service

       WSDL  finds the          WSDL  provider publishes

         |   service              |   the web service)

         |   they want)           |

         |                        |

         v                        |

   +-----------+            +-----------+

   | service   |<---SOAP--->|  service  |

   | requestor |            |  provider |

   +-----------+     (3)    +-----------+

WSDL -- Web Services description Language - descrie prin XML ce face un web service
UDDI -- Universal Description, Discovery and Integration protocol - protocolul care publica wsdl-urile
SOAP -- protocol de transport mesaje XML folosind HTTP (peste TCP, folosind portul 80)

Pasul 1 e folosit doar cand se doreste publicarea pe web a web service-ului, iar pasul 2 cand clientul nu stie ce anume/de unde sa sa foloseasa de la un web service.
Ca sa descrii ce anume face web service-ul tau, ar trebui facut un fisier WSDL cu XML, dar acest lucru nu mai este necesar cand folosesti Axis, acesta creeza automat fisierul pentru tine, pe baza codului java.

Ce este Apache Axis

Axis este o implementare a protocolului SOAP, care ne scuteste de munca cu SOAP si WSDL. Este folosit atat pe partea de server pentru a scrie web service-ul (aplicatie web deployata pe un server de aplicatii gen Tomcat) cat si pe partea de client, pentru a face apeluri de metode ale instantei de web service catre server.

In continuare vom scrie o mini-aplicatie demonstrativa client-server in Axis. Serverul va executa cateva operatii matematice simple gen adunari/scaderi pe baza unor parametri transmisi de client, returnandu-i clientului rezultatul pentru metodele invocate.
De ce avem nevoie ?
De Axis si de un server de aplicatii Tomcat. Axis se poate downloada de la http://people.apache.org/dist/axis/nightly/axis-bin-1_4.zip
Instalarea acestuia e foarte simpla. Se dezarhiveaza si se copie tot folderul webapps/axis in folderul webapps din Tomcat. Daca nu apar probleme, un apel catre http://localhost:8080/axis/ ar trebui sa incarce pagina cu Apache-AXIS.
Tot din folderul dezarhivat de Axis (in lib), pentru scrierea clientului, sunt necesare cateva biblioteci (jar-uri) . Eu am folosit doar axis.jar, commons-discovery-0.2.jar, commons-logging-1.0.4.jar, jaxrpc.jar si wsdl4j-1.5.1.jar.

Serverul arata cam asa:

public class Server {

public String echo(String str) {
return str;
}

public int add(int a, int b) {
return a+b;
}

public int substract(int a, int b) {
return a-b;
}
}




Acesta e initial un fisier Server.java care il copiem in directorul webapps/axis din Tomcat, schimbandui extensia din .java in .jws, deci vom avea webapps/axis/Server.jws

Iar clientul arata astfel:

import org.apache.axis.client.Call;
import org.apache.axis.client.Service;
import org.apache.axis.encoding.XMLType;

import javax.xml.rpc.ParameterMode;

public class Client {
public static void main(String [] args) throws Exception {
String endpoint = "http://localhost:8080/axis/Server.jws";

String str = "echo string";
Integer a = new Integer(2);
Integer b = new Integer(7);

Service service = new Service();
Call call = (Call) service.createCall();

call.setTargetEndpointAddress(new java.net.URL(endpoint));

String method = "echo";
call.setOperationName(method);
call.addParameter("unstring", XMLType.XSD_STRING, ParameterMode.IN);
call.setReturnType(XMLType.XSD_STRING);
String retstr = (String) call.invoke(new Object [] {str});
System.out.println("am trimis " + str + ", am primit " + retstr);

call.clearOperation();

method = "add";
call.setOperationName(method);
call.addParameter("unint", XMLType.XSD_INT, ParameterMode.IN);
call.addParameter("altint", XMLType.XSD_INT, ParameterMode.IN);
call.setReturnType(XMLType.XSD_INT);
Integer retint = (Integer) call.invoke(new Object [] {a, b});
System.out.println("am trimis " + a + " + " + b + ", am primit " + retint);

call.clearOperation();

method = "substract";
call.setOperationName(method);
call.addParameter("unint", XMLType.XSD_INT, ParameterMode.IN);
call.addParameter("altint", XMLType.XSD_INT, ParameterMode.IN);
call.setReturnType(XMLType.XSD_INT);
retint = (Integer) call.invoke(new Object [] {a, b});
System.out.println("am trimis " + a + " - " + b + ", am primit " + retint);
}
}





Ideea pe care s-a construit clientul e ca s-a pornit de la crearea a doua obiecte, un Service si un Call bazat pe Service. Aceste doua obiecte retin metadata despre web service. Apoi s-a setat endpointul pentru call (URL destinatie pentru mesajul SOAP), s-a setat operatia care se doreste apelata pe server, tipul parametrilor pentru operatie si se invoca operatia cu parametru un vector de obiecte ce reprezinta parametrii metodei invocate, iar ce anume returneaza metoda invoke pe call reprezinta chiar rezultatul operatiei apelate pe server.