<%BANNER%>

Schema Exportation and Integration for Achieving Information Sharing in a Transnational Setting

xml version 1.0 encoding UTF-8
REPORT xmlns http:www.fcla.edudlsmddaitss xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.fcla.edudlsmddaitssdaitssReport.xsd
INGEST IEID E20110320_AAAADC INGEST_TIME 2011-03-20T18:57:26Z PACKAGE UFE0009360_00001
AGREEMENT_INFO ACCOUNT UF PROJECT UFDC
FILES
FILE SIZE 38561 DFID F20110320_AABVJX ORIGIN DEPOSITOR PATH patil_m_Page_69.jp2 GLOBAL false PRESERVATION BIT MESSAGE_DIGEST ALGORITHM MD5
4a62c39e6535f070b2ac2aa91333b4c5
SHA-1
898aecab17faf79179dc8d4cb5bf283e3a3ca8aa
35731 F20110320_AABVCB patil_m_Page_64.pro
da67c15288add5207dc00abf8a951629
153af5828c9c583240e4fecaef85503a01cc163d
196947 F20110320_AABVEZ patil_m_Page_40.jpg
f377478d7947366524d9146aed6c1c77
96c5251d936c29411acb47e9cb8cdc104e2407a8
1053954 F20110320_AABUVE patil_m_Page_15.tif
fa6701d911aea53874a33f53cb3d13dc
4be2fb90a6eb79d6e58a88126d2bc88d54732eb8
87489 F20110320_AABVJY patil_m_Page_71.jp2
9262840f5b5953d5e0b43e43769e464f
c75c81a250289f4f6362167d1575ae44d78c25cc
46486 F20110320_AABVCC patil_m_Page_65.pro
dc69adce3a6e73cd677baf22a75f616d
456128a850cb66062dcd125bf04498a9c792371c
F20110320_AABUVF patil_m_Page_16.tif
617014d4d6a3da0e975c7382b26cac7b
d2a626b305afc57e7ef150fd6c144affe09b70fb
102575 F20110320_AABVJZ patil_m_Page_72.jp2
ed1b9277907ff72ff4dbbbb5432bd72b
5ddc4972cf41c3173427064d21fd719cd382d971
67763 F20110320_AABVHA patil_m_Page_68.QC.jpg
d854a2d1c7ff0a89138ff6aa9f836013
c3dd1526cc47d33f6ecf84743090be7bde0a5f09
45164 F20110320_AABVCD patil_m_Page_66.pro
1a3180864fd6f43804bbe6cb658548d0
4edd99ffbe40f5801fa993fb9ea3a2509a3e79c6
F20110320_AABUVG patil_m_Page_17.tif
70c97af17f42d2c16d6f828bad93c27f
5da5101079c45b7dcea41d8a36479dc1c7bca9da
84684 F20110320_AABVHB patil_m_Page_69.jpg
57d5c5dbddc95066bd334492a988ed23
5ad807ca4f6278ad17e343ae3b8d90b89ae91ba0
47383 F20110320_AABVCE patil_m_Page_67.pro
49905048ffa1f51430d652861ee20c94
4072f0f5bed444085774e85dbcbb113e74b0b604
F20110320_AABUVH patil_m_Page_18.tif
3300e7c221140085f68452f1038e10c6
d748c8b65010ebd13d22418ca3210396fbb6237a
27730 F20110320_AABVHC patil_m_Page_69.QC.jpg
46e6db325c804131101ef0baa84be566
9dcae2eb4428d87b0cb2b56eacdc2ed21f6b7aee
44679 F20110320_AABVCF patil_m_Page_68.pro
5dee5e18b6e7be1b5489ced41fa9e8ee
559fe103e47330ebd7dd1b51ffdd4b187a84099c
44472 F20110320_AABVMA patil_m_Page_54thm.jpg
548ce21841d92ccd8274d4afe3690684
1ed1da48314a9c60bda3e4f10db608992908618f
174408 F20110320_AABVHD patil_m_Page_70.jpg
4a7dab41999995ec5d45021f9305f0a0
77581c2db0b756548f5d2fbcc867e86c90f96407
16831 F20110320_AABVCG patil_m_Page_69.pro
049058abbcf188208663da3ae2525cc7
9e70be8341473e682fe277edcf660f4578e75c02
F20110320_AABUVI patil_m_Page_19.tif
8c3c8309433f8f6e1b5ac44468170f01
2db79ef2bc9b0cb8abef5ef8c63190c5e82b786d
24830 F20110320_AABVMB patil_m_Page_55thm.jpg
56ce3f1aeaebaad9a147b10b75c07732
a8620869d68a38bc35e3db71fa0b37c66ad9b07c
171709 F20110320_AABVHE patil_m_Page_71.jpg
692b7eef0ab97e18c4651f3274cf5890
b9dd62c799353131d3695bc459d54f8c3d559789
41711 F20110320_AABVCH patil_m_Page_71.pro
fbf16462a02a4de9afdb86fac8164208
3f45ec627d3771fb7155bb724c4451bde4d4b99a
25271604 F20110320_AABUVJ patil_m_Page_20.tif
8b5fb49b91f7f9cd0f6a24c4f856fb90
3941f81a6bc37529c6ef0c8263759c189530c2ea
24627 F20110320_AABVMC patil_m_Page_58thm.jpg
d21033f3d915767a4dd60e439a5f730f
e6b7eb8e3179672f43492d10beb04e4f12254250
60706 F20110320_AABVHF patil_m_Page_71.QC.jpg
3c09a0bb22fe77530bc4e4fe9a0e58d7
d16de8867a35bceeebd50f6abfcbac1dd417c426
49204 F20110320_AABVCI patil_m_Page_72.pro
8d76e7e202655224f3baf53132456cbe
0e20b0ec2456900d00fc512a510ee482a35bc9e3
F20110320_AABUVK patil_m_Page_21.tif
f5a1a79c9c3253ef4347fb87c5212819
54544f3173ebc352c690455da3b837904ad0372f
43797 F20110320_AABVMD patil_m_Page_59thm.jpg
a7dcd9c4c0cbec7427ad1b8a161cfc47
0aa866b7893554ba0d78a4bd9f8b6dccd096c132
204979 F20110320_AABVHG patil_m_Page_72.jpg
db23601b879481a5e01868c30caf90b5
0ab7e57cfc892e97d6251e1a404e479cd930c57b
45387 F20110320_AABVCJ patil_m_Page_73.pro
c9dd17910ff6053e06befa61b767be94
bab935ba5de00574a87f36b1894ced8e7057b2a6
F20110320_AABUVL patil_m_Page_22.tif
4cdca04b1078095faf42f0ee2bdcb10e
03f13bb390d5052cefaca18d03c5bee9e91bad0c
48219 F20110320_AABVME patil_m_Page_60thm.jpg
37fce6797840219c62be78e14a5defeb
594b4ba57eb2346124c54d4544d7e2d0998dcc56
72007 F20110320_AABVHH patil_m_Page_72.QC.jpg
8e6e7dad16ed4b1cf3623b37c13b06e8
85aadc9b41954fb8fdc3fc7ee299e9961b6a7667
57915 F20110320_AABVCK patil_m_Page_75.pro
55f7a0b4a9de74eeb6f7f3b954834053
d74e5dfd0a6b4801979141aa51afd6b7c0ab2a70
F20110320_AABUVM patil_m_Page_23.tif
c2cce52e3d08e8932ce63303c69ef9b5
0fcc3f6df1f4f62805f245805971e61848441258
21794 F20110320_AABVMF patil_m_Page_61thm.jpg
a52831d17010cae1a34d973b7a8822e9
7afd100fd66c0be93d53ecdeda8bd6c629647566
192360 F20110320_AABVHI patil_m_Page_73.jpg
a6d69419c417db38e929ee23ac0b4db7
49ba253a693fba1710377c919804eaacd323b46f
23358 F20110320_AABVCL patil_m_Page_76.pro
d540ccb26879c5de0f72ac64864c89be
dab380d6e6126eb021db9d3be3ae1ba78ca348a0
F20110320_AABUVN patil_m_Page_24.tif
eabf2f6c262a087ce7bb72eaec29be60
22664ef313d6469bfea4eace622448d6fa98335c
22315 F20110320_AABVMG patil_m_Page_62thm.jpg
daa9ccdef507dcdcb2855fe2d9d42975
f285e81e2f93ea3b1dc6f4734e39de07e09d1778
72581 F20110320_AABVHJ patil_m_Page_73.QC.jpg
177cbfb21b624dc523082685f23429fe
6e82bf741de7198bd292367e5a79be9b0abd3699
19286 F20110320_AABVCM patil_m_Page_77.pro
e7db3f4c13ba1d9d458fe46b93b6a657
cfdb3198a86fd7bae4e7ef19065388ed7d0f8054
F20110320_AABUVO patil_m_Page_25.tif
eeaef501aae310bbcc0c61cc4ee3455f
f4413a57302a6a30acb9ea84e7c30b8b30acd1ec
23862 F20110320_AABVMH patil_m_Page_63thm.jpg
2dc5e4b6d7993e901860d91097f775cd
1f070d18fb6d0bb630bd8c0a6841c30f79932bd2
210281 F20110320_AABVHK patil_m_Page_74.jpg
116272e039dda3e73dab544bc62f7f17
1df0b4b37fe5446a071a500b177dddfac8780ce0
53299 F20110320_AABVCN patil_m_Page_01.jpg
b8edb74190afba3ce7a19fbcbc1cea8e
db15355d3b67d9f389dac204491f242a547aae09
F20110320_AABUVP patil_m_Page_26.tif
c2a0227689c3130649016e85377aed74
16f57114f56139bec4cb96f99c9b4012222e82f4
18030 F20110320_AABVMI patil_m_Page_64thm.jpg
d9a2955e4249894ae3b8f8cac0e61047
384aaaf7c7447ef0a06c1192f15bf2c705b0f40b
250676 F20110320_AABVHL patil_m_Page_75.jpg
8abf4cacb3b032eb0cafa07f09eea3b5
2a8861399b4aafc44e8d82626e6146d4e11d8713
17841 F20110320_AABVCO patil_m_Page_01.QC.jpg
e4f4a3d2fe2614512d717bb01558e637
1887ebba7011831461cdb442afdb855ecdadbae7
F20110320_AABUVQ patil_m_Page_28.tif
01b3b069cfc77d7732d094980125fc6a
dd19e129265299fb7a79bc6825bbeadad367da5c
30998 F20110320_AABVMJ patil_m_Page_65thm.jpg
478576eedd1551c1fb19a3773c200221
c09b14a50fbca6fe1570a03d40c2b0bf8d74544d
86462 F20110320_AABVHM patil_m_Page_75.QC.jpg
f70e70d25ca45d29e96c167a1c004729
1f727cd2f8efa77c2c5f90818484006a81d3aac0
15483 F20110320_AABVCP patil_m_Page_02.jpg
b532bf3e7cc0390755953713b9a69960
c96647e27aceb3ef30158dd6e9999491d40ba99d
F20110320_AABUVR patil_m_Page_29.tif
ca40c1d1ea19918572fd7fea4bbd0589
711695d42161ee69118aed1a4ad26671dafcdb7b
31382 F20110320_AABVMK patil_m_Page_66thm.jpg
b0f5d019569efb54ea550a9dabaeb636
b856fb6a7fa1fe66d2a42cc61e76cdb370d59fc1
109575 F20110320_AABVHN patil_m_Page_76.jpg
5f3795de2c0e6f6a2b7f3e0a99c1fd0d
003ee549717b769c258cf800f8f1e639696a070a
6224 F20110320_AABVCQ patil_m_Page_02.QC.jpg
3bfdd181c4ddf3965a4057b4409c85bb
bb11e2bb0a9045c2cb573cf3dca6b405440484c0
F20110320_AABUVS patil_m_Page_30.tif
0fb315f65cc7917458b8b5d960c6f491
5a3f19d2fcb905f99e2f587ce95d6caa40082fff
31884 F20110320_AABVML patil_m_Page_67thm.jpg
14715b86abf58dd56526ef6fc95a852a
d7c6d5e89853d261636ce3a7a692be72977500aa
37724 F20110320_AABVHO patil_m_Page_76.QC.jpg
84dab40b75449567ce07d5d38a8eb57b
4b1a7a0fed2c51a5480724e5b0f7324b2600ae2e
15382 F20110320_AABVCR patil_m_Page_03.jpg
55cf5b90aa156667e184a2c7b65cca36
9eff2aae28fc2594545597b4c1da97cf6987007b
F20110320_AABUVT patil_m_Page_31.tif
71bd8e545d40fa9145ba18923074629e
a5a578c0d4bdec925b1cc7c6751cd1c368a6ecc7
21612 F20110320_AABVMM patil_m_Page_68thm.jpg
189bad45881f9693f3edca5ed5446910
9e714b128866002c1466c620b05a0c70e378dd5e
88889 F20110320_AABVHP patil_m_Page_77.jpg
d2a7590e9f80e832f5c5fb29ec5c1c8b
c62a826e4e9fe287cf72e453da38cdc9a012db7e
5330 F20110320_AABVCS patil_m_Page_03.QC.jpg
f48b1a581f43116d43a9de4401a6fcf4
72062fba631457a90079e559883fa7f4cc0d062e
F20110320_AABUVU patil_m_Page_32.tif
079688c7e1c4192d6e305beb59b8241a
7ffc47f5b1e49c1ada96efb7370adcfb161ebab4
8786 F20110320_AABVMN patil_m_Page_69thm.jpg
e1c467ba70a7aadac7274c56e9957213
77a4372a45016b82079a04c28d045e1d13ac8cbd
34258 F20110320_AABVHQ patil_m_Page_77.QC.jpg
64b555d4a8b2180db36f8dab2457b9a5
6804a8e94c8afbeca197ab54060913c986d05254
133534 F20110320_AABVCT patil_m_Page_04.jpg
296b649a96fc37c7147431ffa8f9b21d
b865fde45f618df226263b5c14f393114ab4d5e5
F20110320_AABUVV patil_m_Page_33.tif
bf4329532b548159dfeae6a9fde94429
cd53eed252599ad50a395db29863e8de463a8cfe
18951 F20110320_AABVMO patil_m_Page_70thm.jpg
df3d6693cbcf62e12f3108281c02adc2
c61d28ee1348afeca9eb264db2996a2fc8975451
25997 F20110320_AABVHR patil_m_Page_01.jp2
8514c05c6d67d6a1e04e6633b6ecb486
cab007b3ba1bf30bcecf06b494dd98078471b60f
F20110320_AABUVW patil_m_Page_34.tif
da66ba2505f2b027903fbf7341299ed3
2d35fe2c08412d9915a0dfd19fba8b6fe2c803e9
18329 F20110320_AABVMP patil_m_Page_71thm.jpg
6165eac9e3b10896ad49c54a294808d6
bc70ec7ea5bfb87d40b80f3104294513eeb649c0
6038 F20110320_AABVHS patil_m_Page_02.jp2
f1d4780126a22b54f0d95ca943a1192e
b59c5734718a7b001b81d2ceee11b48c01847cb6
87552 F20110320_AABVCU patil_m_Page_05.QC.jpg
c50791ba0c8e17fbcaab1e3ad075217e
86cc9bf8930080098a896a0d5d4b8253d16e2682
F20110320_AABUVX patil_m_Page_35.tif
28dc907b205cc72ea38db54245558c6e
d9fa080562b6a2e71bdbfb98e5f6d0fece765a88
22692 F20110320_AABVMQ patil_m_Page_72thm.jpg
f153e1b023b503965f290fed3ac701dc
7bffa63fdbe62929a5d2e77a5f3bc98ddcf2aa4d
6043 F20110320_AABVHT patil_m_Page_03.jp2
d1b2ee224f04e0967388b79deadfe776
d8e9d92847507d2fcb88ec1184cb9f2f1ed672a7
340670 F20110320_AABVCV patil_m_Page_06.jpg
bd5c70c681f88b1f9f70aa5da0d4198b
288896e83d5ba7859771dad470fcc3c5bdfd1a75
231560 F20110320_AABUTA patil_m_Page_05.jpg
23c4f626c51dcfd053c89ee5ed798454
593c27584ff750605eafa72d54a27d525603e25e
F20110320_AABUVY patil_m_Page_37.tif
f6641e3c864958898c782bd1e10f4474
731dd6d9b6e64bde4b9e610b75a241c0b1410c22
22750 F20110320_AABVMR patil_m_Page_73thm.jpg
4c08c2a1945c934a628512009c4f41c9
b982cf5d277bfed382398faf751b54ccb776e5b3
67142 F20110320_AABVHU patil_m_Page_04.jp2
52015a08107e4fe3167adade7b3c88fc
468e783c67c78b2cb227de937b9b5ea720965b1e
117341 F20110320_AABVCW patil_m_Page_06.QC.jpg
d4aa84498c4234fd6eba2a3beb58c18f
185d3c3e3773d9c3007ceaeb9fb3303d0b156541
195490 F20110320_AABUTB patil_m_Page_50.jpg
c782a6bcf6ac86fc0dbeb542a1489cf2
ce19b834cd5cf9fb13fa59a52fe87a41110352ac
F20110320_AABUVZ patil_m_Page_38.tif
cf2acf7cd2d11fc29750a52e0771e9f4
22dfc25f7aaa634ccc0ffa412f9564930389e8cb
24811 F20110320_AABVMS patil_m_Page_74thm.jpg
4387b2fc311de87f1e0ce9289a90de04
481ed7e8f2241df72f522e34634ccf0e71bf60dc
1051970 F20110320_AABVHV patil_m_Page_05.jp2
921846d713631a56cc906a8814427633
320f267a64a8c1806a1c038847bf76e275e95e18
138973 F20110320_AABVCX patil_m_Page_07.jpg
1bec9c6ee38d10bbb188df80b3c1f2f7
207fcff401a3b1cf14750c7e041e499bf760a4d5
182098 F20110320_AABUTC patil_m_Page_12.jpg
b573ad9b821ba03c3c6c599bef129f1b
42dd88532cb3a1e895a8d7f244544be0929ed1b4
30162 F20110320_AABVMT patil_m_Page_75thm.jpg
44d68b1bbdf0adf1951ca26c86361314
89dacb10fe0c8e7662f4df375866c16e1d345101
1051982 F20110320_AABVHW patil_m_Page_06.jp2
5bfd8ac544261cb9f012fa2945e0ceed
754e0e4c87325aad604c46d30ac34407743e5534
1455 F20110320_AABVAA patil_m_Page_03.pro
e5bf2fc9d0df2d4a3e2d98a918ee11cb
67a9ce8674a432720f4323c4187366b2670cd16a
60404 F20110320_AABVCY patil_m_Page_07.QC.jpg
54b70d32de3df854c4f93391261bf200
e4d872660efb0d863dac12cdeed58cddbd41d5c6
3621 F20110320_AABUTD patil_m_Page_29.pro
748b81bb100100ce9dfec7b93b7bd78a
f7437f6349a87dfd230a0c5504efa92752acc9bf
2071 F20110320_AABUYA patil_m_Page_18.txt
e067c483261ec25515fe892233295f3a
644f5f621ef102b6482bb8c14b697827ab72f157
11598 F20110320_AABVMU patil_m_Page_76thm.jpg
238f998acdd9482d2719f000a0c0a4d2
8f3a5778769d40537d5edb19ff16b9d787f286a6
888409 F20110320_AABVHX patil_m_Page_07.jp2
4fbe81f891b7309ca119f75791cfb8b4
20f9955a04b3df4705914bb9907583c46d2d762a
29486 F20110320_AABVAB patil_m_Page_04.pro
afba8d310a6f12fcc69ffb4f8eea90e7
e68ccaa5a447b3e3f978cb84cab736592f1c93cc
77992 F20110320_AABVCZ patil_m_Page_08.jpg
68777736688e21119adb31a8b10d328a
f7a30c31b1f8e7cc24de107a1b2f20c502e8d18e
65725 F20110320_AABUTE patil_m_Page_36.jpg
e5cb23db0142ea8dcd382614e32cf693
5663f3222e0f7dd87cfd86efccbbfe62cd7b2bef
244 F20110320_AABUYB patil_m_Page_19.txt
1f5d44d672601f7865497a2a6565861c
057e9b7ffede37d154c6622c9231a446533bb02d
12046 F20110320_AABVMV patil_m_Page_77thm.jpg
5069bbd6fa4c2f3b1f90fbaaca1d2cf6
6950492b66e5def016d21c8f79bcbfb66fe32c79
1051985 F20110320_AABVHY patil_m_Page_09.jp2
5d0787dc63cb94d9bbdfb4da84136774
3ad6fbb6f81d397836770ce702d76fbd426ff5c5
65174 F20110320_AABVAC patil_m_Page_05.pro
f3a33fa7ac7f440b072a16182dfb7bdb
a761e5dd93253cb4bac6c98b67b7a1ed84a38d4c
2008 F20110320_AABUTF patil_m_Page_23.txt
29b2c776b60b36c898ef08f1f94743f6
22e6781716851ea6e1d79090febfbed22996bf67
1060 F20110320_AABUYC patil_m_Page_20.txt
7f3338a3e7e2f4ed5aa35249d0c39487
8c32496c6236f8cf3ce42b2758a19ca62ee9c2b4
1092037 F20110320_AABVMW patil_m.pdf
cc4c9ca9cdc0ff44fb924430d18db994
f63ece2a24b15b4b419cc75b7ea0026abe20881e
99874 F20110320_AABVAD patil_m_Page_06.pro
70149d4cde7a8908f1ea7307d3618e61
1e89ead90bebfaf67cdbfa8e6886c1db51b0f110
70029 F20110320_AABVFA patil_m_Page_40.QC.jpg
d7a3623ee5ccd808c11334b6e6809d42
9e233e3078ca2763a230f88f778e240a6c20678c
1895 F20110320_AABUYD patil_m_Page_21.txt
b5c2b586c48c415fa555ad1989efa54c
92bb0b17c92e6351cdfc6be4794c38ded9a5b40b
89954 F20110320_AABVMX UFE0009360_00001.mets FULL
71f6512b4106410b890532e7f05b895c
4421f3b2395bfeaaa1b2c28f7e4e95e6d4b564f0
87440 F20110320_AABVHZ patil_m_Page_10.jp2
7fd013d7608414a9e87a0da292ba0f5e
94fb4e6a206823a671ad17bce9176fc81a287db7
52065 F20110320_AABUTG patil_m_Page_60.pro
64f00d6807d8408e84154f7c125c3f0a
0f2e2052a7402eaffd1bf5472a1842ac6380b925
145428 F20110320_AABVFB patil_m_Page_41.jpg
c2a3c82b4bfdf131f43fd1d173e4426a
9ce86189860206e54a889a923a0b24c6afba9bc2
1930 F20110320_AABUYE patil_m_Page_24.txt
81d494e509ec2975c6be97f37b19dfbe
7783860b440583ddc620fce0bab40508c4e9dabc
31779 F20110320_AABVAE patil_m_Page_07.pro
d7fc4848936e25c376cc9b5ca43a4e6c
1999a5528cbcc1540d0aea187a7ffc68617cada4
66444 F20110320_AABUTH patil_m_Page_38.QC.jpg
e92b59e320643dc3a4c2830d485687ed
e47a69d757589aceae928c42659ba70e1ba94407
47971 F20110320_AABVFC patil_m_Page_41.QC.jpg
1b27510b0e13e6d2afac2e17f59fcced
23a85728d5b4b964b1193001760187ba749f8b28
874 F20110320_AABUYF patil_m_Page_25.txt
6ba3c8d3aa368e469dd7dc2f483dc815
161c39b7552ac86c34e13c2e71fbb8e6abec9d5b
12514 F20110320_AABVAF patil_m_Page_08.pro
f31bcf6fc060950ba0f2fdedcca0f897
f7e672b2cb4b5fc00fc0a13194910c1f6ad2cdc0
100523 F20110320_AABVKA patil_m_Page_73.jp2
7276d56b12cd13dd6fab3a0bbb6e5c3d
947f2183aa5018d98aaa75cdee847c8434ee04a3
1815 F20110320_AABUTI patil_m_Page_66.txt
b859296e4148c08b833d7e102bb046b7
322352e220eac85da5d119b84d38888774331da8
206958 F20110320_AABVFD patil_m_Page_42.jpg
708b1a145845a0a9e53382edd3e4f110
5830be31120fff6014cfe238d9fbf745b6e6a212
1146 F20110320_AABUYG patil_m_Page_26.txt
b9aa630ddac0f76ca30ce3de583ca3fc
f2d5fa81ca2b8213de579ed96ad3b1739cf2d8f1
56897 F20110320_AABVAG patil_m_Page_09.pro
8b6fd30073666cca42771cd717bd5b13
5a8507b0935f18ca2d19c53cfba1c0f9bc29b699
109181 F20110320_AABVKB patil_m_Page_74.jp2
a8240716fa512a7f244ce3c8d42076e7
897a582e16e6b671866f505c2bf016f107673ca6
323 F20110320_AABUTJ patil_m_Page_47.txt
7ef34ce75aead711e5957d30a785357b
b961c06f1c9f0d5dc648e2269bd60b1a536baba8
92131 F20110320_AABVFE patil_m_Page_42.QC.jpg
d345727a07cd8e511ec0af9bfb697562
b3bbfce6dfdbe0b684c0a0ddb01b3d9b00413e09
2070 F20110320_AABUYH patil_m_Page_27.txt
6d59e6cd9f46add5343ed5f59a8ca34c
784430f194f0ed62c1e82b1686850eb9b25f73a0
38735 F20110320_AABVAH patil_m_Page_10.pro
31ce20e443b7a05a7020cfdc27921d5b
e105c0e18959ee6b7aa142be19dfd883f3a5fa30
1051889 F20110320_AABVKC patil_m_Page_75.jp2
e701607b7ca78f77c73ece32b07edc8d
1d3efd9706980b484a96167c1b9d4ebb5d27051e
71902 F20110320_AABUTK patil_m_Page_41.jp2
e31c037322e120e60ea69fe11a3dc0b7
f870ed566e81f3ce8abb586e93a69a608a9015c2
235941 F20110320_AABVFF patil_m_Page_43.jpg
cbcdca11d879fdda83c66e71fb2e6cd1
4ca00d9e7d5c04919405184abfaa6c3d86f086b0
1832 F20110320_AABUYI patil_m_Page_28.txt
3a15459ccda1dee8a51eece474a2284d
400f15cf4604df28cb5456accd43a9c1725da8d2
35247 F20110320_AABVAI patil_m_Page_11.pro
05daafe7792edcf0284db50b17c6088a
c87adad320ad426c55df90112c67f4620febf5a8
55344 F20110320_AABVKD patil_m_Page_76.jp2
76ee1613935bbe752c1f3d69aaadde96
2f9ac0ddec25acfd8b4837d0b2dbeda3de32e919
13472 F20110320_AABUTL patil_m_Page_31.pro
fb2ecf0d31e7756fa016cea340536d39
7ed6691c026e3ce96968f68f812cbf801071f388
78139 F20110320_AABVFG patil_m_Page_43.QC.jpg
ade065210b9916a388054d99255cdf4a
93356f08bc95f0d3d86fe37c0e67af8cad6b4fa3
172 F20110320_AABUYJ patil_m_Page_29.txt
fbb55e6ae380ac53cce1105451076aaf
b215651e52a44cee3fd53d1646c086a095a1ca8d
41674 F20110320_AABVAJ patil_m_Page_12.pro
cf0d5995157efe3aeab8b407722da9bb
a30a85ffd5b529ec66c9db9253b690991ce5f939
46142 F20110320_AABVKE patil_m_Page_77.jp2
c955b1baef2880eb4c4cc8d0002b8c0f
fe7adaf26209e0deb93490afe8c86bdd44f9bebf
51953 F20110320_AABUTM patil_m_Page_18.pro
604ae162cd29990ae939930d30096f89
7a4c8d46f2ff4b86a3c02141412d91de9d8d57e4
311278 F20110320_AABVFH patil_m_Page_44.jpg
fcb187b1e6fa8912927ac17d524f0c9c
58c35c5ada3a86214f325954bc508b9b1ebe058e
317 F20110320_AABUYK patil_m_Page_30.txt
f558f0f9de27c5c266b02cc5f383ca95
01b517a486dd334ad21ece55b7f0b633c08d5fb2
25876 F20110320_AABVAK patil_m_Page_13.pro
62fea3f7595f0f0c56e8f425c97bc6e6
7fcedb59737885a78f742b0414d6455510300fdc
7018 F20110320_AABVKF patil_m_Page_01thm.jpg
698e50effd19f1b9462280997b5cd464
a377f3fdab0208c3e404290b4c8742cb577d0d4b
184423 F20110320_AABUTN patil_m_Page_22.jpg
8bbc35e0746758ea35d28c8091649a52
882d8c3d65d36a7326ee03529b69125c3db7cd05
96423 F20110320_AABVFI patil_m_Page_44.QC.jpg
1edb27db3175912aa78ab6348c884715
33f924c23477fe7170a91042e34fad3f8d24656d
69019 F20110320_AABVAL patil_m_Page_14.pro
40512971f41b2d9036af647205f8f258
5e67f2dcddfb7579b355b11dd0f1862b297be6e4
3184 F20110320_AABVKG patil_m_Page_02thm.jpg
bac244ff4f43e2b1d7a9cdc4cb85a599
948d44c899cb5a116b1a6cae29b7f6dc08447055
73859 F20110320_AABUTO patil_m_Page_50.QC.jpg
9d8ed8a4880cb5f44cfa23329e7d2934
79188fe62c29eb64ba1c58d40021def886991b02
258570 F20110320_AABVFJ patil_m_Page_45.jpg
e3882548055c4431338b95ec8c00e377
a5edcd10c4d28de35b93052a174d8492c08da32a
582 F20110320_AABUYL patil_m_Page_31.txt
a80e606eba971050d75212811f724a9b
c9a448f3ad93241ae8b1c7baefe422f670fe8bcd
46810 F20110320_AABVAM patil_m_Page_16.pro
4fa7a523da833832e0a0ca570bff1841
39f73520d184cdc93ae5626bc5ac5e7c328e4c16
16271 F20110320_AABVKH patil_m_Page_04thm.jpg
ae555c813a40b46ea47a939f10e1ddd0
cca65859bbe6b3d379cbe9a7bd3f9b747f8dbab9
51113 F20110320_AABUTP patil_m_Page_74.pro
0f3153aa201814f57c439ce61a325a17
d036d763bc7446cef90a5aa6faa48c0adbcaa626
82904 F20110320_AABVFK patil_m_Page_45.QC.jpg
c27b9122e37b31e8c5ddf567abe04fa6
15216b931248903800b2129d5504f00be42d39fc
1185 F20110320_AABUYM patil_m_Page_32.txt
706939dba010183d5a4c153fc5a42d10
737288b277be35d2bab3af9cceae039cfa671f21
53084 F20110320_AABVAN patil_m_Page_17.pro
790da344b2a9ed60b471aa608604336b
4fe402d39db76dc3a8e47fdc008adf36ed90be42
44272 F20110320_AABVKI patil_m_Page_05thm.jpg
94a784638524912600ab89e7d74af93c
3af4b10ffc0b5daf60fcdaae12a54958d0a9c13b
1850 F20110320_AABUTQ patil_m_Page_22.txt
d720bf753f4ee93773470e4f81ea1404
63a4b11c4249afa21d7fd836286b3671fc0b22fb
307002 F20110320_AABVFL patil_m_Page_46.jpg
9a720440bfe862c9987c379836f0dfa4
68b63f8d18d9e243b1871dd1a55f7169fe5a5c51
1852 F20110320_AABUYN patil_m_Page_33.txt
afc00e0d2aa5b85a6cf6266a21b286e0
9e61ac7a21f9c63a808b225cdbe0ac51d03ace3d
5057 F20110320_AABVAO patil_m_Page_19.pro
4a2fead1401274b447c2201115feff75
0e7927038616a18b8af1a6662581e24761fa344b
50098 F20110320_AABVKJ patil_m_Page_06thm.jpg
d2b805743ca2aba5424638c8e09d32f3
ae11952973851f02929c0dc55da877552ec4b3eb
46033 F20110320_AABUTR patil_m_Page_52thm.jpg
a3831771dab8e434207478acc4c6e852
afc11fabced107dcdc09ef8259f6ec74d498e1a8
91929 F20110320_AABVFM patil_m_Page_46.QC.jpg
5078e3e005a907499a08238e20c388fe
f971e7c5360f08f742fd396a5d5cb0a762b557b0
2211 F20110320_AABUYO patil_m_Page_34.txt
a16bf1986053d6c3e62bccfc6ee97744
1d044691486263fdfa36d107da82a869f7374dce
21118 F20110320_AABVAP patil_m_Page_20.pro
75e5620be309a105b69fa1edc05164f2
5c551267e5a1f20a99b442fd696e08c93a7a2710
36031 F20110320_AABVKK patil_m_Page_07thm.jpg
cb64ffb50f2e7aec170402d0786ec5b0
2f48d4b005e35a6d797e939972540f1273102632
376522 F20110320_AABUTS patil_m_Page_08.jp2
7c1678017b29ae16cea79dbd3b1b3f45
ed580537c1af7c5b5d985f560f25eba8eab47e52
93478 F20110320_AABVFN patil_m_Page_47.jpg
7f32d4e0a3707280373723be708374fd
e8ee4aa016a94dca3d212ce7a27462b049129e6a
554 F20110320_AABUYP patil_m_Page_35.txt
d3f37f26ae22e7cf83685343b0a5678a
33a4be6d5652084c716f5ee8bb5d652f308553f7
46008 F20110320_AABVAQ patil_m_Page_21.pro
f4290380ab0970a675494f96ccc4f7c3
5609d1b4ebf97c354962f2ffc74f82ce8d7b3725
44809 F20110320_AABVKL patil_m_Page_09thm.jpg
cca9386d898bbf4bb46d6ddcdce3a21f
305448864de4a4212dd64e3fb617d12b2c1ddb82
153641 F20110320_AABUTT patil_m_Page_15.jp2
9c12f114e67e7c7878f52c08208cbbfb
dbcceba6b4e18710c15435f83d55d3767e35921a
38022 F20110320_AABVFO patil_m_Page_47.QC.jpg
34da2165407196a4f055b43a7f137bdf
7973c9b3b8d20dc5adc15c520de8a9427a9f0006
196 F20110320_AABUYQ patil_m_Page_36.txt
beaaac6780f9c1f4f51ed8046cf86a61
dfd6a140d0faa80cf5a1795026ec326dd8a6a9c2
44599 F20110320_AABVAR patil_m_Page_22.pro
284ee0d1653049da6957c76355d5e40a
4f089fd591c4235644d2f645b0d9c31dafc58bc6
19256 F20110320_AABVKM patil_m_Page_10thm.jpg
b60fc091ac628a29b90e933907c24b22
06f17cea10554d3e93fcc2a461c5548194bea880
49236 F20110320_AABUTU patil_m_Page_23.pro
4ea4008ebe3b5fa66eac2834f4cf2643
491c0528239399aab0c9f696334b0289758e75ef
162727 F20110320_AABVFP patil_m_Page_48.jpg
1ca63b452b3d7812f11e7371c5512d1a
bd39bc6aec92fe11f16ef39090cc7422d5cc5545
2552 F20110320_AABUYR patil_m_Page_37.txt
70cc9cd400398d86a120c350104bda53
0f9254bc74d896903bd5faf7e7d3fbcbc79c27c8
18946 F20110320_AABVKN patil_m_Page_11thm.jpg
37aaa3bc5e6c70e52653da0eb0dce8c4
84a0e62e7e1eb255cbc214824f36beea0b4741c1
30567 F20110320_AABUTV patil_m_Page_36.jp2
c7210e34dd22cdea31fb117e8d570e2d
c25412406f80635d98721c96a47b51725eb17f90
55687 F20110320_AABVFQ patil_m_Page_48.QC.jpg
9a2951ffb28021269148c7cb94cdec0f
d1f80781b67865ccfec1ebb385dbe3b7a373cfd0
1697 F20110320_AABUYS patil_m_Page_38.txt
4bd591c91b7e03e91667763ce7b3855d
b105e06d5773458ddb0bcffe719deda3220a2bf7
48068 F20110320_AABVAS patil_m_Page_24.pro
77f3ffcb572214629698126f0738fed2
8771cfb211e4b8f0c9c0d8f42e533570de2c939d
20793 F20110320_AABVKO patil_m_Page_12thm.jpg
5a75772974d7f9045167a726103706ad
e8041a8d8eaea778ada06572cebe5e0c2fbb1d4d
77696 F20110320_AABUTW patil_m_Page_74.QC.jpg
9d942b7538a7cb4914e93c1aeb55c619
5acded9848e9adfe87271bb34d65e5a40b263688
182344 F20110320_AABVFR patil_m_Page_49.jpg
1f344fa15f0dc1bd3f3d410ceca2f79c
6b0cb207108706646e2c83323f48cad52b70ce38
634 F20110320_AABUYT patil_m_Page_39.txt
220b75ccd7e11e5b7fdce0b807be1384
3a56b39bb4bab33a44cec525e028f70db307634f
21002 F20110320_AABVAT patil_m_Page_25.pro
b21dceca1aaf8de113b52757b065e85c
26d5bac8391c62d14521d5e7d97737daaa4a9179
49308 F20110320_AABVKP patil_m_Page_13thm.jpg
1b1fafb601154585bcbadfd45b2f5e02
3f07267a89a024d417108aeba0b3b20edc4dcf3b
119313 F20110320_AABUTX patil_m_Page_43.jp2
d605c5b4446868f569a57a29c0a13172
5204139f5f779b9a72cf0bcd257133570c511c53
65130 F20110320_AABVFS patil_m_Page_49.QC.jpg
de290a7801e43c5ee65a2635c6b46501
755dfc2afad030cb0ec144d023707e6c8ce72dc9
1966 F20110320_AABUYU patil_m_Page_40.txt
133ac897a0cece7f7ffef04a7a851169
116efd50ff504a302ed52f62056d84b290c5dd7c
21300 F20110320_AABVAU patil_m_Page_26.pro
da49ddbeb5a8416073107f9de9fbb5c9
47ac0d00ef4ebd1bb60fd269ebe57bc8c0c07f7b
25752 F20110320_AABVKQ patil_m_Page_14thm.jpg
1048f2c3aad8d763298a5f3d6434029d
b6be6b633cf69e1483611bc2f67f841290c7378a
F20110320_AABUTY patil_m_Page_39.tif
801b5420f82f97cedce88aa92df48259
e5ee981bc285f964063e9f28335f19fec2c98a84
234253 F20110320_AABVFT patil_m_Page_51.jpg
0c5fcdefa9f7a9d861d0047478239179
514a92c1efbb4af185e48a4e85436b448ed0f63c
2092 F20110320_AABUYV patil_m_Page_42.txt
54901e8ab2e2c4a43d60a6f7ed1b695d
8ba00c121c6bdb1f592a8d6b6314c2c5a0e34718
51200 F20110320_AABVAV patil_m_Page_27.pro
d08cb8156d83ecc9607265fa1735500b
28f45b4db5e4c6e382d8e29e853eb217bc018d65
25602 F20110320_AABVKR patil_m_Page_15thm.jpg
2c2548c2200927bc047e3d6d02dbbc57
448e889eb5f29db1c75b6850fec355d13f3973a4
100286 F20110320_AABVFU patil_m_Page_51.QC.jpg
a7e2d92c74a2030cf2092216ed53c67e
f0ddfb34d35381ebb47825104b42976abbd6d343
2408 F20110320_AABUYW patil_m_Page_43.txt
5bfb5b6033dd67568efd38875bc0b2ae
25bf11eeff7cca7c9e1380a2b2fe9643699bd057
44112 F20110320_AABVAW patil_m_Page_28.pro
9a60f8e875e52e2b63984e0b33fd40c9
ca796ac839096d4704d847ba962d60998c440e5e
24800 F20110320_AABUTZ patil_m_Page_16thm.jpg
92058867be2d7bbefb8d5c48a908c1f2
74c8d1f94f784da688dfba842b2a76a0423ba514
24402 F20110320_AABVKS patil_m_Page_18thm.jpg
0667c5a7f5c08fe2fcfec8fe7fff5d15
25824c6b51d7551c063e7aa822d7de84fcbdeae7
192576 F20110320_AABVFV patil_m_Page_52.jpg
27d25f4daa6e368abf662775db6553d3
2a6163abe18cbd928ef70e1a1197f382c6b7b8c1
3292 F20110320_AABUYX patil_m_Page_44.txt
881b5399744dc2960443f0cbb8b6c4ea
de3e083540cb97c5740541d975faea36fdbb91ee
6724 F20110320_AABVAX patil_m_Page_30.pro
fac7eb3e4d228befcc6a196008c46fac
ffb067ce962b5e03156501a56711093f456ca95b
4891 F20110320_AABVKT patil_m_Page_19thm.jpg
9edd8bc64345e68d9f9521656d57c6da
727a0ebbe21ca02384cdd079ddede4cbc97d23ac
86664 F20110320_AABVFW patil_m_Page_52.QC.jpg
48bb875d87274ed452f94962e59563f4
feff5dfdfeb06db08e27f704ab3c9bccae4897df
F20110320_AABUWA patil_m_Page_40.tif
eca15d462da47066985c213a8f9a1179
91de3194f17f40788ea5574ac31e468a7447ca16
2544 F20110320_AABUYY patil_m_Page_45.txt
427eed72770ff1502fab86c51c5dc821
b221ab666dcafc0da9e8ad64b3b2770b6f527e4a
24503 F20110320_AABVAY patil_m_Page_32.pro
941bd2cd5cc161482e80ac339cfe18d4
013b8dc595012fff61db574b4d5174d39da9d49e
49101 F20110320_AABVKU patil_m_Page_20thm.jpg
4e7df58e0227cc952701dd1529f728a1
1d7a26ad3c4dd7f5ec56c5cc53f56cf5b9e72b75
F20110320_AABUWB patil_m_Page_41.tif
e420b1cfda1d63930ff25d5e8f17ed28
6af497bf33a530e3aa60dae080ba61bc3e469451
1603 F20110320_AABUYZ patil_m_Page_48.txt
670229c5c54b9980f287790762a5d078
5ffa20b99820bc60e5be9e131caf66e886bc1056
37599 F20110320_AABVAZ patil_m_Page_33.pro
28f66f223229143baf22ad4ad176203d
970177b075b8e85802d8041d5f78d5b3e7d009d1
22776 F20110320_AABVKV patil_m_Page_21thm.jpg
afb9da3056778e92d78e80045f2c77d3
ba99b268785e8a798a5641bc8c1b2c2a7f86d687
210807 F20110320_AABVFX patil_m_Page_53.jpg
e625d170820177256ee98ec0564233a6
23a595b3047bb1ea04f7f0ed8678a959015b8504
F20110320_AABUWC patil_m_Page_42.tif
b7d01b8302db3d21d9e3824d4ba3091e
4f595d8997ad68b7ed0c9c412115489798b9b249
22711 F20110320_AABVKW patil_m_Page_22thm.jpg
c4136fe44f3d3ccc103b680581482372
41946ec3bfffdff18b18c4ecee17222fa8d90c2c
93601 F20110320_AABVFY patil_m_Page_53.QC.jpg
ff499c0cde00cc40fe864ff5751d5328
05bee2998c94e480ac02c4e907f76ba93a0cb178
F20110320_AABUWD patil_m_Page_43.tif
f109b6100fb9fb8b526a76c5d8096013
e030bb9af9b20bf94d9aaa37ff34f904d406273d
44280 F20110320_AABVDA patil_m_Page_08.QC.jpg
ad04c43858371ee1525503f561b981c0
e841e425b46dac9a98f2c47e190367e1955fdf5c
23262 F20110320_AABVKX patil_m_Page_23thm.jpg
ed1d447aab0fc62b31cddf294688a4ee
2e959899360145c683188b78e0c0f1d693f33249
180010 F20110320_AABVFZ patil_m_Page_54.jpg
005e5b7c7de363329c170f6fafc95511
1d45ba3b028a1466f007c372ea9383c1a6c60381
F20110320_AABUWE patil_m_Page_44.tif
8dc315b41bfcb41e16fbf4040716e7ff
33d90c5a14a415b7203b460bf98a584f899cca8b
225831 F20110320_AABVDB patil_m_Page_09.jpg
4f5cb034d79d3b6505f10d4d6d39d559
c45f1f6a432f04ac1763dab6e4398d1302ace1d3
23917 F20110320_AABVKY patil_m_Page_24thm.jpg
ef3b85bce81c056032cd05bc8c701b6a
404a38805b111386a3838ba469d5b2b60182578d
F20110320_AABUWF patil_m_Page_45.tif
75993b1615adbc12bbe3cb6e33b880b6
aba71946267250fdb0605c1644e95711a1aae6a5
93261 F20110320_AABVDC patil_m_Page_09.QC.jpg
c09673e10063c91ae8acfccd1856f9c4
01386bc31fb6e80dc39cbad88c63bb20bc1c05ee
11789 F20110320_AABVKZ patil_m_Page_25thm.jpg
542efa4a5adef40ca9b3e8e1fbd76184
d4648cc05bfab534fd5b1701ed8bf69c932dadf9
81098 F20110320_AABVIA patil_m_Page_11.jp2
12e580cd9e653a99694ea32a4bdf7d21
9bab9cb331065e2a7bbc9768236965bb00612ce1
F20110320_AABUWG patil_m_Page_46.tif
6ee1d3864d1a885bdfc3fda0ac2e6013
600f62b124b4622fda8b621580bcf9758d434213
173161 F20110320_AABVDD patil_m_Page_10.jpg
54805bda8d2fa1a158cb26fe963e1d76
156b5cd10d85eff05466115f9a7472424a8cad25
93054 F20110320_AABVIB patil_m_Page_12.jp2
ee3569ca67734bfec6d5525a7137bbce
0373c1b4573fc6cd72841e1159c7d8597bcac668
F20110320_AABUWH patil_m_Page_47.tif
d977feb0e458c6c0334b87b088aa2345
abbe8e3bea80e745e44395ef937f23da6562c352
62365 F20110320_AABVDE patil_m_Page_10.QC.jpg
0aac8aec9c5ecc99d32dd02f6d3ab7a6
7d35461ab57e687432ab3b715e6da299e9bb91a8
141297 F20110320_AABVIC patil_m_Page_14.jp2
a9c835483bce1a661eac7ada8905c29f
1155a201b471a39fc1aaf633cc0cdf728889746d
F20110320_AABUWI patil_m_Page_48.tif
bb5eb0c66dcc2b7c49a8c7dcb6a0f172
fd36fcf3b220cf11c626d6531cc63babd492e24d
152610 F20110320_AABVDF patil_m_Page_11.jpg
62fbe692e74844000a7a9cc32fb83e50
8bac2de288906c5007d435352b4c7f864c5818ac
102707 F20110320_AABVID patil_m_Page_16.jp2
244e2e17ee1550e2e37f1b5e28a53e71
514cc8987e6c943aa3daf6407091d3761c11ac93
58094 F20110320_AABVDG patil_m_Page_11.QC.jpg
5c11690cd20267cdb71b763ac01f90f5
ef671adc48c04ca0529ce961971ce41dea2d8716
114248 F20110320_AABVIE patil_m_Page_17.jp2
23b7737a8f172ed1f6adf92739453787
f56c8f072450e23f0c4d3d364ca5c2ea5a9572b4
F20110320_AABUWJ patil_m_Page_49.tif
ea40d0b8c3f83fecfc5587bcf4b2157d
ca53a8a4450bd1e5a56a7d03b8dfd89e4e70be5b
64866 F20110320_AABVDH patil_m_Page_12.QC.jpg
9fafe9589acae5a8b1b714724dd316ef
7381f6966618458d233e565351523ed3571614b0
111488 F20110320_AABVIF patil_m_Page_18.jp2
52f8c5a5c0bdd28bc5ad97fd341a1dd0
847b2ab354174cede538a27ad47be65144191982
F20110320_AABUWK patil_m_Page_50.tif
fc6b94327fd5837b5b32c5eff06d4d55
742a58fe0c22070116a90cd658177b985a97533a
199295 F20110320_AABVDI patil_m_Page_13.jpg
ac0f8916f007cd7fc679ac567385df3a
8ccd4acb1ae17105d0933a69d31d4d68f9fd4702
14266 F20110320_AABVIG patil_m_Page_19.jp2
4a9989e63ec3eb848849cb401c379643
28ad81806cf3db70e1bcbb3d18fdb917a52f88af
F20110320_AABUWL patil_m_Page_51.tif
ef0b8dc41e24c168a12ee4497f9b235d
4fdee54f5876d20fce6db1b66011d5a1fe299ee6
92904 F20110320_AABVDJ patil_m_Page_13.QC.jpg
587418074aec2b7d87fd12e076e98184
f5136f94891cba743a140c0581080faebd29af4e
1051961 F20110320_AABVIH patil_m_Page_20.jp2
65f78c84a38b6cb9f3202c2c607bd601
c1eda2a51022965ba22270ede1c1a77fd4187fe5
F20110320_AABUWM patil_m_Page_53.tif
0ed565f9f2b2a5d76b804e1f879ebe28
ab73a260a56c5a97481084e487c7687229fdd99a
278421 F20110320_AABVDK patil_m_Page_14.jpg
a76be4a5d13bc52b1ac2b57d3eeb1c71
ba0f7e8ed9fcbbdaf09fd95bda7f5ec5fde6d88c
99286 F20110320_AABVII patil_m_Page_21.jp2
5da5dc234f85ba0d133541f00e7dd6fc
baa36842b80dabd387d79bce33ffa972bb09c9dd
F20110320_AABUWN patil_m_Page_54.tif
5c8729f4000f8f7047612a68d612e42b
eac44df65cd2ebce2ae4c3d9f96da2b08f12f1c5
89339 F20110320_AABVDL patil_m_Page_14.QC.jpg
0f6e6fb716bdd8bb45c9b54977acda87
73a1b26e771770e289de7252d078226d65d1cd48
97352 F20110320_AABVIJ patil_m_Page_22.jp2
eebf50b8cbf2768c9cd2e2ce2b32ef88
c4ead53fba73e7242764797140ed3ef71a4b75db
F20110320_AABUWO patil_m_Page_55.tif
62481f21c849c10060a228d9d0696dd6
785c7eed4a3946560a167c5e7e937ff0663752d3
92199 F20110320_AABVDM patil_m_Page_15.QC.jpg
e2c51b15fc4350fd79016cc77f9c9719
e763304b9f4e5bcef5c2631b53d9c42d102a270f
105852 F20110320_AABVIK patil_m_Page_23.jp2
168772d62906031dfbe6e243da6303ce
90963731f9adfe685e07e46bb9696e6603df98d1
F20110320_AABUWP patil_m_Page_56.tif
0ad520fc97a11b92496dcb6d6f5313ab
630ae76f8b8dd6cb0c4bc2cdacddba5875275e92
73197 F20110320_AABVDN patil_m_Page_16.QC.jpg
f99097e53a7e45f4352ea3252e9baae8
00806fe5c9b9b92c6862983c1a708fd8b00f0017
49661 F20110320_AABVIL patil_m_Page_25.jp2
d12cc340855aa902e88fa9817a1c4afc
e0c90936b57080182213402f53b6f1e5a5d2257f
F20110320_AABUWQ patil_m_Page_57.tif
2e6cc2e2902398e4d2f684178f64903a
94df093eca9feb693f1651f43d6b2d66151e3010
214642 F20110320_AABVDO patil_m_Page_18.jpg
3580f57a304029f1414f64aec4599ebd
5cd69dd7e70e816698881f50fc7a21445bcc8fc5
876243 F20110320_AABVIM patil_m_Page_26.jp2
a7438ce9636e5e35892ee33239e596b3
3f5576e49e8cc295d1e478f9861976e08375c91f
F20110320_AABUWR patil_m_Page_58.tif
2f3c4a5bfd560a59cdbc9ade18f48def
0e551350f9820ebf73b9481ecc001284752633d8
79669 F20110320_AABVDP patil_m_Page_18.QC.jpg
e6f8351149ce6470448441a064df9b76
5b904ae3ea4254ab73f136f2491b85c9d4193cc8
109093 F20110320_AABVIN patil_m_Page_27.jp2
e4f439e74b5bde3db8bef73793f4bcca
504b38c20c3d4bd5987c222b5e896177192afa85
F20110320_AABUWS patil_m_Page_59.tif
ddd101b29465e47bd369102fa029ba99
e57278c2ecb04361fa2ed1f14d752c09e47e2e9e
28686 F20110320_AABVDQ patil_m_Page_19.jpg
3c0e68158f926d9412baff1c41cb6c8a
6407ffbe8bf7e3b4bf6a91e66038fb514caf7b40
90380 F20110320_AABVIO patil_m_Page_28.jp2
0e814114e150f9f92852008897523e3a
6f50e360146acf1a8360adc0afd5f95e69769516
F20110320_AABUWT patil_m_Page_60.tif
61b7718adf205248d043e907d48953bc
9eb6b775ac2f4d4e7484a09ef6de41287433d2d7
12331 F20110320_AABVDR patil_m_Page_19.QC.jpg
75acf47af30c15d17c779440b1dd2fc5
147a389842b4257c125d9efaaf03f99575fa98f1
25963 F20110320_AABVIP patil_m_Page_29.jp2
303a8ad18e25ed6ff260fbdc2000217e
a24a60e0efb115590c79eb22616a2783d6bf592f
F20110320_AABUWU patil_m_Page_61.tif
2504aeb3ab6678701312991b71463618
fb9801d453004e08891a735dece31a7a80d03bc5
230652 F20110320_AABVDS patil_m_Page_20.jpg
4b1159e0db0a22cc272fdeddd508f7c8
8e51b7d7d3d5029f83d3ac30d265455ded54c1d0
38962 F20110320_AABVIQ patil_m_Page_30.jp2
7c34b4c13bd716e9b17620f9f02107e8
06ea0abb239612addbaa37c528ef0a9ea91ff2bc
100494 F20110320_AABVDT patil_m_Page_20.QC.jpg
cbe9511ab71b7cf1187ba1c7c0372ccb
298dbf869a49d6cdaa24d51a67a88b45a7a2fcae
F20110320_AABUWV patil_m_Page_62.tif
83ab05b7431300b4415442af3ad00a0a
ac54d60c493aff1f17ac9dbb6653690c2434f2c5
31974 F20110320_AABVIR patil_m_Page_31.jp2
9540e774a09746c62f10650fe7281e93
6ea0add77bfa07ea48eec57a24b1298b1665ef1b
188841 F20110320_AABVDU patil_m_Page_21.jpg
8be642f189a8c504f23795a78c7681fa
8051ac19e6b28f540aed1ca44a8941d885a89d0c
F20110320_AABUWW patil_m_Page_63.tif
c5eb442354e278afca77001ff21f09f3
4a0b33f5b10936aee1d79da56705d7c36e9e2a73
46893 F20110320_AABVIS patil_m_Page_32.jp2
40cf2a4df19e0a7f84cb195e425b9859
5ea723b2154217d082e60b859448787cbb727d7e
F20110320_AABUWX patil_m_Page_64.tif
47af993cbbab7eb80fa661ee2b739aee
b55c180422abcc8bdca0fe9f46571408964e898a
117295 F20110320_AABVIT patil_m_Page_34.jp2
abb9ae964fb928ed1432807a63a1952a
cccb4f4f58a2cb8b83191bb888386ac96a1c8d55
72745 F20110320_AABVDV patil_m_Page_21.QC.jpg
2fd8f41280dcb2faa857c84cb1337462
7dd9b5a1a37ce21cbc762aff8f55eb749a8a1445
205817 F20110320_AABUUA patil_m_Page_60.jpg
ef26cde0c988a5de85b88aa59d398a6e
3267bc2a37f51ead82f3200d023bc68eec8b34b5
8423998 F20110320_AABUWY patil_m_Page_65.tif
29b551484cec814e591e03fd67f04af9
53db80865ef88c25d5bf22817d5c276d3d4d1640
27030 F20110320_AABVIU patil_m_Page_35.jp2
07f3b433df021961ad3e17dd914f1481
e436662c2d4ec5eb34461200e5f43444ee0e05e6
70704 F20110320_AABVDW patil_m_Page_22.QC.jpg
58b5c23e87263a29863fa649b3fab0fe
06ba28c504d4366b951377ff71de5a64f42f1297
51628 F20110320_AABUUB patil_m_Page_04.QC.jpg
47844439c171282b1843b2659bd969c4
b97aea23e4c069e300e00e21178b4f598b42c707
F20110320_AABUWZ patil_m_Page_66.tif
0009e2c1c6e20bde5320635d948481ab
e213ce72da336899ddc97fa0f3bca0b8b5271196
115341 F20110320_AABVIV patil_m_Page_37.jp2
89c7e8f0ea5464a44d5cba911f7ec519
a68615560c658c172b6bbe6f2c0716b0c4eef00b
76186 F20110320_AABVDX patil_m_Page_23.QC.jpg
0ea402be81024f66a14d282de3e4d863
10473e6fc2fc9a214292dd45ab4f019b91adf0e1
F20110320_AABUUC patil_m_Page_71.tif
502d4b4d7fed3041b0d3caf30c41bf66
ba4bcffe7cf155486f2b0b3c846ad13aff5274b4
89523 F20110320_AABVIW patil_m_Page_38.jp2
1989444e75ce8fb3ede46f260718cf16
ea707895b9cc642ceda2f3b41f5dae4f4346fedd
1760 F20110320_AABUZA patil_m_Page_49.txt
3077d4d4f18b4b24785733ff53187f1f
337d7f609ecc9ba173a7f3aa166432c6adf7220e
12282 F20110320_AABVBA patil_m_Page_35.pro
ab164558df471d90e5d264e2e350843d
43fa64fc2718716c377fb8b941afe54071136a2b
197767 F20110320_AABVDY patil_m_Page_24.jpg
e3cf0912ce4658964406998e4c53f3c4
a8e44ec3d28df1bad3f609b264b19681f69801dd
1655 F20110320_AABUUD patil_m_Page_54.txt
e2cb8f9cfc43114747cce3a6f6552be1
ec95ef9a49a6c652a25cfbe931b100a67dd2f048
986481 F20110320_AABVIX patil_m_Page_39.jp2
9523d432e1b8edbc9b16d99ca587f4c3
91e4bd39d4f14a841c3323fb9f1004307fd12d49
1888 F20110320_AABUZB patil_m_Page_50.txt
e6fc1a68c153bebc989d89535a193b5e
bad384f8e8685625d0a85874677cce63c7a8a96c
3847 F20110320_AABVBB patil_m_Page_36.pro
3e586b76fd515540fd47e3eaf642f034
b6bcc212fb324f3731fde743c6c66e6d739d15fd
75614 F20110320_AABVDZ patil_m_Page_24.QC.jpg
079c0f12a0ced402e056f5537328119d
f954210683889d37183ef61d90a4e78aca554a64
24181 F20110320_AABUUE patil_m_Page_43thm.jpg
8b808ce364a84464f36a3e82ee6dc87a
f18a6c002e090452f3eb206da26f0a3912b0b695
101839 F20110320_AABVIY patil_m_Page_40.jp2
aeb03314e895500eed3372c6de9c0e3b
2f5a345661a46ccd2b96f41c02c0e12df3b990ba
3138 F20110320_AABUZC patil_m_Page_51.txt
e9a8477ac749f6314d65346d7bb1154b
453a537c8839f7ae043b423ec852630230936293
57467 F20110320_AABVBC patil_m_Page_37.pro
8d57da77f18a86033fb551cec02659fc
48238ad3d5c9c32e2b9a0dd76570043a14085274
82051 F20110320_AABUUF patil_m_Page_17.QC.jpg
df4d50187c17f3fd8fbcd7f6a60443f2
6d1ce7909be38b59a0a6408d4804def47021dda4
1051954 F20110320_AABVIZ patil_m_Page_42.jp2
18c6ad5abc921527a86af026d7fe5e39
a3d3c918d4d24bcf701d9b09885283a99c1e923b
1636 F20110320_AABUZD patil_m_Page_52.txt
c01b92b502a507fdb0877c0107541b1c
7e6371534f698ecb25c71901ce314007a2e86a0d
40917 F20110320_AABVBD patil_m_Page_38.pro
3fc7986a21281ef175028aef788ad7d5
4da889887621dbe44b091e0a069e5bf45e7705f0
107700 F20110320_AABUUG patil_m_Page_55.jp2
65e1be4ef1b1e3f31de2a0b1b2ab1e5f
ee98f11fac1ecec4286de6c9bb878c51c08406eb
80120 F20110320_AABVGA patil_m_Page_54.QC.jpg
a798c92bdd337f59bf7ac69da9768117
8e190aba8bf08272cbfe52ccf1827a48827585d1
3054 F20110320_AABUZE patil_m_Page_53.txt
c3c724b9e22228f6914520119dcc8522
4585322406035c2bd8d687d4fa86d21564879fec
16566 F20110320_AABVBE patil_m_Page_39.pro
a52f51f12446f1dc91e1c051b9c208d8
db69781bdcc20f48b1e965d0c5eebc367e2ac92e
212265 F20110320_AABVGB patil_m_Page_55.jpg
9653bbd7bc8b9e7859874fc107f1d792
c70907be26b1d7a2d763090a1e3090a1683f9433
1973 F20110320_AABUZF patil_m_Page_55.txt
effacfa008f9b499597a5b9e265e16f1
261a992aae317fca6981bf25271d5d1b652a7924
47955 F20110320_AABVBF patil_m_Page_40.pro
3ca9bc0a312bf249f1a3f5f072f6b54c
8385c3ef8ce26336d64ae7da29ab9d9f6f5c6409
74791 F20110320_AABUUH patil_m_Page_15.pro
2ce164a895d1c03e7ff12bf2e967f7ac
ffbfad98bdff9178b9188891e34c2f9f056c562a
80421 F20110320_AABVGC patil_m_Page_55.QC.jpg
85c42796e17f3265d48d1ad5eea32f00
d23ef3ad79bc4bd2a5cd2ee3fc82989e8a0a3bce
44341 F20110320_AABVLA patil_m_Page_26thm.jpg
ff660cb9092effa096d014219debd745
5be3d72ff4a18bf87cb8fa6a1a2d0084d2ccb7a7
1768 F20110320_AABUZG patil_m_Page_56.txt
dc51387992f06295eca0fc277ae58b00
ca0355839dcb1c929bf1cedcdaf864b08b324f31
33952 F20110320_AABVBG patil_m_Page_41.pro
11e079360864863e310c3df17956309d
6d8c6ae69458f0e6930d4f3e678398d2abbf432a
41733 F20110320_AABUUI patil_m_Page_70.pro
4c535d3a35039ff6bc111c849767c6ec
728dc3c1d292d517cdfab29703392b563ceebee8
199299 F20110320_AABVGD patil_m_Page_56.jpg
d1b993c4f1b67dfeb6c7eb4e2763c18c
322c2569d081f61f8b559c15188457d1794ed05a
24426 F20110320_AABVLB patil_m_Page_27thm.jpg
43e228c66180b3766ea84ac1d18ce3f0
36817d47d05c2e2faf0292d4cc619a8d9cf6f090
2411 F20110320_AABUZH patil_m_Page_57.txt
b55efbf3cba393b1e0ed1d21a9bb7407
77b888fc8bbe285f8a8b008ad947a3e23f670608
44980 F20110320_AABVBH patil_m_Page_42.pro
6a87063cdaad1472866ec0c251f40a80
8c31103fc28e0807408380d1e961547f23c94996
55406 F20110320_AABUUJ patil_m_Page_34.pro
7aaa158c83a2dafcf8a85f3d9683a325
efe6a9d4d031c299f06d5924a3aa903119756e83
71056 F20110320_AABVGE patil_m_Page_56.QC.jpg
176d8e82462733c34e4e798a69393871
23c531c3163b80fcd26fd39b8991c01c6c34beb3
18179 F20110320_AABVLC patil_m_Page_28thm.jpg
c792e037340a494423c7902680376eff
b02bf286c17e49428acdfb486992b29c30f3b6cc
1932 F20110320_AABUZI patil_m_Page_58.txt
b74b56384aed8b5cdda3435ac3088111
0dc87544df157367bc6093ad7800638a7f73613f
59178 F20110320_AABVBI patil_m_Page_43.pro
61215b043fe7ca69c077df3d172d027b
a442da291052719daab5db6fd4926c668537592e
F20110320_AABUUK patil_m_Page_52.tif
7a900411ef7028a24a3eeebd75323a0a
d01992ef0d5fab1ce1971d63b38b0469f5a81937
225608 F20110320_AABVGF patil_m_Page_57.jpg
b16d0540bff94f4c42c2f18ad0ff03e8
9b21d74699c2737b731298ae6355c4e423c8f822
8442 F20110320_AABVLD patil_m_Page_29thm.jpg
504792f344883c9a9a05ac4936898866
c03c72f7420cef34f68821d5786de86238e16422
1746 F20110320_AABUZJ patil_m_Page_59.txt
0821b4267de023aa4f0267af29fadd74
c8f7322c0a6aee5116bd8927de5135bfc9b2d2d2
79311 F20110320_AABVBJ patil_m_Page_44.pro
b7c15584b082fd332158e1b702a47c4d
7885bab771eb6dce5e91d3a76580d3a7c786f397
305846 F20110320_AABUUL patil_m_Page_15.jpg
21018969ac192fd4a3929ce5f13f297c
acc6da06a4e1d3566df7f592a106bc7f895cf12f
90957 F20110320_AABVGG patil_m_Page_57.QC.jpg
3f43eaf6660a3e6cc62502bf3ce6a4db
f6d74087521789f4e07dab2d5bb4c8416faf0018
10426 F20110320_AABVLE patil_m_Page_30thm.jpg
409044b5ce9b54963b7f981bae1d102b
f26f90e56d11ab3bc00833030391ed0782885980
2223 F20110320_AABUZK patil_m_Page_60.txt
f2ed3ba5d8b280ed792361db85c58c58
50b626072f849306265c9ff868a86b06f4224c10
61394 F20110320_AABVBK patil_m_Page_45.pro
9536815affa5311de418b7e96594ff26
625d9ecbd48190b065da0f5f0506072f2ddf5030
87832 F20110320_AABUUM patil_m_Page_70.jp2
052592e074cebc7bf797ae0596059d31
d72615c57c5269d5d9769cf7739e8db9f1dbb6bd
200255 F20110320_AABVGH patil_m_Page_58.jpg
54e0198f3fe4ab1038a9c054a053116c
aaf27d8fa487ab9e19aac21dc41281d3008c0c03
8199 F20110320_AABVLF patil_m_Page_31thm.jpg
990e6fa7d5820058850fc71dc1fd3014
836d4046f6c6165650b2a53ac93c9ba30be4ad73
1806 F20110320_AABUZL patil_m_Page_62.txt
e53c3642727cbfdee00aadaa5d3c2d42
53c1ecb13c5e66b4d142d07de38edd82ebcea288
77400 F20110320_AABVBL patil_m_Page_46.pro
c234195b5ce52c20c1ea60d885ef752c
5ab03b40d4f0d822d010214098321e3507b0c8cf
1887 F20110320_AABUUN patil_m_Page_65.txt
bcaa63636a03d5784338014e585c6ed8
9ed648f89aebe928a2b15196ed5f9328151c2784
74525 F20110320_AABVGI patil_m_Page_58.QC.jpg
6bf1c73ec062031c8f28c513b776ee04
ac757785a60db62a941fec83b5fd8782ab8b5dfd
10008 F20110320_AABVLG patil_m_Page_32thm.jpg
c4eb3711da8d4a63f65802ddf83f0927
2d33a7ab41c184704941698794385dd3125ae8ed
8159 F20110320_AABVBM patil_m_Page_47.pro
aa09e3174a0404b5cf4651f9aa60c181
15570c5976f11b844719f2096c62b966e63488a1
3264 F20110320_AABUUO patil_m_Page_46.txt
46f1d298195bcdaf65ab61fd1d83a3a4
227fda3ddbd50866e67790ecc2b86158e778e390
181184 F20110320_AABVGJ patil_m_Page_59.jpg
4c797514adf95d358b7a35f6fc219228
e0d67734079967584979a77b1847a63d1bdac826
14388 F20110320_AABVLH patil_m_Page_33thm.jpg
1e114cb6fe21a057b70cdc445d04622b
0d1ce0dcfc7ac44a421b3e9862602d6c9c11bff4
1910 F20110320_AABUZM patil_m_Page_63.txt
b52802b6ceb6b9f9c637b0f0159f34a9
d88ef26fbd67c079ca8307b20d90b7f96759a6e3
38846 F20110320_AABVBN patil_m_Page_48.pro
5d511b109a9504867f9b298c4477e97e
16c67948b664a08cb9d9fc16ac9bd0be650d5c13
124969 F20110320_AABUUP UFE0009360_00001.xml
a53ec37cba4928bb4372ca30c8149cf8
f9f097eab197de31ff68df526d35602e928fac87
81128 F20110320_AABVGK patil_m_Page_59.QC.jpg
52210fd2d649e482b3bb6fb91e8c96ce
9f734cd21a14dffedfd282179c5e99933364e712
24602 F20110320_AABVLI patil_m_Page_34thm.jpg
4f8c24ebe4ea73f99d904d8f138cd627
0a2d45a74c1fc64a943e70691adff4c7e57cd12a
1452 F20110320_AABUZN patil_m_Page_64.txt
b14e1dafb4e3509bcb2c7dd379025c74
ef3b3d5c08ac2415e2f02c644141a383b002083e
41688 F20110320_AABVBO patil_m_Page_49.pro
183180c602186401ab10ff1182958043
b89098fbe1efad9a61c8348f0743a209e77308a2
182848 F20110320_AABVGL patil_m_Page_61.jpg
bbc4a112e0da1f5286b4093c7eb8d21f
b7b35db46105f60a36b4f3ed51ad833288789bb0
6478 F20110320_AABVLJ patil_m_Page_35thm.jpg
e4a78d0f017825200a79cf94a4c8419b
b4f4481bf70cdbdd22280b0720133f4126c46769
1938 F20110320_AABUZO patil_m_Page_67.txt
ce6206caf8c0e8617792c4848fc7e9f1
aea0a42cecd73da142d8410943092a7f02404dd3
45864 F20110320_AABVBP patil_m_Page_50.pro
c5288eaab3e49fe91a4b58acdd8001e6
d50a73ee1c1d4b4117ba85986cc0b19f0c5f5157
66698 F20110320_AABVGM patil_m_Page_61.QC.jpg
f1bf9700d9ff5972b9248b6926d5180f
7b6e1df1ab4a293ac34cc24b8f5cbac6edeb7770
9498 F20110320_AABVLK patil_m_Page_36thm.jpg
7947d91ea5505104640ce3e669abe29a
31d01665a8bb06cf9672129ce9ca392a8748200b
1863 F20110320_AABUZP patil_m_Page_68.txt
1b685dc90a31bd9038286cdd376114ef
b27a7db5870f49e4dcb42d58a45bad27e7c44795
67918 F20110320_AABVBQ patil_m_Page_51.pro
8b3ae4a83e835726cffd0c9895fee6f4
ea4a20e6dd41adc45cfd69da2a08d87603a055da
F20110320_AABUUS patil_m_Page_01.tif
e9fd757f200d7d36f7b9131b3e81d03d
4f16c8632acc5bffc8c3d3a190c8793ea4e00a38
193686 F20110320_AABVGN patil_m_Page_62.jpg
6199c2cadb4eeb936aaf9c74dd2d7e8e
583ea765277bb0186e6ea9ab5fdf374bbca338be
19703 F20110320_AABVLL patil_m_Page_37thm.jpg
663d783eb1ccd7bb8798da040a501e1a
abf3326aa23de693c8e2d224684a9979c83b163f
738 F20110320_AABUZQ patil_m_Page_69.txt
7af95fddd9006ee4aa486d56deeeceb9
bf9ddae7d48b6c8497c0b55c4e8adfe3642d798c
34553 F20110320_AABVBR patil_m_Page_52.pro
bd3532791ad39531db6856cc7dacd460
be94e02af23dac3e5e9cf81fc60845251ca17e5c
F20110320_AABUUT patil_m_Page_02.tif
d0be4ee77c37af5e106d713965872a12
2fb023c317613c7910c0502df69b806a61cbfe2c
70121 F20110320_AABVGO patil_m_Page_62.QC.jpg
bb39163003e6a56e1bbc5ab317078198
a7d747434efa14ebce4115ee91ce321d6415ce93
20977 F20110320_AABVLM patil_m_Page_38thm.jpg
d6f25deb29b8d731fffce8db114c88ff
e674bec9107d4c0940726e22475ffb1d040aa69f
35306 F20110320_AABVBS patil_m_Page_54.pro
e9587800534c3e3c20006fa408504c94
773e55b61ebe91778ba07eeb972a19fa9d8f972e
F20110320_AABUUU patil_m_Page_03.tif
f19fae6d7e70c2fc7ae15eb1044aaf8c
efcbbf70db904cbfa71b73bd9fe78951518f58b3
198864 F20110320_AABVGP patil_m_Page_63.jpg
a0ac9b5b86ea5b09a41d6bfe0c3666d1
1ade205077a3e119769fc41da1be82dd49e5595c
1845 F20110320_AABUZR patil_m_Page_70.txt
41204b2e84057c7ea055a565b3f0c656
e4043f51856233f9f3b867871adc34e7847daedf
46414 F20110320_AABVLN patil_m_Page_39thm.jpg
efd4aa8a95fa742969e9a633ba375137
d3c3bca1cf4d19e1da01f45d09e046ce6f2a3047
F20110320_AABUUV patil_m_Page_05.tif
79fcd76fef6ba46ba25cf05418a9fd0b
19a7b1d9054ad87b2eed7f793202173f2a8471f1
75006 F20110320_AABVGQ patil_m_Page_63.QC.jpg
c46255e09f1cdb21357fc14d1aacf31e
1fb0f05bbd5a656b779ea9f070e07b4101bfeae9
1871 F20110320_AABUZS patil_m_Page_71.txt
84687a5d2144d82673f05418b62f0e61
f71a94b226a345a2717fafe6f73c1c8d35978d03
23331 F20110320_AABVLO patil_m_Page_40thm.jpg
af48e8d1692a03a77a6a42c909ebea0e
ee227d7e6041091bfd30dc7358d038ed22d85c8c
49191 F20110320_AABVBT patil_m_Page_55.pro
accf48c0a15d6b7c8b730519905f42e4
43562020663e82b4df42fba2ea7543990dd5af1c
F20110320_AABUUW patil_m_Page_06.tif
8ed89b23d1c7c07e4630e51efed31703
48f195156fc1f4692ad41fb76c717c3a4b4ebc66
158526 F20110320_AABVGR patil_m_Page_64.jpg
9707fc2ac54e901532aca839c56cee06
885564442ba176ddc7d67464c1e1420bba6f1fab
2051 F20110320_AABUZT patil_m_Page_72.txt
374a6ffca230682110c5c45a3691f952
7cc3fd3d8877ef0288216cb618bcf1e9cbd3ab41
15553 F20110320_AABVLP patil_m_Page_41thm.jpg
19dc12e4291cd35b58c3647cb8582055
a06d283177e298de8623cefdadb8f77b0b673c31
42103 F20110320_AABVBU patil_m_Page_56.pro
742b7178d57fb671085ffe426fb0be7b
9bad7143ca9d6dc2c37b2406308e2b755ffa4067
F20110320_AABUUX patil_m_Page_07.tif
cccece0cab2a9e1dd9cf78b7a6736510
7a12eb1d49f018919a3633463e49c8bcfee4b3fb
56936 F20110320_AABVGS patil_m_Page_64.QC.jpg
cbc46110c514ec92ae5b0c880637d040
264891d8491db0ebf35d48ed90f516b3b9a39144
F20110320_AABUZU patil_m_Page_73.txt
d39efd03f9758264f4d790cec1240717
4bff6203ea793f17d8887865302ae0f36db060f7
46333 F20110320_AABVLQ patil_m_Page_42thm.jpg
4b304b3954b5f30c585ac88fb94e0e17
c7e075e8a796e518e39325f9f997ccf6b4f81297
49796 F20110320_AABVBV patil_m_Page_57.pro
3343f5264ffff2825b702058cab5b5d8
6896aa4d887b9ab0e4981b052038e8fef26294e9
2096 F20110320_AABUSA patil_m_Page_17.txt
e307e6a8355a09235a19b375883585c3
77769444af661716b9e7fb03cd5eb2006e1a4317
F20110320_AABUUY patil_m_Page_08.tif
997275d56725dbc94cc90dbd341d898b
090fa362f0df7824fa4397aad1c0d01a89be2f43
207260 F20110320_AABVGT patil_m_Page_65.jpg
ac73c5de35ae2f95698c9acb75a309f4
8e53db3b5ada308b4f7272a42fa0a7971a3ba724
2013 F20110320_AABUZV patil_m_Page_74.txt
ff328af0f5d554927c88d412e778903d
3ae90e47bb18f47ca058781a3604d523290d1c4d
26431 F20110320_AABVLR patil_m_Page_44thm.jpg
ad24d3f45e8ae917406bcec625d1d739
2f4e709355cf864ca7df41ff82197a49ace17e90
47711 F20110320_AABVBW patil_m_Page_58.pro
91eb0b12426b082adb712e13f7550630
985507773637e014b2bc68ba7745165123c4124c
195650 F20110320_AABUSB patil_m_Page_16.jpg
8779f2b07074e9c76f0b7244da65a275
65c4b7551b9da4ec84ec0bd3f48838fa3b12bbdd
F20110320_AABUUZ patil_m_Page_10.tif
c6311a5f411049c3ca6c1630163266d0
7aac7203177f5fcc18988023b53f5238fe37bbbc
80062 F20110320_AABVGU patil_m_Page_65.QC.jpg
8c907d4c6081c33c5c33770949f89456
4eabe511d8301d80602978f3d9d5782f995f5e5b
2394 F20110320_AABUZW patil_m_Page_75.txt
fe69038609f365d8e5168cb0c84a203c
c26c5dc46af558a720e5f88b177c209ef00d667f
24743 F20110320_AABVLS patil_m_Page_45thm.jpg
c604b1dc061435b3184643e73d8c702d
527b750f99374df6a11e56052ea8acc2a2cab463
35063 F20110320_AABVBX patil_m_Page_59.pro
82e47e2a1b37914639b97f93b1ff04de
9258a63cc577c67aa51ddcccac0defa273a0f7f8
1564 F20110320_AABUSC patil_m_Page_41.txt
a4f58018b265bedf05445d435956e9c8
fb0e4d0cd8f914515aebd477aab1ebc48f0e7dc6
198866 F20110320_AABVGV patil_m_Page_66.jpg
194d754435b686aadd0c585e4429ee21
d34c77be4ab804bd0f7ffa65605faf3c6eaa90e5
967 F20110320_AABUZX patil_m_Page_76.txt
6ea3d67f9dce25c1dff3bb0a7288fe0e
fd83b847ebe01e2e9b1784f01f11234643329b2c
25203 F20110320_AABVLT patil_m_Page_46thm.jpg
905fe421dfada40b47aa9fa323cab897
f2f00f9108362cf59428a8acbb9906df835fe65a
102830 F20110320_AABUSD patil_m_Page_24.jp2
6de259a740b181d067cf11ecce293b2e
4b86f253f7b8ee008a1168a43dad713ce650595a
79575 F20110320_AABVGW patil_m_Page_66.QC.jpg
5421b0938a0ea559744233cdd3e712d0
6b0fd9611f5b9e5f1d7cd8bc3df1fc56bea9b3cd
F20110320_AABUXA patil_m_Page_67.tif
85c96103bc6d5cf089b6b32cd0a8bed3
569d5782e3c7945627a90927b8db862816fc3454
821 F20110320_AABUZY patil_m_Page_77.txt
d02925a47a0d95044cc0237ded1bd40a
bbd4065892ffce3ada94bf7ec6b1721463983d35
42908 F20110320_AABVBY patil_m_Page_61.pro
6b8d0665dc51848ba7caf6955a8e5171
1f6b178089a26d36278c5d31f78936049b231fb1
13412 F20110320_AABVLU patil_m_Page_47thm.jpg
f2109e99b268c53d68af53720eb5e4ab
b7548399e5839a2f245b88c2d66460bd43bf749a
205799 F20110320_AABUSE patil_m_Page_39.jpg
2ac78247539472c17c236b28991b7174
a92ee6d01306c971141aea44b40723aa1cb870b5
215833 F20110320_AABVGX patil_m_Page_67.jpg
b66a47a871d65bd481d149c91f9fed24
003e3f3039d3e8da863e1a98bb475656f2ea316b
F20110320_AABUXB patil_m_Page_68.tif
d1187f676a0731a6b5b51e4ac2aca9ea
2aa97355cdc5dc331e23beef2b0f77644421c9de
1381 F20110320_AABUZZ patil_m_Page_02.pro
67e9cb0ad6e4538a8f6b27845e00a85e
b9f76e894544738de72d0e54cf93e27793aeea61
43713 F20110320_AABVBZ patil_m_Page_62.pro
721ce22900e429e455ec919a6e1e6c21
dcd4c45f58fe51124cbe9a1a38a4ae0fbcddc657
18807 F20110320_AABVLV patil_m_Page_48thm.jpg
ce00490b676bffc6e0b0c11a3d68280a
81bc69c9fd20a32e5ffe3f54a41eba029001335e
F20110320_AABUXC patil_m_Page_69.tif
796a14f62e73885a9fda689e479563e5
d6c3589b0abcded6e817120db4cb6f4bd29253ab
20782 F20110320_AABVLW patil_m_Page_49thm.jpg
5e567ef10a2766dda8e66d8b416beb4f
de69feb745813184bd5b86dfd0d50325152f7b62
95252 F20110320_AABVEA patil_m_Page_25.jpg
78311074d7d802e3eee6ccef97590b36
30a200eadea7288e94acf1b4a3cb24e9b074d410
80066 F20110320_AABVGY patil_m_Page_67.QC.jpg
b5b939ba7209841a02849f95f4eaf90e
e964fa4442a2d1750ddbedb86a2461f714bdc5ca
F20110320_AABUXD patil_m_Page_70.tif
ac42af240bac24d5cd758be3934166a7
e15c408c344eae3978966784332bd641bb505351
61004 F20110320_AABUSF patil_m_Page_70.QC.jpg
2f89208b391485a03724bf25ff57772a
7f8e09574105e976ea5afcc04292ab50c0b74f80
22876 F20110320_AABVLX patil_m_Page_50thm.jpg
85ee2777f637c68bda6f8460cd0e9c97
fe41c5c103c92b4dd1406c720d4d073cce8692b6
35739 F20110320_AABVEB patil_m_Page_25.QC.jpg
fbf0129c45fe05501c6567fdff148d0c
c91f7b7e9d0fbf56095a4e1be0324c6fcbe9e60a
193714 F20110320_AABVGZ patil_m_Page_68.jpg
58ee6518f859922b489371c38ccb79dd
bc616d5795ded6e2b45068de73fe055bc22218cd
F20110320_AABUXE patil_m_Page_72.tif
7965e63a6c5569fc30ed92d933dc4ccd
230e14005abcfca805fe7fa84805741dcddbb03e
54696 F20110320_AABUSG patil_m_Page_53.pro
333cb72a424273891d355aa7573074c8
9cb9a837b629ad05c9f1ef34e15ba441ad4a6859
48445 F20110320_AABVLY patil_m_Page_51thm.jpg
f25cc7ddc983fde1874ea4915f770664
b3e1857bc1d28fa026969cb57eb0eedf28b8c8c2
169567 F20110320_AABVEC patil_m_Page_26.jpg
720e409d3555f7828490e044ac90feb0
6140b5d26bc98efa9a5148f3d87840e73fa32c11
F20110320_AABUXF patil_m_Page_73.tif
6d855899fa3e90161a880bb167acb28d
94ba72a899e570c838d6ce2d7c9ccc3b0f151fdb
103845 F20110320_AABUSH patil_m_Page_63.jp2
35b0c03ba93cb7b59f15e31ecb158196
94703aab0f76d80a38b0964078929b3a6eec7aab
47323 F20110320_AABVLZ patil_m_Page_53thm.jpg
859d488bbdabe98a87407d099f142840
2ba7c124c5e1c7531004362fb3380dec678d2b95
155061 F20110320_AABVJA patil_m_Page_44.jp2
9d6ed12aa888436f08b8162b6a635ff6
5a436712adcb682baad1cbce464e4dc1fd574c04
82321 F20110320_AABVED patil_m_Page_26.QC.jpg
6069472ed00a6fcb37c3db4682ab7315
3022ac96143a2d4e76ff601aa3f74d2e45a704f2
F20110320_AABUXG patil_m_Page_74.tif
7908477ed2707ac4c4de94a258ba0b78
4329c720eab1a756fd24f882f76860572a2153b9
1734 F20110320_AABUSI patil_m_Page_61.txt
ca30576653ed1efd524a749073257e48
580eb96dde20c923531f3c6e7856639531b045e9
125875 F20110320_AABVJB patil_m_Page_45.jp2
6e420820c2319be988507992f68c038e
4ec174a449419d57c3b564956d2b57ca5e83d0a4
208449 F20110320_AABVEE patil_m_Page_27.jpg
f0c7b0f4a769b3d9d6416133167519af
ec164cfba7b20bd03ba3a627a0de78330efe1b0d
F20110320_AABUXH patil_m_Page_75.tif
1cd54c55c16fe6780b515afab4041ced
26ca0b47edb892cdc81529d8ae27032a98dd7838
46140 F20110320_AABUSJ patil_m_Page_57thm.jpg
5aa663d7d98bf655cc4268d1c689acf4
2e347a3c54f4a10fa89f3627d30e50206b0d41d7
152841 F20110320_AABVJC patil_m_Page_46.jp2
0151d295aee5d7ed562976465f0032d9
65c9eadf8d521b91e1f53bb68f5d19696d52ff4e
75770 F20110320_AABVEF patil_m_Page_27.QC.jpg
f086b4f71ce2ddedba8acf26e88d8649
f5853fecf398ddc0dea20a75dc331e331202418d
F20110320_AABUXI patil_m_Page_76.tif
fe19fb1db3b3534cad5b45ad8c2f865b
9a6a410e08880abad4a7bf568fd2c6ae4ecf1a5f
F20110320_AABUSK patil_m_Page_27.tif
393b9c20aef5279e626a8dab8784da41
5aafe7caf42a7296d1fd633a1c1d7ff4b3dd46f6
46815 F20110320_AABVJD patil_m_Page_47.jp2
a6fcee50d8e670ce41de10a34fac4981
838c81d850b336dea248d7a03d9d6a2dfdbbea87
175228 F20110320_AABVEG patil_m_Page_28.jpg
f75a2067ec641e074ec5ac3b9409cbd5
e111300971e50610c161917370edd7e731a4cb71
F20110320_AABUXJ patil_m_Page_77.tif
957539b13ee903e7ecef3b5e7f6d03b9
4457fb15ac2aed1525f5ad24fbee8bbaa101fd9a
1001386 F20110320_AABUSL patil_m_Page_13.jp2
9bf3684626a34f6dcc93685a355262ce
029d7223df2a0e00195498c57372e2041c2c57fc
80555 F20110320_AABVJE patil_m_Page_48.jp2
b77f15fc402e9c68fccc5df4c31e7e22
bf80eb8b5642224ead7a0d79feb6880c670021ac
60031 F20110320_AABVEH patil_m_Page_28.QC.jpg
d12f57a4b4a270cb7233dbed59bbafca
e9a6a19e2e2bc5a25bd5f2ef6cf84632b50e9f82
66396 F20110320_AABUSM patil_m_Page_37.QC.jpg
a067289e8371ac353d237bb52dfad11f
8cfc2ab1739e9b9f1c7a9d9263217af3992d7d6b
92280 F20110320_AABVJF patil_m_Page_49.jp2
9955da25c8981c6bba4b04e9fa8cfea1
b56fe6f9ca031311ffe242de821d81cc2a0f0aa1
54922 F20110320_AABVEI patil_m_Page_29.jpg
a97a2fe40d8e84c85677a0f5d0e2b544
a3ad6bfbc0cdd10af7d463ac041f0b334135c5aa
453 F20110320_AABUXK patil_m_Page_01.txt
2dbe67f6f5e0ecd79eb249b7ab72d06e
aa1d2419f28e2fe6452cb0285871563d745c9cee
2970 F20110320_AABUSN patil_m_Page_03thm.jpg
9ec443dfeab904c2fad17cf338dda3a7
5ebf80d4ea81ca5f1ab12d789a31f8d09581fa2b
99931 F20110320_AABVJG patil_m_Page_50.jp2
3de325e43e3108e056986e87a2e89d86
f08e199d698eb7a9ad8f4c318852c574b3f7878f
20702 F20110320_AABVEJ patil_m_Page_29.QC.jpg
ec6dfe2a0bd06a9d115f6667ed3965b2
a72a1f2605af0469526ffa66470b2ab8f6dadb25
125 F20110320_AABUXL patil_m_Page_02.txt
223a85dbce9b147e073b11c90416b799
e8381bcfa04fbcf21500462b9f9622292828a611
206846 F20110320_AABUSO patil_m_Page_23.jpg
475fa62de6fc37132eba4a20a10de8fb
dcbb7e772cb00e8eb4c953f0e935d9915fe6e4ff
F20110320_AABVJH patil_m_Page_51.jp2
a97832e080cefdd8e9b90ee5a6506b04
237912711ddd3ca587ed55ca7e79c81ec01a3afb
82953 F20110320_AABVEK patil_m_Page_30.jpg
32155ed4ca239119cb0e643abe2d1522
c8f509663ada140d64b6d72c4364d8c9094e2caa
108 F20110320_AABUXM patil_m_Page_03.txt
2aeba3e29ec016285aa2bf5888602c90
b8a2ffdc4e5138291992c374cc38666576162b33
24942 F20110320_AABUSP patil_m_Page_17thm.jpg
1151531916e8c4f7482d47b67cb41cd8
ed2905932208414bf4db8f7ccca8410f570d81ed
1010197 F20110320_AABVJI patil_m_Page_52.jp2
fa4c101e57a4614a7edb0bc6f122e1e8
65885bdf75d468f6e2736b883f6f39eab8098eec
31517 F20110320_AABVEL patil_m_Page_30.QC.jpg
0055672e3b2d94e608c41e5ab177ffe7
b8fc2e5bbbb511275faa23fc9c63b3e6e5294191
1230 F20110320_AABUXN patil_m_Page_04.txt
08ee0dd60d59ab5d3d191ce1728d6a5f
5575e601b68bb0df144450a64caa7f212435685f
219152 F20110320_AABUSQ patil_m_Page_17.jpg
8ef096b46a37a819ccf60022d29afbfa
047e4795ae277084ab621c7f8106ea127671d684
1051977 F20110320_AABVJJ patil_m_Page_53.jp2
49da47ef6b94993bdff46f1c6522d67d
e1540e2ab25c527245d18de8228cdece76850314
63351 F20110320_AABVEM patil_m_Page_31.jpg
2abbf09eb82c6a4e6d93132ada8e525b
d3292790b22341bdfe4a3ae352d685ab430627ed
2745 F20110320_AABUXO patil_m_Page_05.txt
7769a7202b52d389e0b06372ed5bdee6
1617a14a127aa89d60a06ac9dabbda4f7e6d5571
F20110320_AABUSR patil_m_Page_36.tif
ccd2fe858e1ececa1ec166decff9bed4
873fb1b28b75bc064270caf19cde3194aa7c3c71
885230 F20110320_AABVJK patil_m_Page_54.jp2
5e20bec7e33d4d49ea543c3e1c9f387c
73dead0dcdadc208860545cfde5869f6680b368b
25361 F20110320_AABVEN patil_m_Page_31.QC.jpg
e1ec2478d4a70881abd7cec79c4ad947
37abe0b969450b4785003e2313f133337f824836
4068 F20110320_AABUXP patil_m_Page_06.txt
0a58cdfa39eb039501e3f90bf6cacad9
9cc8ba47319e9a41cfdb2d0e0310acdba3e8c9ac
31936 F20110320_AABUSS patil_m_Page_08thm.jpg
2b492f5ffff142b7e4db2a8bdff4cfb6
393e844c0eebe78b087ab34168105d304cb591b3
97510 F20110320_AABVJL patil_m_Page_56.jp2
56fab8b4ff974a8b16e03d0b0df03b2c
13aefcd55924110b0f40bf1a26358b42ea2a236a
97058 F20110320_AABVEO patil_m_Page_32.jpg
b952d7c50e61d7c7def886b83c81798a
4cecb5561aa202003ab0c9300bb1ebdbb1f83ddf
1289 F20110320_AABUXQ patil_m_Page_07.txt
709798fa767fa3945e91013a73a8f164
d2dfe11e4d5c5f5a0d406345d90e84935cdff699
78860 F20110320_AABUST patil_m_Page_34.QC.jpg
6f292a9715a7a373fcfd3357dec884f2
dc63a521486f2ae6ab70d4ff314a99aad8ae87f8
1051978 F20110320_AABVJM patil_m_Page_57.jp2
e025ee2c1944e52fd584999879453c37
b8c9782966525c42731b912183419a8664fcc4d7
29154 F20110320_AABVEP patil_m_Page_32.QC.jpg
f1c6281b99749a086ac0aaedf000d559
2dd8bf9bee2f0548e8baf70f6985ce0055d725fc
579 F20110320_AABUXR patil_m_Page_08.txt
ffaf084a411172b1e5b6bc7617038339
4ca651b446013e0befeea9b25e6f199699a8acde
67668 F20110320_AABUSU patil_m_Page_33.jp2
361b51b5bc6ce84cd64643b482340a36
90608b3b83145e77da424d72bc576abd4bd30992
100987 F20110320_AABVJN patil_m_Page_58.jp2
7411b0461f18c30ca3e74a5f33b7511c
a10986d48c15ce231f57c1d777a94f463af58060
134781 F20110320_AABVEQ patil_m_Page_33.jpg
6d0e024b23a250fdce6cd54f29029dcd
fa4b5046dd463de097e2bcd848632ec4f0859348
2291 F20110320_AABUXS patil_m_Page_09.txt
d22d968b8e88a0822dcf188b1d7958b3
a21e3f584f4bd50e3b0d9eba8346f42de03261e1
21259 F20110320_AABUSV patil_m_Page_56thm.jpg
4f1a7a0771b117e0315c3df52e35d07b
d8f4b80a977fd55ff6d88d2c6b1ff3610fae3cc3
920401 F20110320_AABVJO patil_m_Page_59.jp2
db547a7ba177438d32f7af8734e29611
e9eb2f4101cffdab5015789a5f853c5b3e98aba2
41471 F20110320_AABVER patil_m_Page_33.QC.jpg
26a594b4b54d4c8fa7c2b85fa1f35eaf
85d17ef99c29fc577606750d00473f4d4485caa8
1717 F20110320_AABUXT patil_m_Page_10.txt
34e659d99a2fd7ac3a25ba31d97419da
3070dfcfb29b1173845b6f5e6dd0974ef7a85005
95740 F20110320_AABUSW patil_m_Page_60.QC.jpg
d38876c96129e5cec0f3dab3a1ecc039
78192c5d23c1c9f270f28a5d4eb5444d7722aea9
1046003 F20110320_AABVJP patil_m_Page_60.jp2
eb769d7facb0225b518c9131a9786f1b
f1128f2c49007062e03706fa122cb1cb0741aacc
226288 F20110320_AABVES patil_m_Page_34.jpg
400d39905aa9ff10d0e767d166ce59c6
0d0df26f22503b4a247f663545b7d80188e3a150
1404 F20110320_AABUXU patil_m_Page_11.txt
ef94e723d973e16740f237107484c503
0ab25fb6e9fb4eaf16cdf94548b0151650f01279
F20110320_AABUSX patil_m_Page_09.tif
41a93e89d3ade0029962c4b4b375eae5
66fb0df67a033855730cfac93465a4b99eee8a2c
94706 F20110320_AABVJQ patil_m_Page_61.jp2
412ac90a6d8372b2694d90e5c259286e
0ad1315f7639531ceda34d62b08f357d38323346
58565 F20110320_AABVET patil_m_Page_35.jpg
710430bce9ee3bf632a9d5578685b8de
48f7593d6c390a1594603afe8fcfd5a6f95f95da
1750 F20110320_AABUXV patil_m_Page_12.txt
3e14ed37f0a6883f464033c3a3072a48
7a0514a3ab9b5d393583365d5360ba02965d3f35
8686 F20110320_AABUSY patil_m_Page_01.pro
b5f3fed7c92677055431dd8820dc98d0
d09b50a273b695655f2bb54887c72dcebd9cd5fb
98657 F20110320_AABVJR patil_m_Page_62.jp2
42c6ef00bceac5dfd5108e349b98fa08
a674e716d4796626aebfc0e8f8a919e75bc45acb
17096 F20110320_AABVEU patil_m_Page_35.QC.jpg
8f1874ce11a34972e045b6934f9ecdfd
1ae149be620596ae9c8ecc61118f6e83adc81348
1115 F20110320_AABUXW patil_m_Page_13.txt
d5dd09428774b7cc7030c8741f50ce2c
7dc2ec4383091487018ca868634c07b2361d2a2f
F20110320_AABUSZ patil_m_Page_04.tif
89a8a487bfeb80d6d7e15fb6e4dc1252
92aa3098a9f9b647e49891864b4a1e7fed1b3dc3
81255 F20110320_AABVJS patil_m_Page_64.jp2
ef84ebf1cbcd7e0e8d0958072ed6a6c9
c3dabfc94772be05171e38632c32c5cde60487e1
2821 F20110320_AABUXX patil_m_Page_14.txt
72570974de2f0f460c1cb0598fd54274
c03aae934d4fded752df5497422e7f5eba8344ce
23797 F20110320_AABVEV patil_m_Page_36.QC.jpg
a1a87606e4d31b093fff197a1cdf6580
0665173705e0ee15bb7f037b3e16210252f28a1f
1051292 F20110320_AABVJT patil_m_Page_65.jp2
917caecdfe098c17b1af362573bdc6ef
a859497ee6151458879f38c22eff2fa0b07ee881
F20110320_AABUVA patil_m_Page_11.tif
487f57f6bf5cd956c672c16a66f6a14e
f088a6dfcb2a6774239612b64bab3e1241d8451f
3073 F20110320_AABUXY patil_m_Page_15.txt
281c9c0b6ff34f0f818569f5ea22d9d0
d4ff1103bd249ce95c7ebd2e92146d42c7b5bf06
1035043 F20110320_AABVJU patil_m_Page_66.jp2
d2a3e4a060b56a13da6c47ab3de93a6a
a11f78064e91bf490368d96411ebaaa33d32aa92
1880 F20110320_AABUXZ patil_m_Page_16.txt
065b996bb19b8794b1b20aed8b820804
baacb60aaa3cfe1234e32bb809b9092585beec5a
222509 F20110320_AABVEW patil_m_Page_37.jpg
30f450588e6f4a2908141e283aab0312
789abb37afe2c3deaabb54f176e6b5cb63527839
F20110320_AABUVB patil_m_Page_12.tif
649f6b524bd17aa823786326a595dc64
c8317ba0f44bb59123c5a9e4151c53cce13751c4
1051929 F20110320_AABVJV patil_m_Page_67.jp2
2eac7d588ad355caaf8d204bc38ad66f
1e589c43ccecb1523a1035fe07f622818bf3b40f
175342 F20110320_AABVEX patil_m_Page_38.jpg
0afd1a05544549c1ddf87547ca0a15c4
229566a302a25f2c4f9a7c3021f2f8a37343b4c4
F20110320_AABUVC patil_m_Page_13.tif
544ce55743dafd2d769c6930b3be50d3
2e059b1ab40eeb67780504ffb5e1f55b4e4c521e
98845 F20110320_AABVJW patil_m_Page_68.jp2
4ee8d7bd529e6465e94eb81cc3ea5a11
06afd8e576565b984fbe9e3b471fe8572faaecfa
48433 F20110320_AABVCA patil_m_Page_63.pro
fa97bf19bede9245691601179afeb980
3cb46042690cf57c3d685da5758b5f51db71ea1d
92087 F20110320_AABVEY patil_m_Page_39.QC.jpg
7050f406aaa71118c129e6a2549d3279
bdbe78fe971c1e53a1bcb58fca8c19ea6831e760
F20110320_AABUVD patil_m_Page_14.tif
ee344736496a41b6d750edeaaa0e65e4
52629f59c6529f8890c03f0049f766ee236db784



