.NET webservice client med Java applet?

dvs. udføre webservices via en hjemmeside ?
(PS : webservices er ikke en specifik .NET ting - WS har været i brug ifm Java/J2EE i lang tid :-)

Jep, ved at Apache, SUN, IBM og nok mange andre har deres versioner...
Men jeg er mest interesseret i at det skal virke med ASP.NET webservices og blive genereret ud fra WSDL-dokumenter, som kan genereres for disse services.

Og ja, idéen er faktisk at lave noget som Microsofts Remote Scripting, bare med ASP.NET og i alle browsere, der kan få Java-plugin.

MS har jo et værktøj til at generere sådanne proxy classes, men desværre ikke i Java (den kan generere VB, C# og JScript). Det hedder, sjovt nok, WSDL.EXE

Det er sådan noget, jeg søger, bare til Java.

ideen lyder da tiltalende ... og er da igang med at lave et lille eksempel As We Speak :-)

WSDL-dokumenter bliver der lavet i alle tilfælde med webservices - ikke kun ASP.NET --- Faktisk er det hverken Microsoft, apache, sun eller IBM, som sætter dagsordnen for SOAP og WSDL --- Det er W3c (som de alle er medlem af alligevel) .... WSDL er en standard,  på samme fod som HTML -- der er ingen af de ovenstående firmaer som har den "rigtigste" version af Webservices :-)

mangler du programmer til at "eksponere" en java-klasses metoder i form af et  WSDL-dokument  ???

Jamen  det kan de fleste af WDSL-pakkerne allerede .... f.eks. har jeg haft stor glæde af WASP (http://www.systinet.com) - den er nem at gå til - kan analysere en java-fil for at lave et WSDL dokument osv :-)

Klart, men med min erfaring med MS så er der altid en eller anden lille forskel... ved ikke om den også er at finde her, derfor siger jeg ASP.NET

jeg tror ikke at MS har nogen særlig interesse i at netop webservices definitionen bliver "provider" afhængig... Hvis den gør det (og MS.NET systemer ikke kan kommunikere med f.eks. en SUN deployed Webservice) så falder hele ideen til jorden, med hensyn til web-services ... WS er netop lavet så generisk at systemer kan inter-kommunikere uden at være afhængig af provider/implementator...

Hvis MS begynder at lave et eller andet fifleri med WS og det resulterer i at der er webservices, som lige pludselig ikke virker, så er det MS der får problemet, for det er ikke dem, som definerer WSDL - det gør W3C (http://www.w3.org/TR/wsdl.html) :-)

Nej, omvendt, jeg mangler noget, der kan lave en WSDL-fil om til en Java applet class

de fleste Web Services -servere til Java har et tool med (f.eks. WSDL2java) som kan lave en java-template ud fra en WDSL fil..

Systinets WASP server har et tool som hedder WSDL2Java - nedenstående er rippet fra deres hjemmeside :
WSDL2Java - generates the client stubs/proxies, server-side skeletons, and exceptions from the WSDL document.

Systinet har selvfølgelig også WASP i en version til C++ :-)

Ja, men kan det bruges i en applet, der skal køre i hvilken som helst browser med alm. Java-plugin? Uden sysinets særlige .jar filer?

Kort sagt kommer du nok til at skulle bundle x antal klasser med din applet, for at den kan forstå (og kommunikere) via webservices (alt taget i betragtning, så ville det være ret overkill selv at skulle parse XML'en i WSDL filen)

Disse klasser behøver dog ikke at være Systinets egne - De kan ligesågodt komme fra f.eks. javas egen Java Web Services Developer Pack (Java WSDP)

Men selv en ActiveX control vil under .NET også være afhængig af eksterne komponenter (f.esk. MSXML komponenten)

Ja, og denne afhængighed vil jeg ikke have. Hvis det er de klasser, der er en del af Java 2 platformen, så er det fint nok.

Hvis du går efter at lave en applet, som kan forstå webservices, uden at bundle et eller anden package til at parse XML'en etc. så har du lidt af et problem - det er muligt - men det indvolverer at du skal skrive en XML-parser selv (plus funktionalitet til at håndtere indformationerne fra WSDL og SOAP)...
At skulle kode det selv, når der allerede ligger pakker parate...

XML parsing (og klasser til at håndtere WSDL) er standard i Java 2 Enterprise Edition (J2EE) men ikke i standard-udgaven af Java 2 (J2SE)...
Det er dog muligt at hente en komponent som gør ovenstående muligt - den hedder "Java XML Pack" og indeholder bl.a. Java WSDP...

1)  WSDL og SOAP er W3C standarder som alle derfor følger.

    Det er imidlertid ikke det samme som at alle web services
    virker på tværs af sprog.

    Et af problemerne er data type binding. Hvis web service
    udbyderen bruger en data type som web service clienten ikke
    understøtter, så kan de ikke snakke sammen.

2)  Axis fra Apache:
      - er gratis for enhver brug
      - kan bruges både til at lave web services og web service klienter
      - er rimeligt anerkendt (f.eks. kommer JBuilder8 med Axis)

