---

Hejsa,

Jeg ved godt den her er lige på kanten af, hvad denne gruppes fundas er.
Men jeg går ud fra, at der er mange af jer, der arbejder med SOAP:RPC i
det daglige. Derfor er der sikkert mulighed for at få noget kvalificeret
input.

Jeg sidder med en problematik, hvor en platforms WS implementering
understøtter metode operator overloading og en anden (client) ikke.
Begge implememterede i java sdk1.4.x. Eks:

Med Operator overloading:
SomeWebService.getSomeInfo(int foo);
SomeWebService.getSomeInfo(int foo, int bar);

Uden operator overloading:
SomeWebService.getSomeInfo(int foo);
SomeWebService.getSomeInfoDetailed(int foo,int bar);

Fordi clienten ikke kan fatte at styre metode kaldet ud fra parametrene,
men kun ud fra navnet på metoden i sig selv.

Jeg har så forsøgt, at finde ud af, hvad w3c folkets holdning er til
brug af operator overloading, men har ikke rigtigt kunnet finde et sted,
hvor de virkelig tager stilling til det. Det nærmeste jeg er kommet er:

http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#RPCWebArguments

Min holdning er, at det i de fleste OO sprog er nærmest uunværligt at
have den funktionalitet som er nævnt i første eksempel. Selvfølgelig kan
jeg også se de issues, der må opstå ved brug af metoden i ikke
objektorienterede sprog. Der er man nødt til at indføre noget method
name mangling, der kan beskrive forskellen.

Hvad er jeres holdning, og har i set nogen tage nærmere stilling til
problematiken, end i det link jeg har sendt med her.

mvh

Nikolaj Hansen

---

Nikolaj Hansen wrote:

> Hvad er jeres holdning, og har i set nogen tage nærmere stilling til
> problematiken, end i det link jeg har sendt med her.

Tjo, - en (praktisk) holdning kan du godt få: Lad være med at basere
din programmering på noget, som du ikke er garanteret understøttelse af
på alle platforme.

M.v.h.

Jonathan

--
Er din e-mail vigtig? Er du træt af virus og spam i mailen?
Virus-scanning og spam-filtrering på alle mail-konti. På redundant
mail-setup med daglig backup.
http://www.jsp-hotel.dk/

---

Jonathan Stein wrote:
> Tjo, - en (praktisk) holdning kan du godt få: Lad være med at basere
> din programmering på noget, som du ikke er garanteret understøttelse af
> på alle platforme.
>

Tjae, det er så den mindste fællesnævner - det udelukker totalt java i
hver fald

mvh

Nikolaj Hansen

---

Nikolaj Hansen wrote:

>> Tjo, - en (praktisk) holdning kan du godt få: Lad være med at basere
>> din programmering på noget, som du ikke er garanteret understøttelse
>> af på alle platforme.
>
> Tjae, det er så den mindste fællesnævner - det udelukker totalt java i
> hver fald

Tja, hvis ikke Java er multi-platform nok, får du vist svært ved at
finde noget, der kan opfylde dine krav...

M.v.h.

Jonathan

--
Er din e-mail vigtig? Er du træt af virus og spam i mailen?
Virus-scanning og spam-filtrering på alle mail-konti. På redundant
mail-setup med daglig backup.
http://www.jsp-hotel.dk/

---

Jonathan Stein wrote:
> Tja, hvis ikke Java er multi-platform nok, får du vist svært ved at
> finde noget, der kan opfylde dine krav...

Det var mere din kommetar jeg hentyder til:

" Tjo, - en (praktisk) holdning kan du godt få: Lad være med at basere
din programmering på noget, som du ikke er garanteret understøttelse af
på alle platforme."

Det udelukker java. Både i ren form, men specielt med webservices i spil.

Desuden "programmerer" man ikke webservice client stubs, som er emnet
her, de genereres ud fra webservicens WSDL service descriptor. Og det er
netop med en dårlig generator fra en leverandør, jeg ikke vil sætte navn
på, jeg har problemet.

mvh

Nikolaj Hansen

---

Nikolaj Hansen wrote:

>> Tja, hvis ikke Java er multi-platform nok, får du vist svært ved at
>> finde noget, der kan opfylde dine krav...
>
> Det var mere din kommetar jeg hentyder til:
>
> " Tjo, - en (praktisk) holdning kan du godt få: Lad være med at basere
> din programmering på noget, som du ikke er garanteret understøttelse af
> på alle platforme."
>
> Det udelukker java. Både i ren form, men specielt med webservices i spil.

Ja, men hvis ikke Java er multi-platform nok... Nej, nu kører vi vist i
ring.

> Desuden "programmerer" man ikke webservice client stubs, som er emnet
> her, de genereres ud fra webservicens WSDL service descriptor.

Hvis du ikke laver andet end client stubs, kan vi da godt kalde det
generering, - ellers vil jeg nu mene, at det stadig er en del af
programmeringen.

Jeg mener også, man kan kalde sig programmør, selv om man bruger et
design-værktøj til at lave brugergrænsefladen.

Principielt er det selvfølgelig noget, man bør tage stilling til inden
man begynder programmeringen (genereringen ), men på den anden side,
står man jo med et problem, der må løses, hvis det ikke er afgjort
tidligere.

M.v.h.

Jonathan

--
Er din e-mail vigtig? Er du træt af virus og spam i mailen?
Virus-scanning og spam-filtrering på alle mail-konti. På redundant
mail-setup med daglig backup.
http://www.jsp-hotel.dk/

---

Jonathan Stein wrote:

> Ja, men hvis ikke Java er multi-platform nok... Nej, nu kører vi vist i
> ring.
>

Ja, det er lige ved. Dog findes java langt fra til alle platforme. Jeg
kan godt lide at holde mig til Suns jdk implementation, og den findes
eks. ikke til FreeBSD, hvor man selv ryger ud i at skulle patche og
compile hele skidtet fra scratch.

Noget der virkeligt ville ændre sig, hvis de tog sig sammen og frigav
under OSS licens af en eller anden art.

Hvis man blander RMI/IIOP kald fra en VM til en anden (IBM<->SUN eks.)
kan man ryge ud i en masse bøvl med serializering / deserializering og
exceptions i forbindelse hermed. Jeg er godt klar over, at problemet er
mindre med web services.

mvh

Nikolaj Hansen