10/2 DirXML. 10/2.1 Inleiding

Transcriptie

1 Integratie 10/2 DirXML 10/2.1 Inleiding Stel u het volgende scenario eens voor: Binnen uw bedrijf wordt een nieuwe medewerker aangenomen op afdeling X. De manager op deze afdeling vult een formulier in met alle naam- en adresgegevens en stuurt het naar de personeelsadministratie. Tevens stuurt hij een formulier naar de IT-afdeling. Op deze afdeling wordt een mailaccount gegenereerd, de Novell-beheerders geven de nieuwe medewerker toegang tot hun filesystemen en het NT-team en het UNIX-team zorgen voor de toegang in de databases. Het derde formulier gaat naar de facilitaire dienst, die ervoor zorgt dat er voor de nieuwe medewerker een telefoonnummer komt en dat er een toegangspasje wordt aangemaakt. De eerste dag dat de nieuwe medewerker aan het werk gaat, zal hij eerst langs de personeelsadministratie moeten om aanvullende gegevens in te leveren en daarna naar de diverse afdelingen om wachtwoorden en dergelijke op te halen. Komt dit bekend voor? Het is de actuele situatie bij veel bedrijven. Vaak zijn de procedures goed beschreven en doorgaans worden ze ook goed uitgevoerd. Toch zijn er wat bezwaren tegen aan te voeren: Bij dergelijke procedures is sprake van menselijk handelen en dus kunnen er fouten worden gemaakt, bij het invoeren van gegevens bijvoorbeeld, of door een Novell Netwerkoplossingen, aanvulling 6 10/2.1-1

2 DirXML formulier op een verkeerde stapel te leggen, enzovoort. De gebruiker staat in diverse systemen geregistreerd; hij zal dus diverse log-in-accounts moeten instellen en onthouden, waarbij het zelfs zo kan zijn dat er inconsistentie ontstaat door andere naamgeving of doordat simpelweg vergeten wordt een systeem aan te passen. Als we even snel rekenen, zijn er zeven systemen waarin wordt geregistreerd. Dit betekent zeven keer een kwartier werk om de gebruiker op te voeren en zeven keer het risico op een foutje. De doorlooptijd kan wel eens een week in beslag gaan nemen. Geen probleem als de nieuwe medewerker op tijd wordt aangemeld, maar het gebeurt maar al te vaak dat dit wordt vergeten. Stel u nu eens een tweede scenario voor: Dezelfde nieuwe medewerker wordt aangenomen. De manager van de afdeling waar hij komt te werken stuurt een e- mail naar de personeelsadministratie dat op dag X deze nieuwe medewerker zich zal melden. Op de bewuste dag gaat de nieuwe medewerker naar de personeelsadministratie, waar hij samen met een functionaris zijn volledige gegevens invult. Vanaf hier echter gaat het anders: De gegevens van deze medewerker worden vanuit de personeelsadministratie gesynchroniseerd naar een metadirectory. De metadirectory synchroniseert een vooraf bepaald deel van de gegevens door naar de Novell-omgeving, waarmee automatisch een account wordt gegenereerd. Is dit afgehandeld, dan gebeurt hetzelfde naar de NTomgeving en de daarop draaiende databases. 10/2.1-2 Novell Netwerkoplossingen, aanvulling 6

