webservicekald via soap

det var så ikke meningen at koden skulle have været lavet om til aktive URL's.......

//finger

Det er bestemt ikke slam, men henvisninger til de skemaer der definerer hvordan "rigtige" SOAP kald ser ud. Du kan i teorien godt lave din egen SOAP header, men så skal du også lave de klasser i ASP.NET om der sender og modtager SOAP så det tror jeg bestemt ikke kan betale sig. Desuden kan din webservice så kun bruges af dig da den så ikke overholder standarden!

lidt ala det her ?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/html/service06182002.asp

Når det alligvel er 2 .Net programmer der kommunikerer så kan du jo evt. anvende remoting med tcp/ip som channel. I så fald vil du kunne bruge en binær protokol og derved få mindre pakker hvis du er bekymret for netværks performance. Læs om remoting her http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconnetremotingoverview.asp

I øvrigt som en lille detalje, så er det ikke i din SOAP header at det såkaldte slam ligger, men derimod i din SOAP envelope, men det ændrer nu ikke så meget på at det ikke er slam, men derimod nødvendig information om de skemaer der definerer SOAP!

hmmmm.
ved godt det ikke er "slam". det er da bare noget skidt at det skal fylde så meget og ligge i hver enkelt pakke med SOAP. spiller ikke maks.
p.s. skal desværre være en webservice. ellers tak for linket.

tak for det cyberprofessor. det var lige det jeg skulle bruge. vil du have point?

Af ren nysgerrighed kan du så ikke lige forklare hvordan cyberfessors link kan hjælpe dig til at blive fri for henvisninger til SOAP skemaerne. Så vidt jeg kan se handler artiklen udelukkende om SOAP headers og ikke om SOAP envelopes og fortæller intet om hvorledes du kan ændre standarden!

finger>> hvilket.. mit eller z42cool's eller mit link?...

nu ikke så fjendtlig.

Det var vist også lige lidt for hurtigt jeg fik kigget på den artikel.

forstår stadig ikke helt den envolope. Hvorfor skal de links med i SOAP envolope. så vidt jeg kan se er det jo bare en hanvisning til hvor man kan læse om xml-skemaer og soap-envolopes. Men det fortolker webservicen måske? eller hvad?
Og jeg kan ikke slippe for den uden at gå uden om standard? og hvordan går jeg uden om den hvis det er det jeg vil, nu når jeg _skal_ lave en webservice?

hvad så med http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconusingsoapheaders.asp ??

cyberfessor>> Dine links drejer sig desværre (så vidt jeg lige kan se) kun om hvordan man sender information med i SOAP kaldet vha. SOAP headers og ikke om hvorledes SOAP infrastrukturen ændres.

finger>> En SOAP request er i sin mest basale form et xml dokument. Måden man angiver regler for et xml dokument er vha. xml skemaer. Uden skemaer ville det eneste krav til et xml dokument være at det skulle være velformet. Da dette langt fra er nok til at sikre sig at der er tale om et "lovligt" SOAP xml dokument anvender man skemaer til yderligere at refinere syntaksen. Ydermere så er man nødt til at have en mekanisme til at undgår name clashes. Foretsil dig at du har bestemt dig for at udstille en metode der returnerer noget xml vha. en webservice. Din metodes xml indeholder bla. en <element> tag, da SOAP også anvender <element> tags får vi et problem, for hvilke specificerer SOAP delen og hvilke er din custom xml. Dette løses vha. af namespaces. Med baggrund i et skema defineres et namespace der vha. et prefix fortæller parseren hvilket skema en given tag hører til, således at SOAPs element tag bliver til <soap:element>. Denne binding skal naturligvis defineres et eller andet sted og det er præcist hvad xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" gør.
Du kan kun komme uden om disse henvisninger ved at lave din egen web service infrasturktur, men så ændrer du standarden og så er det ikke længere SOAP og så er du den eneste der kan bruge det og så kan du ligeså godt anvende en binær rotokol du selv definerer, DCOM, RPC eller noget helt 5.
I øvrigt har jeg svært ved at forestille mig et transport medie hvor 123 bytes kan have nogen reel betydning for performance.

tak for den lange forklaring! :)

Så må jeg nok hellere beholde de linier.

angående de bytes. det er fordi jeg skriver en større applikation til mange samtidige brugre over een isdn forbindelse. derfor vil jeg gerne spare hvor jeg kan.

tak for hjælpen.