Mellékleteink: HUP | Gamekapocs
Keres

Microsoft Windows Longhorn előzetes

Budai Péter, 2004. április 26. 09:07
Ez a cikk több évvel ezelőtt születetett, ezért előfordulhat, hogy a tartalma már elavult.
Frissebb anyagokat találhatsz a keresőnk segítségével:

6. oldal: Indigo, alkalmazásközi kommunikáció

Az Indigo a Longhorn kommunikációs alrendszere, amely az 1.1-es .Net keretrendszer által lefektetett technológiákon kívül a legfrissebb irányelveknek megfelelően a SOA (Service Oriented Architecture) koncepciót is támogatja. A Longhorn általános nagyvállalati, és integráció-centrikus megoldások fejlesztéséhez az Indigo Szolgáltatásokat ajánlja, amely a World Wide Web Consortium SOAP 1.2 specifikációjára épül. Az ezzel készített szoftverek könnyen skálázhatóak, rugalmasan továbbfejleszthetőek és integrálhatóak.

A korábbi alkalmazások legnagyobb hátránya az volt, hogy a kommunikációban résztvevő valamennyi szoftvernek pontosan ismernie kellett a meghívandó eljárások paramétereit, elérhetőségét, és működésének részleteit. Szélsőséges esetekben egyedi kommunikációs protokollok programozására is szükség volt, hogy a meglévő, nem kifejezetten bővíthető és integrálható alkalmazások is képesek legyenek új funkcionalitás elérésére az újonnan kifejlesztett szoftvermodulokból.


A DxDiag Longhornon

A kommunikációs modellek fejlődése az összes nagyobb szoftverfejlesztő vállalatnál azonos irányban, és közel egyforma tempóban haladt, ennek első állomásának a középréteg megjelenés tekinthető. Eleinte a leghatékonyabbnak az ORB (Object Request Broker) megoldások bizonyultak, -- mint például az OMG által fejlesztett CORBA technológia -- valamint a Microsoft interfész-központú COM (Component Object Model), majd a Windows 2000-ben debütáló COM+ architektúrája. Mindről elmondható, hogy erősen típusos interfészek használatával tették lehetővé alkalmazások kommunikációját, és működéséhez az egymással összekapcsolt szoftvereknek egyenként rendelkezniük kellett az interfészek leírásával. Ez az alkalmazások nehézkés bővíthetőségével járt együtt, ugyanakkor a megközelítés már messze meghaladta a korábbi, egyedi alapon kivitelezett kliens-szerver kommunikációs megoldások lehetőségeit.

A következő mérföldkőnek az üzenet-alapú kommunikáció bizonyult, aminek legjelentősebb képviselői az IBM MQSeries és a Microsoft MSMQ voltak. Az üzenet-alapú kommunikáció szakított az előre rögzített interfészek koncepciójával, helyette hibatűrő, tranzakció-kezeléssel ellátott, rugalmas csatornákat biztosított tetszőleges üzenetek szállítására. Ezeknél a technológiáknál az üzenetek küldése és fogadása a hálózati protokollokhoz hasonló elven működik, amit QoS (Quality of Service) képességek tesznek még hasznosabbá, könnyen skálázhatóvá. Független a hálózat megbízhatatlanságától, mivel nem igényel folyamatos kapcsolatot a kommunikációban résztvevő alkalmazások között, és a hibákat lehetőségeihez képest elhárítja.

A jelenleg legáltalánosabban támogatott megoldások web-alapú szolgáltatásokra (WebService) épülnek. Talán ez az eddigi legrugalmasabb architektúra, mivel nincs megkötve sem a kommunikációs protokoll, sem az üzenetek konkrét formátuma, vagyis akár HTTP, akár TCP segítségével felépíthető az alkalmazásközi kapcsolat. Az üzenetek az esetek nagy többségében SOAP formátumban kerülnek meghatározásra. Minden WebService a külvilág számára szabványos felület segítségével ajánlja ki képességeit, ezáltal bármely másik komponens szabadon felhasználhatja azokat, amennyiben támogat legalább egyet az elterjedt kommunikációs protokollok közül.

