Mi újság a webszolgáltatásokkal?
2003-08-11T16:33:32+02:00
2003-08-12T15:54:48+02:00
2022-06-29T09:25:21+02:00
  • Azért XML-RPC alapokon is működhet webszolgáltatás, mégpedig elég biztonságosan és átláthatóan. A különbség az, hogy a WSDL oldali képesség ez esetben hiányzik.
    Mutasd a teljes hozzászólást!
  • Akkor igy csokorba szedve:

    - Inkompatibilitas tema 1: keszits el egy CORBA-s szerver alkalmazast C++-ban, mondjuk az OmniORB-ra epitve, es probald osszekotni egy ACE/TAO-s klienssel.

    - Inkompatibilitas 2: keszits el egy CORBA-s szerver alkalmazast C++-ban, aztan probalj atterni masik CORBA kornyezetre. Hany helyen kell valtoztatni a kodon?

    - Binaris adatok atvitele: na ez tenyleg szopas, a BASE64 megoldas minimum undorito. Mi ezt sima HTTP multipart POST-tal oldottuk meg, ez volt a leggyorsabb. Irtam hozza egy kis (15 sor) wrappert, ezt hasznalva pont ugy nez ki, mintha xml-rpc hivas volna.

    - Eroforras-zabalas: ezalatt nem tudom pontosan mit ertetek, de nem hiszem, hogy egy 'atlagos' hivas jelentosen tobb CPU-t vagy halozatot enne mint egy CORBA vagy RMI. A generalt halozati forgalmat mondjuk egyszeruen ossze lehet hasonlitani, ha valakinek van kedve csinalhatunk tesztet.

    - https: megy https-en, mi csak ezen keresztul hasznaljuk

    - Bonyolultsag: Pythonban egy komplett xml-rpc hivas-t hasznalo program igy nez ki:

    import xmlrpc srv = xmlrpc.ServerProxy("http://szerverneve.hu/szolgaltatas") result = srv.fuggvenyhivas(param1, param2)

    Ez itt egy komplett, mukodo program. Valaki berakhatna a CORBA/RMI megfelelot.

    Mielott valaki felreertene, ez nem egy mindenhato eszkoz, de az adott celnak tokeletesen megfelel.

    netchan
    Mutasd a teljes hozzászólást!
  • Szia Adam,

    Te be tudsz szamolni komoly inkompatibilitasokrol?


    hat, ha benn jarsz valamikor az iq-ban, akkor kerdezd meg Lovas Jancsit, vagy Horvath Attilat, vagy Gyaraki Gyurit vagy akar Dirner Andort. Majd ok meselnek :)
    Mutasd a teljes hozzászólást!
  • hasznaljanak proxy-t a 80-as porton. ott meg korlatozzak a header-ek alapjan :)

    kiszorod a SOAP headereket es maris nem muxik :)
    Mutasd a teljes hozzászólást!
  • Én ez az alábbi módon oldom meg:


    Ja, én nem erre gondoltam, hanem arra az esetre, amikor az user el akarják tiltani valami elől általában. De mindegy is, célURL limitáció a legtöbb proxyn van azért.
    Mutasd a teljes hozzászólást!
  • Ehhez kepest ugy reklamozzak a webserviceket, mintha valami forradalmi ujdonsag lenne, ami alapjaiban valtoztatja meg a vilagot.


    Mint mindent, amit el akarnak terjeszteni :(

    Te be tudsz szamolni komoly inkompatibilitasokrol?


    Én ugyan nem dolgoztam CORBA-val, de gondolhatod, ha még az én fülembe is eljutott, milyen legendás az inkompatibilitás :) [mondjuk ugyanezt hallottam a SOAP-ról is, de nincs elsőkézből származó információm].

    Péter
    Mutasd a teljes hozzászólást!
  • Hohó! Lehet h ez nemigazán ide tartozik, de nekem 1.800 Ft / hóért van ASP, ASP.NET, PHP, HTML, JavaScript, Java és Cold Fusion támogatás programozási nyelvek közül, adatbázisok: mySQL, Acces


    Ez állat, hol van ilyen?
    Mutasd a teljes hozzászólást!
  • >Azert mert nem mindenki hasznal Javat.
    Kar, az JRMI kommunikacio nem olyan eroforras zabalo mint az XML rpc.
    Ezek szerint az XML rpc egy eroforrasigenyes, viszont 'uberkompatibilis' dolog, aminel mindig talalni hatekonyabb megoldast. Ehhez kepest ugy reklamozzak a webserviceket, mintha valami forradalmi ujdonsag lenne, ami alapjaiban valtoztatja meg a vilagot.

    >Hasznaltal Te mar CORBA-t vegyes >kornyezetben
    Hasznaltam CORBA-t, ami tortenetesen vegyes kornyezetekben levo objektumok kommunikaciojara lett kitalalva. Sajnos en minden oldalon C++-t hasznaltam, tehat nem teszteltem sok kombinaciot. Te be tudsz szamolni komoly inkompatibilitasokrol?
    Mutasd a teljes hozzászólást!
  • Amúgy van valakinek néhány hasznos linkje
    WebService példákkal Delphi-re?

    Részemről úgy érzem, van még itt néhány szürke rész a tudásomból :)


    Én is bedobok egyet:
    www.matlus.com

    Van néhány tutorial WebService-re és ISAPI-ra is. (fájlfeltöltés, 3D-s grafikon dinamikusan, server-push, stb...)
    Mutasd a teljes hozzászólást!
  • Én ez az alábbi módon oldom meg:

    - A szolgáltatás (mivel ez zárt szoftverrendszer) nem publikus.

    - WSDL fájlokat csak fejlesztési időben lehet lekérni, éles üzemben az összes ilyen admin tevékenység tiltva van. Ilyenkor nincs rájuk szükség, és jobb, ha nem látják a formátumot :)

    - Minden kérés session alapú bejelentkezéssel van ellátva. Az elején kell a szolgáltatáshoz sessionid-t kérni, utána ezt mindig el kell küldeni. Ha ez hibás, akkor egy RemoteException keletkezik, gyakorlatilag Access Denied...

    - Az elérését nem tűzfallal kell limitálni, hanem dedikált szerverre szokás tenni az ilyeneket és ott kell egyébb hitelesítést alkalmazni.


    Amúgy állítólag minden probléma nélkül megy a dolog https-en keresztül. Én még nem próbáltam ezt.
    Mutasd a teljes hozzászólást!
  • - Ami nálunk tényleg komoly szempont volt: ne akadályozzák a tűzfalak. Nos mivel ez az egész standard HTTP POST-nak felel meg a 80-as porton, így nincs is vele gond.


    A rendszergazdák meg téphetik a hajukat, ha web service elérést akarnak limitálni egy egyszerűbb tűzfallal.

    Mindennek megvan a saját hátránya :(

    Péter
    Mutasd a teljes hozzászólást!
  • Mi masszivan xml-rpc-t hasznalunk a teljes kliens-szerver kommunikaciora, ennel egyszerubb es nyitottabb megoldast nem tudnek mondani.


    Legutóbb úgy másfél éve nézegettem az XML-RPC-t, valóban egyszerű, de: akkor még nem volt hozzá olyan specifikáció, mint a SOAP w/attachments (bináris adat átvitele mime/multipart (vagy mime/alternative? mindegy) üzenetként), ami nagyban szűkítette az alkalmazási területet.

    Rendben, hálón ne vigyen át az ember nagyméretű adatot, de sajnos az XML DOM-ok hajlamosak már relative kis méretű CDATA/BASE64 encoded string esetén is brutális erőforrászabálásra mind a processzort, mind a memóriát illetőleg. A SAX használatát (nem a Javás SAX-ra gondolok) pedig ritkán támogatja az XML-RPC implementáció.

    Igy kötöttünk ki egy saját MIME/XML megoldásnál, úgysem kommunikál senki sem az alkalmazásszerverünkkel.

    Péter
    Mutasd a teljes hozzászólást!
  • Öndokumentálásra leginkább a WSDL/UDDI párost értettem.

    Persze ez nem velódi dokumentáció, de azért több a semminél.
    Mutasd a teljes hozzászólást!
  • Teljesen egyetértek bhuberttel. Az öndokumentáció persze csak adott eszközöknél igaz, így a Delphi-nél. Webszolgáltatások írása ma már teljesen automatizált, elképesztő sok fejlesztőeszköz támogatja azokat. Ha viszont jobban meg akarjuk érteni, hogy mi történik a háttérben, érdemes a SOAP/UDDI/WSDL trió szerepét megérteni és kézzel egyszerű szolgáltatást és klienst készíteni egy editorban.
    Mutasd a teljes hozzászólást!
  • Az XML egy nagyon rossz, és nagyon ineffektív megoldás gépek (programok) közötti kommunikációra, amelynek előnyei (pl. hogy tűzfalon úgymond könnyű átjuttatni - persze ezt is csak a menedzseragyúak találták ki, mert technikai szempontból nyilvánvalóan ugyanannyira könnyű bármilyen más kommunikációt is átengedni azokon)


    A webservicek számára a legtöbb tűzfal tényleg nem akadály, de nem az xml miatt hanem mert HTTP-ben 80-as porton utazik MINDEN.
    Mutasd a teljes hozzászólást!
  • Az;rt nem olyan rossz dolog ez az XML és a WebService.


    - Ami nálunk tényleg komoly szempont volt: ne akadályozzák a tűzfalak. Nos mivel ez az egész standard HTTP POST-nak felel meg a 80-as porton, így nincs is vele gond.


    - Valóban nem a legerőforrásbarátabb dolog az XML, de a mai gépsebességek mellett nincs igazából vele probléma feldolgozás szempontjából. Az átvitt adat mennyisége valóban lényegesen nagyobb, de ezt a technikát nem arra találták ki, hogy több megás adatbázisokat kérjél le a túloldalról... (amúgy létezik totál XML alapú "SQL SERVER", XML-ben tárol mindent, és kis alkalmazásokhoz fejlesztették ki, én teszteltem, meglepően gyors volt!)

    Tehát pici adatcsomagok mennek és ezek még interneten modemmel is elfogadható sebességet adnak.


    - Nagyon komoly érv a szabványosság. A lényeg, hogy deklarálok szerver-oldalon egy osztály TRemotable-nek, és ez minden gond nélkül átmegy a webszerveren és egy teljesen más OS alól is ugyanennek olvasható.

    - Nem csak szimpla adattípusok mennek át, hanem osztályok, kivételek is... Tehát nagyon jól használható.


    - És az egész öndokumentáló. Bár én ezt a részét le szoktam tiltani biztonsági okokból.



    Az itthoni elterjedésének legnagyobb problémáját én nem a technikában, hanem az emberek fejében látom...

    Mutasd a teljes hozzászólást!
  • Hulyen fogalmaztam. Nyiltsag alatt reszben azt ertem, amit mondtal, reszben meg azt, hogy ez az adott kommunikacios forma minel tobb platformon elerheto legyen, azaz ne csak elmeletben, hanem a gyakorlatban is tenyleg akarmilyen kornyezetbol egyszeruen hasznalhato feluletet biztositsunk.
    A mostani megoldasunknal csak annyit kell tudnia valakinek, hogy mi a szerver http cime, a fuggveny neve, es a parameterei. Jelenleg egy Python alkalmazas, egy masik programba 'beepulo' COM szerverek, Servlet-ek (Tomcat), egy applet es ket Flash program kommunikal a szerver oldallal xml-rpc keresztul.

    netchan
    Mutasd a teljes hozzászólást!
  • Az RMI miert ne lenne platformfuggetlen?


    Azert mert nem mindenki hasznal Javat.

    CORBA raadasul nyelvfuggetlen.


    Hasznaltal Te mar CORBA-t vegyes kornyezetben ahol kulonbozo oprendszerek, nyelvek, stb. vannak? A kulonbozo CORBA implenetcaiok (in)kompatibiltasa is erdekes tema. xml-rpc-nel eleve nincs ilyen gond.

    netchan
    Mutasd a teljes hozzászólást!
  • Hohó! Lehet h ez nemigazán ide tartozik, de nekem 1.800 Ft / hóért van ASP, ASP.NET, PHP, HTML, JavaScript, Java és Cold Fusion támogatás programozási nyelvek közül, adatbázisok: mySQL, Acces
    Mutasd a teljes hozzászólást!
  • Na, de nem az XML-től, meg a webszolgáltatástól (mint technikai elemtől) lesz nyílt egy kommunikációs megoldás, hanem az egységes és mindenki számára hozzáférhető adatcsereformátumtól.

    Az XML egy nagyon rossz, és nagyon ineffektív megoldás gépek (programok) közötti kommunikációra, amelynek előnyei (pl. hogy tűzfalon úgymond könnyű átjuttatni - persze ezt is csak a menedzseragyúak találták ki, mert technikai szempontból nyilvánvalóan ugyanannyira könnyű bármilyen más kommunikációt is átengedni azokon) eltörpülnek hátrányai mellett (pl. az iszonyatos overheadek a konverziók és az átvitel során).
    Mutasd a teljes hozzászólást!
  • Az RMI miert ne lenne platformfuggetlen?
    Keves olyan oprendszert ismerek, amin nem lehetne Javat futtatni.
    Es miert ne lenne egyszeruen hasznalhato?
    Szamomra a vilag legegyszerubb dolga, hogy meghivsz egy fuggvenyt, ami veletlenul egy masik gepen fut le, es akar meg nem is tudsz rola.
    Ha a Java a gond, a CORBA raadasul nyelvfuggetlen.
    Mutasd a teljes hozzászólást!
  • Tehat pl. en CORBA-n vagy RMI-n keresztul kommunikalhatok, nem erdekes, hogy a fizikai forma szamomra olvashato legyen.


    Az viszont erdekes, hogy a megoldas egyszeruen hasznalhato, platformfiggetlen legyen. Az xml alapu dolgokkal ellentetben a CORBA, RMI nagyon nem ilyen.

    Mi masszivan xml-rpc-t hasznalunk a teljes kliens-szerver kommunikaciora, ennel egyszerubb es nyitottabb megoldast nem tudnek mondani.

    netchan
    Mutasd a teljes hozzászólást!
  • Pl. RMI (Java Remote Interface) mar van regen. CORBA meg regebben. Remote Procedure Call meg annal is regebben.
    Ezekkel tok kenyelmesen meg lehet csinalni azt, hogy te felajanlassz egy interface-t, amit mas programok hasznalhatnak. Ahol ezt hasznalni akartak, ott hasznaljak, ahol nem volt ra kereslet, vagy uzleti igeny/igenyesseg, ott nem.
    Azzal, hogy most XML-t hasznalunk, illetve WebService-krol beszelunk, az ilyen jellegu alkalmazasok szama nem fog megnoni. Ugy erzem nem a technologia hianyzott ahhoz, hogy az internetes alkalmazasokat osszekossek.
    Mutasd a teljes hozzászólást!
  • Ami az üzleti modellt illeti: szerintem nagyon jó az elképzelés, csak nálunk még nem igazán jó a hozzáállás ezekhez a dolgokhoz.

    (Csak példa kedvéért: ismerek olyan bankot (!) ahol az elektronikus úton beérkezett átutalásokat papírra nyomtatják, egy "biorobot" felviszi 1 emelettel feljebb és ott újra rögzítik azokat...)


    Szóval, szerintem jó az üzleti elképzelés, csak nálunk van a gond ilyenekkel...

    Biztos vagyok benne, hogy nálunk fejlettebb országokban ez jobban használt technológia. Mi még a papírnál tartunk :)
    Mutasd a teljes hozzászólást!
  • Én jelenleg pont WebService-es alkalmazást fejlesztek.

    Ami benne van:

    - Teljes adminisztrációs felület WebService-n keresztül. Így nem kell az SQL szervert kiajánlani, nem kell HTML/ASP-el szenvedni (sok gond volt az előző verzióval emiatt) és mégis bárhonnan elérhető a dolog, így szabadon lehet konfigurálni a rendszer a neten keresztül.

    Ez picit megerőszakolása az eredeti koncepciónak, de a gyakorlatban jól használható.

    - Lesz benne néhány olyan szolgáltatás, mely más cégektől jön és igazából kifelyezetten pont erre van kitalálva a Webservice. Tulajdonképpen egy foglalási kérelem jön bárhonnan, és azt dolgozza fel a rendszer.

    Mutasd a teljes hozzászólást!
  • Szerintem az XML es a webszolgaltatasok temakore egy kicsit tulfujt lufi, amit 'nyomatnak ezerrel'.

    Az XML (ha adatabrazolasra hasznaljuk) nem tobb mint hierarchikus informaciok egyezmenyes szoveges szerializacios formaja, ami raadasul meg annotalt szoveg jellegu informacio tarolasara is alkalmas.
    Szerintem a legtobbszor teljesen folosleges, es pazarlo dolog, hogy szamitogepek XML-el kommunikaljanak egymassal. Szofverrendszerek kommunikaciojanal szamomra lenyegtelen dolog a fizikai forma, a lenyeg a ketoldali interface. Tehat pl. en CORBA-n vagy RMI-n keresztul kommunikalhatok, nem erdekes, hogy a fizikai forma szamomra olvashato legyen.
    Az XML-nek van letjogosultsaga, de szerintem manapsag 'tulhasznaljak'.

    A webszolgaltatasoknak meg nem igazan latom az uzleti modelljet. Enelkul meg semmi nem fog beindulni. El lehet kepzelni uzleti modelleket, ahol A rendszer hasznalja B-t akkor valahogyan A a bevetele egy reszet B-nek fizeti, de szerintem ez kisse utopisztikus, mert a dolgok ennel sokkal 'profanabbul' mukodnek. A cegek az internetet nem adatszolgaltatasra akarjak hasznalni, hanem a sajat termekeik reklamozasara. Igy nem erdekeltek pl. egy atfogo autoadatbazis letrehozasaban, hanem csinaltatnak egy user altal elerheto szep weboldalt, ahol csak a sajat autoikrol vannak infok, mindez a sajat akcioikkal, es egyeb marketingkoritesekkel megspekelve.
    Mutasd a teljes hozzászólást!
  • A webszolgáltatások egyre inkább felfutóban vannak. Érdemes hát emiatt is egy külön topicot nyitni, amely a legújabb webszolgáltatás-hírekről, programozási kérdésekről ad információt.
    Vitaindító kérdésem: mire lehet jó egy webszolgáltatás? (Egyébként a topic mellett javasolnék egy most megjelent könyvet, az egyik ismerősöm írta a SZTAKI-ból (Gottdank Tibor), a címe: Webszolgáltatások - XML alapú kommunikáció az Interneten, és a ComputerBooks adta ki.)
    Mutasd a teljes hozzászólást!
abcd