3 Integratie Vervolgens worden weer de benodigde gegevens verder gesynchroniseerd naar de mailomgeving. Niet alleen wordt automatisch een adres aangemaakt, maar tevens wordt dit adres teruggesynchroniseerd naar de metadirectory. Hetzelfde gebeurt met de synchronisatie naar de telefooncentrale; het telefoonnummer wordt teruggestuurd naar de metadirectory. Als laatste worden de gewenste gegevens naar het toegangspasjessysteem gestuurd, waarin de gebruiker ook wordt geregistreerd. Vervolgens worden alle toegevoegde gegevens uit het proces weer teruggesynchroniseerd naar de personeelsadministratie. Toegang tot de UNIX-omgeving vergeten? Nee! De authenticatie voor de UNIX-omgeving vindt plaats middels het Lightweight Data Access Protocol (LDAP), en deze LDAP-server kan de LDAP-interface van edirectory zijn die op de metadirectory draait. Als we hier gaan tellen, komen we op andere getallen uit: Er zijn weer zeven systemen. Er is echter maar één keer een invoer, waar de nieuwe medewerker zelf bij is, dus de kans op fouten is nihil. Door het feit dat de vervolghandelingen zijn geautomatiseerd, blijft de kans op fouten door menselijk falen nihil. Voor een dergelijk systeem zijn wel een metaomgeving en diverse geautomatiseerde koppelingen vereist. De metaomgeving kan van alles zijn: Van een RDBMS (Relational Database Management System) gekoppeld met een LDAP-compliant-directory draaiend op dedicated servers bij grote bedrijven tot wellicht de operationele edirectory met koppelingen naar andere systemen bij de kleinere omgevingen en alles daartussenin. De keus tussen Novell Netwerkoplossingen, aanvulling 6 10/2.1-3

4 DirXML LDAP-compliant-directory of RDBMS dient zorgvuldig te worden gemaakt en beargumenteerd in het perspectief van de eisen van de onderliggende systemen (en dus van de gebruikers). 10/2.1-4 Novell Netwerkoplossingen, aanvulling 6

5 Integratie 10/2.2 Metadirectory Om een aantal redenen is het raadzaam om in de metaomgeving een LDAP-compliant-directory op te zetten. Een van die redenen is het feit dat koppelingen met andere systemen kunnen worden verzorgd met technieken die industriestandaard zijn. Vooraleer we een van deze standaarden (XML) gaan bekijken, zullen we eerst een weergave geven van directoryservices. Name space 10/2.2.1 Wat zijn directory s en hoe worden directory s gebruikt Directory services worden al geruime tijd gebruikt. De service stelt de beheerder in de mogelijkheid om op een eenvoudige manier de resources binnen een IT-omgeving te beheren. De directory is namelijk een gedistribueerde database waarin elk object een netwerkresource voorstelt (gebruikers, printers, servers enz.). De belangrijkste taak van een directory is het zetten van een name space. Iets of iemand behoeft niet het adres, zoals adres of netwerkadres, of de fysieke locatie te kennen, maar simpelweg de naam. Deze directory bepaalt dus de name space oftewel de naamstructuur voor een netwerk, zelfs al is het zo groot als internet. De name space wordt bepaald door een set van regels die ervoor zorgen dat elke entiteit binnen een netwerk uniek is. Denkt u hierbij bijvoorbeeld aan de hiërarchische structuur. De full distinguished name van een gebruiker is hiermee altijd uniek te krijgen, ook al hebben de entiteiten dezelfde naam. Het belangrijkste voor een metadirectory is dus ook het feit dat elke entiteit en we praten voornamelijk over gebruikers uniek identificeerbaar is. Novell Netwerkoplossingen, aanvulling 6 10/2.2-1

6 DirXML Behalve het geven van een unieke naam en het onderhouden van het adres, kan een directory nog meer doen. Elke entiteit heeft namelijk een set gegevens, genaamd attributen. In deze attributen kan allerhande informatie worden opgeslagen. Juist deze informatie is, naast de naam, belangrijk voor een metadirectory, omdat de manier waarop koppelingen zich moeten gaan gedragen, van deze attributen afhankelijk is. Bijvoorbeeld: om een gebruikersobject te synchroniseren tussen een PABX-systeem en een metadirectory, zal het attribuut telefoonnummer gevuld moeten zijn of worden. Het vullen van deze attributen gebeurt veelal op basis van de business rules, iets wat te realiseren valt met koppelingen op basis van XML. Hierover later meer. Vier rollen Als voorbeeld wordt binnen de internet name space bekeken waar de directory vier belangrijke rollen heeft: authentication; authorization; personalization; information store voor het opvragen van primary en secondary data. Binnen een willekeurige LAN- of WAN-omgeving (van een organisatie) kan een directory op dezelfde manier acteren, maar dit is wel te definiëren als een andere name space. Hierbij kunnen andere rollen worden toegevoegd, zoals bijvoorbeeld Relation Management. De directory als authentication source (authn) Om de directory als authentication source te gebruiken, is een logische zet, aangezien de directory ontwikkeld is met security als uitgangspunt. Er zijn extreem fijnmazige en robuuste security-mechanismen beschikbaar, zodat security kan worden bepaald tot op het niveau van attributen. 10/2.2-2 Novell Netwerkoplossingen, aanvulling 6