Érdekes mellékvágány a Remoting, ami első ránézésre rugalmasnak és strapabírónak tűnik, azonban komolyabb rendszerek fejlesztésekor szép lassan bukkannak elő problémái. Alapötlete, hogy a kliensoldalról a szerver tudása objektumokon keresztül érhető el, amik a programozó számára úgy viselkednek, mintha valódi kliensoldali példányok lennének. Igazából az ilyen objektumok eljárásainak hívásakor a keretrendszerek proxy osztályokon keresztül automatikusan elvégzik a hálózati kommunikációhoz szükséges valamennyi feladatot, és ebbe a programozónak legfeljebb finomhangolás és teljesítménynövelés céljából kell beleszólnia.

Ez a megoldás kényelmesen használható a kliensoldalon, és a legtöbb esetben nem igényli, hogy a programozó releváns hálózati fejlesztési tapasztalat birtokában legyen; elegendő hozzá az objektum-orientált programozás alapos ismerete. Hátránya, hogy az esetleges hibák felderítése hatalmas feladatot jelent, és az igazán hatékony használatához a rendelkezésre álló Remoting megvalósítások manuális bővítése is szükséges lehet. Ugyancsak negatívum, hogy a kommunikáció kizárólag kapcsolat-alapú protokollok használatával lehetséges, ami szinte lehetetlenné tette hibatűrő rendszerek kialakítását, és a rendszer bővítése általában az összes komponens újrafordításával jár. Remoting megoldással a Java és a .Net keretrendszerben is találkozhatunk, a Javában az RMI (Remote Method Invocation), .Net alatt pedig a .Net Remoting technológia képében.

Az Indigo képes XML WebService, .Net Remoting, .Net Messaging (korábbi nevén MSMQ) és szolgáltatás-alapú kommunikációs modellek kialakítására is. Igazi újdonságot csak az Indigo Szolgáltatások nyújtanak, a többi technológia közel változatlan formában a .Net keretrendszer 1.1-es verziójában is elérhető.


A jogosultság hiánya még a lokális adminisztrátornak is gondokat okoz

Az Indigo Szolgáltatások a meglévő architektúrák pozitív tulajdonságait foglalják magukban: egyesíti a Remoting lokális objektumkoncepcióját, a Messaging alrendszer hibatűrését és tranzakció-kezelését, valamint a WebService-ek könnyű integrálhatóságát és bővíthetőségét. Minden Indigo Szolgáltatás öt réteg felhasználásával jöhet létre (a felsorolás a legmagasabb szintű rétegtől a legalacsonyabb szintűig halad):

  • Szolgáltatások (Services): Ez a réteg tartalmazza az alkalmazások többsége által elérhető szolgáltatásokat, funkciócsoportokat, a legmagasabb absztrakciós szinten definiálva.
  • Típusos csatornák (Typed channels): Ebben a rétegben kerülnek meghatározásra a szolgáltatásból elérhető, meghívható eljárások, metódusok. Itt szabályozható, hogy az alacsonyabb szinten található üzenetek mely metódusokhoz jussanak el.
  • Típus nélküli csatornák (Untyped channels): Egy adott Porttal együttműködve képesek megadott sémák szerinti üzenetek küldésére és fogadására.
  • Portok (Ports): A típus nélküli csatornákról érkező üzenetek útjának és sorrendjének szervezésével foglalkozó réteg.
  • Adatszállítási technológiák (Transports): Ez a réteg felelős a tényleges alkalmazásközi kommunikációért, itt történik meg az üzenetek kiküldése, fogadása, valamint a kívánt formátumokba történő konverziója és szerializációja.
Facebook
Adatvédelmi okokból az adott hír megosztása előtt mindig aktiválnod kell a gombot! Ezzel a megoldással harmadik fél nem tudja nyomon követni a tevékenységedet a HWSW-n, ez pedig közös érdekünk.