3)  Når man genererer web service client stubs med web service tool,
    så skal de stubs distribueres sammen med client programmet (stubs
    fra forskellige tools er ikke kompatible).

4)  Jeg menere sagtesn at man kan distribuere sin applet i en
    jar fil med alle de klasser der behøves.

5)  XML parsere er ikke med i J2SE 1.3.x men de er med i J2SE 1.4.x !

Kan du lave noget eksempel-kode?
Her er en af MS samples, du kan få WSDL-kode fra: http://zhat.dk/test/mathservice.asmx

Jeg prøver lige.

package test;

import org.tempuri.*;
import java.rmi.*;
import javax.xml.rpc.*;

public class MathServiceTest {
    public static void main(String[] args) {
        try {
            MathServiceLocator msl = new MathServiceLocator();
            MathServiceSoap mss = msl.getMathServiceSoap();
            System.out.println(mss.add((float)1.2, (float)3.4));
        } catch (RemoteException ex) {
            ex.printStackTrace();
        } catch (ServiceException ex) {
            ex.printStackTrace();
        }
    }
}

er den kode jeg skrev.

Og så genererede Axis 4 filer i org.tempuri pakken.

Det virker dog ikke - jeg får:

java.net.NoRouteToHostException: No route to host: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)

men jeg er på arbejde og jeg tror at det er firmaets firewall
som blokerer.

Jeg kan prøve igen, når jeg kommer hjem.

Hej.

Det lykkedes mig at sætte et par system properties, så programmet kunne
finde proxy-serveren der kan gå igennem firewallen.

Resultat:
4.6000004

hvilket er rigtigt (float skal kun være rigtigt på de første 7 decimale
cifre).

Så det virker !

Lyder rigtigt fedt. Kan du fortælle mig hvordan du kaldte det dér værktøj, og hvilke classpaths der skal sættes?

Forresten... Har downloaded axis 1.1 rc1, er det den, der er den nyeste?

Axis kan downloades og kaldes manuelt. Så skal du bare
selv bøvle med classpath og al den slags.

Jeg "snød" og brugte JBuilder med "Web Service Kit for Java 3"
(hvilket er et Axis kit bare med en wizard til JBuilder ovenpå !).

Så er det bare:
  new
  web services
  import WSDL
  angive URL eller stil tiL WSDL filen
og klikke next et par gange, så har man koden genereret.

Ifølge http://ws.apache.org/axis/index.html så er 1.1RC1 nyeste.

(du ved godt at RC1 = beta ikke ?)

Jo, men koden, den genererer, burde virke fint nok.

Yes.

Kan sgu ikke få lortet til at virke... får hele tiden
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/discovery/tools/DiscoverSingleton

Selvom jeg kalder java med en classpath, der indeholder samtlige af .jar-filerne i axis\lib

Hm.

Den bør ligge i commons-discovery.jar !

Jeg har fået det til at virke... den kræver åbenbart også en pakke, der hedder xerces.
Har fået nok af det apache-crap, fandt ud af at det er nemmere og hurtigere at lave min egen løsning, der ikke bruger WSDL.

Groft beskrevet: Lave en Applet, der kan requeste et URL og bruge den til at sende paramatre via querystring og hente svaret som tekst.

Denne tekst kan så evt. evalueres af JavaScript som kode eller data.


Utroligt at de forskellige webservice-teknologier ikke har taget højde for at en webservice rent faktisk kunne bruges med en browser som klient... DOH!

Problemet med Apache's dimser er at de ikke nøjes med standard Java-API, men kræver deres egne klassebiblioteker, der fylder flere MB - ikke ligefrem brugbart i en Applet.

Xerces er en XML parser. Apaches XML parser. Baseret på XML4J fra IBM.

Jeg tror at det gælder de fleste Web Service teknologier, at de
kræver en del "stumper".

Og din løsning med bare at sende en simpel HTTP request er
uden tvivl både simplere og hurtigere i browser sammenhæng.

Men Web Services er ikke designet til thin client (browser) miljø, mere
til fat client miljø og ikke mindst server til server kommnukikation.