Szczegółowy  opis  składowych  DCM Collector  Agent  (CA)

Jak już przedstawiono wcześniej, zasadniczym celem CA jest monitorowanie stanu meta-­‐ danych  w  repozytoriach.  Czynności  te  są  realizowane  poprzez:  

• pobieranie  danych  i  ich  wstępną  analizę;

• dostarczanie  do  kontenera  głównego  informacji  o  zmianach  w  repozytorium; • przekazywanie  informacji  o  niezgodnościach  w  strukturze  metadanych.

Pobrane dane są zapisane w XML zgodnie z określonym formatem reprezentacji danych. Poprawna analiza treści metadanych wymaga implementacji obsługi parsowa-­‐ nia danych zgodnie z konkretną ich reprezentacją. W związku z tym kluczowymi meto-­‐ dami OAI-­‐PMH wykorzystywanymi przez CA są: listMetadataFormats(), listRecords()

i  identify().

Wywołanie metody listMetadataFormats pozwala uzyskać informację jakie formaty reprezentacji metadanych są wspierane przez repozytorium. (Opcjonalny argument pozwala  uzyskać  informację  o  dostępnych  formatach  opisu  dla  konkretnego  elementu) Struktura  formatu  odpowiedzi  została  przedstawiona  poniżej  (schema)  (Rys.  56).

Rysunek  56.    Struktura  otrzymanego  wyniku  wywołania  metody  listMetadataFormats

Wywołanie metody listRecordspozwala uzyskać listę rekordów opisujących metadane zgromadzone w repozytorium. W zależności od faktu czy repozytorium wspiera prze-­‐ chowywanie informacji usuniętych metadanych istnieje możliwość uzyskania informacji bezpośredniej o usuniętych metadanych poprzez nagłówek zwracanego rekordu XML w którym atrybut pola status dla danego rekordy wynosi "deleted". Rekord taki nie zawiera metadanych. Inne wartości atrybutu status w nagłówku rekordu to "added" czy "modiWied" w zależności od zmian związanych z metadanymi. Obrazowo schema XML odpowiedzi  została  przedstawiona  poniżej  (Rys.  57):

Rysunek  57.    Struktura  otrzymanego  wyniku  wywołania  metody  listRecords

Wywołanie metody identify pozwala uzyskać informacje opisujące dane repozytorium zawierające przede wszystkim takie elementy jak: nazwę repozytorium, adres URL dostępu do repozytorium, wersję protokołu OAI-­‐PMH wspieranego przez repozytorium, czas ostatnich zmian w repozytorium wyrażony w UTC (UTCdatetime), czy sposób nota-­‐ cji  o  rekordach  usuniętych.  

Agent CA gromadzi przetworzone dane15w obiektach klasy MetaLOM(Rys. 58). Pojedynczy obiekt MetaLOM odpowiada pojedynczemu rekordowi. Obiekty te są następnie przesyłane do CMA (C2MA).

Rysunek  58.    Diagram  struktury  klasy  MetaLOM

LMS  service

LMS service stanowi zbiór komponentów przeznaczonych dla administratorów repozy-­‐ toriów umożliwiający przyłączenie zasobów ich repozytoriów bezpośrednio do DCM. Pakiet oprogramowania jest odpowiedzialny za utworzenie i uruchomienie kontenera zdalnego platformy ABSS, a następnie dokonanie jego rejestracji w kontenerze głównym platformy ABSS. Uruchomiany w ten sposób kontener zdalny tworzy środowisko które może obsługiwać agenta CA. Zarejestrowany kontener zdalny jest konieczny aby nastą-­‐ piła  migracja  agenta  CA  i  była  możliwa  dalsza  komunikacja  pomiędzy  nim  a  CMA.

Komunikacja pomiędzy CA a CMA jest oparta o zmodyWikowaną postać protokołu JICP (jicpABSS) oferowanego przez JADE-­‐LEAP zapewniającą bezpieczną komunikację pomiędzy kontenerami. Mechanizmy bezpieczeństwa uwzględniają szyfrowanie danych w oparciu o wykorzystany protokół SSL/TLS oferowany w Javie oraz wzajemne uwierzy-­‐ telnienia  oparte  o  podpisane  cyfrowe  certyWikaty.

Pakiet LMS Service wprowadza również mechanizm guard threads control który polega na kontroli komunikacji pomiędzy kontenerami i ewentualny restart konte-­‐ nera  zdalnego  jeśli  komunikacja  z  kontenerem  głównym  zostanie  utracona.

Schemat  działania  LMS  Service  został  przedstawiony  na  rysunku  59.