7 Integratie Er zijn veel directory-enabled applicaties beschikbaar die de security-mechanismen van de directory uitbreiden met een brede set authenticatiemechanismen, zoals PKI, biometrics, tokens en andere geavanceerde vormen van authenticatie. Zeer veel portal-oplossingen bieden een security-framework dat gebruikmaakt van een directory. Producten als SiteMinder, Oblix Netpoint of NPS maken gebruik van de voordelen van het security-framework van een directory om zowel meerdere gradaties van authenticatie te verkrijgen als gedistribueerd management- en applicatie-autorisatie. RDBMS-systemen zijn standaard niet zo flexibel met hun security. De meeste databases bieden column-level security, maar de geavanceerde security-oplossingen die een directory biedt, zijn vele malen flexibeler en verfijnder. Binnen een metadirectory is authentication wellicht niet nodig, omdat deze bron eerder een process-service is en geen operationeel systeem. Een metadirectory is echter wel van belang indien er wordt gebruikgemaakt van tussen de verschillende systemen gesynchroniseerde wachtwoorden. De directory als authorization source (authz) Permissies and restricties naar resources zijn ook goed te definiëren in directory s. Veel security- en identity-managementapplicaties vertrouwen op directory s om gebruikers te autoriseren voor resources of web-based applicaties. Producten als SiteMinder, Netpoint en ichain bevatten policy-based autorisatie als een belangrijk onderdeel van hun security-architectuur. Als deze security policy s eenmaal zijn gezet en ingericht, zullen ze niet vaak meer ver- Novell Netwerkoplossingen, aanvulling 6 10/2.2-3

8 DirXML anderen. De frequentie waarmee ze worden uitgelezen, is vaak zeer hoog, omdat de policy s continu worden gecontroleerd om er zeker van te zijn dat de security goed wordt opgelegd. Binnen een metaomgeving is dit een belangrijke service, aangezien er vaak op basis van security policy s zijn voor het wel of niet synchroniseren naar andere systemen. De directory voor personalization Steeds meer applicaties van systemen tot portals en policy-based security-applicaties gebruiken de directory als een repository for storing data related to the user, oftewel een opslag van gebruikersgegevens. Omdat de directory van elke gebruiker een record heeft, lijkt het logisch om alle gebruikersspecifieke data in dat user record op te slaan. Het meest voorkomend zijn gegevens zoals bijvoorbeeld naam, adres, telefoonnummer en e- mailadres omdat deze door veel applicaties worden gebruikt, maar ook kunnen in zo n record voorkeuren worden opgenomen, bijvoorbeeld voor profiling. Voorbeeld: zowel Netscapes My Netscape-portal als Novells Portal Service maken gebruik van een directory (resp. iplanet en edirectory) en bevatten per gebruiker een hoop gegevens voor personalizationkarakteristieken, zodat de gebruiker de look, feel en content van zijn portal individueel kan customizen. Door middel van self provisioning kan de gebruiker dit customizen zelf doen. Zoals eerder vermeld, biedt een directory een grote mate van flexibiliteit in de securityarchitectuur, wat weer een vereiste is voor deze self provisioning. Het kan zelfs zo ver gaan dat een bepaalde gebruiker rechten heeft om bepaalde acties uit te voeren die van invloed zijn op andere gebruikersobjecten. 10/2.2-4 Novell Netwerkoplossingen, aanvulling 6

