czwartek, lipca 15, 2010

Co z tym CRL w C#

Już podobno jest lepiej. Są dwie drogi do uzyskania listy CRL w postaci możliwej do interpretacji: zastosowanie przykładu z BC (w tym samym miejscu gdzie jest StringSigner) lub na piechotę - przetłumaczenie przykładu z książki Hooka (tam jest to co prawda w Javie), inny sposób to rozwiązanie zawarte na forum C# na MSDN.
Tam proponują też rozwiązanie rodem z BouncyCastle, lub wykorzystanie Mono.Security.dll z projektu Mono. Ale tam napotkano na stary problem znany z przykładu w BC "System.Collections.ArrayList.ArrayListDebugView' is inaccessible due to its protection level".
Ja dołożę jeszcze jedną propozycję - spróbować Bonnie.Net.

Nieudana próba

Podczas testowania appletu z strony tego hiszpańskiego projektu nie udało się z marszu czegoś podpisać. Applet jest mocno sparametryzowany, domyślne ustawienia: to wybranie certyfikatu z pliku (ale go nie mam pod ręką), albo wskazanie sterownika urządzenia do obsługi karty inteligentnej (nie wiedziałem jaki jest dla KIR - wybrałem CCPKI...), ale niedobrze trafiłem, a dalej zgadywać mi się nie chciało, więc dałem sobie spokój.
Projekt ten ma teraz nową stronę - http://forja.uji.es/projects/cryptoapplet.
Główna trudność to bariera językowa - hiszpański.
Świetny jest materiał w prezentacji - http://forja.uji.es/docman/view.php/24/3/workshop_slides.pdf
Dokumentacja w języku ang. jest tu.
Z innej beczki w projekcie Bouncy Castle jest strona z przykładami, najbardziej mi zależy na StringSigner, on też nie chodzi błąd z dostępem do elementów klasy BC (zgłosiłem go na forum, ale bez wyniku)

środa, lipca 14, 2010

BC error

http://reisjr.wikispaces.com/page/notify/BouncyCastle.StringSigner
Podobne problemy przy pobieraniu CRL - http://social.msdn.microsoft.com/forums/en-US/csharpgeneral/thread/6fb973f8-9d96-4781-94e9-4686385ceb9c

BC error

http://reisjr.wikispaces.com/page/notify/BouncyCastle.StringSigner. Ciągle nie wiem co to za błąd

poniedziałek, lipca 12, 2010

Chmura cz. 2

O poważnym potraktowaniu zagadnień powstających podczas przetwarzania w chmurze świadczy powołanie przez IBM konsorcjum do badań nad nowymi modelami przetwarzania w chmurze mającymi na celu redukcję kosztów hostingu i utrzymania serwisów webowych. W ramach prac tego konsorcjum IBM wraz z EU oraz wybranymi uniwersytetami europejskimi będzie prowadził badania naukowe w celu opracowania modelu integrującego serwisu pochodzące od różnych platform sprzętowych i środowisk programistycznych jedno elastyczne środowisko do przetwarzania aplikacji użytkowych w chmurze. Tak wypracowane projektowania i wdrażania pozwolą nie tylko na zwiększenie elastyczności integracji ale znacznie zredukują koszty w porównaniu z konwencjalnymi modelami wymagającymi wielu operacji manualnych w celu dostosowania serwisów do pracy ze sobą. Badania będą prowadzone w ramach projektu ACSI (Artifact-Centric Service Interoperation) bazującego na koncepcji kooperujących ze sobą hubów (interoperation hub) wprowadzonej w ubiegłym roku przez ośrodek badawczy IBM Research. Ten właśnie huby pozwolą na stworzenie w chmurze środowiska integracyjnego w którym będzie można łatwo, szybko i w elastyczny sposób tworzyć i wdrażać usługi webowe oraz oprogramowanie wykorzystujące Internet różnych dostawców. Firma IBM słynie ze swego rozmachu w badaniach podstawowych, które czasami mają utylitarne wykorzystanie. Takim spektakularnym wynikiem jest zainicjowanie i w pierwszej fazie wsparcie finansowe i intelektualne projektu Eclipse, który w efekcie tych działań po fazie inkubacji pod skrzydłami IBM okrzepł i rozwinął się w samowystarczalną fundacje. Inna sprawa, że IBM ma tyle środków finansowych, że może sobie pozwolić na pewne ekstrawaganckie ruchu mające na celu przyszłe korzyści (np. zablokowanie prac nad wymienialnością i integracją serwisów w chmurach innych firm zwłaszcza, że oferta IBM w zakresie chmury jest mało konkretna, żeby nie powiedzieć mglista). Źródło - http://www.itworld.com/saas/113287/ibm-and-eu-establish-cloud-computing-consortium?source=ITWNLE_nlt_today_2010-07-08