PAGE 1

SCHEMA EXPORTATION AND INTEGRATION FOR ACHIEVING INFORMATION SHARING IN A TRANSNATIONAL SETTING By MANJIRI PANDURANG PATIL A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLOR IDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2005

PAGE 2

Copyright 2005 by Manjiri Pandurang Patil

PAGE 3

I dedicate this thesis to my beloved parents.

PAGE 4

ACKNOWLEDGMENTS Research for this Transnational Digital Government project is supported by grant EIA-0131886 from the National Science Foundation. I would like to thank Dr. Stanley Y. W. Su (my supervisory committee chair) for giving me an opportunity to work on this thesis topic and for his valuable guidance and support in this research effort. I would also like to express my gratitude to Dr. Jose Fortes (supervisory committee member) for his feedback and guidance, during the design and implementation phases of my research work. I would like to thank Dr. Herman Lam for serving on my supervisory committee. I would like to extend my gratitude to Mauricio Tsugawa and Andrea Matsunaga, Ph.D. students from the Advanced Computing and Information Systems Laboratory (ACIS Lab) for their help in integrating our system with the Machine Translation System and the Conversational Interface System. I am also grateful to all of my friends for their help and support. Most of all, I would like to thank my beloved family for their love, support, constant encouragement, and blessings. They made this thesis possible. iv