9 Integratie Een hiërarchisch ontwerp, support voor multi-value attributes, een extendable schema en support voor de LDAPstandaard en de vele Application Layer Interface (API s), zijn een aantal voordelen van een directory. Daarnaast zijn de Need for Speed en de schaalbaarheid zijn echter ook twee belangrijke voordelen van een directory. De directory als information storage De directory-service kan fungeren als een centraal informatiepunt voor diverse input van buiten de hierboven genoemde bronnen. Er is een nog aantal services die gebruik kunnen maken van de directory. Deze services kunnen worden benoemd als een aantal klassen die ieder op een bepaalde manier van de gegevens in de directory gebruikmaken. Beheer is overzichtelijk Afhankelijk van de rol van een gebruiker is er wel of geen toegang tot deze services en systemen. De directory-service is hierin een centraal informatiepunt voor gebruikers of services. Concreet betekent dit dat alle resources of entiteiten van een IT-omgeving als objecten in de directory zijn opgenomen. Denkt u hierbij niet alleen aan gebruikers maar bijvoorbeeld ook aan computers, applicaties, policy s en actieve componenten. Hierdoor is het beheer van deze objecten overzichtelijk en efficiënt te houden. Primaire Data omvat gegevens als adres die gebruikt worden om gegevens af te leveren bij een gebruiker. Dit kan bijvoorbeeld ook een systeem zijn voor fax- en/of telefoonnummers. Secundaire Data zijn gegevens die niet noodzakelijk zijn voor de werking van informatiesystemen, maar wel erg nuttig zijn om centraal op te slaan. Denk hierbij aan gegevens als kamernummer en de voornaam of achternaam van een persoon. Op deze Novell Netwerkoplossingen, aanvulling 6 10/2.2-5

10 DirXML manier kunnen de directory-services dienen als de gouden gids binnen het netwerk. Een gebruiker van de directory-service hoeft niet per se een echte menselijke gebruiker te zijn. Dit kan evengoed een programma of computersysteem zijn. Hierbij is het van belang dat een directory een unified view biedt aan alle gebruikers, applicaties of systemen. Als de directory op een bepaalde manier wordt benaderd, zal altijd dezelfde informatie terugkomen in hetzelfde formaat. Dit laatste gegeven is een van de belangrijkste eisen voor een metadirectory, wegens het feit dat deze informatie kan worden en ook wordt gebruikt bij het inrichten van de diverse koppelingen. De directory voor Relation-management Niet alleen de identiteit is belangrijk binnen een directory, maar ook de relaties van de entiteit met andere entiteiten. Deze relaties kunnen namelijk, bijvoorbeeld, de rechten bepalen of ze kunnen binnen een metadirectory bepalen waarnaartoe zijn gegevens worden gesynchroniseerd als het gaat om gebruikersentiteiten. Een ander voorbeeld is dat een profiel van een gebruiker kan worden opgebouwd op basis van relaties met andere systemen. 10/2.2-6 Novell Netwerkoplossingen, aanvulling 6

11 Integratie 10/2.3 DirXML en edirectory in de markt Er is een aantal spelers op de markt die dergelijke oplossingen kunnen bieden en Novell is er een van. Novell heeft al enkele jaren, sinds NetWare 4.0, een directory-service om de IT-omgeving te beheren. In NetWare 5.0 werd vervolgens de LDAP-compliancy toegevoegd. Novell heeft dus al een ruime ervaring met directory s en koppelingen met andere systemen. Volgens een rapport van Gartner van The 2H02 Metadirectory Service Magic Quadrant komt Novell zelfs als beste uit een test voor metadirectory s. In de bron wordt verteld hoe men tot deze keuze is gekomen. Bron: Gartner Research Note Markets, 19 August 2002 M Hierbij dient wel een belangrijke opmerking te worden gemaakt: een metaomgeving bestaat uit een metadirectory of database en koppelingen met diverse systemen. Novell heeft voor deze koppelingen een systeem ontwikkeld genaamd dirxml. Novell Netwerkoplossingen, aanvulling 6 10/2.3-1

