[ Pobierz całość w formacie PDF ]
.Nale¿y unikaæ wzajemnie zale¿nych w³aœciwoœci, przez co unikniemy niezgodnoœciwewn¹trz obiektów.Jednak¿e niezale¿nie od punktu widzenia, asymetria wersji jest nieunikniona wsystemie replikacji zbudowanym na modelu luŸnej zgodnoœci ze zbie¿noœci¹ (jakActive Directory).Kiedy mo¿na wycofaæ klasê lub atrybutKlas i atrybutów nie mo¿na nigdy usun¹æ ze schematu (dlatego nie nale¿yswobodnie wprowadzaæ do schematu informacji).Jeœli wiêc posiadamy definicjeklas lub atrybutów, które nie bêd¹ ju¿ wiêcej u¿ywane, jedyn¹ mo¿liwoœci¹ jestich dezaktywacja.Dezaktywacjê (jak te¿ reaktywacjê) mo¿na ³atwo przeprowadziæ w okniew³aœciwoœci danego obiektu (obiektów) schematu.Jednak¿e dezaktywacja nie usuwaani definicji, ani istniej¹cych egzemplarzy obiektu z katalogu.Wobec tegomusimy w³asnorêcznie utrzymywaæ porz¹dek (proszê te¿ pamiêtaæ, i¿ mo¿na usun¹æz katalogu tylko egzemplarze obiektów, nigdy definicje schematu).Nie mo¿na te¿dezaktywowaæ atrybutu zawartego w dowolnej aktywnej klasie.Problem 2: sterowanie wspó³bie¿noœci¹Active Directory musi zapewniæ, by ró¿ne w¹tki programów nie wykonywa³yrównoczesnych niezgodnych ze sob¹ aktualizacji schematu (jak np.dezaktywacjaatrybutu przez jeden w¹tek równoczeœnie z dodaniem przez inny w¹tek tego samegoatrybutu do listy mustContain w klasie).Aby to osi¹gn¹æ, ka¿dy w¹tek próbuj¹cydokonaæ aktualizacji schematu zapisuje podczas tej samej transakcji specjalnyatrybut w kontenerze schematu (to znaczy, Active Directory automatycznie zmuszaw¹tek do zapisania tego atrybutu).W danej chwili tylko jeden w¹tek mo¿ezapisaæ ten atrybut, co zapewnia szeregowe dokonywanie aktualizacji schematu.Metoda ta gwarantuje spójnoœæ schematu, lecz nie zapewnia, które aktualizacjesiê powiod¹.Trzeba pamiêtaæ o tym przy wsadowym dokonywaniu aktualizacjischematu, jak w przypadku instalacji aplikacji korzystaj¹cych z us³ugikatalogowej.Za³Ã³¿my na przyk³ad, i¿ dwie aplikacje wykorzystuj¹ce ActiveDirectory — A i B — s¹ równoczeœnie instalowane, a ka¿da z nich tworzy kilkanowych obiektów schematu.Poniewa¿ Active Directory tworzy jeden w¹tek dlaka¿dej aktualizacji obiektu, mo¿e siê zdarzyæ, i¿ po utworzeniu pewnej czêœciobiektów w A i B (jeœli wewnêtrzne w¹tki nie na³o¿¹ siê) jeden z procesówinstalacji nie powiedzie siê, poniewa¿ w¹tek dla tworzenia obiektu schematu dlaA na³o¿y siê na analogiczny w¹tek dla aplikacji B.Za³Ã³¿my, i¿ nie uda siê instalacja A.Ponowne uruchomienie A od pocz¹tku nieuda siê, poniewa¿ czêœæ obiektów tworzonych przez A ju¿ istnieje w schemacie ipróba ich ponownego utworzenia zwróci b³¹d.Wobec tego, aplikacje modyfikuj¹ceschemat nie powinny byæ uruchamiane równolegle, o ile aplikacja nie sprawdza wpierwszej kolejnoœci, czy planowane aktualizacje schematu nie zosta³y ju¿przeprowadzone dla ka¿dej poszczególnej aktualizacji.Problem 3: jak radziæ sobie z niepoprawnymi egzemplarzami obiektówAktualizacja schematu mo¿e spowodowaæ niepoprawnoœæ istniej¹cego egzemplarzaobiektu.WeŸmy na przyk³ad obiekt X nale¿¹cy do klasy Y, zawieraj¹cej z koleiatrybut Z w liœcie mayContain.Poniewa¿ X jest egzemplarzem klasy Y, X mo¿ewykorzystaæ ten atrybut.Nastêpnie dokonana zostaje aktualizacja schematu , wktórej klasa Y ulega modyfikacji przez usuniêcie Z z listy mayContain.Zmianata powoduje, i¿ obiekt X przestaje byæ poprawny, poniewa¿ zawiera obiekt Zktórego nie ma prawa posiadaæ zgodnie z definicj¹ klasy Y (której egzemplarzemjest X).W obecnej wersji Windows 2000 Server Active Directory pozwala na pozostawanietakich obecnie niepoprawnych obiektów w katalogu.Mog¹ byæ one przydatne, leczto zale¿y od natury zmian schematu, wobec czego nic nie jest tak naprawdêgwarantowane.Jeœli na przyk³ad dodamy w klasie atrybut do listy mayContain(„mo¿e zawieraæ”), nie bêdzie problemów.Jeœli jednak dodamy atrybut do listymustContain („musi zawieraæ”), bêdziemy mogli odczytywaæ istniej¹ce obiekty tejklasy, lecz zapis do nich nie bêdzie mo¿liwy, dopóki nie wprowadzimy wartoœcidla tego nowego obowi¹zkowego atrybutu
[ Pobierz całość w formacie PDF ]