15. Do  realizacji  parsowania  wykorzystano:  DOMparser  stanowiący  składnik  Xerces2  Java   Parser  2.8.0.

Rysunek  59.    Schemat  działania  serwisu  LMS

Poniżej  przedstawiono  możliwości  uruchomienia  usługi  LMS:

Aplikacje  Javy:

public  static  void  main(String[]  args)  throws  InterruptedException    {        LMSAgentContainer.getInstance().start("./conf/lms.properties"); }

Środowisko  serwletów  lub  JSP:

ServletContext  sc  =  getServletContext(); InputStream  is  =

       sc.getResourceAsStream("/WEB-­‐INF/classes/lms.properties"); Properties  props  =  new  Properties();  

try  {  props.load(is);  }

catch  (IOException  e)  {  e.printStackTrace();  }

LMSAgentContainer.getInstance.start(props);

Przedstawione powyżej metody obrazują również dwa rożne podejścia w dostę-­‐ pie do pliku lms.properties. Ścieżka dostępu do niego może być wprowadzona jako ścieżka systemowa lub w ustawieniach serwletów. Ten drugi przypadek jest stosowany również i w przypadku uruchomienia usług LMS poprzez wywołanie metody:

SparkOAI.startService().

ServletContext  sc  =  getServletContext(); String  scPath=sc.getRealPath("");

sc.log("lms.properties  path  Path"+scPath);   InputStream  is  =

sc.getResourceAsStream("/WEB-­‐INF/classes/lms.properties"); Properties  props  =  new  Properties();

FireOAIRepository  localRepository  =  new  MinorOAIRepository(); SparkOAI  oai  =  SparkOAI.getInstance();

oai.setAutoMessageAccepted(true);

oai.setFireOAIRepository(localRepository); oai.properties  =  props;

oai.startService();

Strukturę  zależności  pomiędzy  komponentami  LMS  i  SparkOAI  przedstawia  rysunek  60.

Przykładowa  zawartość  pliku:    lms.properties

#  configuration  for  LMSAgentContainer  version  1.2 #  IDENTIFICATION

#  LMS  prefix  is  needed  to  send  CA  to  repositories

#  The  lack  of  LMS  prefix  disables  sending  agent  to  peripheral  container  is  possible

lms.container_name=LMS_unique_identifier

#  COMMUNICATION

#  IP  address,  where  main  container  operates  (ABSS  server)

lms.abss_host=149.156.114.77 lms.abss_port=8877

lms.local_server_port=1000 #  default  value:  9999

lms.local_client_port=2000 #  default  value:  lms.local_server_port+1   #  SSL/TLS

#  Transmission  is  encrypted  and  authenticated.  Authentication  is  performed,  if  paths

#  to  keyStore  and  trustStore  files  are  specified  and  these  files  are  available

#  Unix  example:

lms.keystore_file=./ssl/abss_privkey.jks lms.truststore_file=./ssl/public_store lms.authentication_phrase=PASSWORD

#  NAT

#  parameter  should  be  set  when  NAT  is  used

#lms.public_nat_ip=83.17.246.230  #default  value:  null #  HARVESTING  MODE

#  true  means  access  to  metadata  by  HTTP/HTTPS  protocol

lms.pmhoai=true

lms.pmhoai_url=http://81.26.9.91:8080/Minor2/OAIServlet

#  METADATA  FORMAT

metadataPrefix=http://fire.eun.org/xsd/strictLreResults-­‐1.0

#  MONITORING

#  delay  (ms)  no  answer  from  main  container  to  restart  peripheral  container

#lms.delay_jade_restart=30000 #  default  value:  30000  =  30  seconds     #

#  timeout  (ms)  no  transmission  CA-­‐CMA  to  restart  peripheral  container

#lms.timeout_cma_communication=1800000 #  default  value:  1800000  =  30  minutes #  LOGGING

#  LMS  logger  uses  jade.util.logger  -­‐  based  on  java.util.logger

lms.log_level=INFO #  default  value:  INFO #  accepted  values  for  lms.log_level

#  SEVERE  –  serious  failure

#  WARNING  –  potential  problem

#  INFO  –  informational  messages

#  CONFIG  –  configuration  messages

#  FINE  –  tracing  information

#  FINER  –  fairly  detailed  tracing  message

#  FINEST  –  highly  detailed  tracing  message

Wymagania stawiane lokalnym systemom w celu zapewnienia poprawnego dzia-­‐ łania  serwisu  LMS  schematycznie  przedstawiono  na  rysunku  61  [96].

• jeden  publiczny  port  TCP/IP  otwarty  na  połączenia  przychodzące  z  serwera  ABSS • jeden  port  kliencki  dla  połączeń  wychodzących

!