12 DirXML Nsure Ten tijde van het schrijven van dit artikel is Novell met het product Nsure Resources op de markt gekomen. Nsure Resources is een metadirectory-product volledig gebaseerd op dirxml. Het grote verschil met eerdere versies is dat er overal gebruik wordt gemaakt van een Remote Loader. Deze techniek zal later nog worden besproken. Het grote voordeel van deze manier van werken is de eerder besproken unified view. 10/2.3-2 Novell Netwerkoplossingen, aanvulling 6

13 Integratie 10/2.4 DirXML 10/2.4.1 Introductie XML, XDS, XSL en XSLT XML DirXML stelt ons in staat om informatie uit een directory te synchroniseren naar andere directory s of applicaties. Dit alles gebeurt op basis van de extensible Markup Language (XML)-standaarden. XML is een taal die net als HTML gebruikmaakt van tags en elements. Het verschil is dat HTML voorgedefinieerde tags en elements kent. XML kan worden opgebouwd uit verschillende XML- woordenboeken, en tags en elements zijn te specificeren op basis van de behoefte. In onderstaande figuur zijn de tags (given-name, surname enz.) en de element names weergegeven voor de definitie van een gebruiker: Op die manier kan niet alleen worden beschreven maar kan tevens worden bepaald hoe de informatie moet worden geïnterpreteerd door een andere applicatie met een ander dialect. Novell Netwerkoplossingen, aanvulling 6 10/2.4-1

14 DirXML Stel er moet een geboortedatum worden gesynchroniseerd van een HR-applicatie naar een mail-applicatie via edirectory. Schematisch gezien gebeurt het volgende: <Date of Birth> </Date of Birth> wordt middels dirxml opgeslagen in edirectory als <birthdate>03/03/ 2000</birthDate> en wordt vervolgens naar de mail-applicatie gestuurd als <Date of creation> </date of creation>. Zoals is te zien, zijn de tags en de inhoud verschillend. Zolang maar bekend is hoe de verschillende woordenboeken werken (lees, hoe de definitie van de attributen is), kan en dient er een vertaalslag te komen van de ene definitie naar de andere en dat is nu juist wat dirxml doet. XDS DirXML gebruikt het extensible Directory Syntax (XDS)- woordenboek. Hierover later meer. De meta language XML is een World Wide Web Consortiumspecificatie die een methode biedt om data en de context van de data te presenteren op een generieke manier en die uitbreidbaar is (denk ook aan bijvoorbeeld localization) en 10/2.4-2 Novell Netwerkoplossingen, aanvulling 6

15 Integratie XSL XSLT die platformonafhankelijk is. Deze data kan worden bewerkt door gebruik te maken van de XML Stylesheet Language (XSL). Dit is een file die bepaalt hoe een XMLdocument wordt gepresenteerd. XSL biedt ook een transformation language XSLT om data binnen een XML-document te manipuleren. XML kent in tegenstelling tot HTML geen vooraf gedefinieerde tags. Deze worden benoemd in een Document Type Definition ook wel DTD. Het voordeel hiervan is dus dat het aantal tags naar wens kan worden uitgebreid. Door een XML-document te verifiëren aan de nds.dtd, ontstaat een XDS-document. XSLT (extensible Stylesheet Language Transformations) in een transformation language voor XML. XSLT is een onderdeel van XSL waarin het formatteren van objecten is opgenomen. Het specificeert de transformation semantics dat kan opereren op XML. Om alles te weten te komen over XML, XDS, XSL en XSLT zijn er enkele goede boeken in de handel: Novell s guide to dirxml door Peter Kuo (XML gerelateerd aan dirxml) XSLT Programmer s Reference 2nd edition door Michael Kay. Daarnaast is er uiteraard meer informatie te vinden op 10/2.4.2 Introductie dirxml Het is dus mogelijk om te communiceren met verschillende applicaties en directory s als maar bekend is hoe de data moet worden geïnterpreteerd. Op basis van dit gegeven is een situatie te creëren zoals in de volgende illustratie: Novell Netwerkoplossingen, aanvulling 6 10/2.4-3