PAGE 5

TABLE OF CONTENTS page ACKNOWLEDGMENTS .................................................................................................iv LIST OF TABLES ...........................................................................................................viii LIST OF FIGURES ...........................................................................................................ix ABSTRACT .........................................................................................................................x CHAPTER 1 INTRODUCTION........................................................................................................1 1.1 Background and Motivation...................................................................................1 1.2 Challenges and Approach Taken............................................................................3 1.3 Thesis Organization................................................................................................7 2 OVERALL SYSTEM ARCHITECTURE...................................................................9 2.1 Participating Sites.................................................................................................10 2.2 Databases..............................................................................................................10 2.3 Export Schema Tool.............................................................................................11 2.4 Schema Integration Tool and the Generation of a Global Schema......................11 2.5 Event Server..........................................................................................................11 2.6 Event Trigger Rule Server (ETR).........................................................................12 2.7 Distributed Query Processor.................................................................................12 2.8 Integration with the Language Translation System..............................................12 2.9 Integration with the Conversational Interface System..........................................13 2.10 Authorization of Agents in the Watch-List Scenario.........................................13 2.11 Short Message Service Center............................................................................14 3 DETAILED DESIGN.................................................................................................15 3.1 Export Schema Tool.............................................................................................16 3.2 Schema Integration Tool to Generate Global Schema.........................................23 v