Podstawowym komponentem do stworzenia aplikacji w chmurach w technologii MS Azure jest Microsoft Hyper-V (wcześniej zwany jako Windows Server Virtualization) o nazwie kodowej Viridian. Firma Microsoft miała trudny orzech do zgryzienia, musiała wybrać oprogramowanie do zarządzania wirtualizacją na możliwie najniższym poziomie (najbliższym warstwie sprzętowej) oraz dokonać wyboru samego sprzętu na którym ma zostać uruchomiona wirtualizacja. Jeżeli chodzi o oprogramowanie to wybrała własny produkt działający jedynie na sprzęcie o architekturze Intel 86-64. Być może dlatego, że już go miała (wyłonił się on w trakcie prac na uproszczonym, “gołym” do minimum serwerem Windows Server 2008W) oraz dlatego, że programiści w Microsoft nie mieli narzędzi ani bibliotek ani doświadczenie w wytwarzaniu aplikacji na inne platformy sprzętowe). Wybór własnego narzędzia niejako zdeterminował sprzęt na którym będzie wirtualizacja – tylko platforma procesorów Intel. Tak że wybrano  technikę wirtualizacji zasobów sprzętowych w oparciu o koncepcję hyperwizora (hypervisor – nadzorca) i w implementacji Microsoft działa wyłącznie na sprzęcie o architekturze zgodnej z x86-64 (czyli procesorami wytwarzanymi przez Intel i AMD). Schemat architektury pokazany jest tu 

800px-Hyper-V    Hypervisor zapewnia izolację między systemami operacyjnymi na zasadzie separacji logicznych partycji. W każdej partycji działa jeden system operacyjny. Instancja hyperwizora ma co najmniej jedną partycję rodzica (parent partition) w której uruchomiana jest wersja MS Windows Sever 2008. Ta partycja główna ma bezpośredni dostęp do urządzeń sprzętowych i przerwań. Wszystkie maszyny wirtualne są uruchamiane i zarządzane przez ta partycję (proces ten nazywa się virtualization stack). Partycja główna tworzy partycje potomne (child partition – dzieci) w których uruchamiane są systemy operacyjne (potocznie mówi się, że host czyli partycja główna uruchamia potomne partycje aby one gościły inne nadrzędne OS-y). Partycje potomne nie mają dostępu do zasobów fizycznych sprzętu, to partycja główna udostępnia im wirtualny widok na zasoby sprzętowe (m. innymi na ilość dostępnych procesorów). Dostęp do wirtualnych zasobów odbywa się poprzez VMB (Virtual Machine Bus), VMB ma kanał logiczny pozwalający na komunikację między partycjami. Hypervisor wspiera wszystkie systemy operacyjne MS od klientów XP/Sp3 poprzez Vista i Windows 7 aż do Windows Server 2000/2003/2008 oraz systemy operacyjne oparte o Linux: SUSE Linux Enterprise i Red Hat Enterprise Linux. Dodatkowo wspiera modny ostatnio pomysł wirtualizacji pulpitu klienckiego (VDI –virtual destop interface) służący do przechowywania i zarządzania środowiskiem wykonawczym stacji klienckich (głownie pulpitu komputera ale też i innych zasobów). Dzieje się to poprzez oprogramowanie firm trzecich  jak vWorkspace (Quest Software), View (VMware), RDS (Microsoft) czy  XenDesktop (Citrix) lub Wyse. Źródlo - http://en.wikipedia.org/wiki/Hyper-V. Do tej pory największym wezwaniem jest wydajna obsługa grafiki oraz uproszczenie wsparcia dla portów USB.

Podczas fazy wyboru oprogramowania do wirtualizacji Microsoft mógł nie mieć potrzebnej wiedzy jakie rozwiązanie wybrać. Obecnie rynek aplikacji wirtualizacyjnych okrzepł na tyle, że wyłoniło się trzech głównych graczy. Są to WMware z ESX/ESXi 4.0, Microsoft z Windows 2008 R2 z Hyper-V oraz Citrix Xen Server 5.5. Porównując te trzy rozwiązania można wysnuć następujące wnioski:

  • bezpłatny produkt WMware ESX jest “gołym” hypervisorem podobnie jak Hypervisor-V firmy Microsoft, abstrahuje od nałożonych na niego  systemów operacyjnych, aby uruchomić system operacyjny trzeba go jeszcze dokupić
  • z racji swego doświadczenia w tworzeniu systemów operacyjnych firma Microsoft włączyła w paczkę darmowy Hypervisor-V z systemem operacyjnym typu Server, po jego zakupie paczki ma się od razu kompletne środowisko do wirtualizacji
  • firma Citrix znana ze współpracy z Microsoft w obszarze zdalnego dostępu do zasobów Windows nie mając własnego rozwiązania przejęła projekt open-source Xen (inny projekt to KVM). Oba te projekty są darmowe i bazują na dostosowaniu jądra Linux-a do wymogów wirtualizacji co napotyka wiele trudności (chociażby niechęć utrzymujących jądro Linuxa programistów do zmian odchodzących od uniwersalnego charakteru Linuxa). Dwa powyższa produkt zostały stworzone od początki z myślą o wirtualizacji  i być może dlatego są bardzie wydajne.
  • Microsoft jak i WMware mają znaczne doświadczenie w tworzeniu maszyn wirtualnych przy pomocy własnych, wbudowanych technologii

Wydaje się, że koncepcja prezentowana przez firmę VMware jest bardziej zaawansowana technologicznie. Jest schemat wygląda tak:

vSphere_Diagram_Large

Niestety rozwiązanie to nie jest tanie - http://www.vmware.com/files/pdf/vsphere_pricing.pdf