16 DirXML DirXML heeft in bovenstaande illustratie diverse taken uit te voeren: Het constateren van wijzigingen binnen edirectory. Het centraliseren en distribueren van data door als een centrale opslag alle data naar zich toe te halen, waaronder de wijzigingen in de andere systemen. Het weergeven van de data aan de andere applicaties in XML-formaat. Het controleren van de datastroom door middel van filtering. Het bewaken van data-autoriteiten door middel van het zetten van permissies en filters. Het uitvoeren van de diverse rules. Deze rules bepalen de interpretatie en de transformatie als de data door het systeem gaat. Het transformeren van de data naar het formaat waarin de applicatie de data begrijpt. 10/2.4-4 Novell Netwerkoplossingen, aanvulling 6

17 Integratie Het onderhouden van associaties. Als er objecten zijn gesynchroniseerd dient te worden bijgehouden dat er een associatie bestaat tussen de objecten in de verschillende systemen om alles up-to-date te houden en om te voorkomen dat er te veel data heen en weer wordt gestuurd. 10/2.4.3 Onderdelen van dirxml Elk van bovenstaande taken wordt door een of meerdere onderdelen van dirxml uitgevoerd. Schematisch gezien ziet een koppeling op basis van dirxml er als volgt uit: Een dirxml-koppeling kan de volgende onderdelen bevatten: edirectory, Application directory of database Publisher en Subscriber Channel edirectory-interface DirXML of Join Engine DirXML Driver Shim Remote Loader Shim Remote Loader Service Novell Netwerkoplossingen, aanvulling 6 10/2.4-5

18 DirXML Filters Rules en Sheets: - Schema Mapping Rules - Matching rules - Create Rules - Placement Rules - Input & Output Sheets - Event Transformation Sheets - Command Transformation Sheets - Advanced Stylesheets Association ID In de volgende paragrafen worden de verschillende onderdelen beschreven. Datastorage De datastorage zijn de twee informatiebronnen waartussen wordt gecommuniceerd. Dit is aan de ene kant edirectory en aan de andere kant kan dit een applicatie, een directory of een database zijn. Publisher en Subscriber Channel Communicatie tussen twee bronnen is bidirectioneel. Door de communicatie te scheiden in twee kanalen, is het mogelijk te bepalen welke data welke kant op gaat. Het kan bijvoorbeeld een wens zijn om het telefoonnummer vanuit een PABX-database naar edirectory te synchroniseren maar niet terug. Binnen een dirxml-koppeling wordt gebruikgemaakt van een Subscriber en een Publisher Channel. Elk van de channels wordt vertegenwoordigd door een object: Subscriber-object: Dit representeert de communicatie van de edirectory naar de applicatie. Anders 10/2.4-6 Novell Netwerkoplossingen, aanvulling 6

19 Integratie gezegd: een externe applicatie subscribet zich aan de data in edirectory en accepteert de aan hem gezonden informatie. In dit object zitten tevens diverse rules en sheets alsmede een lijst met attributen die dienen te worden gesynchroniseerd, ook wel de subscriber-filter. Publisher-object: Dit representeert de communicatie van de applicatie naar de edirectory. Er wordt ook wel gezegd: een applicatie mag zijn data publiceren naar de edirectory. Ook dit object bevat links naar de diverse rules en sheets alsmede een lijst met attributen die dienen te worden doorgelaten door de publisher-filter. Events en commands Het is belangrijk voor de verwerking en de plaatsing van de rules en sheets dat in de gaten wordt gehouden dat er een verschil is tussen events en commands. Een event is een verandering in een object die wordt geregistreerd door dirxml. Een command is het wijzigen van objecten door dirxml. Events en commands worden op verschillende plaatsen binnen dirxml uitgevoerd c.q. geregistreerd, zoals hieronder is weergegeven. edirectory-interface De edirectory-interface is het onderdeel dat veranderingen in edirectory constateert en ze doorgeeft aan de Join Engine. Het is mogelijk om meerdere drivers op een enkele Novell Netwerkoplossingen, aanvulling 6 10/2.4-7