PAGE 6

4 DISTRIBUTED QUERY PROCESSOR AND WATCH-LIST SCENARIO...........27 4.1 Global Query Processor (GQP)............................................................................27 4.1.1 Global Schema Files...................................................................................27 4.1.2 Country Information...................................................................................29 4.1.3 Tomcat Authentication and User Profile Information................................29 4.1.4 Global Search Form....................................................................................31 4.2 Local Query Processor (LQP)..............................................................................33 4.2.1 Web Service Interface for LQP..................................................................34 4.2.2 The Wrapper Associated with the LQP......................................................34 4.3 Watch-List Scenario.............................................................................................35 5 IMPLEMENTATION DETAILS...............................................................................38 5.1 Export Schema Tool.............................................................................................38 5.2 Integrate the Local Schemas to Generate the Global Schema..............................41 5.3 Distributed Query Processor.................................................................................44 5.3.1 Global Query Processing Component (GQPC)..........................................44 5.3.2 Local Query Processing Component (LQPC)............................................46 5.4 Watch-List Scenario.............................................................................................47 5.5 Translation System...............................................................................................49 5.6 Conversational Interface System..........................................................................50 6 TECHNOLOGIES USED..........................................................................................51 6.1 The Events, Triggers, and Rules (ETR) Technology...........................................51 6.1.1 Events, Triggers, and Rules........................................................................52 6.1.2 Event Manager............................................................................................52 6.1.3 The ETR Server..........................................................................................53 6.1.4 Knowledge Profile Manager (KPM)..........................................................53 6.1.5 Persistent Object Manager (POM).............................................................53 6.2 The Java Technologies.........................................................................................54 6.2.1 Java Servlet Technology.............................................................................54 6.2.2 Java Server Pages (JSP) Technology.........................................................54 6.2.3 Tomcat........................................................................................................55 6.3 The XML-Related Technologies..........................................................................55 6.3.1 Extensible Markup Language (XML)........................................................55 6.3.2 Xerces: XML Parsers in Java.....................................................................55 6.4 Web Services........................................................................................................56 6.5 Simple Object Access Protocol (SOAP)...............................................................56 6.6 Apache Axis..........................................................................................................57 6.7 The MySQL Database..........................................................................................57 vi

PAGE 7

7 PERFORMANCE EVALUATION............................................................................59 7.1 Query Performance...............................................................................................59 7.1.1 Simple Queries...........................................................................................59 7.1.2 Aggregate and Join Queries........................................................................60 7.1.3 Queries Invoking the Translator.................................................................61 7.2 Performance of Export Schema and Schema Integration Tools...........................61 7.2.1 Export Schema Tool...................................................................................61 7.2.2. Schema Integration Tool...........................................................................61 7.3 Performance of Rule Processing and Event Notification.....................................61 8 CONCLUSIONS AND FUTURE WORK.................................................................62 LIST OF REFERENCES...................................................................................................64 BIOGRAPHICAL SKETCH.............................................................................................66 vii

PAGE 8

LIST OF TABLES Table page 3-1. Dominican Republics sample exported schema........................................................21 3-2. Belizes sample exported schema...............................................................................22 3-3. Attribute mappings in the global schema...................................................................26 4-1. Role list based on access privileges............................................................................30 viii

PAGE 9

LIST OF FIGURES Figure page 1-1. Virtual collaboration grids............................................................................................2 2-1. Overall system architecture of the prototype system....................................................9 3-1. Export schema and integrate exported schemas.........................................................15 3-2. The export schema flow chart....................................................................................18 3-3. The add attributes to export schema flow chart..........................................................19 3-4. Generate global schema by mapping the exported attributes.....................................25 4-1. Architecture of the Distributed Query Processor.......................................................28 4-2. Global search form at the Belize site..........................................................................31 4-3. The Watch-List Scenario flow chart...........................................................................36 5-1. Format of the exported_attributes.xml file.................................................................39 5-2. Export schema page....................................................................................................40 5-3. Add attribute to export schema page..........................................................................41 5-4. Published schemas page.............................................................................................42 5-5. Mapping page for exported attributes.........................................................................43 5-6. Sample XML query..................................................................................................465 5-7. Sample XML result....................................................................................................46 5-8. Query results displayed at the Belize site...................................................................46 5-9. Create authorized agents list page.............................................................................48 5-10. Arrival form at the port of entry in a Dominican Republic border station...............49 ix

PAGE 10

Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science SCHEMA EXPORTATION AND INTEGRATION FOR ACHIEVING INFORMATION SHARING IN A TRANSNATIONAL SETTING By Manjiri Patil May 2005 Chair: Stanley Y. W. Su Major Department: Computer and Information Science and Engineering There is an urgent need for collaborations among governments of various countries to tackle global problems such as drug trafficking, disease control, immigration and border control, and terrorism. The Transnational Digital Government project (funded by the National Science Foundation) aims at collaborating, integrating, and sharing information among governments/agencies using information technologies. The transnational government collaboration faces many challenges, because individual countries differ in their languages, laws, policies and regulations, infrastructures, and other resources. Our study focused on the development and use of advanced information technologies for the collection, processing, exchange, and integration of the information needed in a transnational digital government setting. We developed distributed database technologies to support the needs of the project. We designed and implemented an Export Schema Tool for participating countries to define the data that they are willing to share with other countries/agencies (i.e., to define x

PAGE 11

export schemas). We also designed and implemented a Schema Integration Tool for correlating (mapping) and integrating the data entities and attributes specified in different natural languages and stored in different databases. The exported schemas were used to generate a Global Search Form. Data mapping information and the integrated schema were used by a Distributed Query Processor to query and retrieve data from heterogeneous database sources. Our system was integrated with a language translation system developed at the Carnegie Mellon University (Pittsburgh, Pennsylvania) and a conversational interface system developed at the University of Colorado (Boulder, Colorado) to achieve international collaboration. Interoperation among all of these system components was achieved through a Web Services infrastructure. We also demonstrated the use of events, triggers, and rules to enforce government policies and security constraints; and to facilitate event filtering and notification (in a sample scenario called the Watch-List scenario). Contributions of this work are design and development of the Export Schema Tool and the Schema Integration Tool; and integration of these tools with an enhanced Distributed Query Processor, a language translation system, a conversational interface system, and an Event-Trigger-Rule Server. xi

PAGE 12

CHAPTER 1 INTRODUCTION 1.1 Background and Motivation Countries all over the world are facing global problems such as drug trafficking, immigration and border control, disease detection and control, global education, terrorism. These problems can be solved through information sharing and close communication, coordination, and collaboration among government agencies in various countries. There is an urgent need for developing and integrating advanced information technologies to enable government agencies within a country (as well as across national boundaries) to share information and to work together. The Transnational Digital Government (TDG) project is a research project funded by the National Science Foundation (NSF) of the United States. It aims to develop and apply advanced information technologies to address global or regional problems. Under this project, researchers from seven universities (Carnegie Mellon University, University of Belize, University of Colorado, University of Florida, North Carolina State University, University of Massachusetts and Pontificia Universidad Catlica Madre y Maestra of the Dominican Republic) and experts from agencies in three countries (the Organization of American States (OAS) of the United States, the National Drug Abuse Control Council of Belizes Ministry of Health, and the National Drug Council of the Dominican Republic) are developing information technologies to enable information sharing, integration, and coordination among agencies of the collaborating countries. The developed information 1

PAGE 13

2 technologies will enable transnational resource sharing and inter-government and inter-organizational collaboration over virtual collaboration grids (Figure 1-1). Internet Country W Dominican Republic Belize Country X Country Z Country Y US Figure1-1. Virtual collaboration grids To build the transnational prototype system, the participants teamed up with two small countries (Belize and the Dominican Republic), and jointly identified immigration and border control as the transnational problems to tackle. The idea was to share information across countries and agencies, for tracking movements of people entering and leaving these countries. Thus the goal of the initial system is to allow government agencies of collaborating countries to Enter and share immigration information (arrival and departure information of travelers) Integrate the shared information to generate a global view of the distributed data, to facilitate querying Access distributed data to identify suspicious individuals

PAGE 14

3 Support and coordinate inter-government and inter-organizational activities by secured data access, event notification, and policy enforcement Deliver useful information to the right people and organizations, at the right time, using different modes of communication Information technologies being developed by the researchers in this project include a conversational interface system, a language translation system, a collaborative information management system, Internet portals and services, and a network support for collaboration grids. These technologies can be used to solve many other transnational problems similar to the immigration and border control problems. The Research and Development focus of our study was the collaborative information management system. 1.2 Challenges and Approach Taken Solving the complex problems in the transnational setting presents many new technological challenges [1] as described below. Data heterogeneity. Data gathered by the agencies at the ports of entry in both Belize and the Dominican Republic is stored in different formats, structures, and schemas. An integrated, global schema (Section 4.1.1) is needed to give users a uniform view of the distributed data. For this, we designed and implemented a system for data sharing by the two countries, and provided techniques for data mediation and integration. The distributed query processing system is developed for accessing this shared data. The global schema is presented in the different natural languages used by users (i.e., English for Belize users and Spanish for users in the Dominican Republic). 1. 2. 3. Language heterogeneity. The collaborating countries (Belize and Dominican Republic) use different natural languages. The Schema Integration tool is needed to specify the equivalence relationships between the data entities and attributes used in the heterogeneous databases of these countries. The language translation system is needed to translate sentences recorded in the comment field of the port-of-entry forms. For this, we integrated our system with the language translation system (Section 2.8) being developed at the Carnegie Mellon University. Heterogeneity in government policies, and security and privacy rules. Each country may have its own policies, regulations, constraints, and rules regarding what information can be accessed by whom; and when and how information can be used. These policies and regulations may change with time. We provide a system to define and execute such rules. For instance, a country may have a rule that a tourist

PAGE 15

4 official, while querying for some visitors arrival/departure information through the arrival/departure form, will have access to the visitors tourism data or arrival data, but will not have access to the departure data. To achieve this functionality, we use the Knowledge Web Server [2], developed at the Database Systems Research and Development Center, University of Florida. The Knowledge Web Server provides advanced event-filtering and rule-processing capabilities; and tools and software components for defining and processing events, triggers, and rules (Section 6.1.1). Difficulties in inter-agency and inter-government communication and coordination. Communication and coordination are vital among collaborating countries. Collaborating countries can inform others of important events (e.g., the outbreak of a disease, or a terrorists movements), by automatically sending notifications and delivering relevant information on the occurrence of important events. To achieve this, we provide tools and mechanisms for supporting event publication, subscription, filtering and notification, and for performing event and rule-based triggering of operations and processes. 4. 5. Heterogeneity in working environments and computing platforms. Government agents may have varying access to some of the computing facilities; or access to the Internet may be unreliable, or missing. Our system provides different means of communication and notification for such users (e.g., communication by emails and short messages via cell phones). Different government agencies worldwide use dissimilar hardware, software, operating systems, database-management systems, and application systems to perform their functions. There is a need for a common, standard-based infrastructure for accessing and interoperating these resources over a wide-area network like the Internet. Our system uses the Web Services model (Section 6.4) to achieve software resource sharing and interoperation of heterogeneous application systems. The Simple Object Access Protocol (SOAP) (Section 6.5) was used to invoke the Web Services. These Web Services can be accessed over the Internet via HTTP. To show the transnational scenarios decided by the participants of this project and to show the approaches taken to solve the challenges explained above, we developed a Transnational Digital Government (TDG) prototype system at the University of Florida. Design and implementation of this prototype system was the purpose of our study. The system comprises Tool for participating countries/agencies to specify those and only those data that they are willing to share with others (i.e., for defining export schemas) Tool for integrating and correlating the exported information Distributed query-processing system for accessing the shared data

PAGE 16

5 Knowledge Web Server comprising an event server, an event-trigger-rule server, and knowledge profile manager. All of these components were developed at the University of Florida. They were integrated with a language translation system developed at the Carnegie Mellon University, and a conversational interface system developed at the University of Colorado. A Web Services infrastructure was jointly implemented by the collaborating universities to achieve the interoperability of these system components. To test and demonstrate the developed technologies, the projects initial focus was on the information-sharing and process-coordination problems related to border control against illegal immigration and drug trafficking. Our system (executed in Belize and the Dominican Republic) focuses on connecting border stations between these two countries, but the technologies can be used in other problem domains to enhance international cooperation. Limitations of the former prototype system: The Transnational Information Sharing and Event Notification System [3] was developed only for processing distributed port-of-entry and exit data. It cannot be extended to other categories. It was built on a fixed set of database schemas, and was not built to handle join queries and queries that contain aggregate functions. The system can only handle a single user request at a time (i.e., queries issued by multiple users are not processed concurrently, but instead in a sequential order). Thus, there was a need to make this system more robust and extensible so that Multiple authorized users can query the system concurrently Code change will not be necessary in case there is a change in the export schema defined by a participating country or agency

PAGE 17

6 Same system can be used for information sharing in other problem domains such as agriculture inspection and protection, disease control, and homeland security To overcome the limitations of the initial system, we have developed an Export Schema Tool (Section 2.3), which facilitates any agency in a country to define an export schema in any application category that the agency is willing to share with others. This tool is replicated and installed at the sites of all the participating countries, and the user interface of this tool allows users to select the natural languages that they desire for communicating with the tool. There is also a need for a tool to define new application categories for which schemas can be exported by participating countries or agencies. The exported schemas can then be integrated at a host site to generate a global schema, for querying purposes. To meet this need, we have developed a Schema Integration Tool (Section 2.4), which is installed at the host site. A person who knows the languages of the participating countries can log-in to this tool and perform data mappings (i.e., to specify the equivalence relationships) between data entities and attributes given in the exported schemas of an application category, as a way to integrate them and to generate the global schema. The Distributed Query Processor (DQP) (Section 2.7) has been enhanced to use this global, integrated schema and also to process join and aggregate queries on the distributed, heterogeneous databases. It has been further enhanced to use the language translation system developed at the Carnegie Mellon University to mediate the language heterogeneities and display the results of the issued query in the users own natural language. Another extension added to the DQP was its integration with the conversational interface developed at the University of Colorado. The queries issued by the conversational interface are processed by the Distributed Query Processor, and the

PAGE 18

7 query results are sent back to the conversational interface. The interoperability between all these system components is achieved through the Web Services infrastructure. We also integrated our Distributed Query Processing System with the Knowledge Web Server, to demonstrate the enforcement of policies and regulations using events, triggers, and rules. The Watch-list scenario (Section 2.10) was added to create an authorized list of the immigration agents by some supervisor and to mark selected agents as under suspicion. When a traveler enters the country, the port-of-entry event occurs and a rule is triggered to check if the traveler is in the watch-list. If so, a notification (email and/or cell phone) is sent to the subscribers of the event. Along with this, an alert message is shown to only those agents not under suspicion, to warn them that the traveler is in the watch-list. An agent who is under suspicion of collaborating with the traveler will not get the alert message, but the notification of the travelers arrival will be sent to all relevant agencies. 1.3 Thesis Organization This section describes the organization of the thesis in the following chapters. In Chapter 2, we explain the overall architecture of the TDG prototype system and briefly describe the functions of its system components. In Chapter 3, we explain the Export Schema Tool, developed for exporting the shared information to the host site and the Schema Integration Tool, developed for mapping the exported schemas to generate a Global Search Form. In Chapter 4, we describe the enhanced Distributed Query Processing system and its various components. DQP uses the Global Search Form for accessing the shared information. In this chapter we also describe the Watch-list scenario, which makes use of the Knowledge Web Server. Chapter 5 provides the implementation details of the system. In Chapter 6, we describe the existing technologies used to

PAGE 19

8 implement the system. In Chapter 7, we give the performance evaluation of our system, and in Chapter 8, we give a conclusion of this work and propose some problems for future work.

PAGE 20

CHAPTER 2 OVERALL SYSTEM ARCHITECTURE This chapter provides an overview of the system architecture of our prototype system. The various sections describe the components, which include the tool for exporting and integrating the schemas, the distributed query processor, the watch-list scenario, and the integration with the language translation system and the conversational interface system. In this chapter, we shall also discuss the participating sites, the databases used, the Short Message Service Center, the ETR Server, and the Event Server. E xp. Schema Collaboration Portal wSchema Integration Tool, Event Registration & Subscri ith p tion facilit y Host Site (OAS) *SMSC *SMSC DR Belize ETR S erv e r Event S erve r Translato r Dist. Q P DB DBMS ETR Serve r Event S erve r Translato r Dist. Q P DB DBMS Internet Point o f entry Point o f entry Stations with Con v Interface Stations with Con v Interface Agencies Agencies People People Event Registration and D iscoveryelivery Query Event Notification and Data D Post events Post events query query Data otificationotification Cell phone n Cell phone n entry Data entry *SMSC: Short Messa g e Service Cente r Exp. S chema Exp. S chema Figure 2-1. Overall system architecture of the prototype system 9

PAGE 21

10 The overall system architecture is shown in Figure 2-1. This system prototype is developed for processing distributed immigration data (i.e., port of entry and exit data), but it can be extended and used in other application domains such as disease control, agriculture security, etc. The various components of the system are described below. 2.1 Participating Sites There are three participating sites in this prototype. Host Site Belize Site Dominican Republic Site The Host Site has a collaboration portal and provides the facility for generating the global schema, event registration, and subscription. The two participating sites, one in Belize and the other in the Dominican Republic (DR) represent the agencies in the participating countries. The developed software components are extensible and they can accommodate a larger number of participating countries and agencies. The users of this system are authorized users at the host site and the sites of the participating countries. They include agents at the border stations and government agencies related to immigration. 2.2 Databases Figure 2-1 shows a local database system at each of the participating countries sites. Each country may have databases from different vendors, and also the structures and schemas of these database systems may be different. Our system provides a tool to export the sharable entities and attributes of these local databases. The export schemas are integrated to produce a global schema, which represents the view of the distributed data as seen by the global users of the prototype system. Here, global users are those who have the right to query for distributed data. A global user can thus issue a query 10

PAGE 22

11 against the generated global schema. The query once issued will be sent to the local databases of the participating countries. It will then be processed by the local database systems to extract relevant data from the local databases, and return the retrieved data to the user. 2.3 Export Schema Tool The Export Schema Tool is deployed at the local site of each participating country as shown in Figure 2-1. This tool allows an agency of a participating country to define those and only those data entities and attributes that it is willing to share with others. The data defined in an export schema can thus be queried by legitimate users through a Global Search Form, which will be explained in Section 4.1.4. 2.4 Schema Integration Tool and the Generation of a Global Schema This tool, installed at the host site, is used to establish the semantic and language equivalence relationships between data entities and attributes defined in the exported schemas. It allows an authorized user at the host site (an IT personnel who knows different languages of the participating countries) to establish mappings between two sets of entities and attributes, which are exported by the participating nations and defined in different natural languages. The result of this data mapping process is a set of data mapping tables and a global, integrated schema. They are stored as global schema files (Section 4.1.1) at the host site and sent to the participating countries sites by invoking their Web services. 2.5 Event Server The event server handles event registration, event notification, and also communicates with the local ETR server, to activate rules triggered by those events. We 11

PAGE 23

12 use the Event Server in our system in the Watch-list scenario to identify suspicious individuals and send event notifications to the subscribers of this event. 2.6 Event Trigger Rule Server (ETR) The ETR server (Section 6.1.3) handles the installation and processing of rules at each site. Whenever the ETR Server receives an event notification from the Event Server, it identifies the proper triggers and rules to be executed. 2.7 Distributed Query Processor This module is also deployed at the local site of each participating country. It includes a Global Search Form, which is dynamically generated using the global schema files. The Global Search Form includes entities and attributes that are the union of all the entities and attributes shared by the participating countries. If a participating country makes changes to the shared entities and attributes, those changes will be reflected in this form. A new country can easily become a part of the Global Search Form by sharing its database entities and attributes without involving any changes to the underlying code. Authorized users of the participating countries use this form to issue queries to access data stored in the local databases of these countries. The queries can be simple queries, join queries, or queries that contain aggregate functions like max, min, sum, average, and count. 2.8 Integration with the Language Translation System The language translation system is developed at the Carnegie Mellon University. The integration of the language translation system with our system is required since the participating countries may use different natural languages. In that case, there will be a need to translate some of the data into the language of the logged-in user. For example, in the prototype system, Belize uses English language whereas the Dominican Republic 12

PAGE 24

13 uses Spanish. There are several instances in our system where we invoke the language translation system through a Web Service interface that it provides. 2.9 Integration with the Conversational Interface System The conversational interface system is developed at the University of Colorado. This system demonstrates the use of natural language to query the global database, and display the result to the user. The natural language query is translated into a query that is processed by the Distributed Query Processor to retrieve data stored in the database systems of the participating countries. The query is sent to the Distributed Query Processor in an XML format, and the retrieved data is also sent back to the conversational interface in a predefined XML format. The communication between these two system components is achieved through Web Services. 2.10 Authorization of Agents in the Watch-List Scenario This module is installed at the local sites of each of the participating countries. The purpose of this component is to allow a supervisor to authorize the agents at the border stations, to use the system and also to mark some agents as under suspicion of collaborating with some people in a watch-list. In this scenario, if some suspicious individual enters the country, the watch-list database will be checked to see if the traveler is present in the watch-list. If he/she is in the watch-list, then a warning (alert message) will be shown to only those agents, which are not under suspicion. Event notification will also be sent to all the subscribers of this watch-list event (e.g., security agencies, military, and law enforcement organizations). Thus, an agent under suspicion will not receive the alert signal and will not know that the traveler will be watched by relevant agencies. 13

PAGE 25

14 2.11 Short Message Service Center The event notification can be sent to the subscribers of an event using emails and/or cell phone notifications based on the options the subscribers selected at the time of event subscription. The cell phone notification is routed through the Short Message Service Center (SMSC). During event notification, the event server looks up the cell phone numbers and the network of the subscribers, and then sends the message with SMTP to phone@messaging.cell-network.com. The SMSC routes this message to the users cell phones as an SMS message. The communication between the various components of our system deployed at different sites is through the Internet. In most cases, the services of these software components are invoked using the Web Service technology. 14

PAGE 26

CHAPTER 3 DETAILED DESIGN This chapter presents the detailed design of the tools for exporting and integrating the database schemas (Figure 3-1). Section 3.1 explains the design of the Export Schema Tool. This tool includes an interface to define new export schemas and an interface to modify a schema that was already created. Section 3.2 describes the Schema Integration Tool used to correlate all the exported schemas and to generate the global schema. Figure 3-1. Export schema and integrate exported schemas Dominican Republic Belize Internet (OAS/Belize/US/ Dominican Republic) Export local schema Export local schema HOST SITE Map exported schemas Generate global schema IT Personnel Enter local schema information Enter local schema information Immigration Agent Immigration Agent Save global schema Export Schema Service Save global schema Write Global Schema Service Write Global Schema Service 15

PAGE 27

16 The IT personnel of the participating countries will use the Export Schema interface to define the database entities and attributes stored in their local databases that they are willing to share. The ExportSchema Web Service, deployed at the host site will be invoked in order to save the exported schema at the host site. Once all the participating countries have exported their schemas of an application category to the host site, the exported schemas will be integrated using the Schema Integration Tool installed at the host site, to generate the global schema. The host site will invoke the WriteGlobalSchema Web Service at the local site of each participating country. This Web Service will send the generated global schema files, which includes the global, integrated schema and the data mapping tables to the local site. The global schema will be used to generate the Global Search Form. 3.1 Export Schema Tool The Export Schema Tool is used by the participating nations to specify their local database schema entities and attributes to be shared with other nations. It consists of the following interfaces: a form to select the display language so that the user can view the interfaces in his/her natural language, a form to select an application category for which the schema is to be exported, a form to add new data entities, a form to add attributes that are to be exported, and an interface to modify an existing schema. The steps followed by the user while exporting the schema are shown in Figure 3-2. 1. 2. 3. Authorized user logs in to the Export Schema Tool User selects the language for displaying the user interface in that language. The choice of languages is restricted to the languages used by the participating countries User enters the application category for which he/she wants to export the schema. For example, the user can enter a category name such as immigration, or agriculture

PAGE 28

17 4. 5. 6. 1. 2. 3. 4. 5. 6. 7. Next, the user can add new data entities, delete unwanted data entities, or skip this step. All the data entities, whose database attributes are to be exported should be added in this step Next the user gets to view the attributes, if any, that have already been added for exporting. The user can add more attributes by selecting the Add New Attributes (Figure 3-3) option or the user can delete an already added attribute, which is not to be exported Once the user is done with adding all the attributes to the form for exporting, he/she can select the Export Schema option to export the schema Given below is the sequence of steps executed by the user while adding new attributes for exporting (Figure 3-3) On the add attributes page, the user selects the data entity to which the attribute belongs User will enter the attribute name for the new attribute User selects the type of the attribute (String, Integer, Boolean, or Date) Next, the user will select the display type for the attribute (text box, radio button, or list box). This information is used later to generate the Global Search Form If the user wants to insert the new attribute before a particular attribute on the Export Schema page, he/she can enter that particular attributes name in the Insert Before Attribute text box If the display type of the new attribute is radio button or list box, user has to give the default values for this attribute, which will be displayed on the Global Search Form As a result, the new attribute can be appended at the end of the list of attributes that were already added, or it can be inserted before a particular attribute

PAGE 29

18 Select Language En g lish/S p anish Enter Category Add a Data Entity Enter New Data Entit y Name Display list of attributes to be exported Add New Attribute Export Schema Delete attribute N Y Login Figure 3-2. The export schema flow chart

PAGE 30

19 Be g in Select Data Entity Enter New Attribute Name Select Attribute Type (String/Integer/Boolean/Date) Select Display Type (Textbox/Radiobutton/ Listbox) Enter Insert Before Attribute Enter default values for radio button and list box separated by commas Enter Attribute Name Insert Append Back to Export Schema p a g e Be g in N Y Figure 3-3. The add attributes to export schema flow chart

PAGE 31

20 Table 3-1 and Table 3-2 show two example schemas that are exported from the Dominican Republic and Belize site, respectively. Each exported schema includes the local database attribute names, the database relation to which the attribute belongs, the attribute types, and the display types of the attributes. Table 3-3 shows the components of the integrated global schema, which includes the pairs of attributes that are mapped from the two sites and the internal names assigned to each of these pairs.

PAGE 32

21 Table 3-1. Dominican Republics sample exported schema Attribute Name Relation Name docviajenumero SALIDA Numerocedula SALIDA Apellidos SALIDA Nombres SALIDA Sexo SALIDA Fechallegada SALIDA Puertoembarque SALIDA Fechapartida SALIDA Partidanumerovuelo SALIDA Puertodesembarque SALIDA Fechanacimiento SALIDA Lugarnacimiento SALIDA Ciudadnacimiento SALIDA Paisnacimiento SALIDA Nacionalidad SALIDA Ocupacion SALIDA Estadocivil SALIDA Calle SALIDA No SALIDA Ciudadparaje SALIDA Provinciaestado SALIDA Pais SALIDA Numerovuelo SALIDA Motivoviaje SALIDA Comentariogeneral SALIDA id_pais PAIS nombre_pais PAIS Attribute Type: String, Display Type: Textbox

PAGE 33

22 Table 3-2. Belizes sample exported schema Attribute Name Relation Name Attribute Type Passportnum MAIN String Passportdate MAIN String Passportstate MAIN String Passportcountry MAIN String Lname MAIN String Fname MAIN String Middlei MAIN String Gender MAIN String Entrydate MAIN String Portofembcity MAIN String Portofembcountry MAIN String Departuredate MAIN String Portofdisembcity MAIN String Portofdisembcountry MAIN String Birthdate MAIN String Birthcountry MAIN String Nationality MAIN String Occupation MAIN String Paddrstreet MAIN String Paddrnumber MAIN String Paddrcity MAIN String Paddrstate MAIN String Paddrcountry MAIN String Paddrzip MAIN String Vehiclenumber MAIN String Baddrstreet MAIN String Baddrnumber MAIN String Baddrcity MAIN String Baddrstate MAIN String Intendedstaylength MAIN String Purposeoftrip MAIN String Visitnum MAIN Integer Comments MAIN String Passportnum TOUR String Visitedbefore TOUR String Lodging TOUR String Interests TOUR String Display Type: Textbox

PAGE 34

23 3.2 Schema Integration Tool to Generate Global Schema This module is installed at the host site. It is used to establish the semantic and language equivalence relationships between the exported data entities and attributes. In this process, pairs of data entities and attributes displayed in different natural languages will be mapped (correlated) to generate the global schema. This mapping is required to mediate the schematic and semantic heterogeneities that exist between the databases of the participating countries. During attribute mapping, one internal name is given to each set of mapped attributes and they together are added to the global schema at the host site. Internal attribute names are neutral representations of attribute names used in different databases. When the integrated global schema is saved, the global schema files and the data mapping files are also sent to the local sites of each of the participating countries. These files are used to generate the Global Search Form in the language used by the user. This module includes the following form interfaces: a form to add new application categories, a form to map the exported attributes defined by different countries, and a form to assign internal name to a pair of mapped attributes and to add default values for some attributes. The sequence of steps executed during the integration of the exported schema attributes is as follows (Figure 3-4). 1. 2. 3. 4. 5. An authorized user (IT personnel), who knows all the languages of the participating countries logs in to the system at the host site to map the schemas The user can view a list of the available application categories He/she can add more category names and descriptions, so that the participating countries can export the schemas for this new category also The user can select a category, to view the schemas that have already been exported for that category The user will select a correlated pair of attributes from the exported schemas (those attributes, which he/she wants to map). He/she has to provide an internal name to

