Som du ved nu, DataDirect XQuery tilbyder en nem og effektiv måde til at indsamle data tilgængelige i en række data kilder og formater ligesom relationelle databaser, XML-dokumenter, web-service svar, flade filer, EDI-filer og så videre.
Men som du også godt ved, verden af datalagring og adgang er meget rodet , Og der er (og altid vil være) protokoller, datalagre og formater, der ikke er understøttet ud af boksen selv ud fra de mest avancerede data integration værktøj. For eksempel, senest et par DataDirect XQuery brugere har spurgt om muligheden for at få adgang til LDAP bibliotek tjenester til at oprette rapporter, der indeholder oplysninger, der findes i del i rdbms og delvis i LDAP mapper. DataDirect XQuery ikke understøtter LDAP telefonbøger ud af æsken, men det understøtter muligheden for at udvide antallet af understøttede datakilder gennem flere forlængelse metoder, ligesom brugerdefinerede URI resolvers, Java forlængelse funktioner eller sædvane indsamling URI resolvers.
Så jeg begyndte at tænke over, hvad der ville være den bedste måde at eksponere LDAP bibliotek adgang fra XQuery, og jeg kom op med følgende krav for eksempel, som jeg ønskede at stille til rådighed for vores brugere:
-- Adgang til LDAP-biblioteker skal være yderst skalerbar: samme måde vil vi stole på XML-streaming forarbejdning og sofistikerede SQL generation og resultat indeholder forbrug, er vi nødt til at gøre LDAP adgang arbejde i en streaming-mode (i øvrigt en af brugerne er interesserede i denne funktionalitet var planer om at processen hundredtusinder af LDAP optegnelser fra XQuery; bedre gøre det i en streaming-mode!)
- Adgang til LDAP-biblioteker skal være tilgængelige både som en brugerdefineret URI resolver (det er meget naturligt for brugeren at tænke på doc ( "ldap://localhost: 10389 ?...") Webadresser, når adgang til LDAP ressourcer), og som Java forlængelse funktioner (som kan give mere fleksibilitet, når parametrene er dynamisk specificeret)
Det egentlige arbejde var at skabe en StAX interface i stand til at forbruge de resultater, der returneres af LDAP search operationer; udsætter, at interface, enten som en brugerdefineret URI resolver eller en Java-udvidelse funktion var en meget simpel opgave.
Resultatet af denne proces er knyttet her . Hvis du ønsker at prøve det, skal du blot sørge for, at dine classpath omfatter den mappe, hvor du udvide ZIP-fil . Så, en enkel XQuery gerne vil starte retur du data, som er lagret i din LDAP Directory Service (Jeg har prøvet disse eksempler ved hjælp af Apache Directory Suite):
doc ( "ldap://localhost: 10389? auth = simple
& hovedstol = uid = admin, ou = system & amp; pwd = hemmelige
& name = ou = brugere, ou = system & filter = cn =*")
For mig er dette et resultat, jeg får:
; ...
Som man kunne forestille sig, at data ser ud som XML, og på dette punkt kan du håndtere det, som om det var gemt i enhver normal XML-dokument refereres til via doc () funktion.
Så går du for eksempel ønsker at fusionere personoplysninger, som lagres i LDAP med andre oplysninger, der er gemt i relationel database, for eksempel antage, at du er en telcom selskab, og du ønsker at hente alle oplysninger om dine abonnenter, som selv mobiltelefoner med GPS-kapaciteter i et bestemt postnummer:
(
for $ abonnenter i indsamling ( "abonnenter")/abonnenter,
$ telefoner i indsamling ( " ; telefoner ")/telefoner
hvor $ telefoner/id = $ abonnenter/telefon og
$ telefoner/GPS = "ja" og $ abonnenter/postnummer = "01880"
vende tilbage
(
doc (concat ( "ldap://localhost: 10389?
auth = simple & hovedstol = uid = admin, ou = system &
pwd = hemmelige & name = ou = brugere, ou = system & filter = uid = ",
; $ abonnenter/id)
)//email/tekst ()
)
(
concat ($ telefoner/brand, "", $ telefoner/model)
)
)
Pretty nice, er det ikke. Det ville returnere et resultat som dette:
<; telefonen> Apples iPhone II
;
A lignende fremgangsmåde anvendes, hvis du vil udsætte en LDAP bibliotek via Java forlængelse funktioner, og forlængelsen funktion mekanisme er mere fleksibel, og det giver os også en chance for at cache nogle fabrik/forbindelse objekter til LDAP service, så kan det også mere effektiv afhængigt af det problem, du forsøger at løse.
Den mekanisme, skrev jeg som et eksempel baseret på en enkelt Java-klasse med en entreprenøren og en metode; konstruktøren bruges til at skabe fabrikken genstand, der anvendes af opkald () metode, der rent faktisk udfører LDAP søgning. Fra en XQuery synspunkt, tingene ser sådan her ud:
(: erklære namespace gennemførelse af Java-udvidelse funktioner:)
declarenamespace ldap = " ; ddtekjava: com.ddtek.ldap.ldap ";
(: erklære konstruktøren og metoden fungerer, som de er set fra XQuery:)
declarefunction ldap: ldap ($ contextFactory som xs: string)
som ddtek: javaObject eksterne;
declarefunction ldap: opkald ($ dette som ddtek: javaObject, $ server som xs: string, $ port som xs: string,
$ pwd som xs: string, $ auth som xs: string, $ principalName som xs: string,
; $ nameToFilter som xs: string, $ filterExp som xs: string)
som dokument - node (element (*, xs: untyped)) eksterne;
(: skabe en "ldap" klasse objektet ved hjælp af en specifik fabrik klasse:)
declarevariable $ ldap: = ldap: ldap ( "com.sun.jndi.ldap.LdapCtxFactory");
(: fuldbyrde opkaldet () metode at angive de nødvendige argumenter:)
ldap: opkald ($ ldap,
"localhost", "10389", "hemmelige", "simple", "uid = admin, ou = system",
"ou = brugere, ou = system" ;, "cn =*")
erklære variable $ ldap: = ldap: ldap ( "com.sun.jndi.ldap.LdapCtxFactory");
(
for $ abonnenter i indsamling ( "ldap.dbo.subscribers")/abonnenter,
$ telefoner i indsamling ( "ldap.dbo.phones")/telefoner
hvor $ telefoner/id = $ abonnenter/telefon og
$ telefoner/GPS = "ja" og $ abonnenter/postnummer = "01880"
vende tilbage
;
(ldap: opkald ($ ldap,
"localhost", "10389", "hemmelige", "simple", "uid = admin , ou = system ",
" ou = brugere, ou = system ",
; concat ( "uid =", $ abonnenter/id))/ldap/post/e-mail/tekst ())
(concat ($ telefoner/brand, "", $ telefoner/model))
;
)
Begge strategier vil forbruge de resultater, der returneres af LDAP-søgninger i en streaming-mode, takket være StAX grænseflade bruges til at interface den brugerdefinerede URI resolver og Java forlængelse funktion til DataDirect XQuery. Du er velkommen til at grave i vedlagte kilder for at lære mere om, hvordan det virker, og/eller at forbedre/ændre Problemet i dette eksempel.
Så et interessant eksempel, men hvad er det punkt, jeg forsøger at gøre her? Som jeg nævnte før, data i dag er til rådighed på en lang række butikker og formater, og tilgængelige gennem en sådan mangfoldighed af forskellige protokoller og API'er, at det er næsten umuligt for dataintegration værktøjer til at støtte alle dem ud af æsken. Men så længe de data, integration værktøj giver dig mulighed for at udvide sin adfærd gennem fleksible og skalerbare mekanismer såsom en beskrevet her, og så længe de data model internt understøttes af værktøjet (XML, i dette tilfælde) er kraftfulde nok til at rumme næsten enhver form for fysisk data model du skal have adgang til, så du stadig kan udnytte kraften, fleksibilitet, skalerbarhed og ydeevne, at sammenlægning værktøj tilbyder. Og det er helt rigtigt for DataDirect XQuery.