20 DirXML Loopback detection instance te laden, zodat een event maar één keer hoeft te worden gelezen. Verder heeft de edirectory-interface een loopback detection. Dit voorkomt dat een wijziging wordt gesynchroniseerd naar een applicatie waarin deze wijziging ook wordt geregistreerd als een nieuw event en deze wijziging dus weer terugstuurt naar de edirectory als zijnde nieuwe informatie.tao Bij het initiëren van dirxml zal de dirxml-engine de subscriber-filter lezen en de actieve drivers registreren. Tijdens de normale verwerking zorgt de edirectory-interface er tevens voor dat de data wordt gefilterd aan de hand van de specificaties. De interface maakt ook een cache aan voor de gefilterde edirectory-events. Deze cache wordt per driver aangemaakt. Deze zijn terug te vinden als bestanden in de directory waar ook de DIB-files (SYS:\_Netware, C:\NOVELL\DIBfiles) staan en deze bestanden eindigen met.tao. Daarnaast vertaalt de interface de events naar XDS, het Novell-woordenboek van XML. Deze.TAO-file wordt gevuld met de events binnen edirectory, die vervolgens de engine ingaan. Elke driver heeft zijn eigen cache (xxxxx.tao-file). De xxxxx staat hier voor het objectid (decimaal) van de driver in de edirectory (let op: dit is dus server-centric). De cache is een FIFO-queue (first-in-first-out) en kan er dus voor zorgen dat er geen enkele wijziging wordt overgeslagen door bijvoorbeeld geen communicatie. Een voorwaarde is dan wel dat de grootte van de cache (Authentication-tab van het driver-object) niet wordt overschreven. Deze.TAO-file wordt ook gebruikt bij de resync-optie. Als om welke reden dan ook de driver niet meer communiceert, is het mogelijk een resync te doen. Deze resync kijkt in elk object in de tree of er een associationid is. Vervolgens 10/2.4-8 Novell Netwerkoplossingen, aanvulling 6

21 Integratie wordt gekeken of er wijzigingen voor elk object zijn die kunnen worden gesynchroniseerd. Dit kan een belasting betekenen voor de server en het netwerk. Waarschuwing U moet dit zeker in acht nemen bij een aantal drivers, zoals de NT-domain-driver met de Remote Loader. Deze zal na het opstarten van de driver altijd een resync genereren, waardoor de NT-server het even druk krijgt. Ook als er geen.tao-file wordt gevonden, zal er eerst een resync plaatsvinden. Dus ook dan kan er een flinke belasting plaatsvinden. In het laatste geval is het zaak de storing te verhelpen (zie de tips hierna). Als een driver wordt gestopt of hij staat op manual startup, betekent dat niet dat de.tao-files (en dus de eventcache) niet wordt gevuld. Pas op het moment dat een driver op disable wordt gezet, worden de.tao-files geleegd. Tips Vlak na het installeren van een driver is het raadzaam een kopie te maken van de bijbehorende.tao-file. Mocht de file ooit corrupt of te groot raken, dan is het mogelijk de lege TAO terug te plaatsen zodat de driver weer goed kan opstarten. Een dergelijke lege file is eventueel ook te downloaden van ftp://ftp.dreamlan.com/empty.tao Een lege.taofile bestaat alleen uit een data header en is 8 KB groot, behalve als hij is gemaakt tijdens de installatie van de driver; dan is de file 11 KB groot en bevat informatie over het creëren van de driver. Novell Netwerkoplossingen, aanvulling 6 10/2.4-9