PAGE 35

24 the pair of mapped attributes and then add it to the global schema. If an attribute is not present in one of the countries local database, then the user has to provide a name for that attribute in the countries natural language so that it can be displayed in the Global Search Form to be generated for the users of that country 6. The user will repeat the above steps to map all the attributes that are to be exported and finally save the global schema

PAGE 36

25 Show available categories Add new category Enter category name & description Select a category Show the schemas exported for selected category Map a pair of attributes from Belize and DR Add the attribute to global schema Map more attributes? N Y Y Save global schema N Figure 3-4. Map Exported Attributes

PAGE 37

26 Table 3-3. Attribute mappings in the global schema Attribute Name in Belize Attribute Name in DR Internal Attribute Name Passportnum docviajenumero passportno Passportdate fechadeemision dateofissue Passportstate lugar-de-emision-estado placeofissue-state Passportcountry lugar-de-emision-pais placeofissue-country Idno Numerocedula idno Lname Apellidos Lastname Fname Nombres firstname Middlei segundo-inicial mi Gender Sexo sex Entrydate Fechallegada dateofentry Portofembarkationcode Puertoembarque portofembarkationcode Portofembcity puertoembarque-ciudad portofembarkationcity Portofembcountry puertoembarque-pais portofembarkationcountry Departuredate Fechapartida dateofdeparture Portofdisembarkationcode puertodesembarque portofdisembarkationcode Portofdisembcity puertodesembarque-ciudad portofdisembarkationcity Portofdisembcountry puertodesembarque-ciudad portofdisembarkationcountry Birthdate Fechanacimiento dateofbirth Birthcountry paisnacimiento placeofbirth Nationality Nacionalidad nationality Occupation Ocupacion occupation Maritalstatus Estadocivil Maritalstatus Paddrstreet Calle permanentaddress-street Paddrnumber No permanentaddress-number Paddrcity Ciudadparaje permanentaddress-city Paddrstate Provinciaestado permanentaddress-state Paddrcountry Pais permanentaddress-country Vehiclenumber Numerovuelo airline-vehicle-vesselno Baddrstreet Direccion-destinada-calle intendedaddress-street Baddrnumber Direccion-destinada-no intendedaddress-number Baddrcity Direccion-destinada-ciudad intendedaddress-city Baddrstate Direccion-destinada-estado intendedaddress-state Purposeoftrip Motivoviaje purpose-of-trip Visitnum visite el nmero visitno Comments comentariogeneral comments Passportnum docviajenumero passportnumber Visitedbefore visitadoantes visitedbefore Lodging accomodation-destinado intended-accomodation Interests intereses-especiales special-interests

PAGE 38

CHAPTER 4 DISTRIBUTED QUERY PROCESSOR AND WATCH-LIST SCENARIO This chapter describes the architectural design and functionality of the Distributed Query Processor (Figure 4-1) and the Watch-list scenario. The components of the Distributed Query Processor are: the Global Query Processing component (GQP) described in Section 4.1 and the Local Query Processing component (LQP) explained in Section 4.2. Section 4.3 explains the watch-list module. 4.1 Global Query Processor (GQP) GQP makes use of the global schema files, country information, and user profile information to generate a Global Search Form in the natural language used by the user. The global schema files include form_info.txt, and mapCountryname.txt. The country information is stored in country_info1.txt file. The user profile information is stored in tomcat-users.xml file, and it is used for authentication and authorization of the logged-in user. We use Tomcats User Authentication facility to authenticate the users [4] [5]. 4.1.1 Global Schema Files These files are generated after mapping the exported schemas from different countries at the host site. As explained in Section 3.2, the global schema files are saved at the local site of each participating country by invoking the WriteGlobalSchema Web Service. The format and use of each of the global schema files is explained below. The form_info.txt file: This file stores information like the internal name for an attribute, the display type of the attribute, the number of default values associated with 27

PAGE 39

28 that attribute, and the country codes of all those countries, which contain this attribute in their local databases. This is one of the files used to generate the Global Search Form. Figure 4-1. Architecture of the Distributed Query Processor The mapCountryname.txt file: A separate mapCountryname.txt file is generated for each of the participating countries. For example, the file sent to the Belize site when the Generate Global Schema button is clicked by the user will be named mapBelize.txt. This file includes information like the internal attribute name, the corresponding name for

PAGE 40

29 the attribute in the countrys local database, the database relation to which the attribute belongs, the data type of the attribute, and the number of default values associated with the attribute. The actual default values will also be stored in the tags. If the attribute is not present in the local database of a country, then that field is replaced by the attribute name in the countrys local language and the database relation name will be set to none. This file is used for mapping the global (internal) attribute names to the countries local database attribute names, when the query is sent to the local site, and vice versa when the query results are generated and returned. This file together with the form_info.txt file is used to generate the Global Search Form that is displayed in the users natural language. 4.1.2 Country Information The file country_info1.txt contains the Web Service URL of all the participating nations along with the specific method name of the service, which needs to be invoked in order to access the Local Query Processing component. The query issued by the user is sent in XML format to the local site by accessing this Web Service of the LQP. 4.1.3 Tomcat Authentication and User Profile Information To set up tomcat user authentication, we did the following 1. Created a conf/users/tomcat-users.xml that has entries as shown below 2. Inserted the following in the webapps/QP/WEB-INF/web.xml file Similar web.xml should be included for each of the applications deployed under tomcat. Query Form

PAGE 41