22 DirXML U kunt een corrupte.tao-file detecteren door de trace-files te bekijken. Hierin zal dan zonder te stoppen de volgende regel voorkomen: VRReadCacheBlock: Read 888 bytes from cache file < TAO> Deze regel verschijnt ook bij het opstarten van een driver; wees dus niet te snel met het trekken van conclusies. Als de volgende regel verschijnt, gaat alles goed: VRPurgeCacheBlock: Purged bytes from cache file < TAO>.TAO-files worden continu gevuld; let dus goed op de vrije schijfruimte. Als de dirxml-engine de.tao-files nog wel kent, zullen de files zelfs worden gevuld als de driver niet meer in gebruik is. Daarnaast is het zo dat de.tao-files niet worden verwijderd, zelfs niet als de driver wordt verwijderd. Het is dus raadzaam om dirxml in z n geheel te verwijderen als de service niet meer nodig is. DirXML of Join Engine De namen van deze onderdelen worden wel eens door elkaar gehaald. De dirxml-engine bestaat uit de eerder genoemde edirectory-interface en de Join Engine. De dirxml-engine bevat een rule-processor en een data transformation-processor. Door rules en stylesheets toe te voegen, bewerkt de dirxml-engine de aangeboden data met de commando s en veranderingen die in de rules en sheets zijn opgegeven. Zoals al eerder vermeld, wordt XDS gebruikt. Deze aangeboden XML-variant wordt vervolgens 10/ Novell Netwerkoplossingen, aanvulling 6

23 Integratie gevalideerd met de NDS.DTD. Dit document is een Document Type Definition waarin de syntax of structuur van XML-documenten van een bepaalde applicatie wordt beschreven. Een DTD beschrijft niet de betekenis. Drie typen verklaringen Binnen een DTD zijn drie typen verklaringen te vinden: Element-Type declarations; Attribute-List declaration; Parameter-Entity declarations. Voorbeeld: In de DTD wordt beschreven dat een object zes attributen heeft die de waarde PCDATA hebben. Dit zegt niks over wat het object is, maar legt vast hoe een object eruit ziet. Een XML-document wordt hieraan gevalideerd en dus is zeker hoe er met de data om kan worden gegaan. Het voordeel van deze techniek is dat binnen XML geen vooraf gedefinieerde tags bestaan net zoals in HTML. Deze worden allemaal gedefinieerd in de DTD en zijn dus uitbreidbaar. In de Join Engine is verder een processor opgenomen, zoals hierboven is aangegeven, die de stylesheets verwerkt tegen de aangeboden XML-data. Dit wordt uitgelegd in de beschrijving hoe dirxml werkt. Novell Netwerkoplossingen, aanvulling 6 10/2.4-11

24 DirXML DirXML Driver Shim De Driver Shim is de connectie tussen dirxml en de applicatie. De dirxml-engine levert de data af in XML-formaat indien nodig in het XML-formaat, dat de applicatie begrijpt dat de events beschrijft. Dit wordt door de shim vertaald in commando s die door de applicatie worden begrepen. De shim is geschreven in Java,C of C++. Als de applicatie XML verstaat, dan zal de Driver Shim niets doen maar de data doorsturen naar de applicatie. Indien de applicatie geen XML verstaat, dan zal de Driver Shim de data omzetten naar application native data format. De Driver Shim is de module die moet worden geconfigureerd voor de specifieke applicatie. Zo zal deze shim in de LDAP-driver ldapmodify commando s geven aan de directory en bijvoorbeeld de change log uitlezen van een applicatie om wijzigingen te constateren en deze vervolgens door te geven aan dirxml. Ondersteunde object events De volgende object events worden door de Driver Shim ondersteund: Add (create); Modify; Delete; Rename; Move; Modify-Password. Daarnaast ondersteunt de Driver Shim een query, zodat dirxml de database, directory of applicatie kan bevragen. Remote Loader Shim Het is mogelijk om de informatie uit de dirxml-engine rechtstreeks de Driver Shim in te sturen. Deze Driver Shim heeft contact met de applicatie waarmee wordt gecommu- 10/ Novell Netwerkoplossingen, aanvulling 6