30 /* GET POST
Belize
FORM /login.jsp /error.jsp Belize The authorized roles and users are added in tomcat-users.xml file. The forms, which require login user authentication, are included as security constraints in the web.xml file for the application. The various user roles and their access privileges used by our system are shown in Table 4-1 below. For example, the role Super has access to all the database attributes, whereas role Police has access to only arrest information in the database. Table 4-1. Role list based on access privileges Role Privilege to access following information Super ALL Police Arrest information Immigration Immigration information User1 Arrival-related immigration information User2 Departure-related immigration information Tourism Tourism information

PAGE 42

31 The participating countries can collaborate and decide on a global roles list and corresponding access privileges for the roles on the local database entities and attributes of those countries. Figure 4-2. Global search form at the Belize site 4.1.4 Global Search Form The Global Search Form (Figure 4-2) is generated automatically based on the integrated global schema, which is a union of the shared entities and attributes from all the participating countries. The Global Search Form is a Java Server Page (JSP) and is displayed in the natural language of the logged-in user. The user profile information, which includes the nationality of the user, is used to decide the display language for this form. Users can issue queries to the local databases of the participating nations using this form. Our system displays the global form in English for Belize users and in Spanish for

PAGE 43

32 users in the Dominican Republic. The Global Search Form includes the following form fields. The list of all the participating countries to which users can issue queries and options to select them The list of all the attributes, which are included in the global schema and the data entities to which they belong. User can select any of these attributes for displaying in the query result User has the option to issue queries containing aggregate function count that displays the sum total of all the records in the query result. The other aggregate functions that the query can include are max, min, avg, and sum for integer type attributes, and only max and min functions for the attribute type, date He/she can also specify the condition clauses (search criteria) for the query The generated query is in a disjunctive normal form and can contain up to three ORed expressions entered into the three columns of Figure 4-2. Each of the OR expressions are a conjunction of the condition parameters entered in each column in the query form. The sequence of steps executed by the user when he invokes the Global Search Form is 1. 2. 3. 4. The user has to login to the system, and then select the countries he/she wishes to query Next he/she has to select the type of the query, e.g., simple query that displays the records or queries containing aggregate functions. He/she also has to select the attributes to be displayed in the query result The user can enter the values for the condition clause of the query If the user selects one or more aggregate type of queries, he/she is not allowed to select the other attributes on the form that are not part of the aggregate function, else it results in a SQL Exception at the database level When the user submits the Global Search Form, the following actions take place. All the roles associated with the logged-in user and the countries whose databases the user wants to query are identified The type of the query is also identified for example, simple query that displays the actual records or query with an aggregate function that displays the result of the functions like sum, max, min, avg, and count on certain attributes in the database

PAGE 44

33 An XML query document is created for each country that is queried. It is a sub-query that includes only those attributes selected by the user and are present in the country's local database. Thus, the query issued by the user is converted to an XML document. For example, belizequery_xmlfile1.xml (Figure 5-7) represents the sub-query sent to the Belize site. It contains the user's role information, the country name to which the query is issued, the query result attributes selected by the user and the condition clause part of the query. The attribute names in the XML query are the internal attribute names from the global schema, which are mapped to the local attribute names before the query is actually processed at the local site The sub-queries are sent to the local sites by invoking a Web Service method of those countries whose databases are being queried. Thus the Global Query Processor acts as a Web Service client of the Local Query Processor, which is deployed as a Web Service at the local sites. The Web Service URL and the method name for each participating country are stored in the country_info1.txt file (Section 4.1.2) After a sub-query is processed at a local site, the query result is returned to the Global Search Form again in the form of an XML string. The XML query result is stored at the query issuing site as a pre-defined XML document called IndividualResult.xml (Figure 5-8). It consists of the name of the country that has sent the query result and the actual query result, which includes the attributes that were selected by the user and their values. At the local site, the local result attributes are mapped to the internal attribute names before sending the result to the query-issuing site. At the issuers site, the XML result document is traversed using the DOM parser and the result is extracted from it. The attributes of the returned result are again mapped to the local attribute names before being displayed to the user. This mapping uses the data mapping files If the query issued by the user contains an aggregate function, then the query results from the two countries have to be combined before displaying the results to the user. For example, if user issues the query Retrieve the last date when a person of US nationality entered the country. This query will be processed independently at the local sites of the two countries, and the max aggregate function will be applied on the date of entry attribute of the two local databases. The two sites will send their local query results to the query-issuing site where the max function is again applied on the two returned results to get the global maximum value, which is then displayed to the user 4.2 Local Query Processor (LQP) The Local Query Processing component consists of a Web Service interface for the LQP and a wrapper, which interacts with the Event Server, the ETR Server, the Translation System, and the local DBMS of the country. The LQP component receives

PAGE 45

34 the XML query document sent by the GQP of the query-issuing site. It translates the received query into an SQL query for processing by the local DBMS. 4.2.1 Web Service Interface for LQP The LQP component is deployed as a Web Service by each of the participating sites. The Web Service method accepts the XML query document sent by the Global Query Processing component as a string argument and returns the query results again as an XML format string to the query-issuing site. 4.2.2 The Wrapper Associated with the LQP The wrapper performs the following functions. It maps the internal attribute names present in the sub-query issued by the GQP to the local database attribute names of the site to which this LQP component belongs. The mapping uses the mapCountryname.txt file The extractor module of the wrapper processes the XML query document using the Document Object Model (DOM) parser to extract information such as the role information of the person who has issued the global query, the attributes being queried along with the attributes included in the condition clause of the sub-query. It also extracts the table names (relation names) to which all the attributes that are present in the sub-query belong Next the access controller module of the wrapper checks if the user who issues the query has the access right to all the attributes in the query. It connects to the local Event Server of the site and posts the qaccess event. The qaccess event triggers a rule to check the access right of the user on the query attributes The translator module deals with the table lookup translation and language translation The translation of internal attribute names to local attribute names and vice versa, and the translation of attribute values use the table lookup method. The mapping tables are implemented as hash tables There are certain attribute values, which cannot be resolved using the lookup method, and for those we need to invoke the CMUs language translation system. For example, the officer at the port-of-entry station can enter comments about the travelers entering the country, in his/her own language. These comments get stored in the local database of that country. If the user who issues the query is interested in searching those records, which contain

PAGE 46

35 specific words in the comments field, then the issuer will enter the search criteria in his/her own natural language. But when the query is actually executed on the local database by the LQP component, that search criteria needs to be translated into the language of the local site before the query is processed. For example, the immigration officer may want to see a list of all the people who appeared nervous when they entered the country. So he/she will enter the word 'nervous' in his/her native language into the comment field. Once this query reaches the local site, it needs to be translated into the language used by the local site before the query is actually processed. Also after getting the query results, the values for the comments attribute need to be translated back to the natural language of the query issuer before being displayed to the user. For these translations, the language translation system developed at the Carnegie Mellon University is invoked The query processor module is responsible for generating a query in SQL format using the attributes extracted from the XML query string. The query processor then connects to the local database and issues the SQL query to the local database system. In the process of generating the SQL query, the translator is used to convert the internal query attribute names to local attribute names of the local database, before the query is sent to the local DBMS, and to convert the local attribute names of the returned query result to the corresponding internal (or neutral) attribute names. The machine translator may also be invoked to translate some query values. The query result is then sent to the wrapper, which converts the result into an XML format and passes it back to the Web Service method of the LQP. The Web Service will send the result to the Web Service client (i.e., the GQP of the issuing site) 4.3 Watch-List Scenario This module will be deployed at the border stations of the participating nations. The Watch-list scenario depicts three goals. Allows the supervisor to mark some of the agents posted at the border stations as under suspicion, if they are suspected of collaborating with some people in a watch-list by admitting them into the country The system checks if the traveler entering the country is in the watch-list, and displays an alert message to the agent on duty, if he/she is not under suspicion The Watch-list scenario is also one of the examples for the Event-Trigger-Rule system, and is used to send event notifications to the subscribers of the event The main components of this module are the authorized agents database, the watch-list database, the local database, which stores the travelers arrival/departure information, and the Event-Trigger-Rule system. The event depicted in the Watch-list scenario is the PEntry event. This event gets posted when the agent at the border station

PAGE 47

36 fills the arrival information in the Arrival form, for a traveler who wants to enter the country. The event triggers a rule called the WatchListCheck Rule. This rule checks if the traveler is in the watch-list by consulting the watch-list database. Supervisor Agent logs in to Arrival Form database Traveler in watch list? Show alert Insert record into database Y 1 2 3 Fill arrival information of the traveler. 4a Authorized Agents Watchlist database ETR sends notification Is the agent under suspicion? Allow traveler to enter? 4b 5 N Y 6b 6a 7a 7b Y N N reject Figure 4-3. The Watch-List scenario flow chart

PAGE 48

37 This module consists of the following form interfaces: a form to mark some of the border agents as under suspicion and a form to fill the arrival information for a traveler. The sequence of steps executed during the Watch-list scenario is as follows (Figure 4-3). 1. 2. 3. 5. The supervisor will log in and create and edit an authorized agents list. Agents who are under suspicion of being corrupted agents are marked Agent at one of the border stations logs into the system and fills the arrival form for a traveler who enters the country The system checks if the traveler is in the watch-list by consulting the watch-list database 4a. If the traveler is in the watch-list, then ETR sends event notification to all the subscribers of this event. Event notification is sent via email and/or cell phone 4b. If not, then the system will insert travelers record into the database Check if the agent is under suspicion by consulting the database of authorized agents 6a. If yes, no alert message will be posted. The agent will allow the traveler to enter the country and the travelers arrival information will be inserted into the database 6b. If not, the alert message, which says that the traveler is in the watch-list, will be displayed to the agent 7a. The agent who gets the alert message can either allow the traveler to enter the country and the travelers data is inserted into the database 7b. Or, the agent rejects the traveler from entering the country

PAGE 49

CHAPTER 5 IMPLEMENTATION DETAILS In this chapter, we describe the implementation details of the main components in our system. Section 5.1 describes the Export Schema Tool, Section 5.2 describes the Schema Integration Tool, Section 5.3 describes the Distributed Query Processor, and Section 5.4 gives the implementation details for the Watch-list scenario. 5.1 Export Schema Tool The files, which are used in the implementation of the Export Schema functionality, are described below. The language.jsp page: This JSP provides an interface, where user can select the language for displaying all the pages in the Export Schema module. The languages currently supported by our system are Spanish and English since these are the languages used by the participating countries of the Dominican Republic and Belize respectively, in the prototype system. Once the user selects the language of his choice on this page, the corresponding language.txt file will be used for displaying the user interfaces in the selected language. For example, if user selects Spanish as the language, the system will use the Spanish.txt file to display the forms in Spanish. In short, our system can easily support a new language interface by including the language.txt file for the new language. For example, to provide the support for French language, we need to add a new file to the system named French.txt with the required translations. The select_category.jsp page: This interface allows the user to select the application category for which he/she wants to export the schema. 38

PAGE 50

39 The relations.jsp page: Based on the category name selected by the user on the select_category page, this interface will display the data entities that are already available for this category. The data entities added, for a particular category, are appended to the relations.txt file under the category folder in the DQP directory of the local site. If there are no data entities that exist for the selected category, then a new relations.txt file will be created, and then the data entity name will be included in that file. As a result, this form interface allows user to add new data entities. The export_schema.jsp page: This JSP (Figure 5-2) displays all the attributes that have been previously added for exporting under the selected category by reading the exported_attributes.xml file of the category. This XML file is read by traversing it using the DOM parser. If there are no attributes previously added for exporting, then a new exported_attributes.xml file is created in the same directory where the relations.txt file is present. The exported_attributes.xml file will be updated every time a new attribute is added or deleted. A sample exported_attributes.xml file is shown in Figure 5-1. Belize MAIN passportnum MAIN string textbox Figure 5-1. Format of the exported_attributes.xml file In Figure 5-1, the country name in the tag indicates that this file is exported from a Belize site. MAIN is the data entity name to which the attributes belong. The attributes belonging to different data entities are stored separately in the XML file.

PAGE 51

40 The tag holds all the information related to the attribute that is to be exported. As shown in the figure, the attribute name is passportnum. It belongs to the data entity (relation) MAIN, the data type of the attribute is string, and the display type is textbox. Figure 5-2. Export schema page The add_attribute.jsp page: This interface is used by the user to add new attributes to the export schema. The newly added attribute is written to the file exported_attributes.xml. After the user has added all the attributes that he/she wants to export, he/she submits the export_schema.jsp page, and then the ExpSchema.java file invokes sendSchema method of the ExportSchema Web Service that will store the exported local schema at the host site. The exported schema is saved as an XML file under the selected category folder at the host site. Here the file ExpSchema.java acts as a

PAGE 52

41 client for the ExportSchema Web Service. Whenever any site exports its local schema for this category, it will be stored as a new XML file under the category folder at the host site. Figure 5-3. Add attribute to export schema page 5.2 Integrate the Local Schemas to Generate the Global Schema The files that are used to implement the schema mapping and integration of the exported schemas are described below. The global_categories.jsp page: An authorized user can select the category for which he/she wants to generate the global schema after logging-in to the global_categories,jsp page. The user can also add new categories to the list of existing categories so that the local sites can also export their schemas for these newly added categories. All the categories and the category descriptions are stored in the categories.txt

PAGE 53

42 file. When the user selects a category, he/she gets to see the schemas exported by all the local sites under that category. The published_schemas.jsp page: This page displays all the schemas currently exported for the selected category. The exported schemas of each site (country) are displayed as columns of attributes. The metadata like the data entity of the attribute, its data type, display type, and the default values if any associated with the attribute are shown when the user clicks on a particular attribute. All this metadata information is extracted from the schema files stored under the OAS folder. Figure 5-4. Published schemas page The add_global_attributes.jsp page: This JSP page is invoked when the user selects the related pair of attributes from each local site and clicks on the 'Add to Global Schema' button on the published_schemas.jsp page. The user will be shown the attributes

PAGE 54

43 that he/she wants to map in order to include the attribute in the global schema. For example, if the user has selected passportnum from Belizes exported schema and docviajenumero from the Dominican Republics exported schema, then he/she is shown the country name and the corresponding attribute name from the countrys exported schema. If an attribute that is to be added to the global schema is not present in one of the countries exported schemas, then user is asked to enter the attribute name in that countries' local language. The user is also asked to enter an internal name for the mapped attribute. If there are any default values for an attribute in one of the countries' exported schemas, then the user has to enter the names for those values in the other country's local language. Figure 5-5. Mapping page for exported attributes

PAGE 55

44 When the user adds an attribute to the global schema, the global schema files are created at the host site and they get updated every time a new attribute is added. The generated global schema files are form_info.txt, parserARRIVAL-DEPARTURE.met, parserARRIVAL-DEPARTUREsp.met and mapCountryname.txt. A separate mapCountryname.txt file is created for each of the participating countries. The dummy.jsp page: Once the user has added all the attributes from the exported schemas to the global schema for the selected category, he can save the schema. This JSP contains the code for generating and storing the global schema files at the host site and sending them to the local sites, where the files are stored for use by the Global Search Form. The files are sent to the local site by invoking the GlobalSchema Web Service at the local site. The WriteGlobalSchema.java file present at the host site acts as a Web Service client of the GlobalSchema Web service. The writeSchema method of this Web Service will write the global schema files at the local sites. 5.3 Distributed Query Processor 5.3.1 Global Query Processing Component (GQPC) The CreateGlobalForm.jsp/ CreateGlobalFormsp.jsp page: This JSP will generate the Global Search Form using the global schema files, mapCountryname.txt and form_jnfo.txt (Section 4.1.1). The page is displayed to the user in English or Spanish language based on the user profile information stored in the tomcat-users.xml file. Figure 4-2 shows a sample Global Search Form at the Belize site. This form is used to issue the queries in English language. The query.jsp page: This file is responsible for query generation based on the attributes selected by the user on the Global Search Form and the display of query results. The query is generated in XML format (Figure 5-6) and it is created using the internal

PAGE 56

45 names of the attributes and attribute values. A separate sub-query is generated for each of the local sites that are queried by the user. The sub-query includes only those attributes that are present in the local database of the country to which the sub-query is being sent. The users ROLE information and the country name being queried are also included in the XML query file. This JSP acts as an AxisClient for the Web Service present at the Local Query Processing component of the local site (LQP). The Web Service information is stored in the country_info1.txt (Section 4.1.2) file. The JSP parses the Individual-Result.xml (Figure 5-7) file of each country to which a sub-query was issued. The internal attribute names in the sub-query result are mapped to the local attribute names on the Global Search Form before displaying the result to the user. The results retrieved from the individual sites for the sub-queries involving aggregate functions such as count, sum, max, min, and average will be combined on this form. ]> roleA_super Belize avg(visitno) purpose-of-trip = BUSINESS Figure 5-6. Sample XML query

PAGE 57

46 BELIZE avg(visitno) 3.2500 Figure 5-7. Sample XML result Figure 5-8. Query results displayed at the Belize site 5.3.2 Local Query Processing Component (LQPC) The LQPC is deployed as a Web Service at each of the participating countries. This Web Service will be invoked by the query.jsp file, which acts as the Web Service client.

PAGE 58

47 The classes that comprise the LQP components at the Belize site are described below. Similar files are present at the local site of each participating country. The belizeserver.java file: The belizeinterface method in this file is invoked by the Web Service client of the LQPC. The method in turn invokes the belizespecxml file by passing the XML query string to it. The belizespecxml.java file: The checkAccess method in this file checks the access control of the user to each attribute in the XML query string. The buildSQL method will generate the SQL query from the XML query string, and the createXML method will execute the SQL query on the local database. The createXML method also converts the SQL query results to XML format before sending them back to the GQP (Axisclient). The translation system explained in Section 4.2.2 is invoked to translate the values, if any, in the comments field before issuing the query to the database. The value in the comments field will be translated only if it is not in the local language of the user, which is decided by the role of the logged-in user. The translator is also invoked on the values retrieved by the comments attribute in the query result subject to the constraint that the result is not in the local language of the user. The belizemapattr.java file: This file is used to generate the mappings for the attribute values in the database. The map tables are implemented as hash tables. These mappings will be used while building the SQL query from the XML query string and also while converting the result into the XML format. 5.4 Watch-List Scenario This scenario depicts the events that occur when a person arrives in a country and the agent at the border station fills a form to record the persons arrival information. It is

PAGE 59

48 also an example, which describes the Event registration, subscription, and notification capability of the ETR Server. The files used in the implementation of this scenario are explained below. The AuthorizePpl.jsp page: This JSP (Figure 5-9) is used to create a list of authorized agents and to mark some of these agents as under suspicion. The user of this system is a supervisor, and the list of the agents not under suspicion is stored in the AuthorizedPpl.txt file. Figure 5-9. Create authorized agents list page The ArrivalDR.jsp page: An agent at the border station will fill this form (Figure 5-10) when a person enters the country. When this form is submitted, the ArrivalServlet is invoked and the port-of-entry (PEntry) event gets posted. The event will trigger the WatchListCheckRule to check if the person (traveler) entering the country is

PAGE 60

49 in the watch-list. This checking is done by comparing the travelers last name, first name, and nationality with the values stored in the watch-list. If the traveler is in the watch-list and the agent is not under suspicion, then he/she is shown the alert message, which says Traveler is in the watch list. If the agent decides to allow the traveler to enter the country, then the travelers record is inserted into the database. If the agent is marked as under suspicion, he/she will not be shown the alert message by the system and the traveler will be directly allowed to enter the country, and his/her record will be inserted into the database. Figure 5-10. Arrival form at the port of entry in a Dominican Republic border station 5.5 Translation System The translation by table lookup was explained in Section 4.2.2. This type of translation is used to convert the internal query attribute names into local database

PAGE 61

50 attribute names so that it can be executed on the local database. We also use the language translation system for natural language translations. The translator.java file: This file is used to invoke the machine translation system developed at the Carnegie Mellon University (CMU) and acts as the Web Service client of the service interface provided by CMU. The translate method of the Web Service is invoked for getting the translated result. This method takes two parameters, the actual string to be translated and the language into which the string should be translated. For example, translate (nervous, sp) means that the word nervous should be translated into the Spanish language. The Web Service sends the translated result back to the client. 5.6 Conversational Interface System The conversational interface developed at the University of Colorado uses our Distributed Query Processor for issuing queries to the databases of the participating countries and retrieving the query results. The conversational interface translates the natural language query into an XML query string similar to the one generated by the Global Search Form. This interface then invokes the GlobalQuery Web Service deployed at the host site. The Web Service will invoke the Global Query Processing component of all the sites, which are being queried by the conversational interface. Once the query reaches the GQPC, it is processed in the same way as the query generated by the Global Search Form. The XML query results are sent back by the GlobalQuery Web Service to the Web Service client (i.e., the conversational interface system).

PAGE 62

CHAPTER 6 TECHNOLOGIES USED We have installed our system on the Windows NT platform and it is implemented using JDK 1.4.2_04. The Web server used is Tomcat 4.1.18 and Apache Axis 1.0 toolkit is used to define, deploy, and invoke Web Services. The database management system used as the local database management system is MySQL. In this chapter, we describe the technologies used to implement the following tools and functionalities of the prototype system: tool for defining export schemas, tool for integrating exported schemas, distributed query processing system for accessing data from distributed, heterogeneous databases, and event-trigger-rule processing system for implementing a Watch-list scenario. Section 6.1 describes the ETR technology and its various components. Section 6.2 describes Java related technologies, and Section 6.3 discusses the XML related technologies. Section 6.4 and Section 6.5 explain the Web Services infrastructure and SOAP, respectively. We explain how Apache Axis toolkit is used for deploying the Web Services in Section 6.6. Our prototype system uses the MySQL database management system, which is described in Section 6.7. 6.1 The Events, Triggers, and Rules (ETR) Technology The ETR technology is a part of the Knowledge Web Server [2]. The ETRs event-trigger-rule service is used in the implementation of the Watch-list scenario (Section 4.3). The Knowledge Web Server extends the capability of the current Web servers. Each Knowledge Web Server has a replica of an Event Manager, an ETR Server, and a Knowledge Profile Manager, which are the additional components installed on each Web 51

PAGE 63

52 server. Replicas of the Event Manager exchange events and transfer data associated with the events (i.e., event data) between them. 6.1.1 Events, Triggers, and Rules Any item of interest can be modeled as an event. For instance, entering a travelers information into the arrival form at a border station by an immigration agent can be considered as an event. A rule consists of a condition clause, an action clause, and optionally, an alternative action clause. When an event is posted, if the condition clause associated with the rule evaluates to True, the action clause is executed. Otherwise, some alternative action is performed. Triggers are used to associate events with rules. A trigger specifies that, upon the occurrence of any one of a number of events, an optional expression of occurred events (i.e., an event history) should be evaluated. If the event history is evaluated to True or if the optional expression is not given, a single rule or a structure of rules should be processed. The trigger specification maps event attributes to rule parameters so that run-time event data can be passed to a rule(s) for its (their) evaluation. 6.1.2 Event Manager Legitimate clients can subscribe to published events. They can also specify event filters, which contain some data conditions associated with events. If the data conditions match with the data associated with the occurrence of an event, subscribers want to be notified. The Event Manager is responsible for sending and receiving events and for performing event filtering before sending out the event data, to those subscribers whose filtering conditions are satisfied. When the Event Manager receives an event from a remote web server, it passes the event and event data to the local ETR Server to initiate the processing of triggers and rules.

PAGE 64

53 6.1.3 The ETR Server The ETR Server receives events and event data from the local Event Manager, and performs trigger and rule processing. On receiving an event, the ETR Server identifies the trigger related to the event, processes the event history, and executes the rule(s). 6.1.4 Knowledge Profile Manager (KPM) Each user of the transnational information system has a knowledge profile that is maintained by the Knowledge Profile Manager [6]. A knowledge profile includes the events that the user has subscribed to, the event filters associated with the subscribed events, and the triggers and rules that have been defined on the subscribed events. A Meta-data Manager within the KPM provides persistence for storing the user knowledge profiles. 6.1.5 Persistent Object Manager (POM) POM [7] consists of two main components. Object-Relational mapping engine XML-Relational mapping engine The Object-Relational mapping engine provides a persistent storage facility and a high level interface in the form of APIs for programs to store, retrieve, update, and delete objects without having to know the internal data structures of the objects. The XML-Relational mapping engine provides the persistence capability and a filtering mechanism to the Event Server. POM is implemented on top of an Object-Relational database system called Cloudscape.

PAGE 65

54 6.2 The Java Technologies 6.2.1 Java Servlet Technology Servlets [8] are the Java platform technology of choice for extending and enhancing Web servers. Building a Web page on the fly is useful for a number of reasons. The Web page is based on data submitted by the user The data changes frequently The Web page uses information from corporate databases or other such sources Servlets provide a component-based, platform-independent method for building Web-based applications, without the performance limitations of CGI programs. Unlike proprietary server extension mechanisms (such as the Netscape Server API or Apache modules), servlets are server and platform-independent. Servlets have access to the entire family of Java APIs, including the JDBC API to access enterprise databases. They can also access a library of HTTP-specific calls and receive all the benefits of the Java language, including portability, performance, reusability, and crash protection. 6.2.2 Java Server Pages (JSP) Technology JSP technology [9] enables Web developers and designers to rapidly develop and easily maintain, information-rich, dynamic Web pages that leverage existing business systems. As part of the Java technology family, JSP technology enables rapid development of Web-based applications that are platform independent. It separates the user interface from content generation, enabling designers to change the overall page layout without altering the underlying dynamic content. JSP is an extension of the servlet technology created to support authoring of HTML and XML (Section 6.3.1) pages. It uses XML-like tags that encapsulate the logic that generates the content for the page. The application logic can reside in server-based

PAGE 66

55 resources (such as JavaBeans component architecture) that the page accesses with these tags. Any and all formatting (HTML or XML) tags are passed directly back to the response page. By separating the page logic from its design and display, and supporting a reusable component-based design, JSP technology makes it faster and easier than ever to build Web-based applications. 6.2.3 Tomcat Tomcat 4 [10] implements the Servlet 6.3 and Java Server Pages 1.2 specifications from Java Software, and includes many additional features that make it a useful platform for developing and deploying Web applications and Web Services. 6.3 The XML-Related Technologies 6.3.1 Extensible Markup Language (XML) XML [11] is a simple, very flexible text format derived from SGML (ISO 8879). Originally designed to meet the challenges of large-scale electronic publishing, XML is also playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere. XML stands for EXtensible Markup Language XML was designed to describe data XML tags are not predefined. One must define his/her own tags XML uses Document Type Definition (DTD) or XML Schema to describe the data XML can be used to exchange data between incompatible systems XML can also be used to store data in files or in databases 6.3.2 Xerces: XML Parsers in Java Xerces [12] provides world-class XML parsing and generation. It offers fully validating parsers for Java, implementing the W3C XML and DOM (Level 1 and 2) standards, as well as the de facto SAX (version 2) standard. The parsers are highly modular and configurable. Initial support for XML Schema is also provided by Xerces.

PAGE 67

56 6.4 Web Services The World Wide Web is increasingly used for application-to-application communication. The programmatic interfaces made available are referred to as Web Services [13]. Web Services provide a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks. A Web Service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically, WSDL). Other systems interact with the Web Service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. Thus, Web Services are Web-based enterprise applications that use open, XML-based standards, and transport protocols to exchange data with calling clients. 6.5 Simple Object Access Protocol (SOAP) SOAP [14] provides a simple and lightweight mechanism for exchanging structured and typed information between peers in a decentralized, distributed environment using XML. SOAP does not itself define any application semantics such as a programming model or implementation specific semantics; rather it defines a simple mechanism for expressing application semantics by providing a modular packaging model and encoding mechanisms for encoding data within modules. This allows SOAP to be used in a large variety of systems ranging from messaging systems to RPC. SOAP can potentially be used in combination with a variety of other protocols. SOAP consists of three parts. The SOAP envelope construct defines an overall framework for expressing what is in a message; who should deal with it, and whether it is optional or mandatory

PAGE 68

57 The SOAP encoding rules define a serialization mechanism that can be used to exchange instances of application-defined data types The SOAP RPC representation defines a convention that can be used to represent remote procedure calls and responses 6.6 Apache Axis Axis [15] is essentially a SOAP engine: a framework for constructing SOAP processors such as clients, servers, gateways. The current version of Axis is written in Java and a C++ implementation of the client side of Axis is also being developed. Axis is not just a SOAP engine, it also includes A simple stand-alone server A server which plugs into servlet engines such as Tomcat Extensive support for the Web Service Description Language (WSDL) Emitter tooling that generates Java classes from WSDL Some sample programs, and A tool for monitoring TCP/IP packets Axis is the third generation of Apache SOAP (which began at IBM as "SOAP4J"). In late 2000, the committers of Apache SOAP v2 began discussing how to make the engine much more flexible, configurable, and able to handle both SOAP and the upcoming XML Protocol specification from the W3C. 6.7 The MySQL Database MySQL [16] has become the most popular open source database and the fastest growing database in the industry. This is based on its dedication to providing a less complicated solution suitable for widespread application deployment. MySQL offers several key advantages. Reliability and performance: MySQL AB provides early versions of all its database server software to the community to allow for several months of "battle testing" by the open source community before it deems them ready for production use

PAGE 69

58 Ease of use and deployment: MySQL's architecture makes it extremely fast and easy to customize. Its unique multi-storage engine architecture gives corporate customers the flexibility they need with a database management system unmatched in speed, compactness, stability, and ease of deployment Freedom from platform lock-in: By providing ready access to source code, MySQL's approach ensures freedom, thereby preventing lock-in to a single company or platform Cross-platform support: MySQL is available on more than twenty different platforms including major Linux distributions, Mac OS X, UNIX, and Microsoft Windows

PAGE 70

CHAPTER 7 PERFORMANCE EVALUATION In this chapter we analyze the performance of our system. Section 7.1 gives an evaluation of the queries processed by the Distributed Query Processor, Section 7.2 presents the system performance during schema exportation and integration, and Section 7.3 describes the performance of the rule-processing and event notification in the Watch-List scenario. 7.1 Query Performance 7.1.1 Simple Queries Here we give the time required to fetch the result of each of the sample queries from the local databases of the participating sites using our DQP system. The relations in the local database of Belize contain sixty records and those in the local database of the Dominican Republic contain seventy records. 1. 2. Fetch the passport numbers and names of all the females who arrived in the country after Jan 1, 2003. Number of sites to be queried: (2) This query fetches results from both Belize and Dominican Republic Number of where clause conditions: (2) gender = female and entry-date = -01-01 Execution time: 3 seconds Fetch the passport numbers, names, nationality and purpose of trips of all the people whose nationality was USA or Belize and who had come for business. Number of sites to be queried: (2) This query fetches results from both Belize and the Dominican Republic and is an example of a query in disjunctive normal form Number of where clause conditions: (3) nationality = USA and purpose of trip = business or nationality = Belize and purpose of trip = business 59

PAGE 71

60 Execution time: 3 seconds 3. Get the passport number, name, date of entry, port of embarkation city and port of disembarkation city of all the people who entered the country after Jan 1, 2003 and whose port of embarkation city is Boston and port of disembarkation city is Belize City. Number of sites to be queried: (1) This query fetches results only from Belize database but it can be issued from Belize or Dominican Republic site Number of where clause conditions: (3) date of entry = -01-01, port of embarkation city = Boston and port of disembarkation city = Belize City Execution time: 2 seconds 7.1.2 Aggregate and Join Queries This section describes the times taken to process queries with aggregate functions and join queries. 1. Give the most recent date when a person of US nationality arrived in the country on business. Number of sites to be queried: (2) This aggregate query fetches max (date of entry) from the local databases of Belize and Dominican Republic and then combines the results before displaying them to the user Number of where clause conditions: (2) nationality = USA and purpose of trip = business Execution time: 1 second 2. Give the passport numbers and names of all the people who were staying in a guesthouse. Number of sites to be queried: (1) This join query is issued only to the Belize database and it does a join of two database tables MAIN and TOUR Number of where clause conditions: (2) lodging = guesthouse and tour.passportnum = main.passportnum Execution time: 2 seconds

PAGE 72

61 7.1.3 Queries Invoking the Translator 1. Give the passport numbers and names of all the males who appeared nervous. Number of sites to be queried: (2) This query is issued to the Belize and Dominican Republic databases from the Belize site. Here CMUs translator module is invoked to translate nervous to Spanish language before processing the query at the Dominican Republic site and again to translate the results retrieved from the Dominican database into English before being displayed to the user. Number of where clause conditions: (2) comments = nervous and gender = male Execution time: 4 seconds 7.2 Performance of Export Schema and Schema Integration Tools 7.2.1 Export Schema Tool The system takes approximately one second to export a schema from a local site. The time taken involves the time to invoke the Web Service at the host site, where the schema will be exported and stored. 7.2.2. Schema Integration Tool The tool takes approximately two seconds to integrate the exported schemas in order to generate the global schema. This includes the time to invoke the Web Service at each of the local sites and to save the global schema files at the local sites. 7.3 Performance of Rule Processing and Event Notification The Watch-List scenario takes about 2 to 3 seconds to post the arrival event, trigger the WatchListCheck rule to find if the traveler entering the country exists in the watch-list, to check if the agent on duty is under suspicion, and then to show the alert message to the agent if traveler is in watch-list and agent is not under suspicion. Although, this scenario also involves sending the email and cell phone notifications to the subscribers of this event, the specified time does not include the time for event notification because it will depend on the number of event subscribers.

PAGE 73

CHAPTER 8 CONCLUSIONS AND FUTURE WORK This chapter summarizes the contents of this thesis, its contributions and discusses the scope of future work. Through the various chapters in this thesis, we have established and confirmed the need for a transnational information system. The developed prototype system is the product of integrating a number of component systems: the Export Schema Tool, the Schema Integration Tool, the Distributed Query Processor system, the Language Translation system, the Conversational Interface system, and the Event-Trigger-Rule Server. With these system components in place, we have provided the means for integrating and sharing information, querying the heterogeneous databases using a form-based interface or a conversational interface, applying translations where necessary, and enforcing rules and regulations. The heterogeneous system components are made interoperable by using the Web Service technology. The main contribution of this thesis is the design and implementation of the tool for exporting the schemas from any of the participating countries, the tool for integrating these exported schemas to generate the global schema, the module to create the authorized agents list, the enhanced Distributed Query Processor which can accommodate schema changes made to the local databases, and handle queries that contain aggregate functions and join operations over database tables. The export schema component allows the countries to export their local database entities and attributes, and also to modify the exported schemas whenever there is a change to the local database schema. The modified exported schema can again be integrated with the schemas 62

PAGE 74

63 exported by other countries to generate the global schema. The Distributed Query Processor is able to incorporate the new global schema without making any code changes. Our prototype system is built for immigration and remote border control applications. However, it is designed and implemented in a general way that it can be used for other application domains such as agriculture inspection and protection, disease control, and can be used by a larger number of participating countries. There are some interesting features, which can be added, and some issues that can be further investigated to extend the functionality of the transnational digital government system. The Distributed Query Processor presently handles the join operation over relations (data entities) belonging to a single site. It can be enhanced to handle the join operation over data entities stored in multiple sites. Secondly, event notification is presently done by uni-casting; i.e., the subscriber information for an event is stored at the event publishers knowledge web server. When an event occurs, the notification is sent to each subscriber one-at-a-time, which can be very time consuming. A more efficient approach is to distribute the subscribers information to the knowledge web servers of different countries or agencies to which the subscribers belong. When an event occurs, the Event Server at the event-posting site can use multi-casting to send notifications to the Event Servers of all the event subscriber sites. These Event Servers can then send notifications to their local subscribers in parallel. We need to identify other transnational digital government problems that can be solved using the information technologies developed by the various research groups. The system should be expanded to cover multiple countries and languages, and means have to be established for field-testing and evaluation of the final system.

PAGE 75

LIST OF REFERENCES 1. Su, S., Fortes, J., Kasad, T.R., Patil, M., Matsunaga, A., Tsugawa, M., Cavalli-Sforza, V., Carbonell, J., Jansen, P., Ward, W., Cole, R., Towsley, D., Chen, W., Anton, A.I., He, Q., McSweeney, C., deBrens, L., Ventura, J., Taveras, P., Connolly, R., Ortega, C., Pineres, B., Brooks, O., Herrera, M., A Prototype System for Transnational Information Sharing and Process Coordination, Proceedings of the dg.o2004, Seattle, Washington, May 24-26, 2004. 2. Lee, M., Event and Rule Services for Achieving a Web-based Knowledge Network, PhD Dissertation, Department of Computer and Information Science and Engineering, University of Florida, Gainesville, Florida, 2000. 3. Kasad, T., Transnational Information Sharing and Event Notification, Master Thesis, Department of Computer and Information Science and Engineering, University of Florida, Gainesville, Florida, 2003. 4. Tomcat User Authentication, Jan 2004, Available from URL: http://www.possibility.com/epowiki/Wiki.jsp?page=TomcatUserAuthentication. Accessed on: Feb 2004. 5. Sun Microsystems, Using Login Authentication, 2003, Available from URL: http://java.sun.com/webservices/docs/1.3/tutorial/doc/Security5.html. Accessed on: Oct 2003. 6. Parui, U., Knowledge Profile Manager for Supporting Event-trigger-rule Services on the Internet, Masters Thesis, Department of Computer and Information Science and Engineering, University of Florida, Gainesville, Florida, 1999. 7. Shenoy, A., A Persistent Object Manager for Java Applications, Masters Thesis, Department of Computer and Information Science and Engineering, University of Florida, Gainesville, Florida, 2001. 8. Sun Microsystems, Java Servlet Technology Overview, 2003, Available from URL: http://java.sun.com/products/servlet/overview.html. Accessed on: Sep 2003. 9. Sun Microsystems, Java Server Pages Overview, 2003, Available from URL: http://java.sun.com/products/jsp/overview.html. Accessed on: Sep 2003. 10. The Apache Jakarta Project, The Tomcat 4 Servlet/JSP Container, 2002, Available from URL: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/index.html. Accessed on: Oct 2003. 64

PAGE 76

65 11. W3C Architecture Domain, Extensible Markup Language (XML), 2004, Available from URL: http://www.w3.org/XML/. Accessed on: Jan 2004. 12. The Apache XML Project, Xerces: XML parsers in Java and C++, 2002, Available from URL: http://xml.apache.org/#xerces. Accessed on: Jan 2004. 13. W3C Working Group, Web Services Architecture, Feb 2004, Available from URL: http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/. Accessed on: Mar 2004. 14. W3C, Simple Object Access Protocol (SOAP), Jun 2003, Available from URL: http://www.w3.org/TR/soap/. Accessed on: Feb 2004. 15. The Apache Software Foundation, Axis Users Guide, Jun 2003, Available from URL: http://ws.apache.org/axis/java/user-guide.html. Accessed on: Nov 2003. 16. MySQL Developer Zone, MySQL Reference Manual, 2003, Available from URL: http://dev.mysql.com/doc/mysql/en/index.html. Accessed on: Oct 2003.

PAGE 77

BIOGRAPHICAL SKETCH Manjiri Patil was born on August 11th, 1978, in Pune, Maharashtra, India. She received a Bachelor of Engineering degree in computer engineering (securing first class with honors), from the Maharashtra Institute of Technology, Pune, India, in May 2000. After graduation she worked with Satyam Computer Services Limited (Pune, India), as a Software Engineer. In August 2002, she joined the University of Florida (Gainesville, Florida), to pursue Master of Science degree in computer and information science and engineering. She worked as a Teaching Assistant and a Research Assistant, during her studies at the University of Florida. Her research interests include databases and the Web Services technology. 66


Permanent Link: http://ufdc.ufl.edu/UFE0009360/00001

Material Information

Title: Schema Exportation and Integration for Achieving Information Sharing in a Transnational Setting
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0009360:00001

Permanent Link: http://ufdc.ufl.edu/UFE0009360/00001

Material Information

Title: Schema Exportation and Integration for Achieving Information Sharing in a Transnational Setting
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0009360:00001


This item has the following downloads:


Full Text











SCHEMA EXPORTATION AND INTEGRATION FOR ACHIEVING
INFORMATION SHARING IN A TRANSNATIONAL SETTING
















By

MANJIRI PANDURANG PATIL


A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2005

































Copyright 2005

by

Manjiri Pandurang Patil
































I dedicate this thesis to my beloved parents.















ACKNOWLEDGMENTS

Research for this Transnational Digital Government project is supported by grant

EIA-0131886 from the National Science Foundation. I would like to thank Dr. Stanley Y.

W. Su (my supervisory committee chair) for giving me an opportunity to work on this

thesis topic and for his valuable guidance and support in this research effort. I would also

like to express my gratitude to Dr. Jose Fortes (supervisory committee member) for his

feedback and guidance, during the design and implementation phases of my research

work. I would like to thank Dr. Herman Lam for serving on my supervisory committee.

I would like to extend my gratitude to Mauricio Tsugawa and Andrea Matsunaga,

Ph.D. students from the Advanced Computing and Information Systems Laboratory

(ACIS Lab) for their help in integrating our system with the Machine Translation System

and the Conversational Interface System. I am also grateful to all of my friends for their

help and support.

Most of all, I would like to thank my beloved family for their love, support,

constant encouragement, and blessings. They made this thesis possible.
















TABLE OF CONTENTS

page

A C K N O W L E D G M E N T S ................................................................................................. iv

LIST OF TA BLES .................................... .... ................. ... viii

LIST OF FIGURES ......... ......................... ...... ........ ............ ix

A B ST R A C T .......... ..... ...................................................................................... x

CHAPTER

1 IN TR OD U CTION ............................................... .. ......................... ..

1.1 B background and M motivation ............................................................................. .. 1
1.2 Challenges and Approach Taken................................ ......................... ........ 3
1.3 Thesis Organization .................. .......................... .. ...... ..................

2 OVERALL SYSTEM ARCHITECTURE ....................................... ............... 9

2 .1 P articip atin g S ites ....................................................................... .................... 10
2 .2 D databases ................................................................. ..... ... ....... 10
2 .3 E xport Schem a T ool ................................................................................... ... 11
2.4 Schema Integration Tool and the Generation of a Global Schema ................... 11
2 .5 E v ent S erv er............... ........................................................................ 1 1
2.6 Event Trigger Rule Server (ETR)............... ........ ...................... 12
2.7 Distributed Query Processor..................... .............................. 12
2.8 Integration with the Language Translation System............................................12
2.9 Integration with the Conversational Interface System ........................................13
2.10 Authorization of Agents in the Watch-List Scenario ................ ............ ....13
2.11 Short Message Service Center................................................................14

3 DETAILED DESIGN ............. ................... ............................. ............... 15

3.1 E export Schem a T ool .............. ........ ....... .........................................................16
3.2 Schema Integration Tool to Generate Global Schema ......................................23







v









4 DISTRIBUTED QUERY PROCESSOR AND WATCH-LIST SCENARIO ...........27

4.1 Global Query Processor (G QP) ........................................ ........................ 27
4.1.1 G lobal Schem a Files........................................................ ............... 27
4.1.2 C country Inform ation .............................................................................. ...29
4.1.3 Tomcat Authentication and User Profile Information.............................29
4.1.4 Global Search Form ............ .... ......... ........................ 31
4.2 Local Query Processor (LQP) ........................................ ......................... 33
4.2.1 W eb Service Interface for LQP ...................................... ............... 34
4.2.2 The Wrapper Associated with the LQP.....................................................34
4 .3 W atch-L ist Scenario ..................................................................... ..................35

5 IM PLEM ENTATION DETAILS.................................... ............................ ......... 38

5 .1 E x p ort S ch em a T o ol .............................................................................................3 8
5.2 Integrate the Local Schemas to Generate the Global Schema.............................41
5.3 Distributed Query Processor.......................... ....... ............... 44
5.3.1 Global Query Processing Component (GQPC)........................................44
5.3.2 Local Query Processing Component (LQPC) ........................................46
5.4 W atch-L ist Scenario ..................................................................... ..................47
5.5 T translation Sy stem ............................................................... .... ...... ...... 49
5.6 Conversational Interface System ........................................ ....... ............... 50

6 TECH N OLO G IE S U SED ................................................ .............................. 51

6.1 The Events, Triggers, and Rules (ETR) Technology .......................................51
6.1.1 Events, Triggers, and Rules................................... ........................ 52
6.1.2 Event M anager.............................. ................... .. .......... .... 52
6.1.3 The E TR Server............... ................................................................... 53
6.1.4 Knowledge Profile M manager (KPM ) .................................. ............... 53
6.1.5 Persistent Object M manager (POM ) ............. ............................................. 53
6 .2 T he Jav a T technologies .............................................................. .....................54
6.2.1 Java Servlet Technology....................................... .......................... 54
6.2.2 Java Server Pages (JSP) Technology .................................... ............... 54
6 .2 .3 T om cat ................................................................... ............... 5 5
6.3 The XM L-Related Technologies ............................................... ............... 55
6.3.1 Extensible Markup Language (XML) ................................................55
6.3.2 X erces: X M L Parsers in Java .......................................... ............... 55
6 .4 W eb S erv ices ........................................................... ................ 5 6
6.5 Simple Object Access Protocol (SOAP).................................. ............... 56
6 .6 A p ach e A x is................................................... ................ 57
6.7 The M ySQ L D database ................................................ .............................. 57









7 PERFORMANCE EVALUATION...................................................................... 59

7.1 Query Perform ance ....................................................... .. ............ 59
7.1.1 Sim ple Q ueries ..................... .. .... ................... .... .. ........... 59
7.1.2 A ggregate and Join Queries.................................... ........................ 60
7.1.3 Queries Invoking the Translator........................................... ................. 61
7.2 Performance of Export Schema and Schema Integration Tools...........................61
7.2.1 Export Schem a Tool ............................................................................61
7.2.2. Schema Integration Tool ..................................... .............61
7.3 Performance of Rule Processing and Event Notification ............................ .. 61

8 CONCLUSIONS AND FUTURE WORK................................................ 62

L IST O F R E F E R E N C E S ...................... .. .. ............. ....................................................64

BIO GRAPH ICAL SK ETCH .................................................. ............................... 66
















LIST OF TABLES

Table p

3-1. Dominican Republic's sample exported schema................................... ............... 21

3-2. B elize's sam ple exported schem a........................................ ........................... 22

3-3. Attribute mapping in the global schema ....................................... ............... 26

4-1. Role list based on access privileges............. ............................ 30
















LIST OF FIGURES

Figure page

1-1. V virtual collaboration grids ................ ............................ .................. ............... 2

2-1. Overall system architecture of the prototype system.......... .......... ...............9

3-1. Export schema and integrate exported schemas.................................... ............... 15

3-2. The export schem a flow chart ............................................................................. 18

3-3. The add attributes to export schema flow chart............................... ............... 19

3-4. Generate global schema by mapping the exported attributes................................25

4-1. Architecture of the Distributed Query Processor .............. ........................................28

4-2. Global search form at the Belize site .... ....................... ...............31

4-3. The W atch-List Scenario flow chart .....................................................................36

5-1. Format of the exported_attributes.xml file...........................................................39

5-2. Export scheme a page .............................................................................. 40

5-3. Add attribute to export schema page ................................... ..................... 41

5-4 Published scheme as page ..................................................................... ..................42

5-5. M apping page for exported attributes.................................... ......................... 43

5-6. Sam ple X M L query ......................................................................... ...................465

5-7. Sam ple X M L result ................................................................. .... .. ..46

5-8. Query results displayed at the Belize site ............................................................ 46

5-9. Create authorized agents' list page........... ........................................ ............... 48

5-10. Arrival form at the port of entry in a Dominican Republic border station...............49















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

SCHEMA EXPORTATION AND INTEGRATION FOR ACHIEVING
INFORMATION SHARING IN A TRANSNATIONAL SETTING

By

Manjiri Patil

May 2005

Chair: Stanley Y. W. Su
Major Department: Computer and Information Science and Engineering

There is an urgent need for collaborations among governments of various countries

to tackle global problems such as drug trafficking, disease control, immigration and

border control, and terrorism. The Transnational Digital Government project (funded by

the National Science Foundation) aims at collaborating, integrating, and sharing

information among governments/agencies using information technologies. The

transnational government collaboration faces many challenges, because individual

countries differ in their languages, laws, policies and regulations, infrastructures, and

other resources. Our study focused on the development and use of advanced information

technologies for the collection, processing, exchange, and integration of the information

needed in a transnational digital government setting.

We developed distributed database technologies to support the needs of the project.

We designed and implemented an Export Schema Tool for participating countries to

define the data that they are willing to share with other countries/agencies (i.e., to define









export schemas). We also designed and implemented a Schema Integration Tool for

correlating (mapping) and integrating the data entities and attributes specified in different

natural languages and stored in different databases. The exported schemas were used to

generate a Global Search Form. Data mapping information and the integrated schema

were used by a Distributed Query Processor to query and retrieve data from

heterogeneous database sources. Our system was integrated with a language translation

system developed at the Carnegie Mellon University (Pittsburgh, Pennsylvania) and a

conversational interface system developed at the University of Colorado (Boulder,

Colorado) to achieve international collaboration. Interoperation among all of these

system components was achieved through a Web Services infrastructure.

We also demonstrated the use of events, triggers, and rules to enforce government

policies and security constraints; and to facilitate event filtering and notification (in a

sample scenario called the Watch-List scenario). Contributions of this work are design

and development of the Export Schema Tool and the Schema Integration Tool; and

integration of these tools with an enhanced Distributed Query Processor, a language

translation system, a conversational interface system, and an Event-Trigger-Rule Server.














CHAPTER 1
INTRODUCTION

1.1 Background and Motivation

Countries all over the world are facing global problems such as drug trafficking,

immigration and border control, disease detection and control, global education,

terrorism. These problems can be solved through information sharing and close

communication, coordination, and collaboration among government agencies in various

countries. There is an urgent need for developing and integrating advanced information

technologies to enable government agencies within a country (as well as across national

boundaries) to share information and to work together.

The Transnational Digital Government (TDG) project is a research project funded

by the National Science Foundation (NSF) of the United States. It aims to develop and

apply advanced information technologies to address global or regional problems. Under

this project, researchers from seven universities (Carnegie Mellon University, University

of Belize, University of Colorado, University of Florida, North Carolina State University,

University of Massachusetts and Pontificia Universidad Cat6lica Madre y Maestra of the

Dominican Republic) and experts from agencies in three countries (the Organization of

American States (OAS) of the United States, the National Drug Abuse Control Council of

Belize's Ministry of Health, and the National Drug Council of the Dominican Republic)

are developing information technologies to enable information sharing, integration, and

coordination among agencies of the collaborating countries. The developed information









technologies will enable transnational resource sharing and inter-government and inter-

organizational collaboration over virtual collaboration grids (Figure 1-1).













\. Internet 1











Figurel-1. Virtual collaboration grids

To build the transnational prototype system, the participants teamed up with two

small countries (Belize and the Dominican Republic), and jointly identified immigration

and border control as the transnational problems to tackle. The idea was to share

information across countries and agencies, for tracking movements of people entering

and leaving these countries. Thus the goal of the initial system is to allow government

agencies of collaborating countries to

* Enter and share immigration information (arrival and departure information of
travelers)

* Integrate the shared information to generate a global view of the distributed data, to
facilitate querying

* Access distributed data to identify suspicious individuals









* Support and coordinate inter-government and inter-organizational activities by
secured data access, event notification, and policy enforcement

* Deliver useful information to the right people and organizations, at the right time,
using different modes of communication

Information technologies being developed by the researchers in this project include

a conversational interface system, a language translation system, a collaborative

information management system, Internet portals and services, and a network support for

collaboration grids. These technologies can be used to solve many other transnational

problems similar to the immigration and border control problems. The Research and

Development focus of our study was the collaborative information management system.

1.2 Challenges and Approach Taken

Solving the complex problems in the transnational setting presents many new

technological challenges [1] as described below.

1. Data heterogeneity. Data gathered by the agencies at the ports of entry in both
Belize and the Dominican Republic is stored in different formats, structures, and
schemas. An integrated, global schema (Section 4.1.1) is needed to give users a
uniform view of the distributed data. For this, we designed and implemented a
system for data sharing by the two countries, and provided techniques for data
mediation and integration. The distributed query processing system is developed
for accessing this shared data. The global schema is presented in the different
natural languages used by users (i.e., English for Belize users and Spanish for users
in the Dominican Republic).

2. Language heterogeneity. The collaborating countries (Belize and Dominican
Republic) use different natural languages. The Schema Integration tool is needed to
specify the equivalence relationships between the data entities and attributes used
in the heterogeneous databases of these countries. The language translation system
is needed to translate sentences recorded in the comment field of the port-of-entry
forms. For this, we integrated our system with the language translation system
(Section 2.8) being developed at the Carnegie Mellon University.

3. Heterogeneity in government policies, and security and privacy rules. Each
country may have its own policies, regulations, constraints, and rules regarding
what information can be accessed by whom; and when and how information can be
used. These policies and regulations may change with time. We provide a system to
define and execute such rules. For instance, a country may have a rule that a tourist









official, while querying for some visitor's arrival/departure information through the
arrival/departure form, will have access to the visitor's tourism data or arrival data,
but will not have access to the departure data. To achieve this functionality, we use
the Knowledge Web Server [2], developed at the Database Systems Research and
Development Center, University of Florida. The Knowledge Web Server provides
advanced event-filtering and rule-processing capabilities; and tools and software
components for defining and processing events, triggers, and rules (Section 6.1.1).

4. Difficulties in inter-agency and inter-government communication and
coordination. Communication and coordination are vital among collaborating
countries. Collaborating countries can inform others of important events (e.g., the
outbreak of a disease, or a terrorist's movements), by automatically sending
notifications and delivering relevant information on the occurrence of important
events. To achieve this, we provide tools and mechanisms for supporting event
publication, subscription, filtering and notification, and for performing event and
rule-based triggering of operations and processes.

5. Heterogeneity in working environments and computing platforms. Government
agents may have varying access to some of the computing facilities; or access to
the Internet may be unreliable, or missing. Our system provides different means of
communication and notification for such users (e.g., communication by emails and
short messages via cell phones). Different government agencies worldwide use
dissimilar hardware, software, operating systems, database-management systems,
and application systems to perform their functions. There is a need for a common,
standard-based infrastructure for accessing and interoperating these resources over
a wide-area network like the Internet. Our system uses the Web Services model
(Section 6.4) to achieve software resource sharing and interoperation of
heterogeneous application systems. The Simple Object Access Protocol (SOAP)
(Section 6.5) was used to invoke the Web Services. These Web Services can be
accessed over the Internet via HTTP.

To show the transnational scenarios decided by the participants of this project and

to show the approaches taken to solve the challenges explained above, we developed a

Transnational Digital Government (TDG) prototype system at the University of Florida.

Design and implementation of this prototype system was the purpose of our study. The

system comprises

* Tool for participating countries/agencies to specify those and only those data that
they are willing to share with others (i.e., for defining export schemas)

* Tool for integrating and correlating the exported information

* Distributed query-processing system for accessing the shared data









* Knowledge Web Server comprising an event server, an event-trigger-rule server,
and knowledge profile manager.

All of these components were developed at the University of Florida. They were

integrated with a language translation system developed at the Carnegie Mellon

University, and a conversational interface system developed at the University of

Colorado. A Web Services infrastructure was jointly implemented by the collaborating

universities to achieve the interoperability of these system components.

To test and demonstrate the developed technologies, the project's initial focus was

on the information-sharing and process-coordination problems related to border control

against illegal immigration and drug trafficking. Our system (executed in Belize and the

Dominican Republic) focuses on connecting border stations between these two countries,

but the technologies can be used in other problem domains to enhance international

cooperation.

Limitations of the former prototype system: The Transnational Information

Sharing and Event Notification System [3] was developed only for processing distributed

port-of-entry and exit data. It cannot be extended to other categories. It was built on a

fixed set of database schemas, and was not built to handle join queries and queries that

contain aggregate functions. The system can only handle a single user request at a time

(i.e., queries issued by multiple users are not processed concurrently, but instead in a

sequential order). Thus, there was a need to make this system more robust and extensible

so that

* Multiple authorized users can query the system concurrently

* Code change will not be necessary in case there is a change in the export schema
defined by a participating country or agency









* Same system can be used for information sharing in other problem domains such as
agriculture inspection and protection, disease control, and homeland security

To overcome the limitations of the initial system, we have developed an Export

Schema Tool (Section 2.3), which facilitates any agency in a country to define an export

schema in any application category that the agency is willing to share with others. This

tool is replicated and installed at the sites of all the participating countries, and the user

interface of this tool allows users to select the natural languages that they desire for

communicating with the tool. There is also a need for a tool to define new application

categories for which schemas can be exported by participating countries or agencies. The

exported schemas can then be integrated at a host site to generate a global schema, for

querying purposes. To meet this need, we have developed a Schema Integration Tool

(Section 2.4), which is installed at the host site. A person who knows the languages of the

participating countries can log-in to this tool and perform data mappings (i.e., to specify

the equivalence relationships) between data entities and attributes given in the exported

schemas of an application category, as a way to integrate them and to generate the global

schema.

The Distributed Query Processor (DQP) (Section 2.7) has been enhanced to use this

global, integrated schema and also to process join and aggregate queries on the

distributed, heterogeneous databases. It has been further enhanced to use the language

translation system developed at the Carnegie Mellon University to mediate the language

heterogeneities and display the results of the issued query in the user's own natural

language. Another extension added to the DQP was its integration with the

conversational interface developed at the University of Colorado. The queries issued by

the conversational interface are processed by the Distributed Query Processor, and the









query results are sent back to the conversational interface. The interoperability between

all these system components is achieved through the Web Services infrastructure.

We also integrated our Distributed Query Processing System with the Knowledge

Web Server, to demonstrate the enforcement of policies and regulations using events,

triggers, and rules. The Watch-list scenario (Section 2.10) was added to create an

authorized list of the immigration agents by some supervisor and to mark selected agents

as 'under suspicion'. When a traveler enters the country, the port-of-entry event occurs

and a rule is triggered to check if the traveler is in the watch-list. If so, a notification

(email and/or cell phone) is sent to the subscribers of the event. Along with this, an alert

message is shown to only those agents not 'under suspicion', to warn them that the

traveler is in the watch-list. An agent who is under suspicion of collaborating with the

traveler will not get the alert message, but the notification of the traveler's arrival will be

sent to all relevant agencies.

1.3 Thesis Organization

This section describes the organization of the thesis in the following chapters. In

Chapter 2, we explain the overall architecture of the TDG prototype system and briefly

describe the functions of its system components. In Chapter 3, we explain the Export

Schema Tool, developed for exporting the shared information to the host site and the

Schema Integration Tool, developed for mapping the exported schemas to generate a

Global Search Form. In Chapter 4, we describe the enhanced Distributed Query

Processing system and its various components. DQP uses the Global Search Form for

accessing the shared information. In this chapter we also describe the Watch-list scenario,

which makes use of the Knowledge Web Server. Chapter 5 provides the implementation

details of the system. In Chapter 6, we describe the existing technologies used to






8


implement the system. In Chapter 7, we give the performance evaluation of our system,

and in Chapter 8, we give a conclusion of this work and propose some problems for

future work.















CHAPTER 2
OVERALL SYSTEM ARCHITECTURE

This chapter provides an overview of the system architecture of our prototype

system. The various sections describe the components, which include the tool for

exporting and integrating the schemas, the distributed query processor, the watch-list

scenario, and the integration with the language translation system and the conversational

interface system. In this chapter, we shall also discuss the participating sites, the

databases used, the Short Message Service Center, the ETR Server, and the Event Server.

*SMSC: Short Messace Service Center
Host Site (OAS)
Collaboration Portal with Schema
DR Integration Tool, Event Registration Belize
& Subscription facility


Figure 2-1. Overall system architecture of the prototype system









The overall system architecture is shown in Figure 2-1. This system prototype is

developed for processing distributed immigration data (i.e., port of entry and exit data),

but it can be extended and used in other application domains such as disease control,

agriculture security, etc. The various components of the system are described below.

2.1 Participating Sites

There are three participating sites in this prototype.

* Host Site
* Belize Site
* Dominican Republic Site

The Host Site has a collaboration portal and provides the facility for generating the

global schema, event registration, and subscription. The two participating sites, one in

Belize and the other in the Dominican Republic (DR) represent the agencies in the

participating countries. The developed software components are extensible and they can

accommodate a larger number of participating countries and agencies. The users of this

system are authorized users at the host site and the sites of the participating countries.

They include agents at the border stations and government agencies related to

immigration.

2.2 Databases

Figure 2-1 shows a local database system at each of the participating countries'

sites. Each country may have databases from different vendors, and also the structures

and schemas of these database systems may be different. Our system provides a tool to

export the sharable entities and attributes of these local databases. The export schemas

are integrated to produce a global schema, which represents the view of the distributed

data as seen by the "global users" of the prototype system. Here, global users are those

who have the right to query for distributed data. A global user can thus issue a query









against the generated global schema. The query once issued will be sent to the local

databases of the participating countries. It will then be processed by the local database

systems to extract relevant data from the local databases, and return the retrieved data to

the user.

2.3 Export Schema Tool

The Export Schema Tool is deployed at the local site of each participating country

as shown in Figure 2-1. This tool allows an agency of a participating country to define

those and only those data entities and attributes that it is willing to share with others. The

data defined in an export schema can thus be queried by legitimate users through a

Global Search Form, which will be explained in Section 4.1.4.

2.4 Schema Integration Tool and the Generation of a Global Schema

This tool, installed at the host site, is used to establish the semantic and language

equivalence relationships between data entities and attributes defined in the exported

schemas. It allows an authorized user at the host site (an IT personnel who knows

different languages of the participating countries) to establish mappings between two sets

of entities and attributes, which are exported by the participating nations and defined in

different natural languages. The result of this data mapping process is a set of data

mapping tables and a global, integrated schema. They are stored as global schema files

(Section 4.1.1) at the host site and sent to the participating countries' sites by invoking

their Web services.

2.5 Event Server

The event server handles event registration, event notification, and also

communicates with the local ETR server, to activate rules triggered by those events. We









use the Event Server in our system in the Watch-list scenario to identify suspicious

individuals and send event notifications to the subscribers of this event.

2.6 Event Trigger Rule Server (ETR)

The ETR server (Section 6.1.3) handles the installation and processing of rules at

each site. Whenever the ETR Server receives an event notification from the Event Server,

it identifies the proper triggers and rules to be executed.

2.7 Distributed Query Processor

This module is also deployed at the local site of each participating country. It

includes a Global Search Form, which is dynamically generated using the global schema

files. The Global Search Form includes entities and attributes that are the union of all the

entities and attributes shared by the participating countries. If a participating country

makes changes to the shared entities and attributes, those changes will be reflected in this

form. A new country can easily become a part of the Global Search Form by sharing its

database entities and attributes without involving any changes to the underlying code.

Authorized users of the participating countries use this form to issue queries to access

data stored in the local databases of these countries. The queries can be simple queries,

join queries, or queries that contain aggregate functions like max, min, sum, average, and

count.

2.8 Integration with the Language Translation System

The language translation system is developed at the Carnegie Mellon University.

The integration of the language translation system with our system is required since the

participating countries may use different natural languages. In that case, there will be a

need to translate some of the data into the language of the logged-in user. For example, in

the prototype system, Belize uses English language whereas the Dominican Republic









uses Spanish. There are several instances in our system where we invoke the language

translation system through a Web Service interface that it provides.

2.9 Integration with the Conversational Interface System

The conversational interface system is developed at the University of Colorado.

This system demonstrates the use of natural language to query the global database, and

display the result to the user. The natural language query is translated into a query that is

processed by the Distributed Query Processor to retrieve data stored in the database

systems of the participating countries. The query is sent to the Distributed Query

Processor in an XML format, and the retrieved data is also sent back to the conversational

interface in a predefined XML format. The communication between these two system

components is achieved through Web Services.

2.10 Authorization of Agents in the Watch-List Scenario

This module is installed at the local sites of each of the participating countries. The

purpose of this component is to allow a supervisor to authorize the agents at the border

stations, to use the system and also to mark some agents as 'under suspicion' of

collaborating with some people in a watch-list. In this scenario, if some suspicious

individual enters the country, the watch-list database will be checked to see if the traveler

is present in the watch-list. If he/she is in the watch-list, then a warning (alert message)

will be shown to only those agents, which are not 'under suspicion'. Event notification

will also be sent to all the subscribers of this watch-list event (e.g., security agencies,

military, and law enforcement organizations). Thus, an agent under suspicion will not

receive the alert signal and will not know that the traveler will be watched by relevant

agencies.









2.11 Short Message Service Center

The event notification can be sent to the subscribers of an event using emails and/or

cell phone notifications based on the options the subscribers selected at the time of event

subscription. The cell phone notification is routed through the Short Message Service

Center (SMSC). During event notification, the event server looks up the cell phone

numbers and the network of the subscribers, and then sends the message with SMTP to

phone@messaging.cell-network.com. The SMSC routes this message to the users' cell

phones as an SMS message.

The communication between the various components of our system deployed at

different sites is through the Internet. In most cases, the services of these software

components are invoked using the Web Service technology.
















CHAPTER 3
DETAILED DESIGN

This chapter presents the detailed design of the tools for exporting and integrating

the database schemas (Figure 3-1). Section 3.1 explains the design of the Export Schema

Tool. This tool includes an interface to define new export schemas and an interface to

modify a schema that was already created. Section 3.2 describes the Schema Integration

Tool used to correlate all the exported schemas and to generate the global schema.


HOST SITE
H T SI Map exported schemas
Generate global schema

IT Personnel


local schema


:port local schema


Dominican


Internet
(OAS/Belize/US/
Dominican Republic)


k information
Immigration Agent


Belize






Enter local sche a
information

Immigration Agent


Figure 3-1. Export schema and integrate exported schemas









The IT personnel of the participating countries will use the Export Schema

interface to define the database entities and attributes stored in their local databases that

they are willing to share. The ExportSchema Web Service, deployed at the host site will

be invoked in order to save the exported schema at the host site. Once all the participating

countries have exported their schemas of an application category to the host site, the

exported schemas will be integrated using the Schema Integration Tool installed at the

host site, to generate the global schema. The host site will invoke the WriteGlobalSchema

Web Service at the local site of each participating country. This Web Service will send

the generated global schema files, which includes the global, integrated schema and the

data mapping tables to the local site. The global schema will be used to generate the

Global Search Form.

3.1 Export Schema Tool

The Export Schema Tool is used by the participating nations to specify their local

database schema entities and attributes to be shared with other nations. It consists of the

following interfaces: a form to select the display language so that the user can view the

interfaces in his/her natural language, a form to select an application category for which

the schema is to be exported, a form to add new data entities, a form to add attributes that

are to be exported, and an interface to modify an existing schema. The steps followed by

the user while exporting the schema are shown in Figure 3-2.

1. Authorized user logs in to the Export Schema Tool

2. User selects the language for displaying the user interface in that language. The
choice of languages is restricted to the languages used by the participating
countries

3. User enters the application category for which he/she wants to export the schema.
For example, the user can enter a category name such as immigration, or
agriculture









4. Next, the user can add new data entities, delete unwanted data entities, or skip this
step. All the data entities, whose database attributes are to be exported should be
added in this step

5. Next the user gets to view the attributes, if any, that have already been added for
exporting. The user can add more attributes by selecting the Add New Attributes
(Figure 3-3) option or the user can delete an already added attribute, which is not to
be exported

6. Once the user is done with adding all the attributes to the form for exporting, he/she
can select the Export Schema option to export the schema

Given below is the sequence of steps executed by the user while adding new attributes for

exporting (Figure 3-3)

1. On the add attributes page, the user selects the data entity to which the attribute
belongs

2. User will enter the attribute name for the new attribute

3. User selects the type of the attribute (String, Integer, Boolean, or Date)

4. Next, the user will select the display type for the attribute (text box, radio button, or
list box). This information is used later to generate the Global Search Form

5. If the user wants to insert the new attribute before a particular attribute on the
Export Schema page, he/she can enter that particular attribute's name in the "Insert
Before Attribute" text box

6. If the display type of the new attribute is radio button or list box, user has to give
the default values for this attribute, which will be displayed on the Global Search
Form

7. As a result, the new attribute can be appended at the end of the list of attributes that
were already added, or it can be inserted before a particular attribute















Select Language
English/Spanish


N
Display list of
attributes to be
exported


Figure 3-2. The export schema flow chart






















Select Attribute Type
(String/Integer/Boolean/
Date)


Select Display Type
(Textbox/Radiobutton/
Listbox)


Enter default values for
radio button and list box
separated by commas


Figure 3-3. The add attributes to export schema flow chart






20


Table 3-1 and Table 3-2 show two example schemas that are exported from the

Dominican Republic and Belize site, respectively. Each exported schema includes the

local database attribute names, the database relation to which the attribute belongs, the

attribute types, and the display types of the attributes. Table 3-3 shows the components of

the integrated global schema, which includes the pairs of attributes that are mapped from

the two sites and the internal names assigned to each of these pairs.









Table 3-1. Dominican Republic's sample exported schema
Attribute Name Relation Name
docviajenumero SALIDA
Numerocedula SALIDA
Apellidos SALIDA
Nombres SALIDA
Sexo SALIDA
Fechallegada SALIDA
Puertoembarque SALIDA
Fechapartida SALIDA
Partidanumerovuelo SALIDA
Puertodesembarque SALIDA
Fechanacimiento SALIDA
Lugarnacimiento SALIDA
Ciudadnacimiento SALIDA
Paisnacimiento SALIDA
Nacionalidad SALIDA
Ocupacion SALIDA
Estadocivil SALIDA
Calle SALIDA
No SALIDA
Ciudadparaje SALIDA
Provinciaestado SALIDA
Pais SALIDA
Numerovuelo SALIDA
Motivoviaje SALIDA
Comentariogeneral SALIDA
id_pais PAIS
nombrepais PAIS
Attribute Type: String, Display Type: Textbox









Table 3-2. Belize's sample exported schema
Attribute Name Relation Name
Passportnum MAIN
Passportdate MAIN
Passportstate MAIN
Passportcountry MAIN
Lname MAIN
Fname MAIN
Middlei MAIN
Gender MAIN
Entrydate MAIN
Portofembcity MAIN
Portofembcountry MAIN
Departuredate MAIN
Portofdisembcity MAIN
Portofdi semb country MAIN
Birthdate MAIN
Birthcountry MAIN
Nationality MAIN
Occupation MAIN
Paddrstreet MAIN
Paddmumber MAIN
Paddrcity MAIN
Paddrstate MAIN
Paddrcountry MAIN
Paddrzip MAIN
Vehiclenumber MAIN
Baddrstreet MAIN
Baddrnumber MAIN
Baddrcity MAIN
Baddrstate MAIN
Intendedstaylength MAIN
Purposeoftrip MAIN
Visitnum MAIN
Comments MAIN
Passportnum TOUR
Visitedbefore TOUR
Lodging TOUR
Interests TOUR
Display Type: Textbox


Attribute Type
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
String
Integer
String
String
String
String
String









3.2 Schema Integration Tool to Generate Global Schema

This module is installed at the host site. It is used to establish the semantic and

language equivalence relationships between the exported data entities and attributes. In

this process, pairs of data entities and attributes displayed in different natural languages

will be mapped (correlated) to generate the global schema. This mapping is required to

mediate the schematic and semantic heterogeneities that exist between the databases of

the participating countries. During attribute mapping, one internal name is given to each

set of mapped attributes and they together are added to the global schema at the host site.

Internal attribute names are neutral representations of attribute names used in different

databases. When the integrated global schema is saved, the global schema files and the

data mapping files are also sent to the local sites of each of the participating countries.

These files are used to generate the Global Search Form in the language used by the user.

This module includes the following form interfaces: a form to add new application

categories, a form to map the exported attributes defined by different countries, and a

form to assign internal name to a pair of mapped attributes and to add default values for

some attributes. The sequence of steps executed during the integration of the exported

schema attributes is as follows (Figure 3-4).

1. An authorized user (IT personnel), who knows all the languages of the participating
countries logs in to the system at the host site to map the schemas

2. The user can view a list of the available application categories

3. He/she can add more category names and descriptions, so that the participating
countries can export the schemas for this new category also

4. The user can select a category, to view the schemas that have already been exported
for that category

5. The user will select a correlated pair of attributes from the exported schemas (those
attributes, which he/she wants to map). He/she has to provide an internal name to






24


the pair of mapped attributes and then add it to the global schema. If an attribute is
not present in one of the countries' local database, then the user has to provide a
name for that attribute in the countries' natural language so that it can be displayed
in the Global Search Form to be generated for the users of that country

6. The user will repeat the above steps to map all the attributes that are to be exported
and finally save the global schema





























Show the schemas exported
for selected category


Map a pair of attributes
from Belize and DR


Figure 3-4. Map Exported Attributes









Table 3-3. Attribute mappings in the global schema
Attribute Name in Belize Attribute Name in DR
Passportnum docviajenumero
Passportdate fechadeemision
Passportstate lugar-de-emision-estado
Passportcountry lugar-de-emision-pais
Idno Numerocedula
Lname Apellidos
Fname Nombres
Middlei segundo-inicial
Gender Sexo
Entrydate Fechallegada
Portofembarkationcode Puertoembarque
Portofembcity puertoembarque-ciudad
Portofembcountry puertoembarque-pais
Departuredate Fechapartida
Portofdisembarkationcode puertodesembarque
Portofdisembcity puertodesembarque-ciudad
Portofdisembcountry puertodesembarque-ciudad
Birthdate Fechanacimiento
Birthcountry paisnacimiento
Nationality Nacionalidad
Occupation Ocupacion
Maritalstatus Estadocivil
Paddrstreet Calle
Paddrnumber No
Paddrcity Ciudadparaj e
Paddrstate Provinciaestado
Paddrcountry Pais
Vehiclenumber Numerovuelo
Baddrstreet Direccion-destinada-calle
Baddrnumber Direccion-destinada-no
Baddrcity Direccion-destinada-ciudad
Baddrstate Direccion-destinada-estado
Purposeoftrip Motivoviaje
Visitnum visit el numero
Comments comentariogeneral
Passportnum docviajenumero
Visitedbefore visitadoantes
Lodging accomodation-destinado
Interests intereses-especiales


Internal Attribute Name
passportno
dateofissue
placeofissue-state
placeofissue-country
idno
Lastname
firstname
mi
sex
dateofentry
portofembarkationcode
portofembarkationcity
portofembarkationcountry
dateofdeparture
portofdisembarkationcode
portofdisembarkationcity
portofdisembarkationcountry
dateofbirth
placeofbirth
nationality
occupation
Maritalstatus
permanentaddress-street
permanentaddress-number
permanentaddress-city
permanentaddress-state
permanentaddress-country
airline-vehicle-vesselno
intendedaddress-street
intendedaddress-number
intendedaddress-city
intendedaddress-state
purpose-of-trip
visitno
comments
passportnumber
visitedbefore
intended-accomodation
special-interests














CHAPTER 4
DISTRIBUTED QUERY PROCESSOR AND WATCH-LIST SCENARIO

This chapter describes the architectural design and functionality of the Distributed

Query Processor (Figure 4-1) and the Watch-list scenario. The components of the

Distributed Query Processor are: the Global Query Processing component (GQP)

described in Section 4.1 and the Local Query Processing component (LQP) explained in

Section 4.2. Section 4.3 explains the watch-list module.

4.1 Global Query Processor (GQP)

GQP makes use of the global schema files, country information, and user profile

information to generate a Global Search Form in the natural language used by the user.

The global schema files include forminfo.txt, and mapCountryname.txt. The country

information is stored in countryinfol.txt file. The user profile information is stored in

tomcat-users.xml file, and it is used for authentication and authorization of the logged-in

user. We use Tomcat's User Authentication facility to authenticate the users [4] [5].

4.1.1 Global Schema Files

These files are generated after mapping the exported schemas from different

countries at the host site. As explained in Section 3.2, the global schema files are saved at

the local site of each participating country by invoking the WriteGlobalSchema Web

Service. The format and use of each of the global schema files is explained below.

The form info.txt file: This file stores information like the internal name for an

attribute, the display type of the attribute, the number of default values associated with









that attribute, and the country codes of all those countries, which contain this attribute in

their local databases. This is one of the files used to generate the Global Search Form.


Figure 4-1. Architecture of the Distributed Query Processor

The mapCountryname.txt file: A separate mapCountryname.txt file is generated

for each of the participating countries. For example, the file sent to the Belize site when

the "Generate Global Schema" button is clicked by the user will be named mapBelize.txt.

This file includes information like the internal attribute name, the corresponding name for









the attribute in the country's local database, the database relation to which the attribute

belongs, the data type of the attribute, and the number of default values associated with

the attribute. The actual default values will also be stored in the tags. If the

attribute is not present in the local database of a country, then that field is replaced by the

attribute name in the country's local language and the database relation name will be set

to "none". This file is used for mapping the global (internal) attribute names to the

countries' local database attribute names, when the query is sent to the local site, and vice

versa when the query results are generated and returned. This file together with the

forminfo.txt file is used to generate the Global Search Form that is displayed in the

user's natural language.

4.1.2 Country Information

The file country_infol.txt contains the Web Service URL of all the participating

nations along with the specific method name of the service, which needs to be invoked in

order to access the Local Query Processing component. The query issued by the user is

sent in XML format to the local site by accessing this Web Service of the LQP.

4.1.3 Tomcat Authentication and User Profile Information

To set up tomcat user authentication, we did the following

1. Created a conf/users/tomcat-users.xml that has entries as shown below






2. Inserted the following in the webapps/QP/WEB-INF/web.xml file
Similar web.xml should be included for each of the applications deployed under
tomcat.


Query Form









/*
GET
PO ST


Belize




FORM

/login.j sp
/error.j sp




Belize


The authorized roles and users are added in tomcat-users.xml file. The forms,

which require login user authentication, are included as security constraints in the

web.xml file for the application. The various user roles and their access privileges used

by our system are shown in Table 4-1 below. For example, the role Super has access to

all the database attributes, whereas role Police has access to only arrest information in the

database.

Table 4-1. Role list based on access privileges
Role Privilege to access following information
Super ALL
Police Arrest information
Immigration Immigration information
Userl Arrival-related immigration information
User2 Departure-related immigration information
Tourism Tourism information











The participating countries can collaborate and decide on a global roles list and


corresponding access privileges for the roles on the local database entities and attributes


of those countries.


File Edit Vew Favorites Tools Help
flak ] j -;, ^o *"-, ** ..... < 3 J5 .earh
AQddress i|l http:oa128.227 176.39:38080QPfreateGlobalForrm.]5p g Lnks "
" 5earhWeb I Mail My Yahool Games Personas I LAUNCH ign
CHECK COUNTRIES YOU WISH TO QUERY
SBehze (b)
SDoirmican Repubhc (d)

Display R]Records OCount


ENTER PARAMETERS FOR QUERYING ARRIVAL/DEPARTURE RECORD INFORMATION
Check the box beside field if youwish the field to be retrieved in the final result
Fields in a single columnwill be ANDed together; second and third columns will be ORed into the expression



r ~ OR OR
MAIN.passportnumn
IR ( b,d) I I 1
MATIN.passportdate
(b)
MATIN.passportstat
I (b)
AIN.p assportcountry
(b)
SMAIN .Inanme



Figure 4-2. Global search form at the Belize site

4.1.4 Global Search Form

The Global Search Form (Figure 4-2) is generated automatically based on the


integrated global schema, which is a union of the shared entities and attributes from all


the participating countries. The Global Search Form is a Java Server Page (JSP) and is


displayed in the natural language of the logged-in user. The user profile information,


which includes the nationality of the user, is used to decide the display language for this


form. Users can issue queries to the local databases of the participating nations using this


form. Our system displays the global form in English for Belize users and in Spanish for









users in the Dominican Republic. The Global Search Form includes the following form

fields.

* The list of all the participating countries to which users can issue queries and
options to select them
* The list of all the attributes, which are included in the global schema and the data
entities to which they belong. User can select any of these attributes for displaying
in the query result
* User has the option to issue queries containing aggregate function 'count' that
displays the sum total of all the records in the query result. The other aggregate
functions that the query can include are max, min, avg, and sum for integer type
attributes, and only max and min functions for the attribute type, date
* He/she can also specify the condition clauses (search criteria) for the query

The generated query is in a disjunctive normal form and can contain up to three

ORed expressions entered into the three columns of Figure 4-2. Each of the OR

expressions are a conjunction of the condition parameters entered in each column in the

query form. The sequence of steps executed by the user when he invokes the Global

Search Form is

1. The user has to login to the system, and then select the countries he/she wishes to
query

2. Next he/she has to select the type of the query, e.g., simple query that displays the
records or queries containing aggregate functions. He/she also has to select the
attributes to be displayed in the query result

3. The user can enter the values for the condition clause of the query

4. If the user selects one or more aggregate type of queries, he/she is not allowed to
select the other attributes on the form that are not part of the aggregate function,
else it results in a SQL Exception at the database level


When the user submits the Global Search Form, the following actions take place.

* All the roles associated with the logged-in user and the countries whose databases
the user wants to query are identified

* The type of the query is also identified for example, simple query that displays the
actual records or query with an aggregate function that displays the result of the
functions like sum, max, min, avg, and count on certain attributes in the database









* An XML query document is created for each country that is queried. It is a sub-
query that includes only those attributes selected by the user and are present in the
country's local database. Thus, the query issued by the user is converted to an XML
document. For example, belizequery xmlfilel.xml (Figure 5-7) represents the sub-
query sent to the Belize site. It contains the user's role information, the country
name to which the query is issued, the query result attributes selected by the user
and the condition clause part of the query. The attribute names in the XML query
are the internal attribute names from the global schema, which are mapped to the
local attribute names before the query is actually processed at the local site

* The sub-queries are sent to the local sites by invoking a Web Service method of
those countries whose databases are being queried. Thus the Global Query
Processor acts as a Web Service client of the Local Query Processor, which is
deployed as a Web Service at the local sites. The Web Service URL and the method
name for each participating country are stored in the country_infol.txt file (Section
4.1.2)

* After a sub-query is processed at a local site, the query result is returned to the
Global Search Form again in the form of an XML string. The XML query result is
stored at the query issuing site as a pre-defined XML document called
IndividualResult.xml (Figure 5-8). It consists of the name of the country that has
sent the query result and the actual query result, which includes the attributes that
were selected by the user and their values. At the local site, the local result
attributes are mapped to the internal attribute names before sending the result to the
query-issuing site. At the issuer's site, the XML result document is traversed using
the DOM parser and the result is extracted from it. The attributes of the returned
result are again mapped to the local attribute names before being displayed to the
user. This mapping uses the data mapping files

* If the query issued by the user contains an aggregate function, then the query
results from the two countries have to be combined before displaying the results to
the user. For example, if user issues the query "Retrieve the last date when a person
of US nationality entered the country". This query will be processed independently
at the local sites of the two countries, and the "max" aggregate function will be
applied on the "date of entry" attribute of the two local databases. The two sites
will send their local query results to the query-issuing site where the "max"
function is again applied on the two returned results to get the global maximum
value, which is then displayed to the user

4.2 Local Query Processor (LQP)

The Local Query Processing component consists of a Web Service interface for the

LQP and a wrapper, which interacts with the Event Server, the ETR Server, the

Translation System, and the local DBMS of the country. The LQP component receives









the XML query document sent by the GQP of the query-issuing site. It translates the

received query into an SQL query for processing by the local DBMS.

4.2.1 Web Service Interface for LQP

The LQP component is deployed as a Web Service by each of the participating

sites. The Web Service method accepts the XML query document sent by the Global

Query Processing component as a string argument and returns the query results again as

an XML format string to the query-issuing site.

4.2.2 The Wrapper Associated with the LQP

The wrapper performs the following functions.

* It maps the internal attribute names present in the sub-query issued by the GQP to
the local database attribute names of the site to which this LQP component belongs.
The mapping uses the mapCountryname.txt file

* The extractor module of the wrapper processes the XML query document using the
Document Object Model (DOM) parser to extract information such as the role
information of the person who has issued the global query, the attributes being
queried along with the attributes included in the condition clause of the sub-query.
It also extracts the table names (relation names) to which all the attributes that are
present in the sub-query belong

* Next the access controller module of the wrapper checks if the user who issues the
query has the access right to all the attributes in the query. It connects to the local
Event Server of the site and posts the access event. The access event triggers a
rule to check the access right of the user on the query attributes

* The translator module deals with the table lookup translation and language
translation

The translation of internal attribute names to local attribute names and vice
versa, and the translation of attribute values use the table lookup method. The
mapping tables are implemented as hash tables

There are certain attribute values, which cannot be resolved using the lookup
method, and for those we need to invoke the CMU's language translation
system. For example, the officer at the port-of-entry station can enter
comments about the travelers entering the country, in his/her own language.
These comments get stored in the local database of that country. If the user
who issues the query is interested in searching those records, which contain









specific words in the 'comments' field, then the issuer will enter the search
criteria in his/her own natural language. But when the query is actually
executed on the local database by the LQP component, that search criteria
needs to be translated into the language of the local site before the query is
processed. For example, the immigration officer may want to see a list of all
the people who appeared nervous when they entered the country. So he/she
will enter the word 'nervous' in his/her native language into the comment field.
Once this query reaches the local site, it needs to be translated into the
language used by the local site before the query is actually processed. Also
after getting the query results, the values for the 'comments' attribute need to
be translated back to the natural language of the query issuer before being
displayed to the user. For these translations, the language translation system
developed at the Carnegie Mellon University is invoked

* The query processor module is responsible for generating a query in SQL format
using the attributes extracted from the XML query string. The query processor then
connects to the local database and issues the SQL query to the local database
system. In the process of generating the SQL query, the translator is used to convert
the internal query attribute names to local attribute names of the local database,
before the query is sent to the local DBMS, and to convert the local attribute names
of the returned query result to the corresponding internal (or neutral) attribute
names. The machine translator may also be invoked to translate some query values.
The query result is then sent to the wrapper, which converts the result into an XML
format and passes it back to the Web Service method of the LQP. The Web Service
will send the result to the Web Service client (i.e., the GQP of the issuing site)

4.3 Watch-List Scenario

This module will be deployed at the border stations of the participating nations.

The Watch-list scenario depicts three goals.

* Allows the supervisor to mark some of the agents posted at the border stations as
under suspicion, if they are suspected of collaborating with some people in a
watch-list by admitting them into the country
* The system checks if the traveler entering the country is in the watch-list, and
displays an alert message to the agent on duty, if he/she is not under suspicion
* The Watch-list scenario is also one of the examples for the Event-Trigger-Rule
system, and is used to send event notifications to the subscribers of the event

The main components of this module are the authorized agents' database, the

watch-list database, the local database, which stores the traveler's arrival/departure

information, and the Event-Trigger-Rule system. The event depicted in the Watch-list

scenario is the PEntry event. This event gets posted when the agent at the border station









fills the arrival information in the Arrival form, for a traveler who wants to enter the

country. The event triggers a rule called the WatchListCheck Rule. This rule checks if the

traveler is in the watch-list by consulting the watch-list database.


Figure 4-3. The Watch-List scenario flow chart









This module consists of the following form interfaces: a form to mark some of the

border agents as 'under suspicion' and a form to fill the arrival information for a traveler.

The sequence of steps executed during the Watch-list scenario is as follows (Figure 4-3).

1. The supervisor will log in and create and edit an authorized agents' list. Agents
who are under suspicion of being corrupted agents are marked

2. Agent at one of the border stations logs into the system and fills the arrival form for
a traveler who enters the country

3. The system checks if the traveler is in the watch-list by consulting the watch-list
database

4a. If the traveler is in the watch-list, then ETR sends event notification to all the
subscribers of this event. Event notification is sent via email and/or cell phone

4b. If not, then the system will insert traveler's record into the database

5. Check if the agent is under suspicion by consulting the database of authorized
agents

6a. If yes, no alert message will be posted. The agent will allow the traveler to enter the
country and the traveler's arrival information will be inserted into the database

6b. If not, the alert message, which says that the traveler is in the watch-list, will be
displayed to the agent

7a. The agent who gets the alert message can either allow the traveler to enter the
country and the traveler's data is inserted into the database

7b. Or, the agent rejects the traveler from entering the country













CHAPTER 5
IMPLEMENTATION DETAILS

In this chapter, we describe the implementation details of the main components in

our system. Section 5.1 describes the Export Schema Tool, Section 5.2 describes the

Schema Integration Tool, Section 5.3 describes the Distributed Query Processor, and

Section 5.4 gives the implementation details for the Watch-list scenario.

5.1 Export Schema Tool

The files, which are used in the implementation of the Export Schema

functionality, are described below.

The language.jsp page: This JSP provides an interface, where user can select the

language for displaying all the pages in the Export Schema module. The languages

currently supported by our system are Spanish and English since these are the languages

used by the participating countries of the Dominican Republic and Belize respectively, in

the prototype system. Once the user selects the language of his choice on this page, the

corresponding language.txt file will be used for displaying the user interfaces in the

selected language. For example, if user selects Spanish as the language, the system will

use the Spanish.txt file to display the forms in Spanish. In short, our system can easily

support a new language interface by including the language.txt file for the new language.

For example, to provide the support for French language, we need to add a new file to the

system named "French.txt" with the required translations.

The select_category.jsp page: This interface allows the user to select the

application category for which he/she wants to export the schema.









The relations.jsp page: Based on the category name selected by the user on the

selectcategory page, this interface will display the data entities that are already available

for this category. The data entities added, for a particular category, are appended to the

relations.txt file under the "category" folder in the DQP directory of the local site. If there

are no data entities that exist for the selected category, then a new relations.txt file will be

created, and then the data entity name will be included in that file. As a result, this form

interface allows user to add new data entities.

The export_schema.jsp page: This JSP (Figure 5-2) displays all the attributes that

have been previously added for exporting under the selected category by reading the

exported_attributes.xml file of the category. This XML file is read by traversing it using

the DOM parser. If there are no attributes previously added for exporting, then a new

exported_attributes.xml file is created in the same directory where the relations.txt file is

present. The exportedattributes.xml file will be updated every time a new attribute is

added or deleted. A sample exported_attributes.xml file is shown in Figure 5-1.

Belize

MAIN

passportnum
MAIN
string
textbox



Figure 5-1. Format of the exported_attributes.xml file

In Figure 5-1, the country name in the tag indicates that this file is

exported from a Belize site. MAIN is the data entity name to which the attributes belong.

The attributes belonging to different data entities are stored separately in the XML file.








40



The tag holds all the information related to the attribute that is to be


exported. As shown in the figure, the attribute name is passportnum. It belongs to the data


entity (relation) MAIN, the data type of the attribute is string, and the display type is


textbox.


3 EXPORTSCHE:MA I cr_ o so WernerExplorer .1le lr


File Edit View Favorites Tools Help

B0ack I .... S -earch
Address | htLpi 128.227 ,176.39;8080/DQPIeport_ schema. sp
S- |[Search Webh ||-


Medea -' 4\


DI MaiI rlyVahool GI ames Personal s LAUNCH gnI


EXPORT SCHEMA


This schema will be exported for the category immigration

Attribute Name Data Entity Type Display
passportnum MAIN string textbox
passportdate MAIN strong textbox
passportstate MAIN strong textbox
passportcountry MAIN strong textbox
Iname MAIN strong textbox
fame MAIN stnng textbox
rmddle MAIN strong textbox
gender MAIN strong radiobutton
entiydate MAIN date textbox
portofembcty MAIN string textbox
portofembcountry MAIN string textbox
departuredate MAIN date textbox
portofdisemb cty MAIN strong textbox
portofdsembcountry MAIN strong textbox
birthdate MAIN date textbox
brthcountry MAIN strong textbox


Delete
Default Values A rbue?
Delettribute?
[ DeleteAttrbute ]
Delete Attribute
Delete Attribute
[ Delete Attrbute
Delete Attribute
Delete Attrbute
male, female [ Delete Attnrbute
Delete Attribute
[ Delete Attrbute
[ DeleteAttrbute
Delete Attribute
[ DeleteAttrbute
[ DeleteAttrbute
Delete Attribute
[ Delete Attrbute
el te .,e


Figure 5-2. Export schema page


The add_attribute.jsp page: This interface is used by the user to add new


attributes to the export schema. The newly added attribute is written to the file


exported_attributes.xml. After the user has added all the attributes that he/she wants to


export, he/she submits the export schema.jsp page, and then the ExpSchema.java file


invokes 'sendSchema' method of the ExportSchema Web Service that will store the


exported local schema at the host site. The exported schema is saved as an XML file


under the selected category folder at the host site. Here the file ExpSchema.java acts as a


V


Linksnle










client for the ExportSchema Web Service. Whenever any site exports its local schema for

this category, it will be stored as a new XML file under the category folder at the host

site.


Fsl. Edi :'.1. F .te ,ool .... .
0Back- I L .i e -I 5earch Meda J' 4 3 D i:

V .*lI 0 C* LI r *^ I L |

ADD ATTRIBUTE


Select Data Entity MAN
Attribute Name personid
Attribute Type .
Display Type TextBox
Insert Before Attribute


If display type for attribute is list box or radio button, provide a list of comma
separated values for the attribute.



[ nseZ ] Append ] [Back]




Figure 5-3. Add attribute to export schema page

5.2 Integrate the Local Schemas to Generate the Global Schema

The files that are used to implement the schema mapping and integration of the

exported schemas are described below.

The global_categories.jsp page: An authorized user can select the category for

which he/she wants to generate the global schema after logging-in to the

global_categoriesj sp page. The user can also add new categories to the list of existing

categories so that the local sites can also export their schemas for these newly added

categories. All the categories and the category descriptions are stored in the categories.txt








42



file. When the user selects a category, he/she gets to see the schemas exported by all the


local sites under that category.


The published_schemas.jsp page: This page displays all the schemas currently


exported for the selected category. The exported schemas of each site (country) are


displayed as columns of attributes. The metadata like the data entity of the attribute, its


data type, display type, and the default values if any associated with the attribute are


shown when the user clicks on a particular attribute. All this metadata information is


extracted from the schema files stored under the OAS folder.


File Edit View Favorites Tools Help
Back- L1 [1 Ii;I Search Media :
Address http:;128,227,176.39:8080QOA5 spublslshhed_shemassph dCategory=mmigraLon I Links "
S- 1\SearchWeb M I M M yVahoo IC Games yPersonas LAUNCH -SgnInl

PUBLISHED SCHEMAS


The public hed schemas ae shown below. Select the attributes to be added to the global schema.
Belize NAME Dominican NAME
passponum Republic
S passportdate docvalenumero
S passportstate 0 apelldos
0 passportcountry 0 nombres
0 Iname 0 sex
S fame 0 fechallegada
O middle 0 puertoembarque
0 ender fechaiarttda
0 entrdate 0 partidanumerovuelo
O pgotofembct O puertodesembarque
O portofembcountry O fechanacrimento
O departuredate 0 luganacimiento
S porto disembcity 0 ctudadnac mento
O portofdisembcountri 0 pa0snacrmiento
O brthdate 0 nacionaidad
O btrthcounr O ocupacion
S national 0 estadocivl
O occupation calle
O paddrstreet 0 no
o oaddmumber 0 cudadparale



Figure 5-4. Published schemas page


The add_global_attributes.jsp page: This JSP page is invoked when the user


selects the related pair of attributes from each local site and clicks on the 'Add to Global


Schema' button on the published_schemas.jsp page. The user will be shown the attributes










that he/she wants to map in order to include the attribute in the global schema. For

example, if the user has selected 'passportnum' from Belize's exported schema and

'docviajenumero' from the Dominican Republic's exported schema, then he/she is shown

the country name and the corresponding attribute name from the country's exported

schema. If an attribute that is to be added to the global schema is not present in one of the

countries' exported schemas, then user is asked to enter the attribute name in that

countries' local language. The user is also asked to enter an internal name for the mapped

attribute. If there are any default values for an attribute in one of the countries' exported

schemas, then the user has to enter the names for those values in the other country's local

language.


FH, Ite iEJ i 1 w, Y I F Ik-s Tr-oo)1 t i t`

0 Back ?I -)Seach # L 1ede
Address I httLp 1128.227 176.39:8080o /A5add_global_attrbutes,.sp L Linkb
' Search eb a- 1i O MyVahool [ Games 1 Personals ,LAUNCH -

MAP EXPORTED ATTRIBUTES


Country Attribute Name
Belize passportnum
Dominican Republic docviajenumero


Enter Internal Attribute Name passportno



|Map |Back lNeF1]








Done S Internet

Figure 5-5. Mapping page for exported attributes









When the user adds an attribute to the global schema, the global schema files are

created at the host site and they get updated every time a new attribute is added. The

generated global schema files are forminfo.txt, parserARRIVAL-DEPARTURE.met,

parserARRIVAL-DEPARTUREsp.met and mapCountryname.txt. A separate

mapCountryname.txt file is created for each of the participating countries.

The dummy.jsp page: Once the user has added all the attributes from the exported

schemas to the global schema for the selected category, he can save the schema. This JSP

contains the code for generating and storing the global schema files at the host site and

sending them to the local sites, where the files are stored for use by the Global Search

Form. The files are sent to the local site by invoking the GlobalSchema Web Service at

the local site. The WriteGlobalSchema.java file present at the host site acts as a Web

Service client of the GlobalSchema Web service. The writeSchema method of this Web

Service will write the global schema files at the local sites.

5.3 Distributed Query Processor

5.3.1 Global Query Processing Component (GQPC)

The CreateGlobalForm.jsp/ CreateGlobalFormsp.jsp page: This JSP will

generate the Global Search Form using the global schema files, mapCountryname.txt and

formjnfo.txt (Section 4.1.1). The page is displayed to the user in English or Spanish

language based on the user profile information stored in the tomcat-users.xml file. Figure

4-2 shows a sample Global Search Form at the Belize site. This form is used to issue the

queries in English language.

The query.jsp page: This file is responsible for query generation based on the

attributes selected by the user on the Global Search Form and the display of query results.

The query is generated in XML format (Figure 5-6) and it is created using the internal









names of the attributes and attribute values. A separate sub-query is generated for each of

the local sites that are queried by the user. The sub-query includes only those attributes

that are present in the local database of the country to which the sub-query is being sent.

The user's ROLE information and the country name being queried are also included in

the XML query file. This JSP acts as an AxisClient for the Web Service present at the

Local Query Processing component of the local site (LQP). The Web Service information

is stored in the country_infol.txt (Section 4.1.2) file.

The JSP parses the Individual-Result.xml (Figure 5-7) file of each country to which

a sub-query was issued. The internal attribute names in the sub-query result are mapped

to the local attribute names on the Global Search Form before displaying the result to the

user. The results retrieved from the individual sites for the sub-queries involving

aggregate functions such as count, sum, max, min, and average will be combined on this

form.







]>

roleAsuper
Belize
avg(visitno)

purpose-of-trip
=
BUSINES S




Figure 5-6. Sample XML query







46





BELIZE


avg(visitno)
3.2500




Figure 5-7. Sample XML result


File Edit View Favorites Tools Help
e)Back _1 [x ^ ,;| ^)5^h -'-S 4 fJp, S e ;j
Address | htL p l28.227.176.39:8080UQPjquery.jsp ] Go Links "
|[SearchVWeb I-IE [- | Mal MyYahoo I Games Personals LAUNCH -5ignn

QUERY RESULTS


BELIZE
MAIN.PASSPORTNUMMAIN.LNAMEMAIN.FNAMEMAIN.GENDERMAIN.ENTRYDATE
S 15804022 CHANG LAURA FEMALE 2003-05-10
S 829095 GONZALEZ KATHY FEMALE 2003-01-15
S A943574 SUTO REYNA FEMALE 2004-05-10
S 2210201 WILLIS CHRISTY FEMALE 2004-06-15

DOMINICAN REPUBLIC
MAIN.PASSPORTNUMIMAIN.LNAME MAIN.FNAME MAIN.GENDER MAIN.ENTRYDATE
S A943574 SMITH AMEE FEMALE 2003-04-04
S 22102010 LOPEZ DELFINA FEMALE 2003-06-15
F 4017790 RAMIREZ SHENNY FEMALE 2003-03-10
S 244716 CRUZ CLAUDIA FEMALE 2003-11-18
i 36102010 CASTILLO ALEXANDRA FEMALE 2004-07-02
S 2517790 SMITH TINA FEMALE 2004-03-25
S A943574 SMITH AMEE FEMALE 2003-04-04
S 22102010 LOPEZ DELFINA FEMALE 2003-06-15
S 4017790 RAMIREZ SHENNY FEMALE 2003-03-10
I )IAA71c I P I 17 rP Al 1fi A I IFtAAI I n 'lAt -11_1 j
U, "

Figure 5-8. Query results displayed at the Belize site

5.3.2 Local Query Processing Component (LQPC)

The LQPC is deployed as a Web Service at each of the participating countries. This

Web Service will be invoked by the query.jsp file, which acts as the Web Service client.









The classes that comprise the LQP components at the Belize site are described below.

Similar files are present at the local site of each participating country.

The belizeserver.java file: The belizeinterface method in this file is invoked by

the Web Service client of the LQPC. The method in turn invokes the belizespecxml file

by passing the XML query string to it.

The belizespecxml.java file: The checkAccess method in this file checks the

access control of the user to each attribute in the XML query string. The buildSQL

method will generate the SQL query from the XML query string, and the createXML

method will execute the SQL query on the local database. The createXML method also

converts the SQL query results to XML format before sending them back to the GQP

(Axisclient).

The translation system explained in Section 4.2.2 is invoked to translate the values,

if any, in the comments field before issuing the query to the database. The value in the

comments field will be translated only if it is not in the local language of the user, which

is decided by the role of the logged-in user. The translator is also invoked on the values

retrieved by the comments attribute in the query result subject to the constraint that the

result is not in the local language of the user.

The belizemapattr.java file: This file is used to generate the mappings for the

attribute values in the database. The map tables are implemented as hash tables. These

mappings will be used while building the SQL query from the XML query string and also

while converting the result into the XML format.

5.4 Watch-List Scenario

This scenario depicts the events that occur when a person arrives in a country and

the agent at the border station fills a form to record the person's arrival information. It is











also an example, which describes the Event registration, subscription, and notification


capability of the ETR Server. The files used in the implementation of this scenario are


explained below.


The AuthorizePpl.jsp page: This JSP (Figure 5-9) is used to create a list of


authorized agents and to mark some of these agents as 'under suspicion'. The user of this


system is a supervisor, and the list of the agents not 'under suspicion' is stored in the


"AuthorizedPpl.txt" file.


FRl I EJi, Vi, Fie 111tet 5 T.-o ip P

Address http:I 128.227.1 76.40:80 8C/superluthorIPpli. p Go Links
C Sear hWeb -5E5- | Mail *My Yahoo' I Games S Personals LAUNCH -1gnIn J
Agentes Autorizados a Ver la Lista de Sospechosos



Nombres de los Agentes
suwerdr
|Userl
d rector

Chck en el nombre del agent para borrarlo I


S Aada a un agent por nombre










SDone Internet


Figure 5-9. Create authorized agents' list page

The ArrivalDR.jsp page: An agent at the border station will fill this form


(Figure 5-10) when a person enters the country. When this form is submitted, the


ArrivalServlet is invoked and the port-of-entry (PEntry) event gets posted. The event will


trigger the WatchListCheckRule to check if the person (traveler) entering the country is








49



in the watch-list. This checking is done by comparing the traveler's last name, first name,


and nationality with the values stored in the watch-list. If the traveler is in the watch-list


and the agent is not 'under suspicion', then he/she is shown the alert message, which says


"Traveler is in the watch list". If the agent decides to allow the traveler to enter the


country, then the traveler's record is inserted into the database. If the agent is marked as


'under suspicion', he/she will not be shown the alert message by the system and the


traveler will be directly allowed to enter the country, and his/her record will be inserted


into the database.


'3 Numrol edla icrosft u ntrnel xplorr Q E)


File Edit Vew Favorites Tools Help
oaock. _., ] j i 5....ch t-"- y... 5- _:__
Addres g http:/p128.227. 176.40:80801memrrA iva DR.. p .
S- [searchWeb M- | Mail myV ahoo' LJGames SPersonals LAJUNCH -[ 3gn I-


Go Linkks


REGISTRO DE LLEGADA ^


Noarnhr e ompieio
Apelldos Domnguez Nombres

Fech Nacrento 197-03-02 Sexo
&yy mm dd)
CludadNacimento |SantoDomingo i PatsNacimiento

Ocupacon Actores EstadoCvil

la d'ecciors permriaer Le
Calle church drive No
CludadP araje chcago ProvmcaEstado

PuertoEmbarque bosion NumeroVuelo

DocViajeNumero B6571234 NumeroCedula

ComentanoGeneral parei nervioso
777 r


Juliana

Ev
IUSA ^ Nacionahdad Dominican Republic v




208 ]
illnois Pass [Do mincani Republic v

A4707 MotivoViaje [Re re

1023


Figure 5-10. Arrival form at the port of entry in a Dominican Republic border station


5.5 Translation System


The translation by table lookup was explained in Section 4.2.2. This type of


translation is used to convert the internal query attribute names into local database









attribute names so that it can be executed on the local database. We also use the language

translation system for natural language translations.

The translator.java file: This file is used to invoke the machine translation system

developed at the Carnegie Mellon University (CMU) and acts as the Web Service client

of the service interface provided by CMU. The translate method of the Web Service is

invoked for getting the translated result. This method takes two parameters, the actual

string to be translated and the language into which the string should be translated. For

example, translate ("nervous", "sp") means that the word "nervous" should be translated

into the Spanish language. The Web Service sends the translated result back to the client.

5.6 Conversational Interface System

The conversational interface developed at the University of Colorado uses our

Distributed Query Processor for issuing queries to the databases of the participating

countries and retrieving the query results. The conversational interface translates the

natural language query into an XML query string similar to the one generated by the

Global Search Form. This interface then invokes the GlobalQuery Web Service deployed

at the host site. The Web Service will invoke the Global Query Processing component of

all the sites, which are being queried by the conversational interface. Once the query

reaches the GQPC, it is processed in the same way as the query generated by the Global

Search Form. The XML query results are sent back by the GlobalQuery Web Service to

the Web Service client (i.e., the conversational interface system).














CHAPTER 6
TECHNOLOGIES USED

We have installed our system on the Windows NT platform and it is implemented

using JDK 1.4.2_04. The Web server used is Tomcat 4.1.18 and Apache Axis 1.0 toolkit

is used to define, deploy, and invoke Web Services. The database management system

used as the local database management system is MySQL. In this chapter, we describe

the technologies used to implement the following tools and functionalities of the

prototype system: tool for defining export schemas, tool for integrating exported

schemas, distributed query processing system for accessing data from distributed,

heterogeneous databases, and event-trigger-rule processing system for implementing a

Watch-list scenario. Section 6.1 describes the ETR technology and its various

components. Section 6.2 describes Java related technologies, and Section 6.3 discusses

the XML related technologies. Section 6.4 and Section 6.5 explain the Web Services

infrastructure and SOAP, respectively. We explain how Apache Axis toolkit is used for

deploying the Web Services in Section 6.6. Our prototype system uses the MySQL

database management system, which is described in Section 6.7.

6.1 The Events, Triggers, and Rules (ETR) Technology

The ETR technology is a part of the Knowledge Web Server [2]. The ETR's event-

trigger-rule service is used in the implementation of the Watch-list scenario (Section 4.3).

The Knowledge Web Server extends the capability of the current Web servers. Each

Knowledge Web Server has a replica of an Event Manager, an ETR Server, and a

Knowledge Profile Manager, which are the additional components installed on each Web









server. Replicas of the Event Manager exchange events and transfer data associated with

the events (i.e., event data) between them.

6.1.1 Events, Triggers, and Rules

Any item of interest can be modeled as an event. For instance, entering a traveler's

information into the arrival form at a border station by an immigration agent can be

considered as an event. A rule consists of a condition clause, an action clause, and

optionally, an alternative action clause. When an event is posted, if the condition clause

associated with the rule evaluates to True, the action clause is executed. Otherwise, some

alternative action is performed. Triggers are used to associate events with rules. A trigger

specifies that, upon the occurrence of any one of a number of events, an optional

expression of occurred events (i.e., an event history) should be evaluated. If the event

history is evaluated to True or if the optional expression is not given, a single rule or a

structure of rules should be processed. The trigger specification maps event attributes to

rule parameters so that run-time event data can be passed to a rules) for its (their)

evaluation.

6.1.2 Event Manager

Legitimate clients can subscribe to published events. They can also specify event

filters, which contain some data conditions associated with events. If the data conditions

match with the data associated with the occurrence of an event, subscribers want to be

notified. The Event Manager is responsible for sending and receiving events and for

performing event filtering before sending out the event data, to those subscribers whose

filtering conditions are satisfied. When the Event Manager receives an event from a

remote web server, it passes the event and event data to the local ETR Server to initiate

the processing of triggers and rules.









6.1.3 The ETR Server

The ETR Server receives events and event data from the local Event Manager, and

performs trigger and rule processing. On receiving an event, the ETR Server identifies

the trigger related to the event, processes the event history, and executes the ruless.

6.1.4 Knowledge Profile Manager (KPM)

Each user of the transnational information system has a knowledge profile that is

maintained by the Knowledge Profile Manager [6]. A knowledge profile includes the

events that the user has subscribed to, the event filters associated with the subscribed

events, and the triggers and rules that have been defined on the subscribed events. A

Meta-data Manager within the KPM provides persistence for storing the user knowledge

profiles.

6.1.5 Persistent Object Manager (POM)

POM [7] consists of two main components.

* Object-Relational mapping engine
* XML-Relational mapping engine

The Object-Relational mapping engine provides a persistent storage facility and a

high level interface in the form of APIs for programs to store, retrieve, update, and delete

objects without having to know the internal data structures of the objects. The XML-

Relational mapping engine provides the persistence capability and a filtering mechanism

to the Event Server. POM is implemented on top of an Object-Relational database system

called Cloudscape.









6.2 The Java Technologies

6.2.1 Java Servlet Technology

Servlets [8] are the Java platform technology of choice for extending and enhancing

Web servers. Building a Web page on the fly is useful for a number of reasons.

* The Web page is based on data submitted by the user
* The data changes frequently
* The Web page uses information from corporate databases or other such sources

Servlets provide a component-based, platform-independent method for building

Web-based applications, without the performance limitations of CGI programs. Unlike

proprietary server extension mechanisms (such as the Netscape Server API or Apache

modules), servlets are server and platform-independent.

Servlets have access to the entire family of Java APIs, including the JDBC API to

access enterprise databases. They can also access a library of HTTP-specific calls and

receive all the benefits of the Java language, including portability, performance,

reusability, and crash protection.

6.2.2 Java Server Pages (JSP) Technology

JSP technology [9] enables Web developers and designers to rapidly develop and

easily maintain, information-rich, dynamic Web pages that leverage existing business

systems. As part of the Java technology family, JSP technology enables rapid

development of Web-based applications that are platform independent. It separates the

user interface from content generation, enabling designers to change the overall page

layout without altering the underlying dynamic content.

JSP is an extension of the servlet technology created to support authoring of HTML

and XML (Section 6.3.1) pages. It uses XML-like tags that encapsulate the logic that

generates the content for the page. The application logic can reside in server-based









resources (such as JavaBeans component architecture) that the page accesses with these

tags. Any and all formatting (HTML or XML) tags are passed directly back to the

response page. By separating the page logic from its design and display, and supporting a

reusable component-based design, JSP technology makes it faster and easier than ever to

build Web-based applications.

6.2.3 Tomcat

Tomcat 4 [10] implements the Servlet 6.3 and Java Server Pages 1.2 specifications

from Java Software, and includes many additional features that make it a useful platform

for developing and deploying Web applications and Web Services.

6.3 The XML-Related Technologies

6.3.1 Extensible Markup Language (XML)

XML [11] is a simple, very flexible text format derived from SGML (ISO 8879).

Originally designed to meet the challenges of large-scale electronic publishing, XML is

also playing an increasingly important role in the exchange of a wide variety of data on

the Web and elsewhere.

* XML stands for EXtensible Markup Language
* XML was designed to describe data
* XML tags are not predefined. One must define his/her own tags
* XML uses Document Type Definition (DTD) or XML Schema to describe the data
* XML can be used to exchange data between incompatible systems
* XML can also be used to store data in files or in databases

6.3.2 Xerces: XML Parsers in Java

Xerces [12] provides world-class XML parsing and generation. It offers fully

validating parsers for Java, implementing the W3C XML and DOM (Level 1 and 2)

standards, as well as the de facto SAX (version 2) standard. The parsers are highly

modular and configurable. Initial support for XML Schema is also provided by Xerces.









6.4 Web Services

The World Wide Web is increasingly used for application-to-application

communication. The programmatic interfaces made available are referred to as Web

Services [13]. Web Services provide a standard means of interoperating between different

software applications, running on a variety of platforms and/or frameworks.

A Web Service is a software system designed to support interoperable machine-to-

machine interaction over a network. It has an interface described in a machine-

processable format (specifically, WSDL). Other systems interact with the Web Service in

a manner prescribed by its description using SOAP messages, typically conveyed using

HTTP with an XML serialization in conjunction with other Web-related standards. Thus,

Web Services are Web-based enterprise applications that use open, XML-based

standards, and transport protocols to exchange data with calling clients.

6.5 Simple Object Access Protocol (SOAP)

SOAP [14] provides a simple and lightweight mechanism for exchanging

structured and typed information between peers in a decentralized, distributed

environment using XML. SOAP does not itself define any application semantics such as

a programming model or implementation specific semantics; rather it defines a simple

mechanism for expressing application semantics by providing a modular packaging

model and encoding mechanisms for encoding data within modules. This allows SOAP to

be used in a large variety of systems ranging from messaging systems to RPC. SOAP can

potentially be used in combination with a variety of other protocols. SOAP consists of

three parts.

* The SOAP envelope construct defines an overall framework for expressing what is
in a message; who should deal with it, and whether it is optional or mandatory









* The SOAP encoding rules define a serialization mechanism that can be used to
exchange instances of application-defined data types

* The SOAP RPC representation defines a convention that can be used to represent
remote procedure calls and responses

6.6 Apache Axis

Axis [15] is essentially a SOAP engine: a framework for constructing SOAP

processors such as clients, servers, gateways. The current version of Axis is written in

Java and a C++ implementation of the client side of Axis is also being developed. Axis is

not just a SOAP engine, it also includes

* A simple stand-alone server
* A server which plugs into servlet engines such as Tomcat
* Extensive support for the Web Service Description Language (WSDL)
* Emitter tooling that generates Java classes from WSDL
* Some sample programs, and
* A tool for monitoring TCP/IP packets

Axis is the third generation of Apache SOAP (which began at IBM as "SOAP4J").

In late 2000, the committees of Apache SOAP v2 began discussing how to make the

engine much more flexible, configurable, and able to handle both SOAP and the

upcoming XML Protocol specification from the W3C.

6.7 The MySQL Database

MySQL [16] has become the most popular open source database and the fastest

growing database in the industry. This is based on its dedication to providing a less

complicated solution suitable for widespread application deployment.

MySQL offers several key advantages.

* Reliability and performance: MySQL AB provides early versions of all its
database server software to the community to allow for several months of "battle
testing" by the open source community before it deems them ready for production
use






58


* Ease of use and deployment: MySQL's architecture makes it extremely fast and
easy to customize. Its unique multi-storage engine architecture gives corporate
customers the flexibility they need with a database management system unmatched
in speed, compactness, stability, and ease of deployment

* Freedom from platform lock-in: By providing ready access to source code,
MySQL's approach ensures freedom, thereby preventing lock-in to a single
company or platform

* Cross-platform support: MySQL is available on more than twenty different
platforms including major Linux distributions, Mac OS X, UNIX, and Microsoft
Windows













CHAPTER 7
PERFORMANCE EVALUATION

In this chapter we analyze the performance of our system. Section 7.1 gives an

evaluation of the queries processed by the Distributed Query Processor, Section 7.2

presents the system performance during schema exportation and integration, and Section

7.3 describes the performance of the rule-processing and event notification in the Watch-

List scenario.

7.1 Query Performance

7.1.1 Simple Queries

Here we give the time required to fetch the result of each of the sample queries

from the local databases of the participating sites using our DQP system. The relations in

the local database of Belize contain sixty records and those in the local database of the

Dominican Republic contain seventy records.

1. Fetch the passport numbers and names of all the females who arrived in the country
after Jan 1, 2003.

Number of sites to be queried: (2)
This query fetches results from both Belize and Dominican Republic
Number of where clause conditions: (2)
gender = 'female' and entry-date = '2003-01-01'
Execution time: 3 seconds

2. Fetch the passport numbers, names, nationality and purpose of trips of all the
people whose nationality was USA or Belize and who had come for business.

Number of sites to be queried: (2)
This query fetches results from both Belize and the Dominican Republic and
is an example of a query in disjunctive normal form
Number of where clause conditions: (3)
nationality = 'USA' and purpose of trip = 'business' or nationality = 'Belize'
and purpose of trip = 'business'









Execution time: 3 seconds

3. Get the passport number, name, date of entry, port of embarkation city and port of
disembarkation city of all the people who entered the country after Jan 1, 2003 and
whose port of embarkation city is Boston and port of disembarkation city is Belize
City.

Number of sites to be queried: (1)
This query fetches results only from Belize database but it can be issued from
Belize or Dominican Republic site
Number of where clause conditions: (3)
date of entry = '2003-01-01', port of embarkation city = 'Boston' and port of
disembarkation city = 'Belize City'
Execution time: 2 seconds

7.1.2 Aggregate and Join Queries

This section describes the times taken to process queries with aggregate functions
and join queries.
1. Give the most recent date when a person of US nationality arrived in the country on
business.
Number of sites to be queried: (2)
This aggregate query fetches max (date of entry) from the local databases of
Belize and Dominican Republic and then combines the results before
displaying them to the user
Number of where clause conditions: (2)
nationality = 'USA' and purpose of trip = 'business'
Execution time: 1 second

2. Give the passport numbers and names of all the people who were staying in a
guesthouse.

Number of sites to be queried: (1)
This join query is issued only to the Belize database and it does a join of two
database tables 'MAIN' and 'TOUR'
Number of where clause conditions: (2)
lodging = 'guesthouse' and tour.passportnum = 'main.passportnum'
Execution time: 2 seconds









7.1.3 Queries Invoking the Translator

1. Give the passport numbers and names of all the males who appeared nervous.
Number of sites to be queried: (2)
This query is issued to the Belize and Dominican Republic databases from
the Belize site. Here CMU's translator module is invoked to translate
'nervous' to Spanish language before processing the query at the Dominican
Republic site and again to translate the results retrieved from the Dominican
database into English before being displayed to the user.
Number of where clause conditions: (2)
comments = 'nervous' and gender = "male"
Execution time: 4 seconds

7.2 Performance of Export Schema and Schema Integration Tools

7.2.1 Export Schema Tool

The system takes approximately one second to export a schema from a local site.

The time taken involves the time to invoke the Web Service at the host site, where the

schema will be exported and stored.

7.2.2. Schema Integration Tool

The tool takes approximately two seconds to integrate the exported schemas in

order to generate the global schema. This includes the time to invoke the Web Service at

each of the local sites and to save the global schema files at the local sites.

7.3 Performance of Rule Processing and Event Notification

The Watch-List scenario takes about 2 to 3 seconds to post the arrival event, trigger

the WatchListCheck rule to find if the traveler entering the country exists in the watch-

list, to check if the agent on duty is 'under suspicion', and then to show the alert message

to the agent if traveler is in watch-list and agent is not 'under suspicion'. Although, this

scenario also involves sending the email and cell phone notifications to the subscribers of

this event, the specified time does not include the time for event notification because it

will depend on the number of event subscribers.














CHAPTER 8
CONCLUSIONS AND FUTURE WORK

This chapter summarizes the contents of this thesis, its contributions and discusses

the scope of future work. Through the various chapters in this thesis, we have established

and confirmed the need for a transnational information system. The developed prototype

system is the product of integrating a number of component systems: the Export Schema

Tool, the Schema Integration Tool, the Distributed Query Processor system, the

Language Translation system, the Conversational Interface system, and the Event-

Trigger-Rule Server. With these system components in place, we have provided the

means for integrating and sharing information, querying the heterogeneous databases

using a form-based interface or a conversational interface, applying translations where

necessary, and enforcing rules and regulations. The heterogeneous system components

are made interoperable by using the Web Service technology.

The main contribution of this thesis is the design and implementation of the tool for

exporting the schemas from any of the participating countries, the tool for integrating

these exported schemas to generate the global schema, the module to create the

authorized agents list, the enhanced Distributed Query Processor which can

accommodate schema changes made to the local databases, and handle queries that

contain aggregate functions and join operations over database tables. The export schema

component allows the countries to export their local database entities and attributes, and

also to modify the exported schemas whenever there is a change to the local database

schema. The modified exported schema can again be integrated with the schemas









exported by other countries to generate the global schema. The Distributed Query

Processor is able to incorporate the new global schema without making any code

changes. Our prototype system is built for immigration and remote border control

applications. However, it is designed and implemented in a general way that it can be

used for other application domains such as agriculture inspection and protection, disease

control, and can be used by a larger number of participating countries.

There are some interesting features, which can be added, and some issues that can

be further investigated to extend the functionality of the transnational digital government

system. The Distributed Query Processor presently handles the join operation over

relations (data entities) belonging to a single site. It can be enhanced to handle the join

operation over data entities stored in multiple sites. Secondly, event notification is

presently done by uni-casting; i.e., the subscriber information for an event is stored at the

event publisher's knowledge web server. When an event occurs, the notification is sent to

each subscriber one-at-a-time, which can be very time consuming. A more efficient

approach is to distribute the subscribers' information to the knowledge web servers of

different countries or agencies to which the subscribers belong. When an event occurs,

the Event Server at the event-posting site can use multi-casting to send notifications to

the Event Servers of all the event subscriber sites. These Event Servers can then send

notifications to their local subscribers in parallel.

We need to identify other transnational digital government problems that can be

solved using the information technologies developed by the various research groups. The

system should be expanded to cover multiple countries and languages, and means have to

be established for field-testing and evaluation of the final system.















LIST OF REFERENCES


1. Su, S., Fortes, J., Kasad, T.R., Patil, M., Matsunaga, A., Tsugawa, M., Cavalli-
Sforza, V., Carbonell, J., Jansen, P., Ward, W., Cole, R., Towsley, D., Chen, W.,
Anton, A.I., He, Q., McSweeney, C., deBrens, L., Ventura, J., Taveras, P.,
Connolly, R., Ortega, C., Pineres, B., Brooks, O., Herrera, M., "A Prototype
System for Transnational Information Sharing and Process Coordination,"
Proceedings of the dg.o2004, Seattle, Washington, May 24-26, 2004.

2. Lee, M., "Event and Rule Services for Achieving a Web-based Knowledge
Network," PhD Dissertation, Department of Computer and Information Science
and Engineering, University of Florida, Gainesville, Florida, 2000.

3. Kasad, T., "Transnational Information Sharing and Event Notification," Master
Thesis, Department of Computer and Information Science and Engineering,
University of Florida, Gainesville, Florida, 2003.

4. "Tomcat User Authentication," Jan 2004, Available from URL:
http://www.possibility.com/epowiki/Wiki.j sp?page=TomcatUserAuthentication.
Accessed on: Feb 2004.

5. Sun Microsystems, "Using Login Authentication," 2003, Available from URL:
http://java.sun.com/webservices/docs/1.3/tutorial/doc/Security5.html. Accessed on:
Oct 2003.

6. Parui, U., "Knowledge Profile Manager for Supporting Event-trigger-rule Services
on the Internet," Master's Thesis, Department of Computer and Information
Science and Engineering, University of Florida, Gainesville, Florida, 1999.

7. Shenoy, A., "A Persistent Object Manager for Java Applications," Master's Thesis,
Department of Computer and Information Science and Engineering, University of
Florida, Gainesville, Florida, 2001.

8. Sun Microsystems, "Java Servlet Technology Overview," 2003, Available from
URL: http://java.sun.com/products/servlet/overview.html. Accessed on: Sep 2003.

9. Sun Microsystems, "Java Server Pages Overview," 2003, Available from URL:
http://java.sun.com/products/jsp/overview.html. Accessed on: Sep 2003.

10. The Apache Jakarta Project, "The Tomcat 4 Servlet/JSP Container," 2002,
Available from URL: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/index.html.
Accessed on: Oct 2003.









11. W3C Architecture Domain, "Extensible Markup Language (XML)," 2004,
Available from URL: http://www.w3.org/XML/. Accessed on: Jan 2004.

12. The Apache XML Project, "Xerces: XML parsers in Java and C++," 2002,
Available from URL: http://xml.apache.org/#xerces. Accessed on: Jan 2004.

13. W3C Working Group, "Web Services Architecture," Feb 2004, Available from
URL: http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/. Accessed on: Mar
2004.

14. W3C, "Simple Object Access Protocol (SOAP)," Jun 2003, Available from URL:
http://www.w3.org/TR/soap/. Accessed on: Feb 2004.

15. The Apache Software Foundation, "Axis User's Guide," Jun 2003, Available from
URL: http://ws.apache.org/axis/java/user-guide.html. Accessed on: Nov 2003.

16. MySQL Developer Zone, "MySQL Reference Manual," 2003, Available from
URL: http://dev.mysql.com/doc/mysql/en/index.html. Accessed on: Oct 2003.















BIOGRAPHICAL SKETCH

Manjiri Patil was born on August 11th, 1978, in Pune, Maharashtra, India. She

received a Bachelor of Engineering degree in computer engineering (securing first class

with honors), from the Maharashtra Institute of Technology, Pune, India, in May 2000.

After graduation she worked with Satyam Computer Services Limited (Pune, India), as a

Software Engineer.

In August 2002, she joined the University of Florida (Gainesville, Florida), to

pursue Master of Science degree in computer and information science and engineering.

She worked as a Teaching Assistant and a Research Assistant, during her studies at the

University of Florida. Her research interests include databases and the Web Services

technology.